首頁 / 技術文章 / 網站用了 SSR，AI 爬蟲仍可能漏讀：初始 HTML 的逐區塊稽核方法
技術文章
網站用了 SSR，AI 爬蟲仍可能漏讀：初始 HTML 的逐區塊稽核方法
確認 SSR 網站的關鍵內容是否可讀，應檢查各區塊是否已出現在伺服器回傳的初始 HTML，並與渲染後 DOM 比對。框架名稱不足以證明價格、評論、FAQ 與 JSON-LD 都已送出；稽核單位應是內容區塊。
SSR 的驗收單位應是內容區塊
對已採用 SSR 或 SSG 的網站，真正需要排除的是混合載入的缺口：頁面主體已在初始 HTML，但價格、評論或 FAQ 答案仍可能等到瀏覽器執行 JavaScript、接手頁面互動後，才透過客戶端請求補上。若某個區塊只有此時才出現，不執行 JavaScript 的讀取方式就無法從初始回應取得它。這是需要逐頁驗證的風險，不能直接推定每個 SSR 網站都有相同問題。
建議將稽核對象分成初始 HTML 與渲染後 DOM：前者是未執行頁面 JavaScript 的 HTTP 回應內容，後者是瀏覽器完成指定載入條件後的頁面結構。兩者應使用相同的內容清單驗收。僅看畫面完整與否，無法回答內容在哪個階段出現；僅搜尋原始碼中的某個字串，也不足以確認它位於預期的內容區塊。
先分清官方說明、第三方觀測與稽核假設
Google 官方文件說明，Google Search 使用 evergreen Chromium 執行 JavaScript，並以 crawling、rendering、indexing 處理 JavaScript 網頁；爬取與渲染各有佇列。因此，即使把 Googlebot 納入考量，也不宜把取得 HTML 與完成渲染當成同一個時間點。讓關鍵資訊直接存在初始回應，是減少對後續渲染時程依賴的做法。
OpenAI 官方爬蟲文件列出 GPTBot、OAI-SearchBot 等爬蟲的用途與 user-agent，但現有依據不足以將其 JavaScript 執行能力寫成官方承諾。Vercel 與 MERJ 的第三方觀測則指出，GPTBot、ClaudeBot、PerplexityBot 等受觀測爬蟲沒有執行 JavaScript。這項結果受觀測期間與網路範圍限制，不宜外推為永久規格，也不能直接套用到使用者即時觸發的瀏覽功能。
因此，較穩健的驗收基準是：重要的公開內容在不執行 JavaScript 時仍可取得。這是設計取捨，並非宣稱所有爬蟲都不會渲染。它讓開發與內容團隊可以驗收自己的輸出，不必先猜測每家服務的內部能力。
建立關鍵內容清單，先寫清楚通過條件
先依頁面用途挑選代表網址，再為每個網址列出必要區塊。產品頁可優先檢查價格與評論，文件頁則可檢查主文與 FAQ。選擇器應指向站內穩定的內容容器，文字比對則應包含足以辨識內容的片段。以下是可採用的驗收模板，選擇器須依網站實際結構調整，不代表任何網站的檢查結果。
| 區塊 | 定位範例 | 建議驗收條件 |
|---|---|---|
| 價格 | [data-audit="price"] | 包含適用商品的金額、幣別與計價條件，不能只有載入提示 |
| 評論 | [data-audit="reviews"] | 包含指定的公開評論文字；若只有摘要，另外標記覆蓋範圍 |
| FAQ | [data-audit="faq"] | 問題與對應答案皆存在，不能只有問題標題 |
| JSON-LD | [type="application/ld+json"] | 能解析為 JSON，並核對預期實體與必要欄位 |
通過條件要描述實際資訊，不能只寫容器存在。空的價格容器、只有標題的評論區，或尚未填入資料的結構化資料，都應與完整內容分開記錄。若某段文字只出現在供客戶端讀取的序列化資料中，建議另列為資料已傳送、頁面區塊尚未輸出，避免把字串命中直接算成內容可讀。
以不同 user-agent 保存原始回應，再比對 DOM
- 固定比較條件。記錄網址、語系、地區、登入狀態與 Cookie 條件，選定同一批待驗收內容。價格等容易變動的資訊，應在相近時間取得兩份快照。
- 建立 user-agent 測試組。保留一般瀏覽器作為對照，另設 GPTBot、OAI-SearchBot 與 Googlebot。各組使用官方公布的完整識別字串，並將實際採用值留存；不要自行拼接版本或把爬蟲名稱當成完整字串。
- 使用不執行 JavaScript 的 HTTP 工具逐組抓取。保存回應本文、回應標頭、狀態碼、重新導向紀錄及最終網址。先確認回來的是預期內容頁，再執行區塊比對。
- 取得瀏覽器渲染後 DOM。沿用比較條件，將完成條件設定為必要區塊出現或載入失敗，並記錄等待與互動條件。若答案需要點擊才載入，應另外保存互動後結果。
- 對兩份內容套用同一份清單。解析 HTML，依選擇器擷取區塊，再比對必要文字或欄位。將結果分成皆存在、僅 DOM 存在、僅初始 HTML 存在、皆缺漏，以及無法判定，並保留差異片段。
GPTBot 與 OAI-SearchBot 的識別資料應從 OpenAI 官方文件原樣取得；Googlebot 組也應核對其官方完整識別字串後再執行。稽核報表應保留完整值，避免只留下爬蟲名稱，讓後續重跑無法確認請求條件是否相同。
以同一組選擇器檢查各份初始 HTML，能把內容缺漏與請求差異放在一起判讀。如果一般瀏覽器組有價格，某個爬蟲組卻沒有，就應進一步檢查 CDN、WAF、快取或動態渲染設定；但僅憑差異，還不能判定是哪一層造成。若所有原始回應都缺漏、只有 DOM 存在，才較有理由沿著客戶端載入流程追查。
報表要能區分存取失敗、內容缺漏與載入時差
建議以網址、user-agent 與區塊為報表的一筆紀錄，附上擷取時間、請求條件、回應狀態、初始 HTML 結果、DOM 結果與差異片段。原始回應及 DOM 快照也應一併保存。這樣重新驗收時，團隊能判斷是內容更新、回應改變，還是修正確實讓區塊提前出現。
若取得的是驗證頁或錯誤頁，先標記為存取問題，不要算成 SSR 缺漏。若初始 HTML 有舊價格、DOM 有新價格，則應追查資料更新與快取條件，而非只給內容存在的通過標記。兩邊都找不到時，也要先排除選擇器失效、頁型不適用或擷取過早，避免將測試本身的問題交給前端修正。
對 FAQ，建議將答案文字是否存在，與畫面是否展開分開驗收。對評論與分頁內容，則要明訂檢查的是摘要、首批內容，還是完整清單。否則一個通過標記可能掩蓋尚未檢查的範圍，讓內容與工程團隊對可讀性的理解不同。
依缺漏區塊修正，避免直接重做整站
若價格只在客戶端請求完成後出現，可評估把公開價格的取資料與輸出移到伺服器端，並明確處理更新條件。若評論是主要決策資訊，可先讓必要的公開評論或摘要隨初始 HTML 送出；是否輸出完整清單，應依頁面用途決定。對 FAQ，則可把答案內容先輸出，再讓瀏覽器處理展開互動。
如果 JSON-LD 只在渲染後 DOM 出現，修正方向是讓它隨伺服器回應輸出，並讓它與頁面內容使用一致的資料來源。驗收時除了檢查可解析性，也應比對商品、價格或其他目標欄位是否對應頁面。這項檢查只能證明輸出內容符合預期，不能證明特定 AI 服務會採用它；引用效果還需要另一層證據，可延伸閱讀結構化資料與 AI 引用的證據界線。
修正順序宜依內容用途安排：先處理直接影響商品判斷、答案完整性與實體辨識的公開資訊，再處理次要互動。個人化或登入後內容則應另訂驗收範圍，不能因為追求初始 HTML 完整，就把不應公開的資料納入公開輸出。
對已用 SSR 的團隊，下一個可交付成果應是一份能重跑、能定位缺漏的區塊報表。將它納入頁面模板、資料取得方式或 CDN 規則變更後的驗收，才能把框架選型轉成可核對的內容輸出。通過代表關鍵資訊不再依賴後續渲染才出現；是否被搜尋服務採用與引用，仍須分開評估。
常見問題
網站已經使用 SSR，還需要檢查哪些內容？
建議先檢查價格、評論、FAQ 答案與 JSON-LD，逐區塊比較初始 HTML 與渲染後 DOM。驗收應確認必要資訊已輸出，不能只檢查容器或標題存在。
換成 GPTBot 的 user-agent，就能確認 GPTBot 實際看到的頁面嗎？
不能。這只能檢查指定請求條件下的回應，適合用來追查不同 user-agent 是否得到不同內容。真實爬蟲的存取結果與身分驗證仍需另行查核。
Googlebot 會執行 JavaScript，為什麼還要驗收初始 HTML？
Google 官方文件將爬取、渲染與索引分成不同階段，渲染需要進入佇列。把必要內容放進初始 HTML，可減少對後續渲染時程的依賴。
JSON-LD 出現在初始 HTML，就代表 AI 搜尋會引用嗎？
不能據此保證。這項驗收只確認結構化資料已隨回應輸出，且內容符合預期；特定服務是否讀取、採用或引用，不能由這個結果直接推定。