網頁設計費用怎麼估？需求範圍、報價拆解與交付驗收

網頁設計費用沒有一個脫離需求仍然可靠的固定答案。同樣寫著「企業網站」，可能只包含既有內容排版，也可能包含訪談、文案整理、多種頁面模板、會員流程、資料串接、舊站搬移與上線後維護。先把交付物、數量、責任與驗收方式寫清楚，報價才有比較基準。

本篇只處理估價、付款與驗收。企業內容由誰維護，可另看 企業官網的內容治理；需要角色、資料與流程的功能，應先讀 客製化網站需求規格；供應商能力與合作流程可看 網頁設計公司選擇指南；帳號權限與測試證據則由 網站 SEO 與技術交接驗收清單 補充。這些工作不應被含糊地包成一筆「網站製作費」。

一、先記住：報價是在估一份被定義的工作

因此，看到兩份總價不同的提案，第一步不是判斷哪一份貴，而是核對它們是否估了同一套工作。若一方負責內容盤點、測試與移交，另一方只交畫面稿，兩個數字本來就不能直接排序。

二、估價前先做需求釐清，不急著決定解法

GOV.UK Service Manual 的探索階段說明 強調，在承諾建置服務之前，應先理解使用者要完成的事、既有流程以及技術或制度限制。這個原則可直接用在網站詢價：先描述問題與限制，再讓團隊判斷需要哪些內容、介面與技術，而不是先指定動畫、套版或某套系統。

一份可估價的需求摘要，至少要回答以下問題：

• 主要任務：訪客要閱讀資訊、送出資料、預約、購買，還是登入處理工作？
• 內容現況：文字、翻譯、照片、圖表與下載檔是否已備妥，誰有核准權？
• 範圍單位：有幾種頁面模板、內容類型、語系、表單與權限角色？
• 既有資產：網域、主機、內容管理系統、程式庫與分析帳號由誰持有？
• 必要限制：上線日期、法務審閱、資安規範、無障礙要求與舊系統相依性是什麼？
• 不含範圍：本期明確不做哪些頁面、功能、搬移、維護或第三方設定？

尚未確定的項目也可以報價，但要標成待確認、暫估或另案。把未知寫出來，比用一句「依實際需求調整」更能保護雙方。

三、把總價拆成工作包，才知道費用從哪裡來

美國政府問責署的成本估算與評估指南 把可靠估算連結到目的、範圍、時程、技術基準、工作分解、假設、資料、風險與後續更新。它原本用於政府專案，本文只借用其中「先分解工作、寫明假設、持續更新」的方法，不把它當作網站價格表。

四、頁數不是唯一計價單位

「二十頁網站」可能是同一模板套入二十筆內容，也可能是二十種版型；兩者需要的設計、開發與測試工作差很多。詢價時應同時列出固定頁、內容模板與內容筆數。例如服務詳情是一種模板，十項服務是十筆內容；案例詳情是另一種模板，既有資料要不要整理與搬入，則是另一項工作。

功能也不能只用名稱計數。「聯絡表單」要進一步寫欄位、必填與錯誤狀態、收件方式、個資告知、垃圾訊息處理與成功頁；「會員」則牽涉註冊、登入、忘記密碼、權限與資料管理。名稱相同，不代表範圍相同。

五、法西納案例：網站圖片是一個獨立交付類別

法西納案例國民法官網站圖片設計專案 的資料明確記載法西納完成一組不同風格的網站 Banner，並說明各主題的構圖與配色。這項作品可以證明網站圖片的視覺設計範圍，也說明「網站設計」報價裡，主題數量、文字素材、畫面方向與版本核准都能成為獨立欄位。

這個設計工作包可以按「主題數、需製作文案或圖片、延伸尺寸、修改與核准範圍」詢價；如果委託還包含頁面程式、CMS 或追蹤設定，就另列對應工作包。如此既保留圖片設計的價值，也不會將單一類別誤當成整站費用。

以這類網站圖片為例，委託方可以在詢價表寫出每張的尺寸、主題文案、既有識別規則、是否需要插畫、交檔格式與核准人。若同一張還要延伸桌機、手機或社群比例，也要說明是裁切、重排或重新構圖。工作被定義後，設計方才能估算，委託方也能判斷收到的檔案是否完整。

可填寫的預算算式：先算一次建置，再加持續費用

沒有確認需求前，不適合把某個總價當成所有網站的行情；但仍可以先計算自己的範圍。下表是詢價用工作表，不是法西納報價、服務價格或市場均價。將同一套數量交給各供應商填單價，空白項目標「未估」，不要自動當成零元。

第一年預算＝一次建置各工作包小計＋第一年持續費用＋未包含於前項的第三方支出。 若以三年持有期比較，則將三年內各項續費分別加總，並寫明稅費、幣別、價格是否固定與調整條件。一次性授權不要每年重複加，已含在套餐的項目也不要算兩次。

