網站驗收清單：上線前該逐項確認的 5 大面向

買預售屋交屋那天，沒有人會拿到鑰匙就轉身離開。老練一點的屋主會帶著一張驗屋清單，把每扇窗開關一遍、每個插座插上測電筆、每片磁磚敲一敲聽有沒有空心，確認拿到的房子跟當初圖面說好的一樣，才在點交單上簽名。網站做完的那一刻，其實也是同一種交屋現場。只是多數人簽下網站結案單時，心裡想的是「終於做完了」，而不是「這樣真的能用嗎」。

問題在於，設計公司說「做好了」，跟這個網站真的沒問題，中間隔著一段距離。畫面好看只是最表層的那一項，手機版會不會跑版、聯絡表單送出後你到底收不收得到通知信、網站開起來夠不夠快、網域到底登記在誰名下，這些在「看一看、點一點」的匆忙簽收裡幾乎都被跳過。網站驗收，就是在正式上線前，拿一張逐項對照表把這些看得見與看不見的地方全部確認過一遍。 少了這一步，等到上線後才發現手機版整頁跑掉、詢價信件三個月都沒進到信箱，補救的成本會比驗收當下高出許多。

這篇會把網站驗收拆成五個面向，從最容易被跳過的依據對齊講起，一路帶到簽收前那幾天期限藏著的申訴空間。你可以把它當成自己的那張驗屋清單，收到「做好了」的通知時照著走一遍。

網站驗收要驗什麼，得先弄清楚依據是什麼

驗收不是簽約當下的事，而是網站做完、正式上線前的最後一道把關。這個時間點之所以關鍵，是因為它是你唯一能拿著「當初談好的內容」去對照「實際做出來的東西」的機會。一旦簽了字上了線，再回頭說「這個功能好像不太一樣」，立場就弱了一大截。

所以驗收真正的第一步，不是打開網站猛點，而是先把手上的「驗收依據」找齊。這些文件是你判斷「符不符合當初說好的範圍」的唯一標準，通常包括這幾樣：

1. 合約與報價單：白紙黑字寫了要做哪些頁面、含哪些功能、報價涵蓋到哪裡。
2. 設計稿或線框圖：版面、配色、頁面結構要跟提案時看到的一致。
3. 功能需求清單：會員登入、金流串接、多語系這類功能，有沒有逐項對得上。
4. 過程中的往來紀錄：Email、通訊軟體訊息裡談定的修改與追加，都是依據的一部分。

為什麼要先對齊依據，再開始檢查？因為沒有明確依據時，最常出現的就是「我以為有包含這個功能」的認知落差。舉個去識別化的情境，一位中小企業經營者簽約時口頭談好網站要有線上預約功能，等到交付時翻遍規格書卻發現上面根本沒寫這一條。這種時候如果沒有書面依據，很容易變成各說各話。先把依據攤開來對，就能把「這是原本範圍」跟「這是後來新增的需求」清楚分開。

那萬一真的沒有完整的書面文件呢？回頭翻對話紀錄，把散在 Email 和訊息裡的共識整理出來，以雙方都認可的最後一版需求為準，也好過憑印象爭論。要記得，驗收不是找碴，而是確認你拿到的東西跟當初談好的範圍一致。有了清楚的依據，這件事才對得起來。

網站驗收要留多久時間，太趕會漏看什麼？

一個單純的形象網站，安排一週內驗完通常還算從容；但如果網站含電商購物車、會員系統或金流串接，驗收往往需要三週以上。在國際軟體測試的實務裡，使用者驗收測試（UAT，User Acceptance Testing）本來就是一個結構化的過程，執行時間會抓在 1 到 4 週不等，完全看專案規模與要回報的問題量而定，而不是一次點完就算數的一次性事件。

會強調這件事，是因為最常見的踩雷模式就是「趕著上線，驗收只花一個下午」。這通常不是因為經營者不夠細心，而是根本沒有替驗收預留足夠的時間。一個下午能做的，頂多是把首頁點開、看幾張圖、確認畫面沒歪，然後急著簽字。真正需要逐頁點過的表單、每個裝置都要開一次的排版、後台要實際操作一輪的功能，全部被壓縮掉了。結果就是錯字、跑版、表單沒收到信這類問題，全被原封不動帶到上線之後，再花更高的力氣回頭修。

