網站維護費用包含什麼：合約型態、SLA 與轉移須知
網站上線那天不是專案的終點，而是另一種支出的起點。
多數企業主在看建置合約時很仔細，卻在「維護」兩個字上一筆帶過，直到某天網站打不開、或收到一筆沒預期的帳單，才開始追問：這筆錢到底買了什麼？這篇不談數字，談的是維護的實際內容、合約的常見樣貌，以及你在簽約前該問清楚的事。
維護費用買的到底是什麼
「網站維護」是一個籠統的詞，底下至少混了七類性質完全不同的工作。
主機與網域：網域名稱就是你的網址，每年要續約，忘記續約網站會直接消失；主機或雲端服務則是存放網站檔案與資料的地方，依規格與流量計費。這兩項屬於租金性質，不論你有沒有更新內容都會持續發生。
SSL 憑證：讓網址顯示鎖頭、資料傳輸加密的憑證。多數雲端方案已內含並自動更新，但仍要確認到期時由誰負責。
備份：定期把網站檔案與資料庫複製留存。重點不在「有沒有備份」，而在頻率、保留份數，以及有沒有實際演練過還原。沒還原過的備份不算備份。
套件與系統更新：網站底下的框架、外掛與函式庫會持續改版。長期不更新，等於把已經公開的漏洞留在門口。
資安修補：更新以外的主動處理，例如漏洞通報後的緊急修補、異常流量阻擋、被入侵後的清理與復原。
內容更新：改文案、換圖、上架新產品、發布消息。這一類最常被雙方各自假設是對方的責任。
緊急處理：網站掛掉、金流失效、表單收不到信。這類服務的價值不在工時，而在出事時有人接得到電話。
把七項攤開就會發現，它們的計費邏輯完全不同：前三項接近固定成本，中間兩項是技術工時，後兩項取決於你的使用頻率。合約若只寫「維護費一式」，等於把七件事混成一筆看不懂的錢。
一次性建置費與持續性費用的分界
爭議幾乎都發生在這條線上。判斷原則其實只有一句話：讓網站維持在「當初驗收時的樣子」是維護；讓網站變成「它原本沒有的樣子」是新專案。
依這條線推下去：修正原本就該正常運作卻失效的功能，屬於保固或維護；文字與圖片的替換，多數會列在維護的內容更新額度內；但新增一個原本沒有的頁型、串接一個新的外部服務、或改變商業流程，就是新的開發需求。
實務上真正該在合約寫明的是模糊地帶：既有頁面的版面調整算不算、每月的更新額度怎麼計算（次數、時數還是件數）、額度沒用完能不能累積、超出後如何計價。這些寫清楚，日後就不需要每次都重新談判。成本結構的完整拆解可以參考網站製作費用怎麼算。
三種常見的維護合約型態
按月或按年的包月制：固定支付，換到約定範圍內的服務與一定額度的調整。優點是預算可預期、廠商有動機把系統維持穩定；缺點是更新需求很少時會覺得付了用不到。適合網站承載實際業務、或內容需要定期更新的企業。NETVANA 的軟體開發流程把維護列為第五階段，提供的就是月費制的技術支援方案，包含效能監控、定期備份與安全更新。
按次計費：有需求才發工單，依工時或件數結算。優點是不用養固定費用；缺點是沒有人主動盯著你的系統，安全性更新往往被遺漏，緊急狀況也不保證有人力。適合純形象、極少更新，且已另外確保基礎維運的網站。
混合制：基礎維運（主機、備份、安全性更新、監控）包月，內容與功能調整按次或按時數另計。這是實務上最常見、也最容易把責任講清楚的作法。
選哪一種的關鍵不是省錢，而是問自己：網站壞掉一天，我的業務損失多少？ 損失明顯的，就不該把基礎維運放在按次計費。
SLA 要看哪三件事
SLA 是服務水準協議，作用是把「我們會盡快處理」翻譯成可以檢驗的承諾。
一、回應時間，而且要分級。 全站無法使用、金流失效這類事故，和「這張圖想換掉」不該適用同一個時限。合約至少要分成緊急與一般兩級，並寫明各自的回應時間。要注意回應時間不等於修復時間，多數合約承諾的是前者，這很合理，但你要知道差別。
二、服務時間。 是上班日的辦公時間，還是含假日？電商在連假檔期出事的機率最高，如果你的營收集中在特定時段，這條要特別談。
三、可用性與備援。 備份頻率、保留份數、還原所需時間、有沒有測試環境可以先驗證再上線。承諾很高的可用性數字通常伴隨較高的架構成本，重點是這個數字有沒有對應的備援設計，而不是數字本身好不好看。
此外也要問：通報管道是什麼？ 只靠單一窗口的個人通訊軟體，在那個人請假時就會斷線。
沒有維護合約會發生什麼
不會立刻壞掉，這正是危險的地方。典型的順序是這樣：
前半年一切正常，因為系統還新。接著套件開始出現安全性更新通知，沒有人處理。再過一段時間，網域或憑證到期，沒人收到提醒。某天網站顯示錯誤或被瀏覽器標示為不安全，你才回頭找當初的廠商，卻發現對方人力已經排給別的專案，或聯絡不上。
這時候的成本不只是修復，而是要先有人讀懂這套系統。接手一套沒有文件、沒有維護紀錄的網站，前期幾乎都要花額外時間做技術盤點。同樣的道理也適用在更大的系統上，狀況更嚴重時就會變成舊系統現代化的議題。
更換廠商時，你應該拿回什麼
決定換人時才開始談移交，籌碼是最少的。正確的作法是在最初的開發合約就把交付清單寫進去，至少涵蓋：
- 網域名稱的註冊商帳號或移轉授權
- 主機、雲端服務的帳號與管理權限
- 完整原始碼與資料庫備份
- 部署與環境設定文件（新廠商靠它重建環境）
- 設計原始檔
- 第三方服務帳號：金流、電子報、分析工具、地圖、客服系統
- 現行的排程工作與監控設定清單
NETVANA 的作法是專案費用結清後，原始碼、設計檔與文件完整移交，維護合作與程式碼歸屬是分開的兩件事——這也是評估廠商時值得確認的重點，更完整的檢查方式見如何挑選軟體開發公司。
移交時還有一件常被忽略的事：不要在移交當天才第一次測試新環境。合理的節奏是新廠商先在測試環境完整重建、比對無誤後再切換網址，避免搜尋排名與既有連結受影響，相關步驟可參考網站改版 SEO 檢查清單。
常見爭議：這件事到底算不算維護
以下幾個情境幾乎每份合約都會遇到，事前說清楚就不會變成爭執：
「網站被駭要不要另外收費？」 取決於原因。若是因為廠商未依約執行安全性更新而導致，通常屬於維護範圍；若是你方人員的帳號密碼外流、或使用了合約範圍外自行安裝的外掛，責任歸屬就不同。合約應該寫明維護涵蓋的是哪些層面的安全工作。
「我自己改壞了怎麼算？」 如果你有後台編輯權限，就會有改壞的可能。合理的約定是保留還原服務，但計費方式另計，並確保備份頻率足以支撐還原。
「第三方服務漲價或停止服務怎麼辦？」 金流、地圖、電子報這類外部服務的價格與規格不在廠商控制範圍內。合約要處理的是「發生時由誰評估替代方案、更換的工時怎麼計算」。
「網站變慢算不算故障？」 建議把可量測的效能指標列入監控項目，並約定超出範圍時的處理流程，而不是等到有人抱怨才討論。
「要新增一個頁面，可以用額度嗎？」 這是最常見的模糊地帶。把「內容更新」與「新增頁型」的界線寫成具體例子，比寫抽象定義有效得多。
簽維護合約前的檢查清單
- 七類工作中，哪些含、哪些不含，逐項列出
- 每月調整額度的計算單位與是否可累積
- 緊急與一般問題的分級定義與回應時間
- 服務時間是否涵蓋假日
- 備份頻率、保留份數、還原演練
- 監控項目與通知方式（誰會先知道網站掛了）
- 定期報告的內容與頻率
- 合約終止時的移交程序與期限
- 帳號與原始碼的歸屬（不因終止維護而改變）
以上為一般性原則整理，實際條文建議請律師協助確認。
維護費用會讓人不舒服，通常不是因為金額，而是因為看不出買到什麼。當七類工作被拆開、責任被寫清楚、SLA 有具體條件，這筆支出就從「說不清楚的月費」變成可以評估的風險管理。
如果你正在檢視手上的維護合約、或準備把網站移交給新的合作對象，與 NETVANA 討論你的需求。軟體服務採先諮詢再報價，各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：想了解建置階段的成本結構，見網站製作費用怎麼算；準備更換廠商或改版，見網站改版 SEO 檢查清單；系統之間要互相串接時的注意事項，見系統整合與 API 串接開發指南；維護範圍會因為主機方案不同而改變，可以看網站主機怎麼選指南；合約最該寫明的一段，是資安事故誰負責，可以看企業網站資安基本功；多一種語言就多一份長期維護成本，可以看多語系網站開發指南；維護到什麼程度該改版，有幾個明確訊號，可以看網站改版怎麼進行；維護合約談好之後，問題來了該怎麼回報，可以看怎麼跟開發廠商回報問題；備份該寫進合約的條款可以對照這篇確認，可以看網站備份與災難復原指南。
