網站發包需求規格書與驗收清單

你把網站發包出去,三個月後對方交件。你打開一看,跟你想的不一樣。手機打開跑版,聯絡表單填了沒收到信,Google 上搜公司名字還是搜不到,問廠商要原始碼,對方說「這個沒有包含在報價裡」。

這種情境在台灣中小企業的發包經驗裡重複上演。而且很殘忍的是:大部分時候,錯不在廠商。 廠商照著他理解的需求做完了,只是那個理解跟你腦袋裡的畫面差很多;而你也從來沒有一份文件,能在爭執的時候攤在桌上說「這裡有寫」。

網站發包出事的地方永遠是同樣兩端:一開始沒講清楚(做出來不是你要的),以及最後不知道怎麼驗收(上線後才發現手機版壞掉、SEO 沒做、網域不在自己名下)。這篇文章只做一件事:給你兩份可以直接複製貼上拿去用的清單,一份給發包前,一份給上線前。中間再放一份合約權責對照表,把最容易變成呆帳的十個項目寫死。

先講定位。這篇談的是流程與文件,不是法律意見。所有涉及契約條款、著作權歸屬、違約責任的細節,請務必回到你自己的律師身上確認。我們能做的是幫你把該問的問題先問出來,不要等到交件那天才發現漏了。整個系列從網站架設費用與報價單怎麼看開始,如果你連預算區間都還沒抓,建議先看那一篇再回來。

一、網站發包會出事,幾乎都不是廠商壞,是兩份文件沒寫

直接回答:網站發包的糾紛集中在兩個時間點——簽約前的需求定義、驗收時的通過標準。中間的施工過程反而很少出問題。 只要這兩端各補一份書面文件,大部分爭議在發生之前就消失了。

為什麼會這樣?因為網站是一個「雙方對同一句話理解不同」的高風險商品。你說「我要一個有質感的官網」,廠商聽到的是版型與配色;你腦中想的可能是「客戶進來會想詢價」。你說「要有多語系」,你想的是中英文各一套完整內容,廠商報價時想的是「加一個語言切換按鈕,內容你給」。這兩種落差,在製造業發包模具或治具時不會發生,因為圖面上有尺寸公差;但在網站發包時,沒有人畫圖面。

規格書就是網站的圖面。 它不需要很長,也不需要你懂技術——它需要的是把「你期待的結果」寫成對方無法誤解的句子。一份兩到三頁的規格書,通常就能把八成的爭議擋掉。

第二個容易被忽略的原因是:網站的成本有一大半在交件之後才發生。 台灣的建站行情調查顯示,網域續費、主機、SSL、備份這類隱藏成本,大約佔初期建置費的15% 到 25%,而且是每年都要付的。這些項目在報價單上常常只有一行「首年免費」,第二年帳單來了才發現要自己處理,而帳號密碼還在廠商手上。這不是廠商坑你,是規格書沒寫「第二年之後誰付、誰管、帳號在誰名下」。

還有一個結構性的第二層效應值得先講:沒有驗收清單的專案,通常也不會有結案。 台灣中小企業常見的狀況是網站「差不多好了」就上線,尾款一直卡著,廠商覺得你在拖,你覺得他沒做完,雙方都很不爽但沒人說得出到底還差什麼。一份逐項打勾的驗收清單,同時保護你跟廠商:勾完了就是結案,尾款付得心甘情願,後續要加東西就是新的委託。清單不是拿來刁難廠商的,是拿來讓雙方都能收工的。

二、需求規格書該寫什麼:十二個欄位,兩頁寫完

直接回答:一份夠用的網站需求規格書有十二個欄位——目標、受眾、架構、內容產出責任、語系、功能、後台維護、效能相容性、SEO 基礎、AEO 要求、資料整合、時程里程碑。 每個欄位寫三到五行就夠,重點不是長度,是把口頭承諾變成文字。

下面這張表你可以直接複製到 Google 文件裡當範本。左欄是欄位,中欄是「寫到什麼程度才算清楚」,右欄是「沒寫清楚最常發生的事」。右欄那些情境,每一個都是真實發生過的發包意外。

十二欄規格書範本(可直接複製)

