做一個網站多少錢？不是只算頁數，也要看複雜度與長期成本

頁數可以幫助理解網站規模，卻不能直接代表製作複雜度。

一個十頁的形象網站，如果沿用一致版型、內容完整、沒有特殊功能，可能比三頁的互動活動網站更容易製作。後者即使頁面少，也可能包含動畫、即時計算、會員辨識、報名流程或外部資料串接。

估算時，比頁數更重要的是頁型。十篇套用同一個文章版型的內容，和十個各自需要重新設計的頁面，工作方式並不相同。

因此，可以先把網站內容分成首頁、一般內容頁、列表頁、內容詳情頁、表單頁與特殊功能頁。頁型和重複規則愈清楚，估算就愈接近實際工作。

網站設計不是在空白框裡填入一些文字。標題長度、圖片比例、服務數量、案例結構與行動按鈕，都會影響頁面如何安排。

如果企業已經有確認過的品牌資訊、服務文案、圖片與案例，設計團隊可以較快進入版面規劃。若資料分散在簡報、舊網站、聊天紀錄與不同人手中，就需要先盤點、篩選、改寫與確認。

內容移轉也不是單純複製貼上。舊文章可能有格式不一致、圖片缺少原始檔、連結失效、分類重複，或需要重新導向原網址。數量愈多，清理和驗證的工作就愈重要。

估價前先列出「已完成、需要整理、尚未製作」三類資料，通常比先猜網站要有幾頁更有幫助。

客製化不只是把網站做得和別人不一樣，也包括針對內容、流程與使用情境設計適合的方式。

品牌需要特殊敘事、複雜資訊比較或獨特互動時，客製設計有明確價值。但一般文章列表、常見問題與聯絡表單，如果成熟元件已經能滿足需求，不一定要全部重新開發。

現成版型也不必然不安全或品質較差；客製網站同樣不會自然免除風險。真正需要確認的是版型與程式的來源、是否持續更新、依賴多少外掛、能否通過測試，以及發生問題時由誰處理。

合理的預算不是把所有地方都做成客製，而是把資源放在真正影響品牌、使用流程與營運效率的差異上。

「需要會員」、「需要預約」或「需要表單」看起來像是一項功能，實際上仍有很多尚未回答的問題。

會員是否要分不同權限？註冊要不要審核？忘記密碼怎麼處理？預約是否連動行事曆、付款與取消規則？表單資料只是寄到信箱，還是要進入 CRM、建立案件、通知不同窗口？

每多一個例外情況，就會增加介面、資料、權限與測試工作。真正影響費用的，往往不是畫面上的按鈕，而是按下去之後有哪些系統和人員必須一起運作。

列功能時，可以同步寫下使用者、觸發條件、資料去向、成功狀態、失敗處理與管理方式。這些資訊愈清楚，估價中的假設就愈少。

網站串接電子報、付款、行事曆、CRM、物流或內部系統時，API 能連得上只是第一步。

雙方系統的欄位名稱和格式可能不同，資料也可能重複、缺漏或暫時傳送失敗。還要決定哪一套系統是主要資料來源、同步多久執行一次，以及外部服務中斷時是否保留待處理紀錄。

權限與個人資料也需要一起評估。網站應該取得哪些資料、保存多久、誰能查看，以及金鑰和帳號如何管理，都會影響技術做法。

因此，串接預算不宜只用「一支 API」估算。資料規則、錯誤回復、測試環境與日後監控，才是讓整合真正可以營運的工作。

近期網站工具已能透過提示建立多頁網站、元件、CMS 內容，甚至產生可連接資料的簡易應用。AI 也可以協助撰寫初稿、整理程式、產生測試與加快重複製作。

這些能力能降低探索與原型成本，讓團隊更快看見方向。但 AI 產生的結果仍要進入正式開發流程：確認需求、整理真實內容、檢查授權、修正手機版、驗證無障礙、測試資料與處理安全問題。

如果網站加入生成式搜尋、聊天、推薦或自動化功能，還會多出模型服務費、使用量、資料保護、回答品質、記錄與人工接手等持續成本。

AI 會改變工作分配，而不只是把原本預算全部刪除。較適合由工具加速的工作可以變快，真正需要人做決策、驗證與承擔責任的部分，反而要在範圍裡寫得更清楚。

手機版、網站效能、搜尋基礎、無障礙、安全與跨瀏覽器測試，有時會被放在估價最後，看起來像有預算再做的選配。

但這些要求會回頭影響整個製作方式。圖片如何準備、元件怎麼建立、表單如何回饋、外部程式能不能加入，以及資料怎麼處理，都需要從設計與開發階段一起考量。

品質標準也要有明確範圍。是測試主要頁型，還是所有內容？支援哪些瀏覽器與裝置？是否包含弱點掃描、人工無障礙檢查、壓力測試或上線後監控？