例如同樣有 12 筆服務或消息內容，若全使用已完成的頁型，就應問「新增資料的費用」，而不是自動計成 12 套全新設計。反過來，若其中三筆需要獨立流程或版型，先列出差異再估價。

六、比較提案時，用同一張表逐欄對齊

不要只把各公司的總價抄在一列。先建立共同需求版本，再要求每份提案標出包含、選配、不含與待確認。若提案採不同解法，也要保留差異，而不是為了表面一致而刪掉重要限制。

若某項價格差異很大，回到工作包找原因：也許一方含文案與資料搬移，另一方假設委託方提供完整內容；也可能一方包含正式環境部署，另一方只交測試網址。把差異寫清楚，才能討論是否需要，而非只要求刪價。

七、內容、功能與串接，要分開估

內容工作通常受素材完整度、篇數、審稿人數與語系影響；介面工作受模板與狀態數影響；程式工作則受規則、資料、權限與例外情境影響。三者可能互相依賴，但不應混成「內頁製作」。內容延遲會阻礙排版，規則未決會阻礙開發，責任欄位因此也是費用前提。

第三方串接更要寫明服務提供者、資料從哪裡到哪裡、測試帳號由誰提供、錯誤時顯示什麼，以及服務變更或停止後由誰處理。報價可分為首次設定、客製開發、外部訂閱與依用量發生的費用，避免把持續支出藏在一次性建置費中。

八、帳號與數位資產也要進入報價附件

網域註冊、DNS、主機或雲端、程式碼儲存庫、內容管理系統、分析工具、寄信服務與第三方介面，應逐項列出擁有人、管理者、付款人、登入方式與移交時間。最好由委託方持有核心帳號，再依工作需要授權；若由供應商代管，也要寫明終止合作時如何匯出與移轉。

帳號盤點應在詢價時完成，才能把設定、移轉與文件工作計入時程，避免交付時才發現核心資產無法管理。

九、付款里程碑要綁成果，不綁模糊進度

常見階段可以是需求基準、資訊架構、視覺方向、可操作版本、測試修正、正式上線與完整移交；實際拆法取決於專案，不存在適合所有網站的付款比例。每一階段至少寫出交付物、提交格式、審查人、回覆期限、可接受的修正範圍，以及何時視為核准。

行政院公共工程委員會的官方頁面提供資訊服務採購契約範本 。民間網站專案可以把它當成提醒：技術工作也需要契約化的範圍、履約與驗收結構；但範本的版本、適用性及個別條款仍應由雙方依實際交易確認，本文不代替契約審閱。

十、需求改變時，用變更單保留決策脈絡

網站專案中出現新想法很正常，真正危險的是口頭加入、沒有確認代價。變更紀錄應包含提出日期、原需求、修改內容、原因、受影響的畫面或功能、費用、時程、測試與核准人；確認後再排入工作。若只是修正原交付未符合規格，則應記為缺失，不要和新增需求混在一起。

同時保留需求書、提案、報價與變更單的版本號。會議結論若改變交付範圍，也要回寫正式文件。如此在付款與驗收時，雙方核對的是同一版基準，不必靠零散訊息回想承諾。

十一、驗收條件要在估價時就寫

GOV.UK 的使用者故事撰寫指南 將驗收條件描述為確認服務是否完成任務的成果清單。網站也應以可觀察結果驗收，例如「必填欄位未填時，送出被阻止且指出錯誤」；「表單成功後，使用者看到確認訊息，指定收件人收到資料」。只寫「表單完成」無法判斷例外狀態。

• 每一頁與功能對應哪一條需求，誰負責測試與核准。
• 要在哪些裝置、瀏覽器、帳號角色與環境操作。
• 正常、錯誤、空白、逾時與重複操作各預期什麼結果。
• 文字、圖片、下載檔、連結與法律頁面由誰完成最終校對。
• 問題如何分級、修正、複測與關閉，哪些項目可延後處理。
• 正式上線後如何確認網域、憑證、表單、備份與管理權限。
• 原始檔、程式碼、操作文件、帳號清冊與教育何時移交。

十二、可直接使用的網站詢價欄位

十三、常見問題

十四、結論：先讓範圍可比較，再談取捨

網頁設計費用的重點不是找出一個通用數字，而是知道每一筆費用換來什麼、由誰完成、何時核准、如何驗收。需求、內容、功能、串接、帳號、變更與維護拆開後，委託方可以刪減低優先工作，也能保留真正影響交付的項目。

準備詢價時，可帶著網站目標、內容清單、功能流程、既有帳號與期望上線時間，透過法西納聯絡頁 說明需求。我們會先整理頁型、內容、功能與交付需求，再討論本期優先完成的工作組合。