網站檢測怎麼做？上線前 20 項功能、SEO、行動版與表單檢查

網站檢測怎麼做？上線前 20 項功能、SEO、行動版與表單檢查

內容目錄 顯示
加入為 Google 偏好來源

網站上線檢查不是把清單全部打勾，而是用證據回答「這個版本能不能正式提供使用」。完整的網站上線檢查要涵蓋主要功能與表單或交易的下游結果，也要檢查行動版和內容，核對 SEO 與分析設定，並完成安全項目。

網站首頁能開啟，不代表導覽、表單與分析事件都正常；前台顯示送出成功，也不代表後台真的收到資料。驗收要從使用者任務出發，核對瀏覽器畫面、系統紀錄、Email 或分析事件，再依 P0、P1、P2 決定上線、附條件上線或延後。

來源：數位發展部政府網站營運交流平台：上線作業與Google Search Console 網址檢查工具（查證 2026-07-24）。政府網站指南從環境部署及資料安全，到備份、功能測試與監控，都列為上線流程重點；Google 文件則說明網址檢查的索引版本與即時測試範圍。本文的 20 項驗收表與 P0／P1／P2 是專案框架，不是政府或 Google 的認證標準。

網站上線檢查是什麼？

網站上線檢查是將準備發布的網站版本，放進接近正式營運的情境中驗證。它要確認程式與內容是否正確部署，主要任務是否完成，外部服務是否串接，以及失敗時是否有回復方式。

  1. <strong>測試結果</strong>：哪些 URL、裝置與任務已驗證。
  2. <strong>問題清單</strong>：問題等級、負責人、修正期限與重測狀態。
  3. <strong>上線決策</strong>：誰決定 go、conditional go 或 no-go，依據是什麼。

上線檢查要驗證使用者任務與系統結果

網站不是一組獨立頁面，而是一連串使用者任務。企業網站常見任務包括找到服務，切換導覽，閱讀內容，送出詢價及收到確認；電商網站還包含加入購物車，付款，建立訂單及收取通知。

證據層級要回答的問題表單示例電商示例
前台結果使用者看到什麼成功訊息與錯誤提示是否正確付款結果頁是否顯示正確狀態
系統結果資料是否真的寫入後台是否新增一筆完整紀錄後台是否建立正確訂單
通知結果應通知的人是否收到客戶與站方是否收到信件訂單信與付款通知是否送達
追蹤結果分析系統是否記錄任務GA4 是否收到表單事件轉換事件是否只記錄一次

安全掃描、SEO audit 與使用者測試不是同一件事

這四種工作會重疊，但輸出不同：

工作核心問題常見輸出不能取代什麼
網站上線檢查目前版本能否正式提供使用Go／no-go、驗收表、問題清單深度資安與長期營運監控
安全掃描是否出現已知弱點或可疑行為弱點、惡意程式與設定報告功能、內容及轉換驗收
SEO audit搜尋引擎能否發現、理解與收錄內容索引、canonical、結構與內容問題表單及交易流程
使用者測試目標使用者能否理解並完成任務觀察紀錄、成功率與困惑點技術部署及下游資料核對

首頁回傳 200 只證明一個請求成功

HTTP 200 表示伺服器成功回應這次請求，但它不能證明所有頁型、互動與資料流程都健康。常見落差包括：

  • 首頁 200，服務頁連結卻指向 404。
  • 伺服器 HTML 有內容，JavaScript 執行後卻把區塊隱藏。
  • 表單頁 200，送出請求卻被權限或垃圾信規則阻擋。
  • 商品頁 200，加入購物車後價格或庫存不正確。
  • 追蹤碼存在於 HTML，實際事件卻重複或沒有送出。

上線檢查不是一次性的永久保證

上線前驗收只能證明特定版本、時間與測試範圍的狀態。DNS、第三方服務、付款環境與網站內容之後仍可能變動，因此要保存日期、版本及證據，並安排上線後 24 小時監控。

