網站 SEO 怎麼驗收？GA4、GSC、權限與技術交接清單

直接答案是：網站 SEO 驗收不能只看搜尋結果截圖、Lighthouse 分數或一句「GA4 已安裝」。公司要能用自己的帳號進入 Google Search Console 與 GA4，重要網址要能被搜尋引擎讀取，canonical、Sitemap、轉址與 404 要符合規劃，聯絡事件要用真實操作測到，最後還要取得網域、程式、主機與文件的接管能力。

本篇專注上線前後的技術檢查與交接證據。若還在比較公司、報價與合作流程，先讀 網頁設計公司選擇指南 ；兩篇分工不同，不需要用本篇的技術欄位取代前期需求與報價比較。

封面取自有紀莊園品牌識別案例 展示的網站品牌簡介區塊，以產品照片、ABOUT 文字與「關於有紀」入口呈現可見的內容層級；內文另保留完整頁尾，示範聯絡資訊與政策連結的盤點。這些是網站視覺案例，不是 SEO、GSC 或 GA4 成果，入口導向、事件及管理權限都要另行實測。

一、先分成三層：可被找到、可被量測、可被接管

網站能打開只證明瀏覽器收到頁面，不能證明搜尋引擎會收錄、轉換會進入正確報表，或公司日後能自行維護。驗收時把問題分成三層，較不會把不同責任混在一起。

Google Search Essentials 說明符合技術要求也不保證一定被檢索、建立索引或排名。因此驗收的是「設定、狀態與證據」，不是供應商無法單方面控制的排名結果。

二、先做網址清冊，再決定每種網址的預期結果

驗收前先列出首頁、服務、作品、文章、聯絡、政策頁、舊站網址及不再使用的頁面。每個網址都標示預期狀態，才能判斷 200、轉址、canonical 或 404 是否真的正確。

Google 的 canonical 說明 將 canonical 視為多種訊號共同作用；因此 HTML 標記、轉址、站內連結和 Sitemap 應盡量一致。不要一邊在 Sitemap 提交 A，一邊把 A canonical 到 B。

三、技術 SEO 驗收：不要只看外掛綠燈

• 每個重要頁只有一個清楚的頁面主題、標題、H1、摘要與正式網址。
• robots.txt 沒有誤擋重要區域；頁面 robots 指令與預期索引狀態一致。
• Sitemap 只放正式網址，回應成功並使用 HTTPS，不納入 404、轉址或 noindex 頁。
• 舊站轉址逐條核對，不形成轉址鏈、循環或全部導回首頁。
• 導覽、麵包屑、文章內鏈與按鈕使用可抓取連結，重要頁不是只能靠站內搜尋找到。
• 結構化資料可解析，內容與訪客真正看見的公司、服務、文章及案例一致。
• 圖片有正確尺寸、清楚檔案與符合畫面的替代文字；裝飾圖不硬塞關鍵字。

Google Sitemap 指南 說明 Sitemap 是提供網址提示，不是收錄保證。提交成功、沒有格式錯誤，與每個網址最後是否進入索引是兩件事，報告時要分開寫。

四、GSC 驗收：公司帳號要能看網站層級與網址層級證據

Google Search Console 應由公司可長期管理的帳號持有，再授權合作方。驗收不只截一張成效圖，而是確認資源、權限、Sitemap 與代表網址狀態。

1. 確認驗證的是正確網域或網址前置字元資源，並記錄主要擁有者。
2. 由公司帳號登入，檢查使用者清單、權限與可移除協作者的能力。
3. 提交正式 Sitemap，保存提交與讀取結果；錯誤要能對應到具體網址。
4. 抽查首頁、服務、文章、聯絡、近期新增頁及一個舊網址轉址。
5. 分開記錄「可被索引」「Google 已檢索」「目前已建立索引」，不可混成同一結論。
6. 成效報表保留日期範圍、查詢、頁面、國家與裝置條件，避免截圖失去脈絡。

Google 的 Search Console 權限說明 區分擁有者與使用者能力。交付時應由公司確認自己的權限，而不是只接受供應商代傳的報表。

五、GA4 驗收：安裝完成不等於聯絡事件正確

GA4 驗收要先確認帳戶、資源、網站資料串流與網站載入的評估 ID 對得上，再逐一實際操作。公司應保有資源層級的管理能力，合作方只取得工作所需權限；Google Analytics 的 使用者管理說明 也明確區分帳戶與資源層級權限。

以下以法西納官網的聯絡事件命名與觸發條件為例：聯絡方式分開記錄，表單在後端成功回覆後記錄 generate_lead，並以提交識別避免同一提交重複計算。程式定義只是驗收的一層，正式確認仍須核對實際請求與報表；聯絡按鈕被點擊，也不等於已收到詢問。

