網站上線檢查清單應按依賴順序驗收：先確認 DNS、主機和 SSL，再檢查 staging noindex、robots.txt、canonical、XML Sitemap 和 301 轉址，最後用 Google Tag Manager（GTM）Preview、Google Analytics 4（GA4）DebugView、Google Search Console（GSC）URL Inspection 及真人表單測試確認追蹤和轉換。新網站只有在可訪問、可索引、可追蹤、可提交查詢，並且帳戶權限已交接後，才算真正完成上線。
網站外觀看起來完整，但沒有人確認 DNS 是否指向正確主機、表單是否真的送到公司信箱、GA4 是否仍在記錄 staging 網域的數據。這種情況比想像中常見。
設計驗收、技術驗收和市場營銷驗收是三件事，不能用首頁能打開代替全部驗收。每個項目有各自的負責人、測試方法和阻斷條件，任何一個環節沒有完成，後面的測試結果都會失真。
本文把驗收清單分成五類，涵蓋上線前、切換當日、上線後 24 小時和 14 至 90 日監察，並為每一項列出驗證方式。
網站上線前檢查應由哪幾類組成？
網站上線是一條依賴鏈，而不是一個設計完成日。如果前一個條件沒有滿足，後面的測試就無法得出可信結論。建議把驗收分成以下五類：
| 驗收類別 | 核心項目 | 負責人 | 阻斷條件 |
|---|---|---|---|
| 可訪問 | DNS、主機、SSL、HTTPS | DNS 管理員 / 主機供應商 | DNS 未指向正確主機時，其他測試無效 |
| 可索引 | robots.txt、noindex、canonical、XML Sitemap、301 | SEO 負責人 / 開發者 | staging noindex 未移除時，正式網站無法被收錄 |
| 可追蹤 | GA4 Measurement ID、GTM 版本、GSC property | 數據分析師 / Marketing Manager | 安裝 staging ID 時，所有數據記錄到錯誤屬性 |
| 可轉換 | 表單、WhatsApp、電話 CTA、Thank-you page | 開發者 / 項目負責人 | 按鈕 click 不等於成功提交，需要後端確認 |
| 可交接 | 帳戶擁有權、管理員權限、備份、rollback | 項目經理 / 客戶代表 | 沒有 DNS 或 GSC 權限，問題出現時無法應對 |
每個類別需要有實際測試證據，不是打勾就等於完成。
先確認上線情境：新網域、改版、搬主機還是換 CMS？
上線情境不同，驗收要求也不同。全新網站只需確認基礎 DNS、SSL 和首次索引設定。改版或搬遷網站則需要額外處理 301 轉址 mapping、舊 URL 的 canonical 承接和流量基準線比較。只是換主機而 URL 和 CMS 不變，只需要基礎設施 QA 和監察，不需要完整 SEO migration 程序。
弄清楚情境，是避免過度或不足驗收的第一步。
用負責人、狀態和證據管理驗收
一般清單最大的問題是只列出要做的事，沒有記錄誰負責、測試了甚麼、結果是甚麼。建議每個驗收項目都包含：項目名稱、負責人、測試方法、測試結果（截圖或 export）、狀態（通過 / 待確認 / 阻斷）和阻斷問題說明。這樣的驗收表才能用作正式簽核，而不只是個人備忘錄。
新網站 SEO 檢查應該先做甚麼？
新網站 SEO 檢查的正確順序是先做索引控制，再做 metadata 和 Sitemap 提交。索引控制出問題，metadata 寫得再好也沒有意義。
第一步：確認 staging 環境的索引狀態
- 確認 staging 網域是否有
noindex指令或登入限制。 - 切換到正式網域前，staging 的
noindex必須清楚設定，避免 Google 爬取暫存版本。 - Google Search Central robots.txt 文件明確說明 robots.txt 只控制爬蟲存取，不是 noindex 工具，兩者功能不可互換。
第二步：正式網域的 robots.txt、canonical 和 XML Sitemap
- 在瀏覽器直接查看
yourdomain.com/robots.txt，確認沒有Disallow: /阻擋重要頁面。 - 主要頁面的 canonical tag 必須指向正式 URL，沒有殘留 staging 或帶有 query parameter 的版本。
- XML Sitemap 列出所有應被收錄的頁面，確認沒有包含
noindex頁面。Google 的 Sitemap 說明指出 Sitemap 是協助 Google 發現 URL 的提示，不保證收錄。
第三步：Title、Meta Description、H1 和結構化資料
- 每個主要頁面都有唯一 Title Tag 和 Meta Description，沒有重複或空白。
- H1 只有一個，和頁面主題一致。
- 如有使用結構化資料（JSON-LD），確認資料與頁面可見內容完全一致。Google 的結構化資料政策清楚說明結構化資料是 Rich Result 的資格訊號，不是展示保證。
- 內部連結指向正式 URL，沒有殘留 staging 或 HTTP 連結。
如需了解更多技術 SEO 配置和 GEO 優化策略，可參考 LetsGetWeb 的技術 SEO、GEO 與 AIO 服務。
staging 與 production 的索引控制
最常見的錯誤之一：開發期間 staging 沒有 noindex，或者正式上線後 production 忘記移除 noindex。兩種情況的後果都不同：前者導致 Google 爬取未完成的內容，後者導致正式網站完全不被收錄。
建議在切換 DNS 前，用 GSC 的 URL Inspection 工具測試一個已知應被收錄的頁面，確認其 indexability 狀態。
robots.txt、noindex、canonical 和 XML Sitemap
這四個工具的功能各不相同，不能互相替代：
- robots.txt：控制爬蟲存取，不能移除已收錄頁面的索引。
- noindex：告訴 Google 不要將頁面收錄，但爬蟲仍可訪問頁面。
- canonical：向 Google 說明哪個 URL 是正式版本，用於處理重複內容。
- XML Sitemap：提示 Google 應該爬取哪些 URL，不保證收錄或排名。
Title、Meta Description、H1、內部連結和結構化資料
上線前保存每個主要頁面的 URL Inspection 結果和 HTTP response 截圖作為基準線。改版情況下，需要對照舊 URL 和新 URL 的 301 mapping，確認每個舊 URL 指向最相關的新頁面，而不是全部轉到首頁。Google 的 site move 文件說明 301 只適用於 URL 永久改變的情況，單純換主機而 URL 不變，不應無故增加 301 轉址。如需深入了解改版搬遷流程，可參考網站改版 SEO 搬遷清單。
多語言網站才檢查 hreflang 和 x-default
只有網站實際有繁體中文、英文或簡體中文不同 URL 版本時，才需要檢查 hreflang 和 x-default 設定。如果網站沒有多語言 URL 架構，不應假定需要加入 zh-Hant-HK 或 en-HK hreflang 標記。
DNS、主機和 SSL 應該怎樣逐項驗收？
DNS 是所有測試的基礎。DNS 未正確指向主機，HTTPS、SEO 和追蹤的測試結果都會失真。
| 驗收項目 | 測試方法 | 通過標準 |
|---|---|---|
| DNS A record / CNAME | DNS 查詢工具或主機控制台 | 指向正確主機 IP 或 CNAME |
| www 和 apex domain | 瀏覽器直接訪問兩個版本 | 兩者都能正常載入 |
| SSL 憑證有效性 | 瀏覽器鎖頭圖示或 SSL 檢查工具 | 憑證有效且涵蓋實際使用的 hostname |
| HTTP 到 HTTPS redirect | 在瀏覽器輸入 http:// 版本 |
自動 301 redirect 到 https:// |
| Mixed content | 瀏覽器開發者工具 Console | 沒有 mixed content 警告 |
DNS record 是否指向正確主機
DNS 切換後，實際生效時間因 DNS 供應商、TTL 設定和網絡緩存而不同，沒有固定時限。建議用 DNS 查詢工具直接查詢 A record 或 CNAME，確認已指向正確 IP 或主機名稱，而不是依賴預估時間。
正式網域、www 與非 www 是否有一致規則
選擇一個規範版本（www 或非 www），確保另一個版本 301 redirect 到規範版本。canonical tag 和 GSC property 都應與這個規範版本一致。混用兩個版本而沒有 redirect，會造成重複內容和數據分散。
SSL 憑證是否涵蓋所有實際使用的網域
Cloudflare 的 SSL/TLS 說明指出 SSL 憑證建立網站身份驗證和加密連線的基礎。驗收時，確認憑證涵蓋所有實際使用的 hostname，包括 www 版本和任何必要子網域。SSL 是安全和用戶信任的技術基礎，但不是排名保證。
HTTPS、redirect 和 mixed content 測試
在桌面和手機瀏覽器分別測試 http:// 版本，確認有 301 redirect 到 https:// 版本。在開發者工具 Console 確認沒有 mixed content 警告，即頁面內所有資源（圖片、CSS、JS）都透過 HTTPS 載入。如網站使用企業電郵，DNS 的 MX、SPF 和 DKIM 記錄應由郵件供應商或 DNS 管理員另行確認，超出網站上線驗收範圍。
GA4、GTM 和 Search Console 怎樣確認已經正常？
這三個工具分工不同，各自需要獨立確認：GA4 負責事件收集和分析，GTM 管理 Tag 和 Trigger 的部署，GSC 反映 Google Search 對網站的理解和索引狀態。
工具分工確認清單：
- GA4：正式網域安裝的是正式 Measurement ID，不是 staging 環境的 ID。在 DebugView 確認預期事件正常觸發，沒有重複計算。
- GTM：已發布正確 container 版本，Preview 模式顯示預期 Tag 只觸發一次。確認沒有殘留 staging container 或測試 Tag。
- GSC：Domain property 已用 DNS TXT record 驗證，涵蓋所有 protocol 和 subdomain 變體。XML Sitemap 已提交到正式 property。
GA4 Measurement ID 和正式環境
最常見的 GA4 錯誤是把 staging 環境的 Measurement ID 留在正式網站，導致所有正式流量數據記錄到測試屬性。上線前，在正式網域用 GTM Preview 確認只有正式 Measurement ID 觸發，GA4 Realtime 報告顯示正式網域的訪客數據。根據 GA4 官方說明，事件、參數和 Key Event 的設定應按業務意義決定，不應把所有 scroll 或 click 都設為轉換事件。
GTM Preview、DebugView 和事件參數
GTM Preview 模式讓你在發布前確認每個 Tag 的觸發條件和順序。結合 GA4 DebugView，可以逐個事件確認名稱、參數和觸發次數是否符合預期。記錄測試日期、GTM container 版本號碼和測試人員姓名，作為上線驗收證據。
GSC Domain property、URL Inspection 和 Sitemap 提交
GSC Domain property 需要 DNS TXT record 驗證，驗證後涵蓋所有 protocol 和 subdomain 版本。GSC 驗證說明詳細列出 Domain property 和 URL-prefix property 的差異，前者需要 DNS 存取權限。提交 XML Sitemap 後，在 GSC Sitemap 報告確認狀態為「成功」。
如需追蹤表單、WhatsApp 和電話點擊的詳細事件設定，可參考GA4、WhatsApp、電話與表單追蹤指南。
表單、WhatsApp 和電話點擊怎樣驗收？
香港服務型網站最常見的轉換入口有三個：聯絡表單、WhatsApp 按鈕和電話連結。三者的 GA4 事件追蹤能力和實際業務意義有明顯差距，必須分清楚。
| CTA 類型 | GA4 能證明的事 | GA4 不能證明的事 |
|---|---|---|
| 表單提交 | 按鈕 click、頁面瀏覽 Thank-you page、dataLayer 事件 | 後端是否真的收到、是否合資格查詢 |
| WhatsApp 點擊 | 外部連結 click 事件 | 訊息是否已送出、是否已回覆、是否成交 |
| 電話點擊 | tel: 連結 click 事件 |
電話是否已接通、通話內容 |
點擊事件不等於成功查詢
表單按鈕 click 和表單成功提交是兩個不同事件。用戶可以點擊提交按鈕，但表單因驗證錯誤而沒有送出，這個 click 仍會觸發 GA4 事件。WhatsApp click 代表用戶在網站上點擊了按鈕，不代表 WhatsApp 應用程式已開啟、訊息已送出或已有回覆。電話 click 同樣道理。
表單成功條件：Thank-you page、後端回應或 dataLayer
確認表單成功提交的最可靠方式是同時滿足三個條件：前端顯示成功訊息或轉到 Thank-you page、公司收件信箱或 CRM 收到查詢、後端紀錄有對應的提交記錄。GA4 的 generate_lead 或自定義成功事件應只在以上條件成立時觸發，而不是在按鈕 click 時觸發。
至少進行一次桌面測試和一次手機測試，記錄測試時間、使用的測試信箱、收件結果、GA4 事件名稱和是否出現重複觸發。
香港服務網站的手機 CTA 測試
香港用戶普遍使用手機查詢，WhatsApp 和電話 CTA 的手機體驗直接影響轉換率。在 iOS 和 Android 分別測試 WhatsApp 連結是否正確開啟，電話連結是否直接撥打。確認手機版的表單欄位、鍵盤類型和提交按鈕在小屏幕上可以正常操作。追蹤這些數據的商業決策可參考 LetsGetWeb 的營收增長諮詢。
網站上線前最容易漏掉的檢查是甚麼？
最容易漏掉的不是高難度技術問題，而是責任不清和沒有人簽核的灰色地帶。以下是四個最常被忽略的範疇：
1. 帳戶擁有權和管理員權限：確認客戶持有網域註冊商、主機、CMS、GSC、GA4 和 GTM 的管理員帳號。外判項目完成後，供應商是否仍是唯一管理員，是一個常見但嚴重的問題。
2. 備份和 rollback 計劃：上線前備份舊網站（如有），確認有人知道如何在問題出現時回滾到上一個版本，以及誰有權作出 rollback 決定。
3. 404、500 和搜尋功能：用爬蟲工具或手動測試主要頁面，確認沒有 404 或 500 錯誤。如有站內搜尋功能，測試幾個關鍵詞確認結果正常。
4. 跨瀏覽器和手機測試：在 Safari 和 Chrome 分別測試，確認主要頁面、圖片、表單和 CTA 在手機上正常顯示和運作。
帳戶擁有權和權限
建議用以下交接表記錄每個資產的責任人：
| 資產 | 持有帳戶 | 管理員 | 驗證方式 | 狀態 |
|---|---|---|---|---|
| 網域註冊商 | 客戶 | 客戶 | 登入確認 | 待確認 |
| 主機 / 寄存 | 客戶 | 客戶 | 登入確認 | 待確認 |
| Google Search Console | 客戶 | 客戶 | Property 擁有者 | 待確認 |
| Google Analytics 4 | 客戶 | 客戶 | Admin 角色 | 待確認 |
| Google Tag Manager | 客戶 | 客戶 | Admin 角色 | 待確認 |
| CMS | 客戶 | 客戶 | Admin 登入 | 待確認 |
備份、rollback 和交接文件
如果上線後出現嚴重問題，有沒有可以立即回滾的版本、有沒有人有權限執行操作，是決定損失大小的關鍵。備份和 rollback 計劃不需要複雜，但必須在上線前確認。
404、500、搜尋、圖片、瀏覽器和行動版
圖片的 alt text 是否填寫、圖片是否透過 HTTPS 載入、搜尋功能是否有返回結果，這些細節在桌面測試時容易被忽略，但在手機使用者體驗上影響明顯。
網站上線當日應該按甚麼順序操作？
上線當日是壓力最高的時刻，清晰的操作順序能減少出錯機會。
上線前 freeze
- 停止對 staging 的內容修改，確認最終版本已備份。
- 確認 GTM container 最新版本已發布，GA4 正式 Measurement ID 已就位。
- 確認 301 mapping 文件（如適用）已完成並測試。
DNS 切換與 live smoke test
- 切換 DNS，用查詢工具確認 A record 或 CNAME 已更新。
- 在瀏覽器測試正式網域：首頁、主要 landing page 的 HTTP 狀態（應為 200）。
- 確認 HTTPS 正常，HTTP 自動 redirect 到 HTTPS。
- 確認 robots.txt 沒有阻擋重要頁面，canonical 指向正式 URL。
- 用 GTM Preview 在正式網域確認 Tag 觸發正常，GA4 Realtime 收到數據。
- 真人提交一次測試表單，確認收件和 GA4 事件同時成立。
- 手機測試 WhatsApp 和電話 CTA。
記錄每一步的執行時間、負責人和結果。
上線後 24 小時監察
- 持續查看 GA4 Realtime，確認流量來源正常，沒有大量 direct 或 referral 異常。
- 在 GSC 用 URL Inspection 測試主要頁面，提交 XML Sitemap（如未提交）。
- 檢查 GSC Coverage 報告有沒有新增 404 或 crawl error。
- 第 14、30、60 和 90 日繼續監察 GSC 曝光數、點擊率、平均位置、GA4 事件和表單查詢數量。
根據 Google site move 文件，建議在啟用 redirect 前先完成 URL mapping 測試，再正式切換，以減少排名波動風險。
甚麼情況不適合自行完成網站上線驗收？
以下情況建議找同時懂開發、SEO 和數據追蹤的專業團隊協助：
- 同時更換網域、CMS、URL 結構、追蹤設定和內容。
- 網站已有重要的自然搜尋流量，改動可能影響現有排名。
- 沒有 DNS、GSC、GA4 或主機的管理員權限。
- 沒有完整的舊 URL mapping，無法確認 301 轉址覆蓋。
- 沒有人能在問題出現時執行 rollback。
如果只是換主機，URL、CMS、內容和追蹤設定都沒有改變，可能只需要基礎設施 QA 和上線後監察，不一定需要完整 SEO migration 服務。
URL、網域、CMS 和追蹤同時改變
多個變數同時改變時，出現問題後很難判斷根因。建議分階段進行，或在有完整基準線數據的情況下才啟動改版。
沒有 DNS、GSC、GA4 或主機權限
沒有帳戶存取權限，驗收只能停留在表面，出現問題時也無法即時處理。
沒有可比較的上線前基準線
沒有上線前的流量、排名和轉換基準線，上線後無法判斷數據變化是正常波動還是技術問題。
LetsGetWeb 提供網站設計、技術 SEO 和營收增長諮詢，協助香港企業完成網站上線驗收和追蹤設定。具體服務範圍需按專案確認，本文的服務提及不是獨立第三方評測，服務內容於 2026 年 9 月查核，發布前請重新核對官方頁面。如需了解詳情，可參考 LetsGetWeb 網頁設計服務。
常見問題：網站上線檢查清單
1. 網站上線前最少要檢查甚麼？
最少要確認正式網域可訪問、HTTPS 正常、robots.txt 和 noindex 設定正確、主要頁面 HTTP 狀態為 200、GA4 和 GTM 安裝在正式環境、表單可以成功提交並收到查詢、帳戶管理員權限已交接。
2. 新網站 SEO 檢查應該先做甚麼？
先確認 staging 的 noindex 或登入限制已設定，再確認正式網站的 robots.txt、canonical 和 XML Sitemap 沒有阻擋重要頁面，最後用 GSC URL Inspection 測試主要頁面的 indexability。
3. robots.txt 可以阻止網站被 Google 收錄嗎？
不能。robots.txt 只控制爬蟲存取，不能移除已收錄頁面的索引。如需阻止頁面被收錄，應使用 noindex 指令、密碼保護或從頁面移除。詳見 Google robots.txt 文件。
4. XML Sitemap 提交後是否一定會收錄？
不一定。Sitemap 是協助 Google 發現 URL 的提示，不是收錄保證。Google 會根據頁面品質、內容和其他訊號決定是否收錄。
5. GA4 怎樣確認已經正常？
在正式網域用 GTM Preview 確認 Tag 觸發正常，再用 GA4 DebugView 和 Realtime 報告確認事件名稱、參數和觸發次數符合預期，沒有重複觸發。
6. 表單按鈕點擊是否等於成功提交？
不等於。成功提交需要同時確認前端成功訊息或 Thank-you page、後端收件記錄，以及 GA4 明確的成功事件，而不只是按鈕 click 事件。
7. WhatsApp 點擊可以當成成交嗎？
不可以。WhatsApp click 只代表用戶在網站點擊了連結，不能證明訊息已送出、已回覆或已成交，lead quality 需要 CRM 或人工跟進才能確認。
8. 網站改版是否一定要做 301？
只有舊 URL 永久改變時才需要 301 轉址。單純換主機而 URL 不變，不應無故增加 301。每個舊 URL 應指向最相關的新頁面，而不是全部轉到首頁。
9. SSL 檢查要看甚麼？
確認憑證有效且未過期、涵蓋實際使用的所有 hostname（包括 www）、HTTPS 連線正常、HTTP 自動 redirect 到 HTTPS，以及頁面沒有 mixed content 警告。
10. 網站上線後第一日要看哪些數據？
先確認 DNS、HTTPS 和主要頁面 HTTP 狀態，再看 GA4 Realtime 流量來源、測試表單提交、GSC URL Inspection 結果、Sitemap 提交狀態和有沒有新增 404 錯誤。
結論：用驗收證據，而不是首頁外觀，判斷網站是否真正上線
可以自行上線的情況：URL 沒有改變、DNS 和帳戶權限清楚、表單和 GA4 有人負責測試，並且所有驗收項目都有記錄和截圖。
需要專業 QA 的情況：同時改網域、CMS、URL、內容、SEO 和追蹤設定，或網站已有重要的自然搜尋流量，改動風險較高。
上線後仍需持續監察：無論是自行還是外判，都要在上線後 24 小時、14 日、30 日、60 日和 90 日按技術和商業指標持續確認，包括 GSC 曝光、GA4 事件、表單查詢數量和 404 狀態。
如不確定網站是否真的通過 DNS、SEO、追蹤和表單驗收，可先安排網站健檢或免費 Demo 諮詢。