驗收要花的時間，其實跟這篇後面會談到的一件事直接相關。合約裡通常會寫一個「驗收期限」。你安排給自己的檢查天數，最好落在那個期限之內，否則期限一到、你卻還沒驗完，處境會很被動。這一點稍後會單獨拆開來講，這裡先記著一句話，留給驗收的時間不是奢侈，而是你日後的申訴籌碼。

功能能不能用，要自己動手一項項點過

每個按鈕、每個表單都要自己操作一次

功能驗收最忌諱的，就是聽設計公司一句「都測過了」就放心。不是對方不專業，而是他們測試時的心態跟真實使用者不同。開發者知道「該怎麼填才對」，會下意識避開容易出錯的操作。真正能把問題逼出來的，是你親手把每一個互動功能都當成第一次的訪客操作一遍。

實務上最容易被忽略、卻最常出狀況的，是這幾項：

1. 表單通知信：這是最該優先測的一項。聯絡表單、詢價表單送出後，通知信有沒有真的寄到、寄到的是不是正確的信箱，信件內容有沒有跑版或漏掉欄位。很多人以為表單能送出就沒事，其實信根本沒進來。
2. 選單與按鈕的跳轉：每一個導覽選單、每一顆行動按鈕都點過，確認跳到的是對的頁面，沒有連到空白頁或跳錯地方。
3. 有沒有 404：站內連結逐個點，看會不會出現找不到頁面的錯誤。
4. 搜尋功能：如果網站有站內搜尋，隨手打幾個關鍵字，看找不找得到對應的內容。
5. 後台操作：實際登入後台，把新增、編輯、刪除一篇內容都做一次，確認流程順不順、存檔會不會出錯。

這裡要特別把表單通知信單獨拉出來提醒。信箱設定是最容易埋雷的地方，尤其當公司換過負責人、或原本收信的員工已經離職，通知信很可能還寄往一個沒人在看的舊信箱。有一種情況並不少見，某家中小企業的詢價信一直寄到已離職員工的信箱，過了一週才發現有客戶留了資料卻始終沒人回。這種洞光看畫面永遠看不出來，只有自己送出一次測試表單、確認信真的進到現在會看的信箱，才抓得到。

錯誤情境也要故意測一次，不是只測「正常操作」

多數人驗收只測「一切順利」的情境，像是欄位好好填、流程順順走，看到成功畫面就打勾。但真實訪客不會這麼乖，他們會填錯格式、會漏填、會手殘打錯網址。網站在這些「不順」的時刻怎麼反應，才是體驗好壞的分水嶺。在軟體測試領域，這類刻意去戳邊界的測試就叫異常情境（edge case）測試，而國際的驗收測試指南也一再強調，測試案例要同時涵蓋核心使用流程與這些異常情境，不能只跑順的那一條路。

具體要故意測這三種：

1. 表單填錯時的反應：在 Email 欄位打一個不完整的格式、把必填欄位留空就按送出，看網站有沒有跳出清楚的錯誤提示，告訴使用者哪裡要改。如果錯了也沒反應、或整個表單直接卡住，那就是問題。
2. 手機版的輸入體驗：用手機打開表單，看電話欄位會不會自動跳出數字鍵盤、Email 欄位有沒有對應的輸入模式。這種細節做對了，客戶填起來才不會煩躁到中途放棄。
3. 404 頁面合不合理：故意在網址列打一個不存在的網址，看跳出來的 404 頁面有沒有提供返回首頁或搜尋的路徑。一個只丟出冷冰冰「找不到」的 404，等於把迷路的訪客直接推走。

這幾項平常沒人會刻意去做，也正因為如此，設計公司自己測的時候常常跳過。驗收時多花幾分鐘去戳這些邊角，往往能提前攔下上線後才會被客訴的問題。

手機、平板、不同瀏覽器打開，會不會走樣？

同一個網站，在你的桌機螢幕上看起來完美，換到手機上可能整排文字被切掉、按鈕小到手指按不準。這就是為什麼響應式設計（RWD）的跨裝置檢查不能省。你不能只用一台電腦驗收一個大家其實多半用手機打開的網站。