來源：數位發展部政府網站營運交流平台：上線作業與Google Search Console 網址檢查工具（查證 2026-07-24）。Google 說明網址檢查可查看已建立索引版本，並可測試即時 URL 是否可能建立索引，但正面結果不保證出現在搜尋結果。本文的證據層級與四類工作比較為網站交付方法。

P0、P1、P2 與 go／no-go 差在哪裡？

P0、P1、P2 是問題優先級，不是測試結果的顏色。分級要看使用者任務、資料完整性、營運風險與回復能力，再決定是否可上線。

等級影響能否上線常見責任人處理時限最低證據
P0阻擋核心任務，可能造成錯誤交易或資料風險原則上 no-go決策人與技術負責人立即處理上線前修正並重測重現步驟、畫面、系統紀錄與受影響範圍
P1主要功能可用，但明顯影響部分頁面或體驗視風險 conditional go模組負責人與專案管理者約定期限內修正URL、裝置、預期與實際結果
P2不阻擋任務的版面、文字或低影響問題可記錄後上線內容、設計或維運人員排入一般待辦截圖與位置

P0 代表不能接受的上線風險

P0 常見於核心功能中斷、交易狀態錯誤、個資暴露或無法回復。例如：

  • 所有詢價表單都顯示成功，後台卻沒有資料。
  • 付款成功，但訂單沒有建立或金額錯誤。
  • 正式網站仍帶有阻止索引的 noindex。
  • 重要頁面全面 404，導覽無法完成主要任務。
  • 管理權限錯誤，非授權角色可讀取敏感資料。
  • 上線沒有可用備份，而且切換失敗後無法回復。

P1 是可控但不能遺忘的問題

P1 通常不會讓整個網站失效，但會影響重要頁型、特定裝置或一部分使用者。例如手機版選單偶爾遮住按鈕，部分服務頁 title 重複，或某個非核心表單通知延遲。

  • 問題範圍已確認。
  • 有暫時替代路徑或風險控制。
  • 指定負責人與期限。
  • 上線後有監控方式。
  • 修正後必須重新驗收。

P2 不阻擋上線，但仍要留下紀錄

P2 常見於不影響任務的文字、間距或低流量頁面問題。例如次要說明文字有一個錯字，或特定螢幕寬度下裝飾圖偏移，但按鈕與內容仍能正常使用。

Go／no-go 由決策人根據未解問題做判斷

上線決策不是測試人員個人的感覺。驗收前應先指定決策人，並定義：

  1. 哪些 P0 必須歸零。
  2. 哪些 P1 可以附條件接受。
  3. 哪些功能需要正式環境再次驗證。
  4. 切換失敗時，多久內啟動回復。
  5. 上線後由誰監控 24 小時。
  • <strong>Go</strong>：P0 為 0，關鍵任務均有 healthy 證據，備份與回復方案可用。
  • <strong>Conditional go</strong>：P0 為 0，剩餘 P1 範圍明確，有負責人、期限與監控。
  • <strong>No-go</strong>：仍有 P0，關鍵任務缺乏證據，或切換失敗後無法安全回復。
  • 問題總數：2 ＋ 3 ＋ 3 ＝ 8 個。
  • 修正並重測 P0：2 個。
  • 未解 P0：2 － 2 ＝ 0 個。
  • 未解 P1：3 個。
  • 未解 P2：3 個。

網站上線前要檢查哪七類項目？

上線檢查分成四個群組，共七類：功能與內容，行動版與 SEO，追蹤與安全，以及表單或交易。每一類都要先定義預期結果，再記錄操作方法與證據，不能只留一個「完成」勾選框。

