網頁設計外包流程拆解：五階段把關，從需求到上線

想像一下這個場景：你跟設計公司開了三次比稿會議，來回修改首頁，合約簽了、尾款也結了，網站順利上線。幾個月後想加活動頁，才發現後台不能自行新增；想換主機時，又發現原始檔沒交、後台帳號由對方持有，連網域都登記在設計公司名下。這些風險不必等到發生糾紛才處理，需求、權限與交付條件都能在簽約前寫清楚。

需求、報價、驗收與交接若各自使用不同假設，容易產生返工和爭議。以下用五階段整理專案，搭配可檢查的文件與確認點；這是可調整的管理範例，不是所有外包專案的唯一流程。

先約定交付及驗收方式，再依合約安排付款里程碑。不能因套用本篇檢查表，就自行變更已承諾的付款條件。

快速總覽：外包流程的五階段 × 五閘口

1. 需求：整理類型、受眾、任務與範圍。
2. 選商簽約：核對需求、報價、排除項與變更機制。
3. 資訊架構：確認頁面關係、代表性線框與內容責任。
4. 設計開發：按約定檢查視覺、操作、功能與後臺。
5. 上線交接：完成必要驗收、紀錄未結項目，依合約交付和付款。

為什麼「外包流程」本身才是最大的地雷

流程文件有助於釐清期待，供應商能力、資源與溝通也需要評估。不能把多數爭議單一歸因於沒有書面關卡。

本文的「閘口」指雙方約定的確認點，用來記錄決策、責任與待處理事項。重要承諾應保存可追溯紀錄；LINE、Email 等電子紀錄也可能有意義，不能一概說沒有紙本就毫無證據。

資訊架構、CMS、權限與交接條件會影響後續維護和搜尋優化。網站類型不直接決定 canonical 策略，也不能把所有技術決定都量化成固定三到五年的結果。 延伸可參考架站方式全比較。

這篇把流程切成五個階段，每個階段設一道書面閘口。閘口不能保證專案不出問題，但能把需求、責任與驗收證據留下來，降低口頭認知不一致的風險。

文件所需時間取決於範圍、整合、參與者和既有資料。可先列交付與風險，再安排足夠的確認時間，不用固定十小時推算所有專案的節省幅度。

階段一：比稿之前的需求定錨

需求不明可能讓各家報價假設不同。先對齊必要範圍、排除項和估價前提，避免只比較總價；不能由此判定絕大多數糾紛都源於業主。

需求定錨的第一步，是把「網站類型」先敲死，wireframe 還排在更後面。形象官網、一頁式銷售頁、電商購物車、內容部落格、客製系統，這五種是截然不同的工程，報價結構、技術棧、後續維護成本天差地遠。如果你連這個都還在猶豫，先去把一頁式網站設計全指南、品牌官網設計全攻略、電商平台比較這幾篇讀過，把方向先定下來。方向不定，後面的需求文件僅是空話。

需求文件要寫進去的七件事

下面七項可作需求文件的起點，依專案補充或合併。目的是讓報價、合約與驗收能對應，而不是要求每個案件都使用同一份固定表單。

1. 網站類型與核心目標：是要接名單、直接賣東西、做品牌曝光、還是累積內容流量？目標決定功能優先順序。
2. 主要受眾與使用情境：誰會來、用什麼裝置、想做什麼事。這直接影響響應式策略與資訊架構。
3. 頁面清單與優先序：首頁、關於我們、服務、案例、部落格、聯絡，列出第一版必須上線的頁面。
4. 功能需求：表單、金流、會員、多語系、後台可自行編輯、預約系統。能具體就不要模糊。
5. 內容誰負責：文案、圖片、影片是業主提供還是設計公司代寫？這一條沒寫清楚是最大的隱形加價項。
6. 上線時程與預算區間：給區間就好，但要有。沒有預算區間，對方僅能用最保守的規格報價。
7. 後續維護與 SEO 預期：網站要不要自己改？要不要做 SEO？這決定 CMS 與主機的選擇。

先對齊內部決策者與變更核准方式，對仍未知的需求標明假設。修改可能合理增加工作量，不能預先把追加費用等同廠商藉機加價。

階段一的閘口很簡單：需求文件存在、而且已經過內部簽核。沒有這份文件，不要發需求給任何一家公司。你可以參考企業為什麼需要形象網站先把「為什麼要做」想清楚，再回頭把需求寫具體。

階段二：選商、報價與簽約

需求文件出去之後，你會收到幾份報價單。多數人這時候僅看總價，這是最大的錯誤。報價單的本質不是「多少錢」，而是「這份合約到底買到什麼」。你必須把報價單當合約讀，逐條對應你的需求文件，找出缺口。

