1. 網站上線前,我怎麼安排這份 SEO 驗收清單
我做 SEO 二十多年,經手過的網站改版與新站上線不下數百次。累積到後來,我最深的體會是:上線後才發現的 SEO 問題,修復成本往往是上線前的好幾倍。頁面已經被搜尋引擎抓過、索引過、甚至排名過,這時再改結構、改網址、改標記,牽動的就不只是程式,還有已經建立的索引狀態。所以我堅持,SEO 驗收要在上線前做,而且要有一份可以逐條打勾的清單,而不是憑印象檢查。
這篇文章把我實際使用的驗收標準整理成十二大類,每一類都用表格列出「必要項」與「驗收方式」,方便工程師、PM 與 SEO 三方在同一份標準上對齊。
1.1 為什麼驗收要卡在上線這個時間點
上線是一個資訊落差最大的時刻。工程團隊知道自己怎麼寫的,但不見得知道搜尋引擎怎麼讀;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 基本元素
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 圖片、影音與多媒體
媒體驗收的核心觀念是:圖片不該是主要資訊的唯一載體。價目表、營業時間、規格這類文字資訊若只用一張圖呈現,搜尋引擎讀不到裡面的字,這頁在相關搜尋的競爭力會大打折扣。
| 必要項 | 驗收方式 |
|---|---|
| 圖片有語意化檔名與 alt | 檢查檔名非亂碼、alt 自然描述 |
| 圖片採 WebP / AVIF 格式,控制檔案大小 | 檢視資源格式與首屏圖片大小 |
| 圖片非主要資訊載體 | 確認文字資訊未被做成圖片 |
| 影片具 VideoObject 結構化資料或說明文字 | 檢查影片頁的 JSON-LD 或內文描述 |
3.3 社群與分享標籤(OG / Twitter)
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 一致 | 用 Facebook Debugger 與 Twitter Validator 驗證 |
4. 語意強化與國際化:讓搜尋引擎理解得更深
基本標記到位後,這一組是進一步幫搜尋引擎「深度理解」內容。結構化資料補上機器可讀的語意,多語系標註處理語言對應,營業資訊則讓在地商家在地圖與搜尋中正確呈現。
4.1 結構化資料(JSON-LD)
結構化資料不會直接拉高排名,但能幫搜尋引擎更快理解內容,也是取得豐富摘要的前提。我驗收時特別在意兩件事:格式無誤,以及標記內容與頁面實際內容一致,不能標記寫得很豐富、頁面上卻找不到對應資訊。
| 必要項 | 驗收方式 |
|---|---|
| 各頁有對應主要類型的 JSON-LD | 檢查 WebSite / Article / Product / FAQ 等是否套用 |
| 首頁具 WebSite + Organization | 檢視首頁原始碼的 JSON-LD |
| JSON-LD 無語法錯誤,通過 Rich Results Test | 逐頁用驗證工具檢查 |
| 同一頁不重複同類型 | 確認無兩個 Article 之類的衝突 |
| 標記內資訊與頁面內容一致 | 比對標記欄位與畫面實際文字 |
4.2 多語系(Lang / Hreflang)
多語系是最容易出隱性錯誤的區塊,錯了不會報錯,只會讓錯誤地區看到錯誤語言。核心原則是:每個語系有自己的網址,彼此用 hreflang 互相指認,並含 x-default。
| 必要項 | 驗收方式 |
|---|---|
| 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 互動與可及性
可及性與 SEO 有很高的重疊。一個對螢幕閱讀器友善的頁面,通常對搜尋引擎爬蟲也友善,因為兩者都依賴語意正確的 HTML。重點是互動元件要用對標籤,而且禁用 JS 後主要內容仍在。
| 必要項 | 驗收方式 |
|---|---|
| 分頁、切換、表單具正確語意(a、button role=”tab”) | 檢查互動元件標籤與 ARIA 屬性 |
| 互動元件具 aria-label 或 aria-controls | 抽查需要說明的控制元件 |
| 禁用 JS 後仍看得到主要內容 | 關閉 JS 重新載入頁面 |
| Focus 狀態可見、可鍵盤操作 | 用鍵盤 Tab 鍵測試操作流程 |
5.2 效能與技術檢查
效能項目我特別盯與 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 三方責任分工
驗收要跑得順,分工要先講清楚。我的經驗是,把每一類明確指派給對的人,回饋才不會踢皮球。結構、渲染、回應碼這類偏技術的由工程端負責;title、description、內容標記由內容與 SEO 端負責;PM 則負責統籌排程與確認每一項都有人認領。上線前的複驗一定要留時間,修完不複驗等於沒驗。
7. 常見問題
7.1 這十二大類全部都要通過才能上線嗎
不是。標示「必要」的項目是不通過就不該上線的紅線,主要集中在可索引性、結構、渲染這幾類;其餘加分項可以排進上線後的優化排程,分批處理。我的原則是把有限的驗收時間先花在「會決定搜尋引擎能不能讀到內容」的必要項上,加分項慢慢補,不要為了追求一次到位而延誤上線。
7.2 沒有實體門市的網站,營業資訊那一類可以跳過嗎
可以。營業資訊與 OpeningHoursSpecification 這一類是針對有實體據點的本地商家。純線上服務或內容型網站沒有營業時間可標,直接跳過即可,把力氣放回結構化資料裡符合你內容類型的部分,例如文章用 Article、服務用 Product 或 FAQ。清單要依網站性質裁剪,不是每一項都適用每一種網站。
7.3 上線後才發現漏了某一類,補救來得及嗎
大多數項目上線後補都來得及,例如結構化資料、OG 標籤、alt 屬性,補上後重新請搜尋引擎抓取即可。真正麻煩的是牽動網址與結構的項目,例如網址規則錯誤、canonical 指向錯誤,這些改動可能影響已建立的索引,需要搭配 301 重導與 GSC 觀察。所以我才一再強調結構類要在上線前就確認,愈底層的東西愈不該事後才改。
7.4 驗收要花多久,可以壓縮嗎
一個中型網站完整跑一輪,含抽樣、比對、回饋、複驗,通常需要幾個工作天。可以壓縮的是加分項,不能壓縮的是必要項的抽查與複驗。我不建議為了趕上線而跳過複驗,因為修改本身也可能引入新問題,沒複驗過的修正等於沒被確認。與其上線後補救,不如在時程規劃時就把驗收時間預留進去。
7.5 工程團隊說內容都渲染得出來,為什麼我還要看原始碼
因為工程團隊看的通常是「檢查元素」也就是瀏覽器渲染後的最終畫面,那是使用者看到的版本;搜尋引擎最先讀到的卻是「檢視原始碼」的初始 HTML。兩者可能完全不同。一個前端渲染的頁面,在檢查元素裡內容俱全,在檢視原始碼裡卻可能只有一個空框架。這個落差正是我堅持親自看原始碼的原因,它是搜尋引擎與使用者視角差異最容易出事的地方。
7.6 這份清單多久要重新檢視一次
除了每次上線與改版必跑一輪,我建議至少每季對線上網站抽驗一次,因為網站是活的:內容持續新增、外掛更新、模板調整,都可能悄悄破壞原本合格的項目。特別是結構化資料與 canonical,常在改版或外掛更新後被無聲地改動。定期抽驗的目的是在問題影響到排名之前先攔下來,而不是等排名掉了才回頭找原因。