類別核心問題基本方法Healthy 證據常見 P0
功能主要任務能否完成依導覽與任務路徑逐步操作畫面、URL 與系統狀態一致核心按鈕失效或主要路徑中斷
內容正式資訊是否正確完整對照核定文案與聯絡資訊，並檢查媒體內容頁面截圖與內容核准紀錄價格或聯絡資訊錯誤，或缺少必要聲明
行動版手機是否能閱讀與操作真機測試選單、表單及互動指定裝置截圖與操作錄影主要按鈕被遮住或流程無法完成
SEO搜尋引擎能否抓取與理解核對狀態碼、canonical、robots 與 sitemap原始碼、HTTP 標頭及 Search Console 結果正式全站被 noindex 或 canonical 指錯站
追蹤重要行為是否正確記錄用 Tag Assistant、Realtime 或 DebugView 操作事件事件名稱、參數、次數與時間核心轉換完全漏記或重複計算
安全基本防護與回復是否就緒核對 HTTPS 與權限，並確認備份及錯誤資訊憑證、角色測試與可還原備份敏感資料外洩或未授權存取
表單／交易下游資料與通知是否一致完成一筆受控任務並核對各系統核對前台與後台，並確認通知與追蹤對得起來資料遺失、錯誤扣款或訂單狀態不一致

功能與內容要沿著主要任務一起測

功能檢查不是逐個按鈕亂點，而是從使用者目標建立路徑。例如「找到服務並送出詢價」可以拆成：

  1. 從首頁或搜尋入口進站。
  2. 透過導覽找到正確服務頁。
  3. 閱讀價格、條件與聯絡方式。
  4. 進入表單並完成必填欄位。
  5. 送出後看到正確結果。
  6. 後台與收件人取得完整資料。
  • 導覽與頁尾連結是否到正確頁面。
  • 主要 CTA 是否符合頁面承諾。
  • 404 頁是否能引導使用者返回有效路徑。
  • 電話、地址、Email 與營業資訊是否核准。
  • 測試文字、假資料與預留圖片是否已清除。
  • 下載檔案、外部連結與社群連結是否正確。

行動版要用真實任務驗證，不只縮小瀏覽器

響應式版面能隨視窗改變，不代表每種手機都能完成任務。行動版檢查要涵蓋：

  • 選單是否能開啟，關閉及捲動。
  • 文字與表單是否可見，按鈕是否被固定元件遮住。
  • 軟體鍵盤開啟後，欄位與送出按鈕是否仍可操作。
  • 圖片與表格是否超出畫面。
  • 橫向與直向切換後，介面是否維持正確。
  • 點擊電話、Email 或地圖連結時，行為是否符合預期。

SEO 與追蹤要核對工具結果的限制

SEO 上線檢查要確認搜尋引擎看到的是正式版本，包括：

  • 重要 URL 回傳預期狀態碼。
  • 每頁 title 與 meta description 符合頁面主題。
  • canonical 指向預期正式 URL。
  • robots.txt 沒有誤擋正式內容。
  • 重要頁沒有非預期 noindex。
  • sitemap 使用正式網址並包含應收錄頁面。
  • Search Console 網址檢查能存取即時版本。
  • 事件是否在預期時機送出。
  • 事件名稱與參數是否正確。
  • 一次操作是否只記錄一次。
  • 同意管理設定生效前後，事件行為是否符合既定規則。
  • 測試流量是否需要從正式報表排除。

安全與表單交易要看系統邊界

基礎安全檢查至少要確認 HTTPS 是否有效，管理權限是否符合角色，測試帳號是否已處理，除錯資訊是否外露，以及備份是否能找到並具備回復程序。

來源：數位發展部政府網站營運交流平台：上線作業、Google Search Console 網址檢查工具、Google Analytics DebugView與OWASP Web Security Testing Guide（查證 2026-07-24）。官方文件用來確認上線流程面向、網址檢查限制、DebugView 用途與完整資安測試範圍。七類檢查表及其 P0 示例為本文的交付框架。

不同網站要怎麼調整上線檢查清單？

各類網站都要保留共同基線，包括功能與內容，行動版與 SEO，追蹤與安全，以及回復能力，再依商業任務加項。形象網站重視詢價與品牌資訊，內容網站重視大量頁面與分類，預約網站重視時段及通知，電商網站則要處理金額、庫存與訂單狀態。