報價單裡必須看清的十個欄位

用相同需求核對報價，再請廠商補充未寫清的項目。資料不足代表需要釐清，不能直接認定低價綁約；外部行情也只能在範圍、時間及假設相同時比較。 延伸可參考網頁設計費用全公開、網站架設費用完整解析、WordPress 架站費用拆解。

套版、半客製、全客製：流程深度完全不同

流程深度應跟風險和需求相稱。套版也可能有複雜整合，客製也可分階段驗收；不能只由方案名稱判定需要多少文件或會不會受騙。

選商本身是一門學問，這篇的重點是流程，所以僅點到這裡。想知道怎麼實際檢驗一家公司的體質，可以接著讀網頁設計公司挑選指南與網頁設計公司推薦；如果你有 logo、視覺系統要一起談，也別忘了把logo 設計費用一起算進總預算，避免視覺與網站兩頭外包時各做各的。

簽約前對應需求、報價與排除項，將仍未知的工作和變更程序寫清楚。確認時間取決於案件，不能保證兩小時一定省下數十小時。

階段三：資訊架構與線框稿

簽約後，應先把網站的資訊架構（IA）拆清楚，再進入視覺設計。越晚修改 IA，通常牽涉越多版型、網址、內容與轉址工作；但上線後調整不等於「整個 SEO 排名歸零」。先做網址對照、301 轉址、canonical、內部連結與 sitemap 更新，可以降低遷移風險。

IA 階段可交付網站結構圖、線框稿和內容分配表。此處 sitemap 指規劃頁面關係的結構圖，與供搜尋引擎發現網址的 XML sitemap 用途不同；兩者應保持一致，但不能互相取代。 延伸可參考網站 sitemap 指南、sitemap AI 工具。

為什麼 IA 等於你的 SEO 骨架

SEO 不該等到上線後才補。IA 會影響讀者導航、內部連結、爬取路徑與網址規劃；層級太深不等於爬蟲一定抓不到，但可能讓重要頁面較難被發現。網址上線後仍可修改，僅是必須配合逐一轉址與監測，不能假設排名會自動保留或全部重來。

具體來說，IA 階段至少要回答這幾個 SEO 相關問題：

• 主要導覽與 footer 連結結構，能否讓讀者與爬蟲找到重要頁面？三次點擊可作專案目標，但不是 Google 的固定規則。這個原則可以對照網站結構 SEO 指南檢查。
• 每個主要頁面的網址結構是否語意化？產品分類、部落格文章、服務頁的網址層級要怎麼分？網址優化會告訴你規則。
• 頁面之間的內部連結怎麼佈？支柱頁與群集內容的關聯要先在 IA 裡畫出來。
• 版面配置上，每個頁面的主區塊、CTA、內部連結位置怎麼排？網頁版面配置指南可以當檢查表。
• 哪些關鍵字對應到哪些頁面，避免自己網站內部互相搶排名？這個盤點動作建議搭配關鍵字研究一起做。

把 SEO 放進 IA 階段，是為了提早決定分類、頁面角色、網址與內部連結。上線後仍能修正結構，不必一律砍掉重做；僅是需要內容盤點、轉址、canonical 與逐步驗證，成本通常比線框階段高。

可把結構圖、線框與內容責任設成確認點，再進下一階段；也可先用部分高擬真原型驗證關鍵假設。按合約管理變更，沒有唯一能阻止所有返工的順序。

階段四：視覺設計確認與開發

IA 過了之後，進入視覺設計與程式開發。這個階段是最容易情緒化的一關，因為美感見人見智，而「不好看」這句主觀評價無法被驗收。你必須把美感判斷轉換成可量化的檢查項目，否則設計師會在你的主觀感覺裡無限修改，直到修改次數用完。

設計稿確認：把「看起來不錯」翻譯成檢查表

「看起來不錯」不是簽認，「逐項檢查表勾完」才是。設計稿確認時，至少要走過這幾個檢查面向：

• 品牌一致性：色票、字級、logo 使用規範是否與品牌手冊一致？
• 手機版：按代表性版型、尺寸與互動狀態檢查手機呈現，是否每頁另交設計稿由範圍決定。響應式設計與AWD vs RWD 比較能幫你跟設計師對齊「響應式」到底要做到什麼程度。
• CTA 與轉換路徑：每個頁面的主要動作是什麼、按鈕在哪、表單多長？這部分可參考系統化的網頁設計完整指南。
• 常見錯誤掃描：對照網頁設計常見錯誤逐項檢查，把可避免的問題在設計階段擋掉。
• 載入效能預期：首頁用幾張大圖、有沒有影片、動效多不多？這些都會影響上線後的速度，網站速度優化會告訴你紅線在哪。
• 無障礙與對比：文字與背景對比、字級、鍵盤操作，這些既是使用體驗也影響搜尋引擎可讀性。