正確的做法是分別在桌機、平板、手機上，把每一頁都瀏覽過一次，重點看三件事：排版有沒有跑版錯位、文字有沒有被截斷、按鈕大小適不適合用手指點。這一輪逐頁走下來，特別要盯幾個容易被忽略的角落：

1. 頁尾資訊：footer 的地址、電話、版權年份這些資訊常常是最後才填、也最容易填錯或漏更新的地方。
2. 動畫與滾動效果：華麗的動畫在展示機上很順，但在效能較弱的舊手機上可能卡頓掉幀，值得拿一台不那麼新的手機實際滑一次。
3. 空狀態畫面：如果網站有搜尋或篩選功能，試著搜一個查不到結果的關鍵字，看「沒有結果」時畫面呈現合不合理。很多設計只顧著把「有內容」的畫面做漂亮，卻忘了訪客搜不到東西時看到的是什麼。

裝置之外還有瀏覽器。同一段程式碼在不同瀏覽器的呈現偶爾會有差異，所以至少要在 Chrome、Safari、Edge 這三個主流瀏覽器上分別打開來看過，確認沒有哪一家會把版面顯示歪掉。這一步花不了太多時間，卻能避免「我的客戶用某個瀏覽器打開，整個網站是壞的，而你自己從來沒發現」的窘境。

網站開起來會不會慢半拍，怎麼知道多快才算合格？

速度這一項，最怕的就是憑感覺驗收。「打開來還算快吧」是一句沒有標準的話：你的網路快、你的電腦好、你又早就看習慣了，感覺永遠會比第一次來的訪客寬容。要驗速度，得換成有具體數字、能拿去跟人談的依據。

Google 官方提出的核心網頁指標（Core Web Vitals）就是這套依據，它用三個數字量出訪客實際感受到的載入體驗，各有明確的及格線：

1. 最大內容繪製（LCP）：頁面主要內容出現在畫面上要多久，建議在 2.5 秒內完成算良好，超過 4 秒就算不佳。
2. 與下一次繪製的互動延遲（INP）：你點下按鈕後，畫面隔多久才有反應，建議壓在 200 毫秒以內。
3. 累計版面配置位移（CLS）：頁面載入過程中版面會不會亂跳（正要點的按鈕突然被擠走那種），數值建議在 0.1 以下。

要量這三個數字，用 Google 免費的 PageSpeed Insights 就行，貼上網址就會跑出一份報告。它會給一個總分：90 分以上算良好、50 到 89 分屬於待改進、49 分以下就是不佳。要留意的是，這套指標評估的是「多數使用者」的實際體驗（技術上取的是第 75 百分位數的表現），不是只看你這一次打開順不順，所以比你主觀的感覺可靠得多。

速度是整個驗收裡少數能拿出硬數字卡關的項目。與其口頭抱怨「怎麼覺得有點慢」，不如附上一張 PageSpeed Insights 的檢測結果，指著分數跟設計公司討論該從哪裡優化。有數字，這段對話才站得住腳。

內容看起來對不對，這一步最多人漏看

內容與 SEO 的驗收，是整份清單裡最容易被跳過的一塊。原因很單純，人在瀏覽網頁時，根本不會去注意每一頁的網頁標題寫了什麼、Meta 描述有沒有設定、圖片背後有沒有替代文字。這些東西看不見，卻直接影響 Google 找不找得到你、要不要把你排上去。半年後才驚覺「怎麼在 Google 搜自己公司名字都搜不到」，追根究柢，往往就是這些看不見的細節在驗收時沒人檢查。

這一輪要逐頁確認的，包括這幾項：

1. 文字校對：把每頁的文字讀過一遍抓錯字，尤其是電話、地址、營業時間這種一錯就會害客戶白跑一趟、或打不進來的資訊，最該優先核對。
2. 每頁獨立的標題與描述：確認每一個頁面都有自己的網頁標題（title）與 Meta 描述，而不是全站共用同一組、或乾脆空著。這是搜尋結果上顯示給使用者看的第一印象。
3. 圖片替代文字：檢查圖片有沒有加上替代文字（alt text）。它既是搜尋引擎理解圖片內容的依據，也是視障使用者靠螢幕報讀軟體「聽」網頁時的基本無障礙需求。
4. 網址是否簡潔有意義：確認頁面網址是能讀懂的英文或有意義的字串，而不是一長串亂碼參數。
5. HTTPS 是否全站啟用：看網址列有沒有出現安全鎖頭圖示，確認整個網站都跑在加密連線上。沒上 HTTPS 的網站，瀏覽器會標記「不安全」，訪客一看就卻步。