網站類型額外主要任務測試資料下游證據常見 P0
企業形象網站找到服務並完成聯絡一筆可識別的測試詢價後台紀錄、站方收件與客戶確認信詢價資料遺失或聯絡資訊錯誤
內容網站找到文章並沿分類閱讀每種內容類型與分類各抽樣URL 與分類狀態，站內搜尋及索引狀態大量正式內容不可見或被錯誤擋索引
預約／會員網站選時段，建立帳號或變更預約測試帳號及通知信箱，另準備可辨識時段預約與權限紀錄，通知及取消結果重複預約、權限外洩或時段錯置
電商網站選品、計價、付款及訂單通知測試商品、折扣、運費與核准付款方式訂單、付款、庫存、Email 與分析事件金額錯誤、重複扣款或訂單未建立

企業形象網站要證明詢價真的送達

形象網站常被誤認為只要頁面能看就可以上線。實際上，電話、地圖、Email 及詢價表單往往是主要轉換入口。

內容網站要用頁型與分類抽樣

內容網站的風險通常不是單一文章，而是範本或分類規則影響一整批頁面。建立 URL inventory 時，至少列出：

  • 首頁與主要分類頁。
  • 每種文章類型的一篇代表頁。
  • 有圖片、表格、嵌入影片或下載檔的特殊頁。
  • 分頁、站內搜尋與標籤頁。
  • 預期收錄與不收錄的 URL。

預約與會員網站要測狀態及權限

預約流程除了建立成功，還要測取消、額滿、重複時段與通知；會員流程則要測註冊、登入、忘記密碼、登出及不同角色可見內容。

  1. 一般使用者，只能看到自己的資料與可用功能。
  2. 管理或服務人員，可處理核定範圍內的預約與會員資料。

電商網站要把一次交易拆成多個狀態

電商驗收不應只問「能不能付款」。完整交易至少包含：

  1. 商品與價格載入。
  2. 規格、數量、折扣與運費計算。
  3. 付款請求與結果回傳。
  4. 訂單建立及狀態更新。
  5. 庫存調整。
  6. 客戶與站方通知。
  7. GA4 電商事件與 transaction ID。

類型加項不能取代共同基線

電商網站測過付款，不代表 robots 與 sitemap 正確；內容網站抽查文章，也不代表管理權限安全。每種類型的加項都要放在共同基線之上。

  1. 列出主要頁型與使用者角色。
  2. 每種頁型選一個正常代表頁。
  3. 加入一個資料複雜或曾出錯的高風險頁。
  4. 為每個核心任務準備可辨識測試資料。
  5. 指定前台與後台證據，以及通知和追蹤證據。
  6. 標示哪些情境因授權或環境限制尚未測試。

來源：Google Analytics 電商事件設定、Google Analytics DebugView與數位發展部政府網站營運交流平台：上線作業（查證 2026-07-24）。Google 說明電商事件需要加入網站或標籤管理設定，並可用 DebugView 即時驗證；政府網站指南把資料一致與功能測試納入前段，也要求備份及監控。四類網站與測試集方法為本文依任務風險整理的框架。

網站驗收前要準備什麼？

驗收前先固定版本和範圍，確認角色與測試資料，並準備回復方案，才不會一邊測試，一邊有人修改網站。準備工作的輸入是待上線版本與商業任務，輸出則是可重現的測試集、決策規則及證據位置。

先指定決策人與執行人，再指定系統負責人

至少要指定四種責任：

  • <strong>上線決策人</strong>：接受或拒絕風險，做出 go／no-go 決定。
  • <strong>驗收執行人</strong>：依清單操作並留下證據，不自行降低問題等級。
  • <strong>修正負責人</strong>：處理程式、內容或設定問題，提供可重測版本。
  • <strong>系統負責人</strong>：核對表單與分析，並處理 Email、金流或其他外部服務。
  • 唯一編號。
  • URL、頁型與裝置。
  • 預期結果及實際結果。
  • P0／P1／P2 等級。
  • 負責人與重測期限。
  • 證據連結及最終狀態。

URL inventory 要涵蓋頁型與關鍵任務

URL inventory 是這次驗收要覆蓋的網址清單。它不需要列出每個追蹤參數版本，但應包含主要頁型與高風險路徑。

  • 首頁。
  • 主要服務或產品分類頁。
  • 每種內容範本的一篇代表頁。
  • 表單、預約、會員或結帳入口。
  • 搜尋、分頁、404 與重新導向。
  • 隱私權政策及其他必要說明。
  • 預期索引與預期不索引的頁面。