不是每個網站都需要相同等級，但不能等上線前才發現這些工作從未被估進預算。

有些專案在開始時就能清楚描述頁面、內容與功能，適合直接估算完整範圍。有些專案則只有大方向，流程、資料和內部責任仍在討論。

後者若太早要求一個完全固定的價格，報價只能建立在大量假設上。製作中一旦發現真實需求不同，就容易出現追加費用、刪減品質或時程延後。

可以先安排較小的探索階段，完成需求訪談、內容盤點、流程圖、線框稿、技術驗證或可操作原型。這筆費用不是多做一份文件，而是用較小成本找出高風險問題。

當不確定性下降，後續的設計與開發才比較適合以明確範圍估價。

控制預算常會使用 MVP 或第一階段的概念，但它不等於把每一項功能都做一半。

比較好的做法，是挑出一條真正重要的使用路徑並完整完成。例如服務型網站的第一版，可以先讓訪客理解服務、查看案例、送出詢問並收到確認；活動網站則先完成資訊閱讀、報名、通知與後台名單管理。

其他功能可以分成必要、應該有與後續考慮。每一個後續項目要記錄為何延後、會依賴哪些基礎，以及什麼條件出現時再啟動。

分階段不是把問題留給未來，而是先完成可以產生價值、也能驗證需求的一個版本。

網站建置報價和網站每月營運費用通常不是同一件事。

網域、主機、網站平台、付費外掛、字型、圖片素材、電子郵件、簡訊、地圖、影音、分析工具、搜尋服務與 AI API，都可能採用訂閱或使用量計價。流量、檔案、寄信量、模型呼叫或團隊帳號增加後，費用也可能改變。

近期科技成本管理愈來愈不只看雲端主機，也把 SaaS、授權、AI 和人力一起納入。這個觀點同樣適合網站：免費方案能不能正式上線、價格是否依流量變動、停用服務後資料能否取回，都應該在選擇工具時一起確認。

網站不一定需要複雜的成本系統，但至少要有一張持續費用清單，知道費用由誰支付、方案何時續約，以及超過用量後會發生什麼。

網站上線後，內容會增加，瀏覽器、系統與外部服務也會持續更新。

主流 CMS 仍會發布一般維護與安全修補；平台也可能更改編輯器、停用舊功能或調整方案。即使系統自動更新，團隊仍要確認更新後表單、登入、付款與內容管理是否正常。

維護可以包含備份、更新、監控、錯誤排查、安全檢查、套件升級與小幅調整，但每一份維護合約的範圍並不相同。緊急問題的回應時間、內容上稿和新功能開發，也不一定包含在同一費用裡。

把維護責任寫清楚，會比籠統地問「網站有沒有保固」更容易理解真正得到的支援。

初期建置費較低的方案，可能需要較多內部整理、每月訂閱與後續加購；高度客製的網站前期費用較高，也可能因為內容模型和元件規則較完整，降低長期重複製作。

比較不同做法時，可以用三年情境估算：初期規劃與建置、內容與素材、平台與服務訂閱、日常維護、年度調整、內部投入時間，以及未來移轉的可能成本。

這不表示要準確預測三年內每一筆支出，而是避免只比較第一張發票。網站是否容易上稿、是否依賴單一人員、能否擴充，以及發生問題時多久可以恢復，也都具有成本。

真正適合的方案，是總投入和網站帶來的價值相符，而不是單純價格最低或功能最多。

一份容易合作的網站估價，不只列出設計幾頁、開發幾項功能，也應說明內容提供方式、修改輪次、測試範圍、第三方費用、交付項目與上線後支援。

專案假設同樣重要，例如客戶提供已確認文案、資料可由既有系統匯出、外部 API 文件完整，或某項功能沿用平台標準流程。若假設不成立，就需要重新確認影響。

不包含項目不是為了逃避責任，而是避免雙方對「網站做完」有不同理解。攝影、文案、多語翻譯、資料輸入、SEO 長期經營與系統維護，是否包含在建置案中，都應該明確列出。

預算愈透明，團隊愈能一起調整優先順序，而不是等到製作中途才發現缺少重要工作。

不需要先寫出完整規格，才可以詢問網站預算。企業可以先準備一張簡單清單，列出網站目標、主要受眾、現有內容、必要功能、參考網站、預計上線時間與可接受的預算範圍。

接著標示哪些事情已經確定，哪些需要專業團隊協助判斷，以及上線後由誰負責內容、技術和第三方帳號。

若預算有限，可以請合作團隊協助拆分第一版與後續版本，而不是要求在同一金額裡放進所有想法。若需求仍不明確，也可以先估探索階段，再根據確認後的範圍提出建置預算。

這是 Amicable 理解網站預算的方式：不從單頁價格開始，也不把複雜度當成提高報價的理由，而是把工作、風險與長期責任說清楚，讓每一筆投入都對應到網站真正需要完成的事情。