網站上線前檢查清單：上線當天流程與上線後監看重點
網站開發的最後一哩，常常是整個專案最混亂的一段。設計驗收過了、功能測完了，然後有人問一句「那什麼時候上線」，接下來就是一連串沒人記得誰該負責的細節。
上線不是一個動作，而是一段需要順序的流程。這篇提供一份可以直接拿去用的清單，以及上線當天與上線後該做的事。建議在預定上線日的前一週就開始逐項打勾，而不是當天才開始找。
上線前檢查清單
內容與文案
- 全站錯字與語句校對，特別注意標題、按鈕文字與表單提示
- 聯絡資訊正確：電話、地址、營業時間、電子郵件
- 沒有殘留的測試文字、假圖、開發階段的佔位內容
- 圖片都有替代文字，不只是為了無障礙，搜尋引擎也看得到
- 價格、服務內容、法定標示等敏感資訊由業務端最後確認一次
連結與表單
- 全站連結逐一檢查，沒有連到不存在的頁面
- 外部連結是否要在新視窗開啟，行為一致
- 每一個表單實際送出一次，確認有收到通知信
- 通知信寄到哪裡、寄給誰，收件者本人親自確認收得到（不要只看系統回報成功）
- 表單的必填驗證、錯誤提示、送出後的成功畫面都測過
- 垃圾訊息防護已啟用，但不會擋掉真實訪客
SEO 基本設定
- 每頁都有獨立的標題與描述，不是全站共用一組
- 網址結構乾淨可讀，沒有開發階段的暫時路徑
- 網站地圖已產生並提交給搜尋工具
- 確認已移除開發階段用來阻擋搜尋引擎的設定（這是最常見的上線事故）
- 若為改版，舊網址對新網址的轉址表已逐筆實測，詳見網站改版 SEO 檢查清單
- 結構化資料若有使用，用官方工具驗證過格式，作法可參考官網顧客評價與 Review 結構化資料
速度與行動版
- 在真實手機上實際操作一次，而不是只用瀏覽器縮小視窗
- 圖片已壓縮，尺寸符合實際顯示需求
- 首頁與主要轉換頁的載入體驗檢測過，指標與驗收方式見網站速度優化指南
- 第三方程式碼盤點過，沒有重複或已停用的追蹤碼
- 在較慢的網路環境下測試過主要流程
資安與備份
- 全站使用加密連線，沒有混合內容的警告
- 後台登入路徑、預設帳號與弱密碼都已處理
- 權限分配確認：誰能改內容、誰能改設定、誰能看到個資
- 自動備份已啟用，且實際還原過一次確認可用
- 系統與套件更新到穩定版本
- 相關基本功與事故處理順序見企業網站資安基本功
分析與追蹤
- 分析工具安裝正確，且只安裝一次（重複安裝會讓數據失真）
- 轉換事件已定義：表單送出、電話點擊、加入通訊軟體好友
- 排除自己人的流量，避免內部瀏覽污染數據
- 廣告平台的追蹤碼若有使用，一併確認，設定方式見GA4 導入指南
法務頁面
- 隱私權政策與服務條款已依實際做法撰寫，不是範本文字
- 表單旁有可點擊的政策連結
- 若採用追蹤同意機制，未同意前確實沒有載入追蹤程式
- 撰寫原則與常見錯誤見網站隱私權政策與個資法指南
網域、DNS 與憑證
- 網域的所有權在公司名下，不是在離職員工或廠商的個人帳號
- 網域續約日期已記錄，並設定提醒
- 有無帶 www 的版本統一導向同一個位置
- 憑證有效且會自動更新
- 電子郵件相關的設定不會因為網站搬遷而中斷（這是搬家時最常被忽略的一項）
- 網域與 DNS 的基本觀念見網域與 DNS 基礎指南
回退計畫
- 舊網站的完整備份（檔案與資料庫）已另外留存
- 回退需要的步驟寫成書面，並確認執行時間
- 誰有權決定回退，這個人當天在線上
- 若牽涉資料結構變更，確認回退後資料不會遺失
上線當天的流程
上線前的最後確認。把清單再跑一次重點項目，特別是搜尋引擎阻擋設定、表單通知、憑證。同時確認所有相關人員在線上。
執行切換。依既定順序操作，每完成一步就回報。切換過程中不要同時做其他變更，出事時才分得清原因。
切換後的即時驗證。用不同裝置與網路實際打開網站，不要只用自己的電腦（可能是快取）。逐一確認：首頁能開、主要頁面能開、表單能送、通知信收得到、後台能登入、加密連線正常。
對外通知。確認沒問題後，再通知業務與客服團隊，並讓他們知道遇到問題該回報給誰。
觀察期。上線後留一段時間持續觀察，不要切換完就立刻收工。驗收的方法與缺陷分級可參考軟體驗收怎麼做。
上線後該監看什麼
| 觀察項目 | 看什麼 | 出現問題代表什麼 |
|---|---|---|
| 錯誤頁面 | 搜尋工具回報的無法存取頁面 | 轉址遺漏或連結寫錯 |
| 表單送出 | 實際收到的詢問數量趨勢 | 通知信或驗證設定出錯 |
| 流量來源 | 自然搜尋與直接流量的變化 | 改版轉址或追蹤碼問題 |
| 載入速度 | 主要頁面的實際載入表現 | 圖片或第三方程式碼拖累 |
| 主機狀態 | 錯誤紀錄與資源使用 | 流量或程式問題 |
| 客服回報 | 顧客實際遇到的狀況 | 清單沒測到的真實情境 |
最有價值的訊號往往來自客服，而不是報表。 顧客說「表單按了沒反應」通常比任何監測工具都早發現問題，前提是客服知道該回報給誰。
觀察期間要克制的是「順手再改一點」。上線後的第一段時間應該只修問題，新需求先記錄下來排進下一個週期，後續的節奏規劃可參考產品上線後的優化路線。
常見的上線災難
忘記關掉阻擋搜尋引擎的設定。開發階段為了不讓半成品被收錄而加上的設定，上線時忘了移除，結果網站長期搜尋不到。
表單通知寄到沒人看的信箱。通常是廠商測試時填的信箱，上線後沒改回來，詢問全部石沉大海。
網域登記在個人帳號下。到了要續約或轉移時才發現聯絡不到當初辦理的人。
沒有備份就直接覆蓋。出事後只能硬著頭皮往前修，因為已經回不去了。
上線當天才發現內容還沒準備好。內容是最常被低估的一項，建議在專案一開始就明確約定由誰提供、什麼時候到位。
一份好的上線清單，價值不在於它多完整，而在於它逼團隊在上線前就把「誰負責、什麼時候做、出事找誰」講清楚。多數上線災難不是技術問題，而是沒人知道那件事該誰管。
如果你手上的網站專案快要進入上線階段，想確認有沒有漏項，或希望上線流程由熟悉的團隊一起走過一次，與 NETVANA 討論你的專案。NETVANA 的開發流程以兩週為一個 Sprint、每個週期結束提供可操作的 Demo，專案費用結清後原始碼、設計檔與文件完整移交，詳細節奏可以看軟體開發流程。
延伸閱讀：改版搬遷的轉址細節，可以看網站改版 SEO 檢查清單；速度指標怎麼驗收，可以看網站速度優化指南；資安與備份的基本功，可以看企業網站資安基本功；追蹤與轉換事件怎麼設，可以看GA4 導入指南；法務頁面怎麼寫，可以看網站隱私權政策與個資法指南；上線後的優化節奏，可以看產品上線後的優化路線；部署的概念確定後接著看上線當天怎麼做，可以看測試環境、正式環境與部署白話指南。