測試帳號與資料要可辨識並能清理

測試資料若和真實資料混在一起，後台、報表與通知信都難以判讀。建議使用一致前綴及日期，例如 LAUNCH-QA-20260724-A，並建立清理清單。

類型測試資料驗收後處理
表單專用姓名、Email、電話與識別碼標記或刪除測試紀錄
會員不同角色帳號與重設密碼信箱關閉或保留為固定 QA 帳號
預約可辨識時段、服務與測試通知信箱取消預約並確認時段釋放
電商測試商品、折扣、運費及核准付款資料依帳務規則取消、退款或保留紀錄
分析測試裝置、事件名稱及識別參數排除開發流量或註明測試期間

環境與版本要固定，備份與回復條件也要確認

驗收前要記錄：

  • 正式網域與預覽網域。
  • 程式版本或部署識別。
  • 資料庫與內容的基準時間。
  • 快取、CDN 與第三方服務狀態。
  • DNS、SSL 與外部帳號控制權。
  • 備份時間、位置及涵蓋範圍。
  • 回復負責人、觸發條件與預估時間。

來源：數位發展部政府網站營運交流平台：上線作業（查證 2026-07-24）。該指南先要求環境準備與程式部署，再處理資料搬遷和安全檢查，並把備份、正式環境測試及監控維護列入上線流程。角色分工、URL inventory、變更凍結及測試資料命名為本文的交付方法。

網站上線前 20 項檢查要怎麼做？

以下 20 項是共同基線。每項都列出操作方法、Healthy 證據、Broken 證據與預設等級；實際等級仍要依影響範圍與商業任務調整。

#檢查項目操作方法Healthy 證據Broken 證據預設等級
1導覽從首頁依主要選單走到各核心頁選單狀態、URL 與頁面標題一致點擊無反應、錯頁或循環核心路徑 P0，其餘 P1
2404輸入不存在網址並測試返回路徑回傳 404，頁面可導回有效內容假 404 回 200、空白頁或無返回入口P1
3表單用識別資料測必填、格式錯誤與成功送出錯誤提示正確，成功後只有一筆資料無法送出、重複資料或錯誤提示不清核心表單 P0
4收件核對後台、站方收件與客戶確認信欄位完整，收件人與時間正確前台成功但後台或 Email 缺失核心表單 P0
5手機用窄螢幕真機走完主要任務內容可讀，按鈕及欄位可操作遮擋、溢出或軟體鍵盤阻斷阻擋任務 P0，版面 P1
6互動測試選單、頁籤、篩選、彈窗及播放器JavaScript 執行後狀態符合預期點擊無效、狀態錯誤或內容消失依任務 P0／P1
7內容核對文案和價格，也檢查聯絡資訊及必要聲明正式資訊完整且無測試文字價格或必要資訊錯誤關鍵資訊 P0／P1
8連結抽查站內與站外連結，另測下載及社群連結目的頁正確且沒有非預期重新導向404 或錯站，連到測試網域或無權限核心 CTA P0，其餘 P1
9Title檢查每種頁型的 HTML title唯一且符合頁面主題title 空白，保留測試字樣或大量重複P1
10Canonical查看原始 HTML 與正式 URL指向預期 HTTPS 正式網址指向測試站、首頁或錯誤 URL大量頁面錯誤 P0
11Robots開啟 robots.txt 並核對正式規則不誤擋正式內容，測試區維持預期限制正式全站被擋或規則不存在全站誤擋 P0
12Sitemap開啟 sitemap 並抽查 URL使用正式 canonical URL，包含應收錄頁測試網域、404 或大量缺頁P1
13Index用 Search Console 檢查代表 URL即時 URL 可存取，索引版本狀態已記錄非預期 noindex，抓取失敗或 canonical 異常核心頁 P0／P1
14GA4進站後查看 Realtime 或 DebugView測試裝置有預期 page_view 與參數完全無資料、錯資源或頁面位置錯誤P1
15轉換完成表單、電話點擊或購買事件事件名稱與參數正確，一次操作記一次漏記，重複或在錯誤時機觸發主要 KPI P0／P1
16SSL開啟 HTTPS 並檢查憑證與混合內容憑證有效，正式頁無安全警告憑證錯誤、過期或關鍵資源被擋P0
17備份核對檔案、資料庫、時間與存放位置涵蓋本次版本，能讀取且知道如何還原缺檔、無資料庫或無回復權限P0
18權限用不同角色登入並測可見範圍各角色只能存取核定資料與功能未授權讀取、修改或下載資料P0
19付款依授權環境完成一筆受控交易金額、付款、訂單與庫存狀態一致錯誤扣款、重複付款或訂單未建立P0
20通知核對表單、預約或訂單的通知對象、內容、金額及連結正確漏寄、錯寄或敏感資料寄錯人核心通知 P0／P1