這十二欄裡,第 4、9、10 三欄是台灣中小企業最常整欄漏掉的。第 4 欄下一段單獨講,第 9、10 欄放在第四節。其他欄位有一個共通的寫法訣竅:用「上線後我要能做到什麼」的句子來寫,而不是用技術名詞。 你不需要寫「請使用 Next.js 搭配 ISR」,你要寫的是「我要能自己在後台新增一篇產品文章並在十分鐘內上線,不需要找你」。前者你不懂也講不贏廠商,後者是可以驗收的。

三、最容易吵架的一欄:內容到底誰產出

直接回答:台灣多數網站報價不含文案撰寫、專業攝影與翻譯,但報價單上很少明講,這是發包糾紛的第一名。 規格書必須逐項寫明每一類內容由誰產出、何時交付、修改幾次。

先把行情講清楚,你才知道自己在爭什麼。台灣的建站報價區間大致是:一頁式形象站約 新台幣 1.5 萬到 5 萬,企業官網 5 萬到 20 萬,電商 10 萬到 50 萬,客製系統 20 萬到 100 萬以上;另一份行情整理則指出形象網站常見落在 新台幣 4.5 萬到 12 萬,通常已含響應式版面與基本 SEO。注意「通常已含」的是版面與基本設定,不是內容。一家企業官網如果要寫二十頁的產品文案、拍五十張產品照、再翻成英文,那個工作量本身就可能超過建站費用。

六類內容,逐項指定負責人與交期

所以規格書的第 4 欄要拆到這個細度:

• 文案:誰寫?如果是廠商寫,是「潤稿」還是「從零撰寫」?你要提供多少素材?可以改幾次?
• 產品照與情境照:你提供還是廠商拍?去廠拍攝算幾天?去背修圖幾張?
• 圖表與規格表:誰整理?你的舊型錄 PDF 要不要轉成網頁表格?
• 影片:誰拍誰剪?放 YouTube 還是站內?
• 翻譯:機器翻譯加人工潤稿,還是母語人士撰寫?英文版是翻譯中文,還是為海外買家重寫?
• 後續新增:上線後每個月新增內容,是你自己來還是廠商包月?

自己寫文案不一定比較省

這裡要破除一個很常見的迷思:很多老闆以為「內容我自己來比較省」,結果內容永遠寫不完,網站拖了一年還沒上線。 內容不是省錢的地方,是排程的地方。如果你決定自己寫,規格書就要寫「甲方於第 X 週前提供全部文案,逾期則時程順延且不視為乙方違約」——這句話同時保護廠商,也逼你自己排出時間。實務上更務實的做法是分批:先用現有素材把網站上線,把內容補完當成上線後的持續工作,這樣至少網站先開始累積資料。關於這一段的排程邏輯,外銷網站從零到上線的完整流程那篇有更細的時間表。

還有一個第二層效應要提醒:內容產出責任沒寫清楚,受害最深的其實是廠商。 廠商的成本結構是人月,專案拖三個月,他的設計師與工程師就被卡住三個月。你如果希望長期跟同一家廠商合作(而這對中小企業其實很划算,因為網站是要養的),把內容責任寫清楚是對雙方都好的事。

四、規格書裡幾乎沒人寫的一段:SEO 基礎與 AEO 要求

直接回答:規格書如果不寫 SEO 與 AEO 的最低技術要求,你會拿到一個「看起來很漂亮但搜尋引擎與 AI 都讀不懂」的網站,而這件事上線後修的成本遠高於一開始就要求。 這一段是本文最有價值的部分,因為十家中小企業有九家的規格書完全沒有這一項。

SEO 的六條最低要求

先講 SEO 基礎。你不需要要求廠商幫你做關鍵字排名(那是另一個委託),你只需要要求網站不要擋住你以後自己做。最低要求有六條,建議一字不改寫進規格書:

1. 每一頁的標題(title)與描述(meta description)都能在後台獨立編輯,不是全站共用一組。Google 官方文件也說明標題連結與摘要是如何從頁面產生的,不能編輯等於放棄這塊。
2. 網址結構可控、語意化、全小寫、用連字號,不出現問號參數或流水號。
3. 網站能自動產生並更新 sitemap.xml,格式符合 Google 的 sitemap 規範。
4. robots.txt 可編輯,且上線時必須確認沒有殘留開發期的全站封鎖指令(這是上線意外的常客)。
5. 每一張圖片都能填替代文字(alt),Google 圖片的官方最佳實務明確把 alt 當成理解圖片內容的主要依據。
6. 多語系頁面之間有正確的 hreflang 標註,符合 Google 對在地化版本的說明。

