網站上線前的最後幾天，常是最容易遺漏細節的時候：頁面看起來都完成了，卻發現手機版選單打不開、詢問信寄到舊信箱，或測試環境被搜尋引擎收錄。與其靠每個人憑印象瀏覽一次，不如將驗收拆成明確項目，留下確認紀錄。
驗收的目的不是找設計或工程團隊的麻煩，而是確認網站已能在真實情境中，穩定地為客戶與內部人員服務。建議由熟悉業務的人員、實際回覆詢問的同仁，以及網站製作窗口共同參與。
先確認每個頁面是否說對事情
先以網站地圖或頁面清單為基礎，逐頁檢查公開內容。重點不只在錯字，也包括資訊是否已經過時，以及讀者是否能理解下一步該做什麼。
可優先核對以下項目：
- 公司名稱、地址、電話、電子信箱與營業資訊是否正確一致。
- 服務內容、適用對象、流程與聯絡方式是否符合目前的實際作法。
- 圖片是否有授權、人物與案例是否已取得公開同意。
- 暫用的範例文字、測試圖片、建置備註與空白區塊是否已移除。
- 重要頁面的標題、摘要、分享圖片是否能正確代表該頁內容。
- 每個主要頁面是否都有合理的下一步，例如查看服務、預約諮詢或前往聯絡頁。
若團隊有多人校稿，可在清單中標記頁面負責人與確認日期。不要只用口頭說「看過了」；日後若發現資訊變更，也能快速找到應更新的位置。
用真實使用情境測試功能
功能測試應以訪客實際會做的事情為主，而不是只確認按鈕「有反應」。例如，從搜尋結果進入服務頁、閱讀內容、填寫表單，再由內部收到通知並回覆，這才是一條完整路徑。
請至少測試：
- 所有導覽選單、頁尾連結、外部連結與檔案下載是否前往正確位置。
- 詢問表單的必填提示、錯誤訊息與送出成功畫面是否清楚。
- 表單送出後，客戶收到的通知與內部收件信箱是否都正確；垃圾郵件匣也要檢查。
- 電話連結、地圖、社群連結及預約工具是否能在手機上正常使用。
- 若有購物、會員、報名或付款流程，需以測試帳號完整走一次，並確認取消或失敗時的說明。
測試時別只使用熟悉網站的人。請同事依照一個任務自行操作，例如「找到適合的服務並送出需求」，再觀察他在哪裡停下來。這類回饋往往比單純檢查版面更能發現動線問題。
同時檢查桌機、手機與常見瀏覽器
網站在設計稿上的呈現，與不同裝置上的實際體驗可能有差距。尤其手機訪客常在網路不穩、螢幕較小或單手操作的情況下瀏覽，不能只縮小桌機視窗就視為完成測試。
檢查時請留意：
- 手機版文字是否過小、段落是否擁擠，重要按鈕是否容易按到。
- 選單展開後是否能關閉，浮動按鈕會不會遮住內容或表單欄位。
- 橫式圖片、表格、地圖與嵌入內容是否造成頁面左右捲動。
- 常用瀏覽器中，字型、圖片、互動效果與表單是否正常。
- 低速網路下，主要內容是否能先出現，載入中的畫面是否讓人誤以為網站故障。
不必追求每一款舊裝置的視覺完全一致，但主要任務必須可完成。若某項功能只支援特定環境，也應提供清楚替代方式。
上線設定與交接不能留到最後一刻
公開前後還有一些不容易被訪客看見、卻會影響營運的設定。建議指定一位窗口逐項確認，避免「以為別人會處理」。
例如確認正式網域已使用安全連線、網站分析與轉換事件依需求設定、測試站不再對外開放或被索引，以及舊網址已有妥善轉址。也要確認網域、主機、CMS、信箱與第三方服務的帳號擁有權屬於公司，而非只綁在某位離職風險較高的個人帳號。
交接資料至少應包含登入入口、權限名單、備份位置、更新方式、廠商聯絡窗口與發生異常時的通報順序。這些資料應存放在公司可控管的位置，並限制敏感資訊的閱覽權限。
上線後安排一次短期巡查
公開後的第一週，建議固定查看表單通知、網站錯誤頁、重要連結與流量異常。上線當天也可由不同網路環境各瀏覽一次，確認網域解析與安全連線沒有問題。
上線不是專案結束，而是開始累積使用者回饋。將第一批常見詢問、找不到的資訊與操作障礙記錄下來，往往就是下一輪內容與體驗優化最可靠的依據。
今天可以立即做的事
- 建立一份頁面清單，為每頁標記內容確認人與完成日期。
- 用手機完成一次「找到服務、填表送出、收到回信」的完整測試。
- 確認所有網站相關帳號的公司擁有權與緊急聯絡窗口。
- 為上線後七天安排一位負責查看表單與錯誤回報的人員。