在合約約定修改、版本、缺陷與新增需求的處理方式，並保存確認紀錄。版本文件是有用的證據之一，並非唯一可能的證據。

開發階段：同時驗證功能與實際呈現

開發後要確認功能、後臺、資料、跨裝置呈現與無障礙操作。設計稿已確認不代表實作的顏色、字級或版面可以免驗；新增偏好與未符合規格的缺陷應分開處理。

若採用 WordPress，可從實際維護者的任務出發，確認以下項目。平台市佔率不能代替專案適用性的評估。

• 實際操作後臺，確認日常維護角色能完成新增、編輯及發布；另核對管理與交接權限。
• 記錄主題、編輯器、版本及客製範圍，確認更新與接手責任。
• 列出外掛用途、來源、授權與續費；是否需要保留由功能、維護及量測決定，不能只看數量。
• 核對 HTTPS、登入權限、更新、備份與還原程序；功能可由主機、服務或外掛提供，不強制安裝特定類型外掛。 延伸可參考WordPress 架站教學、頁面編輯器、頁面編輯器比較、WordPress 主題推薦、Elementor 完整教學、主題安裝教學、圖片優化、安全外掛、備份外掛。

驗收應使用事先約定、可重現的情境，例如表單通知、發文呈現及手機選單。修改回合是否用完不是通過驗收的條件，仍需記錄缺陷、未完成項目及處理方式。

階段五：驗收、上線與交接

上線前確認必要功能、安全、搜尋設定及交接，並安排上線後觀察。事後修正的成本因問題而異，沒有通用十倍的比例。

上線前的 SEO + 資安 + 交接三方檢查表

網域註冊、DNS、主機、TLS 及後臺權限是不同項目。憑證與 DNS 設定不證明網站全部權利歸誰；應核對管理、續期及移轉責任，並分開約定程式和素材授權。 延伸可參考SSL 憑證指南、DNS 設定教學、網域申請全攻略。

搜尋規劃可以在設計前開始，上線前再檢查具體設定。架構之後仍可調整，但需處理網址、內容和量測的影響，不能把上線日當成流量天花板已定的時刻。 延伸可參考on-page SEO 指南、WordPress SEO 完整教學、WordPress SEO 技巧、從源頭做 SEO 的觀念。

交接：把主導權拿回來

交接依採用的平台與合約逐項驗收，確認能持續營運及瞭解退出限制。SaaS 未必交付底層原始碼，供應商代管也不自動等於鎖定。

• 列出網域、主機、DNS、資料與後臺帳號的責任、權限及安全移交方式；使用個別帳號與必要權限。
• 按約定驗收程式、設計、資料匯出和可還原備份，確認格式與使用方式。
• 記錄主題、外掛、素材的授權、續費與更換廠商後的安排；不一定能轉移供應商整個購買帳號。
• 依範圍交付操作文件、訓練、緊急處理與退出流程。 延伸可參考WordPress 本機上線、搬家外掛、備份還原。

上線後：依風險安排觀察與保固處理

正式流量可能暴露測試未涵蓋的情況。可以在上線後加密觀察，再調整維護節奏；保固期間、免費修復及服務範圍由合約決定，不能一律視為三到六個月或固定 48 小時。

• 搜尋引擎收錄狀態：到 Google Search Console 確認 sitemap 已提交，並用網址檢查工具檢查重要頁面。Google 沒有三天內收錄的保證；未收錄可能和 noindex、robots.txt、抓取、canonical、內容品質或網站新舊有關。robots.txt 僅管理爬取，不是存取控制，敏感頁面仍需登入或伺服器權限保護。
• 表單與金流：親自跑一遍每一張聯絡表單、每一條結帳流程，確認通知信到得了、訂單狀態正確、自動回覆有發出。這是上線最常見的破口，也是對營收影響最直接的環節。
• 速度與穩定度：用 PageSpeed Insights 觀察首頁與主要頁面的分數，並留意主機在尖峰時段是否回應變慢。SEO KPI 的觀念可以幫你設定監控的基準線，知道哪些數字掉到紅線就該求救。
• 行動裝置實測：不要僅看瀏覽器的模擬器，拿實際的手機走一次完整流程，從首頁到結帳或表單送出。很多排版與互動問題僅在真機上才會浮現。
• 404 與轉址驗收：逐一檢查舊網站的重要網址，確認 301 轉址到最相近的新頁面，並找出非預期 404。轉址缺漏可能讓舊網址失效、外部連結價值與使用者路徑中斷，但流量變化仍可能同時受內容、索引、內部連結與搜尋需求影響。