測試資料使用專用識別，不放姓名、電話或 Email 到事件參數。先記程式與觸發條件，再記請求、即時與標準報表各自的查核狀態，不能把其中一層通過填成全部完成。

六、GA4 實測要走完整流程，不要只在程式碼搜尋事件名稱

事件名稱與參數只記錄聯絡管道、入口位置與頁面等分析欄位，不傳姓名、電話或信箱。Google Analytics 的 避免傳送個人識別資訊說明 明確要求不得傳送 Google 可用來識別個人的資訊；測試資料也應使用非真實值。

1. 先開啟瀏覽器開發工具，確認分析程式成功載入且請求沒有被內容安全政策阻擋。
2. 使用不含真實個資的測試資料，依序操作每一個聯絡入口與表單狀態。
3. 在即時或除錯檢視確認事件名稱、頁面路徑及必要參數。
4. 約 24–48 小時後再從標準報表確認資料是否完成處理；實際時間可能因報表與資料量而異。
5. 若事件會匯入廣告平台，另外核對匯入的事件、計次方式與主要／次要用途。

GA4 不應傳送姓名、電話、電子郵件或表單全文等可識別個人資料。測試要記錄日期、裝置、瀏覽器、測試事件與預期結果，並在完成後辨識或排除內部測試流量。

七、視覺、程式與報表，分成不同驗收紀錄

本文封面的品牌簡介區塊可用來核對標題、說明與延伸閱讀入口；下方完整頁尾則讓讀者辨認社群圖示、公司聯絡資訊與政策連結。內文流程圖再把搜尋、量測與接管證據分開整理；可見畫面與教學圖都不能代替實際的技術檢測紀錄。

有紀莊園案例可供核對頁尾的內容分組，卻無法由截圖確認連結實際導向、點擊事件、付款功能或帳號歸屬。對正在驗收的網站，應逐項列出入口、預期行為與負責人，再於經同意的環境操作及保留結果。

技術 SEO 與量測證據則要回到正在驗收的網站本身：查看原始碼、HTTP 狀態、GSC、GA4、帳號清冊與測試紀錄。把兩類證據分開，既不低估視覺設計，也不會把未交付的技術工作誤算進案例。

八、效能、手機版與無障礙要約定條件，再保留複測紀錄

單次分數容易受測試地點、網路、裝置、快取與第三方程式影響。驗收時要固定代表頁、裝置類型、測試工具、日期與網站版本；實驗室結果用來找問題，若已有真實使用者資料，也要分開閱讀，不能把兩者混成一個永久保證。

• 手機版實際操作導覽、文章搜尋、作品瀏覽、聯絡按鈕與表單錯誤狀態。
• 檢查圖片尺寸、載入策略、字型與第三方程式，不以過度壓縮圖片換取單次分數。
• 用鍵盤走過主要流程，確認焦點可見、順序合理且不會困在元件中。
• 檢查表單標籤、錯誤訊息、色彩對比、縮放與圖片替代文字，並保留人工測試。

W3C 的 WCAG 2.2 以可測試的成功準則描述網頁內容需求。自動工具可協助找出部分問題，但鍵盤流程、錯誤理解及真機操作仍需人工判斷。

九、技術交接：下一位維護者要能登入、部署、復原與移除權限

密碼與復原碼不要寫進一般交付文件或公開程式庫，應使用適合的安全管道移交。離場時更新文件、確認公司仍保有最高管理能力，再移除不再需要的供應商帳號。

十、一份合格的網站驗收報告應該長什麼樣

每個檢查項目至少記錄下列欄位，讓結果之後仍可重現：

• 檢查日期、網站版本、正式或測試環境、網址與負責人。
• 預期結果、實際結果、HTTP 狀態或報表證據，以及是否通過。
• 問題嚴重度、影響範圍、修正人、修正版本與複測日期。
• 第三方限制、尚待觀察項目，以及不能由單一供應商保證的結果。
• 上線核准人、未完成事項接受人與後續維護窗口。

「已處理」不是完整紀錄。重要問題要留下重現步驟與複測證據；新頁等待搜尋引擎處理、真實使用者資料尚未累積等狀態，也要寫成觀察項目，不能誤報為技術故障或保證完成。

十一、網站 SEO、GA4 與技術交接常見問題

十二、結語：驗收的是可重現證據，不是漂亮的一次性畫面

專業網站交付要同時回答三件事：搜尋引擎能否正確理解重要網址、團隊能否從 GA4 與 GSC 讀到可信資料、公司能否在合作結束後接管網站。把網址清冊、技術 SEO、事件測試、帳號權限與交付演練寫進同一份驗收紀錄，問題才有負責人與複測依據。

若你正在評估合作範圍，可先查看法西納的設計服務與作品案例 ；若已有網站網址、GSC／GA4 現況或交接清單，可透過聯絡表單 提供可公開討論的資訊。實際權限、憑證與個人資料不要放入一般表單。