這些項目沒有一個是點開畫面就看得出來的，全都得逐頁鑽進去確認。也正因為藏得深，它成了驗收裡最考驗耐心、卻最不該偷懶的一段。

網域、帳號、原始檔案，這些「看不到的資產」交了沒？

驗收不是只看網站「長怎樣」，還要確認一批「看不到的資產」有沒有確實交到你手上。這批東西平常不會用到，但在你想換維護廠商、或需要自己調整的那一天，少了任何一項都可能卡死。之所以常被忽略，就是因為「網站看起來能用」會讓人誤以為一切都到位了。

要逐項確認的，是這幾樣存取權與資產：

1. 網域所有權：確認網域登記在你或你公司名下，而不是掛在設計公司的帳號底下，同時記下到期日，別讓網域哪天悄悄過期。
2. 後台與主機帳號：網站後台的管理員帳號密碼、FTP 與主機的登入資訊，都要拿到自己手上。
3. 第三方服務存取權：Google Analytics、Search Console 這類分析工具的存取權限，要確認已經轉移或加入你的帳號，否則日後看不到自己網站的數據。
4. 原始設計檔案：如果合約有約定要交付設計原始檔，記得一併點收，別等要改的時候才發現手上只有已經上線的成品。

最典型的踩雷，是日後想換一家廠商維護，才發現後台密碼、網域管理權全握在原廠商手上，要不回來也改不動，整個網站等於被綁住。要避免這種局面，收到這些帳號資產後，建議統一記錄在密碼管理工具裡，而且至少讓兩個人知道怎麼存取。負責的人臨時請假或離職時，公司才不會連自己的網站都進不去。

驗收單簽下去前，這幾天期限會決定你之後有沒有申訴空間

前面每一項都測完了，最後這一步反而最容易被忽略，卻可能是影響最大的，就是簽收前先把合約裡的「驗收期限」條款讀清楚。

多數網站設計合約常見的作法，是給你一段驗收期限（實務上常見 7 到 14 個工作天）。這段期限藏著一個許多人不知道的機制，叫做「默示驗收」。它的意思是，如果你在期限內沒有用書面或 Email 明確回報問題，合約可能就默認「驗收通過」了。一旦被視為通過，之後你再回報的任何問題，都很可能被當成「新需求」，要另外計費。換句話說，你檢查得再仔細，若拖過了期限才反映，那份仔細也救不回你的立場。

所以簽收前，務必把這三件事問清楚、看明白：

1. 驗收期限是幾天：先知道自己有多少時間，才排得出前面那幾輪檢查要怎麼分配。
2. 逾期未回覆是否視為驗收通過：這就是默示驗收條款，直接關係到你萬一沒趕上，會不會被當成已經認可。
3. 回饋方式要不要書面：很多合約要求問題必須以書面或 Email 提出，口頭跟窗口反映很可能不算數。養成把問題寫成文字、留下時間紀錄的習慣，日後才有依據。

除了期限，還有兩件同樣該先問的：一是「修改次數」有沒有上限，二是超出原本範圍的調整怎麼計費。這些先問清楚再簽名，比事後為了一筆說不清的追加費用僵持要省心得多。驗收的最後一哩，往往不在畫面，而在這幾行你可能沒細看的條款裡。

驗屋清單存在的意義，從來不是要跟建商過不去，而是讓「完成」這兩個字有一個雙方都認得的定義。網站也一樣。收到「網站做好了」的通知時，先別急著把簽收單點下去。把這份清單留在手邊，替自己排出幾天時間，親手照著點過一輪。上線前的最後一哩路，值得你多花幾天親自走一次，因為這幾天花掉的力氣，遠比上線後回頭補救要輕省得多。