功能、內容與行動版要用任務路徑驗收

項目 1 至 8 不應各自孤立。例如手機版表單失敗，可能同時涉及項目 3 表單、項目 5 手機及項目 6 互動。問題只需建立一張主要待辦，再標記受影響檢查項目，避免同一根本原因被算成三個獨立 P0。

  1. 缺少必填資料時，不能直接送出。
  2. 格式錯誤時，提示要能指出欄位與修正方式。
  3. 資料正確時，前台、後台與通知要只產生一組結果。

SEO 項目要分清抓取、索引與收錄

項目 9 至 13 要分開記錄：

  • <strong>可抓取</strong>：Googlebot 是否能存取必要資源與頁面。
  • <strong>可索引</strong>：頁面是否允許建立索引，且沒有明顯技術阻礙。
  • <strong>已收錄</strong>：Google 的索引版本是否已有該 URL。

追蹤、安全與回復要驗證實際狀態

項目 14 至 18 的共同問題，是「設定存在」不代表「結果可用」。

表單、付款與通知要完成跨系統核對

項目 3、4、19、20 共同要求前台結果與下游系統一致。付款最少要核對：

  • 結帳頁顯示金額。
  • 金流端交易狀態。
  • 網站訂單編號與狀態。
  • 商品、折扣、運費及總額。
  • 庫存是否只調整一次。
  • 客戶與站方通知內容。
  • GA4 purchase 事件與 transaction ID。

來源：Google Search Console 網址檢查工具、Google Canonical 指南、Google Analytics 資料收集驗證與數位發展部政府網站營運交流平台：上線作業（查證 2026-07-24）。官方文件用來確認網址檢查限制、canonical 訊號、Realtime／DebugView 用途與上線流程面向。20 項清單、Healthy／Broken 證據與預設等級為本文的專案驗收框架。

網站上線檢查有哪些常見誤區？

最常見的驗收錯誤，是把間接訊號當成完成證據。首頁有回應，工具顯示綠燈或前台出現成功訊息，都只能證明其中一層，不能推論整條使用者任務正常。

首頁 200 不代表全站完成

首頁回傳 200，只能證明這個 URL 的這次請求成功。它無法證明：

  • 主要服務頁與商品頁都能開啟。
  • 導覽沒有錯誤或循環。
  • JavaScript 執行後內容仍然可見。
  • 表單資料已進後台。
  • GA4 與轉換事件正確。
  • 付款、訂單及通知狀態一致。

前台成功訊息不代表下游完成

表單顯示「送出成功」，可能只是前端程式切換了畫面。驗收仍要核對：

  1. 瀏覽器是否真的送出請求。
  2. 後台是否新增一筆正確紀錄。
  3. 收件人是否收到完整通知。
  4. 使用者確認信是否寄到正確地址。
  5. GA4 事件是否只記錄一次。

只測桌機或只看工具都會留下盲區

桌機測試看不到手機軟體鍵盤、固定工具列與觸控造成的問題。開發工具模擬可以快速找版面異常，但不能完全取代真機任務。

  • Link checker 能找部分失效連結，不能判斷目的頁是否符合文案承諾。
  • Lighthouse 能提供模擬診斷，不能證明所有真實使用者任務完成。
  • Search Console 即時測試能檢查 URL 是否可能建立索引，不能保證最後收錄。
  • 安全掃描沒有警報，不代表完成完整滲透測試。
  • GA4 Realtime 出現事件，不代表事件參數、次數與觸發時機都正確。

