「架網站費用多少」如果只問一次性建置總價，常會漏掉網站上線後真正要持續負責的工作。網域要續用、主機和第三方服務要有人管理、內容要更新、問題要被發現，團隊成員也會更換。這些不一定都由外包公司收費，卻都會占用預算或內部工時。
比較報價前，建議把費用改分成三個桶：首次建置、每年持有、事件性支出。首次建置包含需求、設計、開發、內容搬移與上線；每年持有包含網域、託管、監測、例行更新與支援；事件性支出則是改版、資料移轉、緊急修復或新增整合。這種分法不需要猜一個市場行情，也能讓不同技術方案在相同責任下比較。
網域不是買完就永久存在
Vercel 的網域續用文件說明，其管理的網域預設可自動續用，也能查看續用或到期狀態；若關閉自動續用，網域到期後會失去使用權，而第三方註冊的網域則要依原註冊商政策處理。文件也提醒，即使開啟自動續用，付款方式失效仍可能讓續用失敗。
這些資訊的重點不是推薦特定供應商，而是提醒預算表必須同時記錄「費用」與「責任人」。網域列應包含註冊商、持有人帳號、到期或續用狀態、付款責任與備援聯絡人；DNS、憑證與寄信設定也要有變更紀錄。若供應商代管，合約應寫清楚合作結束時如何移轉，而不是只拿到一張年度請款單。
主機與服務亦然。費用表不能只寫「主機一年」，而要列出託管範圍、流量或容量條件、備份方式、復原責任、監測通知與支援時段。表單寄信、搜尋、地圖、影音、分析或預約等第三方服務，也要標示免費條件用盡或方案變動時由誰評估。若目前無法確認價格，就保留待詢價欄位，不要填入看似精確的猜測數字。
維護要從「有問題再報修」變成可排程工作
W3C Web Accessibility Initiative 的規劃與管理指南把無障礙工作分成啟動、規劃、實作與持續維持，並在規劃中列出責任分配、預算與資源、網站檢視及監測框架；實作階段則包含及早且定期評估、問題排序與進度追蹤。這表示可用性與無障礙不適合只在完工驗收時檢查一次，而應納入持續工作。
年度持有成本因此至少要回答四件事：誰定期檢查主要流程、誰更新內容、誰接收異常、誰決定修復優先順序。檢查頻率可以依網站風險與更新量安排，不必假裝所有網站都要相同方案。簡單形象站可能重點是連結、表單、備份與內容正確；有登入、付款或大量內容的網站，則需要更完整的權限、資料與發布檢查。
報價單中的「維護」也要拆開。內容代更新、程式錯誤修復、套件與平台更新、弱點處理、備份還原、監測、客服與功能擴充不是同一件事。若只寫一個總稱，出現事故時雙方會對「是否包含」有不同理解。最少應列出服務項目、回應方式、排除條件、計價單位與終止合作後的資料取回方式。
從曦谷共好教會案例看頁面之外的成本
「曦谷共好教會」（dayvale-church）案例有近四十種頁面路由，涵蓋聚會、課程、影音、最新動態、課程報名、線上奉獻、無障礙友善版與站內搜尋。這類網站的成本顯然不能只用首頁加幾個內頁估算：不同內容有不同更新人，報名與奉獻是需要反覆驗證的流程，搜尋與無障礙也必須隨新內容持續檢查。
將案例換成自己的需求時，可以做一張「網站資產台帳」。每個頁型或功能列出內容負責人、系統負責人、外部服務、資料保存、例行檢查與停用方式。例如課程頁在活動結束後如何歸檔、影音失效由誰替換、搜尋能否找到新文章、表單通知換人時如何更新，以及新圖片是否有合適的替代文字。這些答案會決定要買後台功能、外包維護，還是投入內部工時。
案例中的頁面數與功能只能說明複雜度來源，不能拿來推導其他組織的價格。真正可比較的是責任單位：若甲方案提供可由內部更新的結構化後台，乙方案每次修改都要工程師處理，兩者的初次報價即使接近，後續持有方式也不同。
用三年責任表比較，不預測不存在的數字
可以為每個方案建立首年、次年與第三年的責任表，但金額只填供應商書面報價或帳戶中可驗證的價格。每列標示一次性或週期性、付款對象、帳號持有人、調價風險、取消後果與資料移轉方式。對尚未確定的流量、用量或功能，以假設區間和重新估價條件呈現，不把最佳情況當成承諾。
驗收尾款前，除了核對畫面，也要實際測試內部人員能否登入、更新、預覽、發布與復原；確認網域和服務帳號可被組織控制；下載操作文件與必要資料；並建立到期提醒及異常通知。若供應商仍持有關鍵帳號，至少要把移交步驟與期限寫入交付清單。
架網站費用的核心問題，不是找到一個適用所有人的固定數字，而是看見網站從建置到退場的完整責任。把資產、例行維運與事件性工作分開，再用可驗證報價填入年度表，才能知道便宜的是建置價格，還是整段持有期間真的比較省事。
