可以先檢查這種情況：瀏覽器畫面完整顯示標題、答案和表格，但用 curl 讀到的初始 HTML 只有一個空容器。讀者的畫面和 crawler 的第一份文件不是同一份東西。
這篇給你可以逐項查的東西：同一頁的三種內容狀態、抓取／渲染／索引三個階段的分工、初始 HTML 與 rendered DOM 的對照方法，以及跨平台推論的界線。內部連結和 canonical 各有一篇：內部連結與 AI 引用、canonical 與 AI citation。
可以想成一份寄出去的邀請函。信封裡放了一張卡片，上面寫「請掃描 QR code 查看詳細資訊」，有掃描器的人拿得到完整資訊，沒有的人只看到一句話。JavaScript 載入的內容就是那個 QR code：有些 crawler 掃得開，有些只收到那張幾乎空白的卡片。Google 官方說明抓取、渲染、索引是不同階段，Google 會渲染可處理的 JavaScript；其他平台我沒有文件可以引用，只能各自查。
不同 crawler 的渲染能力與回答觀測要分開確認。
先分清楚三種內容狀態
同一頁可以同時有三種狀態：
| 狀態 | 讀者看到的證據 | 技術上要查什麼 |
|---|---|---|
| 初始 HTML | 關閉 JavaScript 後的原始 response | status、title、文字、連結、meta |
| 渲染後 DOM | JavaScript 執行完成後的頁面 | DOM 文字、hydration、network、console |
| AI 產品答案 | 某日期某查詢的來源或摘要 | 平台、query、裝置、引用 URL |
瀏覽器截圖只能證明視覺結果，證明不了初始 HTML 長什麼樣，也證明不了 AI 產品用了這頁。只檢查第二種狀態，會漏掉 crawler 沒執行的程式；只檢查第一種，會漏掉渲染後產生的錯誤或重複內容。第三種狀態要獨立觀測，前兩種推不出來。
Google 的抓取、渲染、索引流程
Google 的 JavaScript SEO basics 說明，Googlebot 會先抓取 URL，再將可處理的頁面排入渲染，最後把渲染後的 HTML 用於索引。回應狀態、資源可用性、robots 規則和 JavaScript 錯誤都可能影響後續階段。Google 也說明伺服器端渲染或預先渲染對速度與可用性有幫助，因為不是所有 crawler 都能執行 JavaScript。
這份文件講的只是 Google。OpenAI、Anthropic、Perplexity 用不用同樣的 renderer，Google 的文件推不出來。要做跨平台檢查，先查各家 crawler 文件，再對指定 URL 做 request、HTML 和產品觀測；沒有文件或實測證據，就記「渲染能力未知」。
初始 HTML 應該先放什麼
對內容頁，初始 HTML 應優先提供讀者最需要、crawler 最容易取得的資訊：
- 一個清楚的 H1、title 和描述，並與頁面主題一致。
- 開頭直接回答主要問題，避免答案完全等到點擊或 hydration 後才產生。
- 可見文字中的定義、限制、步驟和必要來源連結。
- 可爬取的
<a href>內部連結，指向 parent、sibling 和服務頁。 - canonical、robots 指令和必要的結構化資料，且與可見內容一致。
- 圖片 alt 和文字替代，不把關鍵主張只放在圖片或 canvas。
互動篩選、即時資料、登入後操作可以留給 JavaScript；重要的公開解釋要有可以直接讀到的文字版本。
SSR、prerender 與 hydration 如何分工
SSR 或 prerender 可以讓伺服器先輸出文章內容，hydration 再讓頁面具備互動。這種架構通常更容易對照初始 HTML 和渲染後 DOM。檢查時要看實際 response，框架名稱說明不了部署結果：
| 架構狀態 | 需要確認 | 風險訊號 |
|---|---|---|
| SSR | response 已含主要文字與 link | 部署環境與開發環境輸出不同 |
| prerender | 靜態 HTML 是否在改版時更新 | 日期或內容滯後 |
| hydration | JS 執行後是否保留文字與 link | hydration error、內容閃爍或被清空 |
| client-only | 初始 HTML 幾乎沒有答案 | crawler 是否渲染未知、首屏依賴腳本 |
| lazy content | 捲動、點擊或延遲後才載入 | crawler 未觸發互動，內容不可見 |
做技術選擇時，把「讀者體驗」「Google rendering」「其他 AI crawler」「正式環境 response」分開評估。某一層通過，其他層仍要個別確認。
五個常見失敗點
1. 200 頁面卻沒有主要文字
HTTP 200 只代表回應成功，若 body 是 loading shell 或錯誤 fallback，crawler 仍拿不到文章。把 initial HTML 存下來，檢查 H1、第一段答案和連結。
2. robots 或 WAF 阻擋腳本與 API
頁面本身可能回 200，但關鍵 JavaScript、CSS 或資料 API 收到 403、429 或 CORS 錯誤。查看 network、server log 和 WAF event，確認渲染結果是否依賴被擋資源。
3. 渲染後內容和原始內容互相矛盾
如果初始 HTML 的 title、canonical 或價格與渲染後不同，Google 需要處理多個訊號。結構化資料也要跟頁面可見內容一致，只存在於腳本裡的主張算不上可見證據。
4. 只測一般瀏覽器
瀏覽器具備完整 JavaScript、cookie、地區和登入狀態，crawler 的請求環境可能不同。至少做無 cookie、不同 user-agent、未執行 JS 的初始 HTML 檢查，並把正式環境和本地結果分開記錄。
5. 把渲染成功寫成 AI 引用成功
Google 或測試 renderer 看到了文字，AI 產品仍可能不用這頁。引用觀測要記錄 query、日期、產品和實際 URL，沒有答案資料時寫「無資料」。
單頁檢查步驟
照這個順序做一頁：
- 固定正式 URL、查驗日期、裝置、地區和環境。
- 取得沒有 JavaScript 執行的初始 HTML，保存 status、headers、title、H1、文字與 links。
- 在可控環境執行渲染，保存 rendered DOM、console errors、network failures 和最終 canonical。
- 比對初始與渲染後的 H1、主要答案、FAQ、來源連結、schema 和 robots 指令。
- 檢查 robots.txt、WAF、CDN 和 API 是否對指定 crawler 產生不同 response。
- 依 Google 工具或 property 的現有資料確認索引狀態，沒有證據就保留「未確認」。
- 針對 AI Search 固定查詢做獨立觀測，把引用 URL、未出現和「無資料」分開。
要把這項檢查放進網站內容治理的流程，可以從我們的 GEO 服務看起；固定查詢觀測 AI 回答的部分，Otlex 是我們為此開發的平台。
常見問題
JavaScript 內容完全不能被 Google 讀到嗎？
Google 有抓取、渲染和索引流程，也處理得了部分 JavaScript。影響結果的是回應狀態、資源可用性和程式錯誤：同一段程式在你的瀏覽器跑得起來，在渲染佇列裡可能因為一個外部資源逾時而拿到空白。重要內容仍然適合在初始 HTML 提供可讀版本，其他 crawler 的能力也要各自查。
SSR 一定會提升 AI Search 引用嗎？
SSR 做到的是讓初始 HTML 更容易檢查和處理，也降低內容只活在 client-side 的風險。AI 產品抓不抓、懂不懂、用不用這一頁，要靠各平台與查詢觀測。SSR 把門打開，走不走進來是另一回事。
只看 rendered DOM 可以嗎？
rendered DOM 要和初始 HTML、HTTP status、network、robots、WAF 和 canonical 一起對照。只看畫面的話，「crawler 沒執行 JavaScript」和「crawler 拿到不同的 response」這兩種情況你都看不到，你的瀏覽器會把它們都補得很完整。
200 狀態但內容是 loading shell，算可存取嗎？
HTTP 層回應成功了，內容層還沒有。主要文字、標題或連結要等互動後才載入的話，記錄初始 HTML 不完整，再查指定 crawler 有沒有渲染能力。一個 200 配一張 loading 骨架，對 crawler 來說是一個沒有內容的成功。
要如何知道某個 AI crawler 會不會執行 JavaScript？
先查那個平台當下的官方文件，再用指定 user-agent、URL 和日期做可重複測試。文件、log 或產品端證據都拿不到時，狀態就寫未知。從自己瀏覽器看得到的結果推廣到某個 crawler，中間換掉的是整個執行環境。