沒有版本、責任人與回復方案就無法追溯

第四類誤區是測試期間持續修改，卻沒有版本識別。早上通過的截圖可能對應舊程式，下午的問題清單卻對應新版本，最後沒有人能說明哪個版本準備上線。

  • 版本或部署識別。
  • 測試日期與環境。
  • 問題負責人及重測者。
  • 證據位置。
  • Go／no-go 決策人。
  • 回復觸發條件與執行人。

一次改太多問題會失去因果

驗收發現表單不收件後，如果同時更新外掛，換 SMTP，改 DNS 又清除相關快取，即使結果恢復，也無法知道哪個變數有效。

來源：Google Search Console 網址檢查工具、Google Analytics 資料收集驗證、Chrome Lighthouse performance scoring與OWASP Web Security Testing Guide（查證 2026-07-24）。官方文件用來界定各工具能驗證的範圍。六類誤區、版本欄位與單一變數修正方法為本文的專案經驗框架。

Healthy 與 Broken 對照要怎麼判讀？

只看 Broken 頁面，很容易把共同特徵誤認成原因。對照法會選一個功能與範本相近的 Healthy case，逐層比較伺服器回傳、JavaScript 後狀態及下游紀錄，再找出最小差異。

同樣回傳 200，JavaScript 後狀態可能不同

假設同一網站有兩個使用相同卡片範本的分類頁：

證據Healthy 分類頁Broken 分類頁能否判定
HTTP 狀態200200兩頁都能回應，不能證明畫面正常
伺服器 HTML8 張卡片8 張卡片資料都已輸出到 HTML
JavaScript 後畫面顯示 8 張卡片顯示 0 張卡片問題發生在前端狀態或顯示邏輯
初始篩選值空值，代表全部0，被當成特定分類支持初始值語意不一致的假設
Console error無無沒有錯誤不代表邏輯正確

表單要比較前台與後台，再核對通知和追蹤

假設同站有主要詢價表單與活動表單：

證據Healthy 詢價表單Broken 活動表單判讀
前台成功訊息有有兩者前台都宣稱成功
Network 請求已送出，回應成功已送出，回應成功不是使用者完全沒送出
後台紀錄1 筆0 筆Broken 資料未完成持久化
站方通知1 封0 封可能因後台流程未完成而未寄
使用者確認信1 封0 封與後台缺資料方向一致
GA4 事件1 次1 次追蹤事件不能證明表單資料保存
  1. <strong>前端沒有送出</strong>：Network 顯示請求已送出，證據不支持。
  2. <strong>只有 Email 寄送失敗</strong>：後台也沒有紀錄，證據不足以支持 Email 是唯一原因。
  3. <strong>後端處理或資料保存失敗</strong>：後台、站方通知及使用者確認信同時缺失，方向較一致。

問題數量要顯示修正前後算式

假設 20 項檢查完成後得到：

  • Healthy：14 項。
  • P0：2 項。
  • P1：4 項。
  • P2：0 項。
  • 總數：14 ＋ 2 ＋ 4 ＋ 0 ＝ 20 項。
  • 修正前 P0：2 項。
  • 已修正且重測通過：2 項。
  • 未解 P0：2 － 2 ＝ 0 項。
  • 新增 Healthy：14 ＋ 2 ＝ 16 項。
  • 未解 P1：4 項。
  • 總數複核：16 ＋ 0 ＋ 4 ＋ 0 ＝ 20 項。

對照證據要轉成 go／no-go 紀錄

可以把結果整理成：

決策欄位結果證據
未解 P00 項兩項修正後重測紀錄
未解 P14 項URL、裝置、影響範圍與期限
關鍵任務導覽、詢價與收件通過前台錄影、後台紀錄與測試信
SEO 基線代表 URL 可抓取且無全站 noindex原始 HTML、robots 與網址檢查
備份與回復已核對備份識別與回復負責人
決策Conditional go決策人、時間與上線後監控條件