AEO 的四條要求:讓答案引擎讀得到你

再講 AEO。AEO(Answer Engine Optimization)指的是讓 ChatGPT、Perplexity、Google AI 概覽這類答案引擎能正確讀取並引用你的內容。這件事跟傳統 SEO 有一個關鍵差異:很多 AI 檢索器不執行 JavaScript,或執行得很有限。 如果你的網站是純前端渲染,人類用瀏覽器看得到內容,爬蟲抓回去卻是一個空殼。Google 自己的 JavaScript SEO 基礎文件就花了大篇幅在講這個渲染落差。所以規格書要寫的 AEO 要求有四條:

1. 主要內容必須為伺服器端渲染或靜態產生,關掉 JavaScript 後用「檢視原始碼」仍看得到文字內容。
2. 輸出結構化資料(JSON-LD),至少包含 Organization、Product 或 Service、BreadcrumbList、FAQPage 四類;可用 Google 的複合式搜尋結果測試工具與 Schema Markup Validator 驗證無錯誤。可輸出的型別清單見 Google 結構化資料資料庫。
3. robots.txt 不得封鎖 AI 檢索器(除非你有明確理由要擋)。這一條要特別檢查,因為有些主機商或外掛的預設值會擋。
4. 每頁要有一段可被單獨引用的答案段落,以及清楚的 H2/H3 階層。

這四條要求對廠商來說多花的工不算多,但如果上線後才補,等於重做一次前端架構。技術細節與實作方式,AEO 技術實作手冊那篇有逐步的設定說明,你可以直接把該篇的檢查項目附在規格書後面當附件。

效能門檻:直接用 Core Web Vitals 當驗收標準

至於效能門檻,建議直接用 Google 的 Core Web Vitals 當驗收標準,因為它有公開定義、有免費工具可量、雙方沒有爭執空間。目前的良好門檻是 LCP 在 2.5 秒以內、INP 在 200 毫秒以內、CLS 在 0.1 以下,且以第 75 百分位的載入為判斷基準。量測工具用 PageSpeed Insights 即可,規格書寫「行動版首頁與主要產品頁在 PageSpeed Insights 行動版評分需達到綠色區間」就是一句可驗收的話。

五、合約要寫死的十件事:網域、原始碼、保固、維護

直接回答:網站合約最容易變成呆帳的十個項目是網域註冊人、主機帳號、SSL 憑證、原始碼、設計原始檔、第三方授權、修改次數、保固範圍、維護費與 SLA、廠商終止營業時的交接。 其中網域與原始碼這兩項,寫不寫的差別可能是整個網站的存亡。

先講最重要的兩條法律現實。

網域:註冊人才是擁有者

第一,網域的擁有者是註冊人(registrant),不是幫你註冊的人。 ICANN 對註冊人變更(Change of Registrant)有一套正式規範,而變更需要現任註冊人配合。也就是說,如果廠商用他公司的名義幫你註冊 .com,法律上那個網域是他的,你要拿回來得他點頭。台灣的 .tw 網域由 TWNIC 管理,同樣看註冊人資料。網域本身很便宜——.com 每年約新台幣 500 到 800 元,.tw 約 800 到 1,200 元——但它是你所有行銷資產的地址。規格書與合約的第一條就該是:網域以甲方公司名義註冊,帳號密碼於簽約後七日內交付甲方。

原始碼:沒寫進合約,法律上多半不是你的

第二,原始碼的著作權預設不在你身上。 台灣《著作權法》第 12 條規定,出資聘請他人完成之著作,原則上以受聘人(也就是廠商)為著作人,契約另有約定者從其約定;未約定著作財產權歸屬者,著作財產權歸受聘人享有——出資人僅得在出資目的範圍內利用。換句話說,你付了錢,但沒有寫進合約的話,程式碼的著作財產權很可能不是你的。 這不是台灣獨有的設計:美國著作權局的說明也指出,獨立承攬人完成的作品只有落在法定的九類特定類型且雙方另有書面約定時,才算「僱傭著作」(work made for hire),網站程式通常不在那九類裡,所以美國的做法同樣是靠合約明文讓與。兩邊的結論一樣:沒寫,就不是你的。 再次提醒,這一段是背景說明而非法律意見,實際條款請讓你的律師擬定。

十項合約權責對照表

把這十件事整理成一張表,簽約前逐項對過:

第 10 項在台灣特別值得寫。網站接案的市場流動性很高,一間工作室三年後還在不在,沒有人說得準。這一條不是不信任對方,而是把「萬一」變成一個雙方都同意的程序。實務上更有效的做法是:不管合約怎麼寫,網域、主機、Google Analytics、Search Console 這四個帳號的最高權限,從第一天就掛在你自己的公司信箱下,再把廠商加為協作者。這樣就算失聯,你什麼都不會掉。

六、上線驗收清單:二十八項照著打勾

直接回答:上線驗收不是「看起來對不對」,而是逐項用可重複的動作去驗證,每一項都有明確的通過標準。 下面這張表按類別排,建議印出來,跟廠商一起坐下來一項一項勾,勾完雙方簽名,尾款當天結清。

驗收前的準備:三支手機、一台桌機、一個外部網路

驗收前先做一件事:準備三支不同的手機(至少一支 iPhone、一支 Android)、一台桌機、以及一個你平常不用的網路(例如手機開熱點)。很多驗收意外是因為只在廠商的電腦、廠商的網路上看過。行動裝置的重要性不需要爭論——根據 Statista 的統計,行動裝置(不含平板)長年占全球網站流量的一半以上,2026 年第二季約為 51.5%,而 Google 早已全面採用行動優先索引,也就是說 Google 主要是用手機版的內容來評估你的網站。

二十八項上線驗收清單

數據與 SEO 帳號:三件必須自己動手做的事

第 14 到 19 項的數據與 SEO 帳號,是驗收時最容易被口頭帶過的一段。請務必自己動手做三件事:第一,打開 GA4 的即時報表,確認看得到你當下的造訪,並依 Google 對 GA4 資料保留期限的說明把保留期間設成你要的值,而不是放著預設值——這個設定影響的是你未來能回頭分析多久的資料,設錯了補不回來。第二,依 Search Console 的資源驗證說明確認資源已驗證,而且你的公司帳號是擁有者(owner)而不是使用者;擁有者才能新增其他人、才能在換廠商時把權限收回來。第三,在 Search Console 的 Sitemap 頁面確認 sitemap 已提交且狀態成功,並比對網址數與你實際的頁數——數字差太多通常代表有一批頁面沒被收進來。這三件事加起來不到十五分鐘,但它們決定了你上線後能不能看見自己的網站表現。

這張表看起來很長,但實際跟廠商一起走完大約兩到三小時。強烈建議不要在上線當天驗收,而是留一到兩週的「上線前驗證期」:網站先掛在測試網址上,用真實內容跑完全部二十八項,確認後再切正式網域。這個安排讓廠商有時間修,也讓你不會在客戶已經看得到的情況下發現問題。

SSL 憑證效期正在縮短:2026 年起的新變化

第 5 項的 SSL 有一個 2026 年的新變化值得注意:CA/Browser Forum 通過的 SC-081v3 決議將公開信任的 TLS 憑證最長效期逐步縮短,2026 年 3 月起從 398 天降到 200 天,2027 年降到 100 天,2029 年降到 47 天。意思很簡單:手動續憑證這件事很快就會變成不可行的做法,你在驗收時要確認的不只是「現在有憑證」,而是「續期是自動化的、而且是誰在負責」。用 Let’s Encrypt 這類自動化憑證或平台內建的自動續期都可以,重點是有人說得出流程。

七、三個最常見的糾紛,以及怎麼在發包前就避開

直接回答:網站發包的三大糾紛是——超出範圍的無限修改、內容遲遲不到位導致的延期究責、以及交件後資產拿不回來。 三個的共同解法都不是「找更好的廠商」,而是在規格書與合約裡先把定義寫死。

糾紛一:改不完的修改

典型情境是老闆、業務主管、二代三個人分批給意見,而且互相矛盾,廠商改到第七版還在原地。預防方法有三個動作:第一,指定單一窗口,所有修改意見由這個人彙整後一次提出,規格書寫明「乙方僅接受甲方指定窗口以書面提出之意見」。第二,定義一次修改的單位——不是「改一個地方算一次」,而是「一輪彙整後的意見算一次」,並寫明包含幾輪(視覺兩輪、內容兩輪是常見的合理值)。第三,區分「調整」與「新增」:在已確認的架構內改文字、換圖、微調間距是調整;增加頁面、增加功能、推翻已簽核的版型是新增需求,另行報價。把這三句話寫進合約,這個糾紛幾乎不會發生。

