一個上線前十分鐘能改完的 canonical 設定錯誤，若拖到上線三個月後才發現，修復成本經常是原本的好幾倍：頁面已經被搜尋引擎抓過、索引過，甚至排名過，再動網址、結構或標記，牽動的不只是程式碼，還有已經成形的索引狀態。根據我們的服務經驗，SEO 驗收必須卡在上線前，並用一份可逐條打勾的清單核對，不能只靠印象確認。這篇文章把我們實際使用的驗收標準整理成十二大類，每一類都附「必要項」與「驗收方式」對照表，讓工程、PM 與 SEO 三方在同一份標準上對齊。
1. 網站上線前的 SEO 驗收，為什麼要卡在這個時間點
上線是資訊落差最大的時刻。工程團隊清楚自己怎麼寫程式，卻不一定知道搜尋引擎怎麼讀；SEO 團隊熟悉搜尋引擎規則，卻看不到後端實際輸出的內容。驗收清單的價值，就是把兩邊的認知在上線前強制對照一次。
1.1 資訊落差最大的時刻，工程與 SEO 各看各的
我們診斷過的案例中，有一家 SaaS 電子簽章服務上線半年排名始終上不來，回頭排查才發現首頁主要內容其實是前端渲染，搜尋引擎從第一天就沒讀到那段文字。這類問題若在上線前用清單抽查，通常幾分鐘就能發現；等排名數字已反映出來，往往要再等一輪抓取週期才看得到修正效果，中間白白損失的是原本可以累積的曝光。
另一個常見的落差發生在回應碼上。工程端測試時看到頁面開得起來，就認定沒問題，卻沒注意到某些分類頁回傳的是軟性 404，也就是頁面內容已經是空的、狀態碼卻仍回 200。這種頁面搜尋引擎抓得到、卻判斷為無內容，長期下來會拖累整站的抓取效率。驗收清單之所以要逐條核對，就是要把這種「人眼看起來正常、機器判讀卻有問題」的落差攤在同一張表上，讓工程與 SEO 兩邊不再各看各的版本。
1.2 必要項與加分項，兩級分類避免驗收變成無底洞
清單裡的項目分成兩級。標示「必要」的是不通過就不該上線的紅線，例如可索引性、canonical、robots 設定；其餘屬於加分項，可排進上線後的優化排程。這樣分級是為了避免驗收變成無止境的完美主義，優先把時間花在「內容能不能被搜尋引擎讀到」的項目上。
1.3 清單怎麼用，時程與複驗怎麼排
建議在預計上線日前至少三到五個工作天跑一輪完整驗收，把沒通過的項目列成待辦回饋給對應負責人，修完再複驗一次，而不是修完就當結案。以下每張表格都可直接當待辦清單使用，左欄是必要項，右欄是實際採用的驗收方式。
2. 網站結構與可索引性，先確定爬蟲進得來也讀得到
這一組是地基。地基不穩，後面所有內容優化都是空談，因為搜尋引擎根本進不來或讀不到。結構、可索引性、渲染方式放在一起討論，是因為它們共同決定搜尋引擎最終看到的版本。
2.1 結構與階層，三層原則與一致性
網站階層決定搜尋引擎理解主題關聯的難易度，也影響抓取效率。我們的原則是重要頁面距首頁不超過三層，導覽列、麵包屑、網址三者的層級要說同一個故事，不能各自一套規則。
我們診斷過的案例中，有一個冷氣安裝品牌的官網，導覽列把服務分成三層，網址卻是扁平的單層結構，麵包屑則完全沒有實作。結果搜尋引擎看到的分類邏輯跟使用者在畫面上看到的完全對不上，連帶讓幾個重要的服務頁被判讀成彼此無關的孤立頁面。驗收這一類時，我們會實際從首頁一路點進最深的詳細頁，邊點邊記錄經過幾層、網址如何變化、麵包屑是否對得上，只要三者之中有一個說了不同的故事，就列成待辦退回工程端修正，而不是等上線後再慢慢調整內部連結。
| 必要項 | 驗收方式 |
|---|---|
| 重要頁面距首頁不超過三層 | 從首頁點擊三次內可抵達分類頁與詳細頁 |
| 導覽列、麵包屑、網址層級一致 | 抽查頁面比對三者是否反映同一結構 |
| 網址用小寫、連字號，具語意 | 檢查是否有大寫、底線、動態參數 |
| 每頁有唯一 canonical，無重複內容 | 檢視原始碼確認 canonical 自我指向 |
| 麵包屑具 BreadcrumbList 結構化資料 | 用 Rich Results Test 驗證 |
2.2 可索引性，五個必查項目
可索引性全部列為必要項，因為這一關直接決定內容存不存在於搜尋引擎眼中。核心動作只有一個：確認搜尋引擎抓得到、也讀得到主要內容。
| 必要項 | 驗收方式 |
|---|---|
| robots.txt 未誤封主要內容 | 確認 /admin、/login 以外路徑開放抓取 |
| sitemap.xml 狀態 200、含 lastmod、頁數相符 | 存取檔案並與全站抓取結果比對筆數 |
| sitemap 已提交 GSC 且顯示成功 | 檢查 Search Console 的 Sitemap 報表 |
| canonical、noindex、robots header 正確 | 抽查各模板的回應標頭與原始碼 |
| 主要模板無需登入即可被抓取 | 用無痕視窗或爬蟲驗證可存取 |
2.3 JS 渲染與 SSR，原始碼裡看得到才算數
這一類最容易被漏掉、卻最傷 SEO。判斷方式很直接：用「檢視原始碼」看到的內容，才是搜尋引擎最先讀到的版本。若原始碼幾乎空白，只剩一個框架，代表主要內容仰賴前端渲染，搜尋引擎可能完全看不到。
| 必要項 | 驗收方式 |
|---|---|
| 初始 HTML 即包含主文與標題 | 用檢視原始碼確認看得到主要文字 |
| 禁用 JavaScript 後仍看得到主要內容 | 瀏覽器關閉 JS 後重新載入頁面 |
| 頁籤、篩選、分頁內容存在於 HTML 結構 | 檢視原始碼確認切換內容非 JS 動態注入 |
| 無單純依賴 JS 注入的主文 | 比對渲染前後的差異 |
一個實務判斷法是：抽首頁、列表頁、詳情頁三種模板，各按一次 Ctrl+U 看原始碼。三種頁面的主要文字都能搜尋得到，渲染方式就過關；搜不到，就要求工程端提供伺服器端渲染或預先渲染的快照方案。
3. 頁面元素與內容標記，每一頁都要能被讀懂
結構過關之後，接著看單頁層級的標記。這一組決定搜尋引擎「理解」一頁內容的品質，包含標題與描述、圖片，以及社群分享時呈現的樣貌。
3.1 On-page 基本元素，title、description 與標題階層
On-page 是每次驗收花最多時間抽查的區塊，直接影響搜尋結果的呈現與點擊率。重點是每頁唯一的 title、與內容一致的 description，以及正確的標題階層。
| 必要項 | 驗收方式 |
|---|---|
| 每頁唯一 title（50 至 65 字元）語意清晰 | 抽查各模板 title 是否重複或過長 |
| meta description 存在且與內容一致（120 至 155 字元） | 檢視原始碼比對描述與頁面內容 |
| 每頁一個 H1，階層 H1 到 H2 到 H3 正確 | 用工具列出標題結構，確認無多 H1、無跳級 |
| 所有圖片具描述性 alt | 抽查 img 標籤的 alt 屬性 |
| 主要連結為 a href，錨文字具描述性 | 確認未用 button 取代分頁連結 |
| 外部連結具 rel=”noopener noreferrer” | 檢查外連的 rel 屬性 |
3.2 圖片、影音與多媒體，文字不能只活在圖片裡
媒體驗收的核心觀念是：圖片不該是主要資訊的唯一載體。價目表、營業時間、規格這類文字資訊若只用一張圖呈現，搜尋引擎讀不到裡面的字，這頁在相關搜尋的競爭力會明顯下降。
我們診斷過的案例中，有一個連鎖餐飲品牌把整份菜單和各分店的價格都做成精美的設計圖，畫面很漂亮，卻等於把最有搜尋價值的文字全部鎖進圖片裡，使用者搜「某某餐點多少錢」時這個網站幾乎沒有機會出現。我們的建議是把關鍵文字以可選取的 HTML 文字或表格重新呈現，設計圖留作視覺輔助即可。驗收時一個簡單的判斷動作，是試著用滑鼠在頁面上框選那段資訊，如果框不起來、選不到字，就代表它只活在圖片裡，需要補一份文字版本。
| 必要項 | 驗收方式 |
|---|---|
| 圖片有語意化檔名與 alt | 檢查檔名非亂碼、alt 自然描述 |
| 圖片採 WebP 或 AVIF 格式，控制檔案大小 | 檢視資源格式與首屏圖片大小 |
| 圖片非主要資訊載體 | 確認文字資訊未被做成圖片 |
| 影片具 VideoObject 結構化資料或說明文字 | 檢查影片頁的 JSON-LD 或內文描述 |
3.3 社群分享標籤，OG 與 Twitter Card
Open Graph 與 Twitter Card 不直接影響排名，但影響內容被分享到社群時的呈現，連帶影響點擊率。我們列為必要驗收，是因為缺漏或抓錯圖的情況成本很低卻很常見。
| 必要項 | 驗收方式 |
|---|---|
| 具 og:title、og:description、og:image、og:url | 檢視原始碼確認四項齊全且唯一 |
| og:image 為 1200×630px 且可公開存取 | 直接開啟圖片網址確認回傳 200 |
| Twitter Card 設為 summary_large_image | 檢查 twitter:card 設定 |
| OG、Twitter、title、description 一致 | 用對應的除錯工具驗證呈現內容 |
4. 語意強化與國際化，讓搜尋引擎理解得更深
基本標記到位後，這一組進一步幫搜尋引擎深度理解內容。結構化資料補上機器可讀的語意，多語系標註處理語言對應，營業資訊則讓在地商家在地圖與搜尋中正確呈現。
4.1 結構化資料，JSON-LD 格式與內容要一致
結構化資料不會直接拉高排名，但能幫搜尋引擎更快理解內容，也是取得豐富摘要的前提。我們驗收時特別在意兩件事：格式無誤，以及標記內容與頁面實際內容一致。
| 必要項 | 驗收方式 |
|---|---|
| 各頁有對應主要類型的 JSON-LD | 檢查 WebSite、Article、Product、FAQ 等是否套用 |
| 首頁具 WebSite 與 Organization | 檢視首頁原始碼的 JSON-LD |
| JSON-LD 無語法錯誤，通過 Rich Results Test | 逐頁用驗證工具檢查 |
| 同一頁不重複同類型 | 確認無兩個 Article 之類的衝突 |
| 標記內資訊與頁面內容一致 | 比對標記欄位與畫面實際文字 |
4.2 多語系標註，語言與地區代碼互相對應
多語系最容易出現隱性錯誤，錯了不會跳出警示，只會讓錯誤地區看到錯誤語言版本。核心原則是：每個語系有自己的網址，彼此用 hreflang 互相指認，並含 x-default。
我們診斷過的案例中，有一個跨境電商同時經營繁體中文與英文兩個版本，hreflang 只從中文頁單向指向英文頁，英文頁卻沒有回指中文頁。這種單向標註等於沒做完，搜尋引擎無法確認兩個版本的對應關係，最後在部分地區混著顯示兩種語言。驗收時我們會逐一打開每個語系的原始碼，確認 alternate 標註是成對互指的，而且每個版本都把自己也列進去，再檢查語言與地區代碼有沒有寫錯，例如把 zh-TW 誤寫成 zh-CN，這種一個字母的差異就足以讓整組標註指到錯誤的對象。
| 必要項 | 驗收方式 |
|---|---|
| html lang 設為正確語系，例如 zh-TW | 檢視原始碼確認 lang 屬性精確 |
| 各語系有獨立 URL，非 JS 切換 | 切換語言看網址是否改變 |
| 各語系互相對應 hreflang，含 x-default | 檢查每個版本的 alternate 是否互指 |
| hreflang 與實際內容語言一致 | 抽查頁面語言與標註是否相符 |
| sitemap 含 hreflang 標註 | 檢查 sitemap 的 xhtml:link |
4.3 營業資訊與開放時間，實體門市的加分項
這一類針對有實體門市的網站。營業時間常被做成一張圖，或只在前端渲染，搜尋引擎讀不到，對本地搜尋相對吃虧。正確做法是用可見文字或表格呈現，再搭配結構化資料補齊。
| 必要項 | 驗收方式 |
|---|---|
| 營業時間以可見文字或 table 呈現，非圖片 | 檢視原始碼確認時間為可讀文字 |
| 內容在初始 HTML 可見 | 用檢視原始碼確認非前端注入 |
| JSON-LD 含 OpeningHoursSpecification | 檢查 LocalBusiness 結構的營業時間欄位 |
| 各分店有獨立 URL 與對應結構化資料 | 確認每間門市頁面獨立且標記完整 |
5. 使用者體驗、可及性與效能，人與爬蟲都在看
最後這一組看的是頁面的實際體驗品質。搜尋引擎越來越重視使用者實際感受，可及性與效能不只是給人看的，也是搜尋引擎評估頁面時會參考的訊號。
5.1 互動與可及性，語意正確的 HTML 兩邊都受益
可及性與 SEO 有很高的重疊，對螢幕閱讀器友善的頁面，通常對搜尋引擎爬蟲也友善，因為兩者都依賴語意正確的 HTML。重點是互動元件要用對標籤，禁用 JS 後主要內容仍要存在。
| 必要項 | 驗收方式 |
|---|---|
| 分頁、切換、表單具正確語意，如 a、button role=”tab” | 檢查互動元件標籤與 ARIA 屬性 |
| 互動元件具 aria-label 或 aria-controls | 抽查需要說明的控制元件 |
| 禁用 JS 後仍看得到主要內容 | 關閉 JS 重新載入頁面 |
| Focus 狀態可見、可鍵盤操作 | 用鍵盤 Tab 鍵測試操作流程 |
5.2 效能與技術檢查，Core Web Vitals 與回應碼
效能項目我們特別盯與 SEO 直接相關的部分，例如版面位移。首屏文字與圖片要在初始回應就出現，伺服器回應碼要正確，這些都是搜尋引擎評估頁面體驗時會參考的指標。
| 必要項 | 驗收方式 |
|---|---|
| Core Web Vitals：版面位移 CLS 小於等於 0.1 | 用 Lighthouse 或 PageSpeed Insights 量測 |
| 首屏文字與圖片於初始回應可見 | 檢查初始 HTML 與載入順序 |
| 伺服器回應碼正確，如 200、301、404 | 抽查各類頁面回應標頭 |
| robots.txt、sitemap.xml 狀態正常 | 直接存取兩份檔案確認回傳 200 |
6. 驗收流程，用固定順序把十二類串起來
有了十二大類的清單，還需要一個固定的執行順序，不然每個人查的重點不一樣，漏項就會發生。我們習慣用五步驟流程，從最底層的「搜尋引擎讀不讀得到」一路往上檢查到效能。
6.1 五步驗收流程，由下而上檢查
這個順序有其邏輯：先確認內容存在，再確認語意正確，最後才看體驗與效能。前一步沒過，後面查得再細也沒有意義。
| 順序 | 步驟 | 目的 |
|---|---|---|
| 1 | view-source 驗證 | 確認主要內容在初始 HTML 出現 |
| 2 | Rich Results 驗證 | 測試結構化資料是否正確 |
| 3 | Google 渲染測試 | 確認搜尋引擎渲染版本與畫面一致 |
| 4 | Lighthouse 檢查 | 量測效能與可用性 |
| 5 | GSC 覆蓋率檢查 | 確認無「可索引但內容空白」頁 |
6.2 三方責任分工，工程、內容與 PM 各司其職
結構、渲染、回應碼這類技術項目由工程端負責；title、description、內容標記由內容與 SEO 端負責；PM 統籌排程，確認每一項都有人認領，回饋才不會被互相推來推去。
根據我們的服務經驗，驗收最常卡關的不是技術難度，而是沒有人認領的灰色地帶，例如圖片的 alt 到底該由設計、工程還是內容端補，常常三方都以為是別人的事。我們的做法是在驗收清單的每一列後面多開一欄，直接寫上負責人與預計修復日，這樣複驗時只要照著名單追蹤即可，不會有項目無聲地消失在交接縫隙裡。
7. 常見問題
7.1 這十二大類全部都要通過才能上線嗎
不是。標示「必要」的項目是不通過就不該上線的紅線，主要集中在可索引性、結構、渲染這幾類；其餘加分項可排進上線後的優化排程，分批處理。我們的原則是把有限的驗收時間先花在「會決定搜尋引擎能不能讀到內容」的項目上，不必為了一次到位而延誤上線。
7.2 沒有實體門市的網站，營業資訊那一類可以跳過嗎
可以。營業資訊與 OpeningHoursSpecification 是針對有實體據點的本地商家設計的。純線上服務或內容型網站沒有營業時間可標，直接跳過即可，把力氣放回符合網站內容類型的結構化資料，例如文章用 Article，服務用 Product 或 FAQ。清單要依網站性質裁剪。
7.3 上線後才發現漏了某一類，補救來得及嗎
大多數項目上線後補救都來得及，例如結構化資料、OG 標籤、alt 屬性，補上後重新請搜尋引擎抓取即可。真正麻煩的是牽動網址與結構的項目，例如網址規則錯誤、canonical 指向錯誤，這些改動可能影響已建立的索引，需要搭配 301 重導與 GSC 觀察。
7.4 驗收要花多久，可以壓縮嗎
一個中型網站完整跑一輪，含抽樣、比對、回饋、複驗，通常需要幾個工作天。可壓縮加分項的細節比對，不能壓縮必要項的抽查與複驗，沒複驗過的修正等於沒被確認過。
7.5 工程團隊說內容都渲染得出來，為什麼還要看原始碼
工程團隊看的通常是「檢查元素」，也就是瀏覽器渲染後的最終畫面，那是使用者看到的版本；搜尋引擎最先讀到的卻是「檢視原始碼」的初始 HTML，兩者可能完全不同。一個前端渲染的頁面，在檢查元素裡內容俱全，在檢視原始碼裡卻可能只剩一個空框架，這正是我們堅持親自看原始碼的原因。
7.6 這份清單多久要重新檢視一次
除了每次上線與改版必跑一輪，我們建議至少每季抽驗一次，因為網站是活的：內容持續新增、外掛更新、模板調整，都可能悄悄破壞原本合格的項目。根據我們的服務經驗，結構化資料與 canonical 最常在改版後被無聲地改動，定期抽驗的目的是在問題影響排名之前先攔下來。