來源：Google Analytics DebugView、Google Search Console 網址檢查工具與數位發展部政府網站營運交流平台：上線作業（查證 2026-07-24）。官方文件用來界定追蹤、索引與上線流程證據。兩組 Healthy／Broken 表格、初始篩選值、問題數量及 go／no-go 結果均為教學假設。

內文精華總結

  • 網站上線檢查是什麼：網站上線檢查是將準備發布的網站版本，放進接近正式營運的情境中驗證。
  • 上線檢查要驗證使用者任務與系統結果：企業網站常見任務包括找到服務，切換導覽，閱讀內容，送出詢價及收到確認；電商網站還包含加入購物車，付款，建立訂單及收取通知。
  • 安全掃描、SEO audit 與使用者測試不是同一件事：安全工具沒有報警，不等於表單正常；Google 的網址即時測試顯示可建立索引，也不保證 URL 一定會出現在搜尋結果，更不代表付款流程已驗收。
  • 首頁回傳 200 只證明一個請求成功：HTTP 200 表示伺服器成功回應這次請求，但它不能證明所有頁型、互動與資料流程都健康。

想把網站上線檢查規劃成能長期營運的網站？

先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。

延伸閱讀

網站營運健檢系列文章

秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器拖曳、複製與調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。上線速度與設計自由不必二選一。

重點整理

網站上線前要檢查什麼？

網站上線檢查是將準備發布的網站版本，放進接近正式營運的情境中驗證。它要確認程式與內容是否正確部署，主要任務是否完成，外部服務是否串接，以及失敗時是否有回復方式。「Go」代表依目前範圍可以上線；「no go」代表存在不能接受的風險，應先延後；「conditional go」則是附條件上線，例如非核心版面問題已記錄，且有明確修正時限與監控安排。

哪些問題屬於不能上線的 P0？

核心流程中斷、交易狀態錯誤、個資暴露、全站索引封鎖，以及沒有可用回復方案，都應視為不能上線的 P0。單一 404 是否為 P0，則要看它是否位於主要入口、付款或其他關鍵路徑。

表單成功訊息是否代表真的收到？

不代表。除了前台成功訊息，還要核對後台紀錄、收件匣、寄件 log、CRM 或 Webhook，以及重複送出是否正確處理。若表單連動付款、預約或名單系統，還要分別驗收各下游結果。

手機版要測哪些尺寸與互動？

至少涵蓋代表性的窄螢幕、一般手機及較大螢幕，並檢查導覽、固定元件、表單、鍵盤、觸控、橫直向及真機操作。不要只縮小桌機視窗；重要裝置和瀏覽器仍要用實機完成主要任務。

title、canonical、robots 與 sitemap 怎麼驗收？

title 要逐頁讀回並確認與搜尋意圖一致；canonical 要指向預期正式網址；robots 與頁面 meta 不得誤擋重要頁面；sitemap 要包含可索引正式 URL，排除測試網址及不該收錄的頁面，最後再用 Search Console 驗證。

GA4、GTM 與轉換事件怎麼驗收？

項目 14 至 18 的共同問題，是「設定存在」不代表「結果可用」。GA4 驗收要操作事件，再到 Realtime 或 DebugView 找到測試裝置。Google 說明一般報表可能需要 24 至 48 小時處理，Realtime 與 DebugView 可用來確認資料是否正在收集。測試時還要展開事件參數，避免只看到事件名稱就判定通過。

電商付款與通知信怎麼測？

付款至少要核對金流結果、網站訂單、金額、庫存、通知、退款或失敗路徑，以及 transaction ID 是否一致。通知信還要檢查收件、寄件紀錄、內容、連結及重複寄送，不能只看到付款頁成功。

SSL、備份與安全要檢查什麼？

先檢查 TLS、憑證鏈及強制 HTTPS，再核對帳號與最小權限、已知弱點與更新狀態，最後確認備份範圍、保存位置及實際還原能力。上線前要保留基準與回復步驟，不要把有鎖頭當成全部安全檢查。

分享此文章：

相關文章