集中記錄問題、重現步驟、影響、截圖與處理狀態，協助雙方追蹤。溝通方式依團隊安排，不能推定通訊軟體回報一定漏掉一半。

上線前確認約定的必要驗收與交付，對未完成事項留下雙方同意的安排。付款依合約與實際驗收處理，本篇檢查表不構成自行扣款或延後既定付款的依據。

五個閘口一張表：把流程變成檢查表

把前面五個階段的閘口濃縮成一張總表，把它印出來或存在專案資料夾，每次開會帶著。這張表的目的不是官僚，是讓每一次付款都有一個明確的對應文件，把口頭承諾全部逼成書面。

里程碑付款是一種安排方式，可依風險、交付和合作模式商議。採用不同付款方式不等於廠商不專業；簽約後應依約執行，變更需重新確認。

三種外包關係，流程深度怎麼抓

流程深度按功能、交易、資料與整合風險決定。可重用代表性範本，避免不必要文件；高風險環節則需可重現的驗收。

第一種是套版快站。預算有限、時程急、功能單純的形象站或活動頁，屬於這一類。這種專案的 IA 與視覺階段可以大幅壓縮，因為你選的就是現成版型。但仍要寫清楚網域註冊人、主機或平台帳號、管理員權限、內容匯出能力與移轉條款。SaaS 平台未必交付底層原始碼，供應商代管也不必然有問題；關鍵是合約與帳號能否讓業主持續營運或順利移轉。想用平台快速搭起來的，可以參考網站製作平台評比。

半客製方案可重用 CMS 或主題，仍需核對客製部分、更新與交付。需求、架構、設計及搜尋設定各要驗到什麼程度，依專案約定，不推定所有中小企業都採同一模式。 延伸可參考餐飲網站設計、作品集網站製作。

交易、會員、多語系或跨系統整合可增加驗收複雜度，應涵蓋正常、錯誤與權限狀態。電商不一定全客製，也沒有所有功能都必須逐一使用相同流程的固定規則。 延伸可參考電商完整指南、WooCommerce 完整教學。

越晚調整可能牽涉更多既有內容與整合，因此提早驗證重大假設很有價值。但 IA、URL 與 CMS 仍可更換，視覺修改也可能涉及無障礙與品牌風險，不能簡單分成不可回頭與無關緊要。

外包時需要核對的五類交付

以下列出容易產生認知落差的交付項目，供簽約及驗收核對；缺漏不自動代表廠商偷取或永久無法補救。

1. 檔案與資料：確認實際交付、格式、時間、可用性及平台限制。
2. 著作權與授權：依適用法律和合約分開約定圖文、程式、版型、字型及第三方素材，不推定付費就取得全部權利。
3. 帳號與服務：核對網域註冊、主機、DNS、CDN、後臺和分析工具的管理及退出安排。
4. 搜尋設定：確認抓取、索引、網址、標記和連結是否符合目標，不將 XML sitemap 或 canonical 當成所有頁面的排名保證。
5. 可維護性：以代表性修改或移轉情境核對文件、授權與工具，瞭解需要的成本及協助。 延伸可參考虛擬主機指南、主機類型比較。

清單有助於發現缺口，仍需實際驗收，不能保證走完流程就消除全部風險。比較維護費用時，可使用相同期間與工作假設來看總成本。 延伸可參考網站維護費用解析。

結語：把外包當專案管理，不要當採購

外包除了採購，也涉及持續的需求與交付管理。把重要決策和驗收留下紀錄，並約定變更方式，能讓雙方知道責任與下一步。

把這篇指南濃縮成六步行動方案：

1. 先整理需求、未知假設與決策者。
2. 比價時核對相同範圍、費用與排除項。
3. 簽約時確認交付、變更、驗收與付款安排。
4. 製作時驗證架構、代表性設計與功能，記錄決策。
5. 驗收時使用可重現情境，同時檢查呈現與操作。
6. 上線時完成必要驗收、交接與未結項目安排，再依約付款。

業主、設計與開發各有責任，可依能力委派工作並約定回報。文件不能取代專業驗證，也不能把所有糾紛歸因於業主沒有親自管理。

上線後仍需安排內容、更新、備份與必要的改版。能否換人接手取決於平台、授權、資料、文件及能力，不必然能交給任何人無痛接手；瞭解限制與退出路徑比以「買到或租到」二分法判斷更實用。

網站可能成為未來數年的內容與名單基礎建設。前期多花時間把需求、權限、驗收與交接寫清楚，無法保證排名或詢問，但能降低返工、綁定與責任不清的成本。