糾紛二:延期到底是誰的責任

這一題九成跟第三節講的內容產出有關。預防的關鍵是把時程表寫成條件式而不是絕對日期:「乙方於甲方提供全部文案與圖片後 30 個工作天內完成開發」,而不是「本案於 6 月 30 日完成」。同時在里程碑表裡明訂每個節點的甲方交付物與逾期效果(順延、不視為乙方違約)。這樣做的第二層好處是:它會逼你在簽約前就正視內容準備的工作量,而不是簽完約才開始煩惱。如果你正在評估的是既有網站要不要打掉重練,改版還是重做的決策框架那篇有更完整的判斷標準,先做完那個判斷再寫規格書會順很多。

糾紛三:交件後資產拿不回來

這是最傷的一種,因為它通常在你想換廠商、或廠商收攤的時候才爆發。前面第五節的十項合約條款就是為此設計的,但這裡再給一個「就算合約沒寫好也能自保」的做法:把四把鑰匙握在自己手上——網域註冊商帳號、主機或建站平台帳號、Google Analytics 資源、Search Console 資源,這四個從第一天就用你公司的信箱建立,廠商是被邀請進來的協作者。這四把鑰匙不牽涉任何技術能力,你只需要保管帳號密碼。握著這四把鑰匙,最壞的情況也只是重做網站,而不是連公司在網路上的身分都失去。

另外提醒一個非糾紛但同樣重要的事:上線不是終點。網站上線後三到六個月,你應該回頭做一次體檢,看看實際跑起來有沒有出現當初驗收看不出來的問題——這部分可以對照中小企業網站常見技術問題自我健檢,以及製造業官網 SEO Checklist。順帶一提,如果你的專案有數位轉型補助的可能性,經濟部中小及新創企業署主管多項相關資源,可以到中小企業數位轉型資訊平台與三十人以下製造業數位轉型專區查詢——補助條件與金額每年變動,一律以官方最新公告為準,規劃時不要把補助當成已經到手的預算。

八、把兩份清單放進時間表:發包前後該做什麼

直接回答:規格書要在詢價之前完成,驗收清單要在簽約時就附在合約後面當附件,兩者都不是事後補的文件。 順序錯了,清單就失去了約束力。

一份可以照抄的發包時間表

實務上的操作順序是這樣的:

1. 第 0 週:寫規格書。 用第二節的十二欄表格,自己先寫一版。寫不出來的欄位就是你還沒想清楚的地方,那正是要在發包前想清楚的。
2. 第 1 週:用同一份規格書向三家詢價。 這一步的價值不只是比價,更是比理解:三家對同一份規格書的回應差異,會告訴你誰真的看懂了你的需求。報價單怎麼拆解、哪些項目該懷疑,費用與報價單那一篇講得更細。
3. 第 2 至 3 週:平台與技術路線確認。 這時候再決定要走 WordPress、SaaS 建站平台還是客製開發,判斷依據可以參考平台選擇的比較。注意順序:先有需求,再選平台,反過來很容易被工具的限制綁架。
4. 簽約時:把規格書與驗收清單一起列為合約附件。 這是整個流程最關鍵的一步。合約本文寫權責,附件寫規格與驗收,兩者互相引用。
5. 上線前一到兩週:在測試網址上跑完二十八項驗收。 逐項勾、拍照存證、列出待修清單。
6. 切換正式網域後:再跑一次第 1 到 6 項與第 18 到 24 項。 因為換網域本身就會影響憑證、轉址與 Search Console 設定,這是最容易在最後一哩掉東西的環節。
7. 上線後 30 天:回頭看 GA4 與 Search Console 的第一批數據。 這時候才會知道網站是不是真的被索引、表單是不是真的有人填。

最後講一句持平的話。這篇文章寫了兩張清單、十項合約條款、三種糾紛的預防方式,但它的目的不是要你把廠商當賊防。台灣做網站的廠商大多是認真的小團隊,他們最怕的其實跟你一樣:需求不清楚、意見改不完、專案結不了案。 一份寫清楚的規格書與一張大家都同意的驗收清單,對他們來說是「終於有人講清楚要什麼」,對你來說是「終於知道錢花在哪裡」。這是一件雙贏的事,而且成本只是你在發包前多花的那兩個小時。

想看整個系列與其他網站主題的文章,可以從網站與 SEO 主題頁進去。