在談引用之前，GEO 必須先滿足的技術條件
如果一項重要事實只在 JavaScript 執行後才出現，AI Agent 可能根本收不到它。
這包括產品能力、比較頁結論、價格條件、文件答案、作者資料，以及你希望 AI 引用的證據。使用者在 Chrome 裡能看到完整頁面，不代表爬蟲、正文擷取器或瀏覽型 Agent 取得了相同內容。
一位 SEO 實務工作者比較了各頁面模板的原始 HTML 與渲染後頁面。文章、教學、商店、課程、落地頁與分類頁中，大部分可見內容已經在 HTML 裡，只有少量內容要等 JavaScript 才出現。重點不在那個特定比例，而在它提出的問題：首次回傳的 HTML，是否已包含你希望 Agent 理解的答案？
對 GEO 來說，這是引用之前的資格檢查。系統必須先能擷取頁面的核心事實，才談得上評估證據或決定是否引用。
不同存取路徑可使用的 JavaScript 能力不同。原始抓取與正文擷取通常只依賴 HTML 回應。
Google 能渲染，不表示每個 Agent 都會渲染
「Google 能渲染 JavaScript」是事實，但常被錯誤延伸為：每個 AI 搜尋產品與 Agent 都會看見最終的瀏覽器頁面。
同一個 URL 可能透過不同路徑被存取：
| 存取路徑 | 實際取得的內容 | 對 JavaScript 的依賴 |
|---|---|---|
| 原始 HTTP 抓取 | 初始 HTML 回應 | 不執行 |
| 閱讀器或正文擷取器 | 從 HTML 選出的文字 | 通常不執行 |
| 瀏覽器自動化 | 渲染後 DOM | 可能執行，但受逾時與政策限制 |
| 搜尋索引管線 | 抓取、排隊、可能再渲染 | 取決於平台 |
| 工具呼叫型 Agent | 其網頁抓取工具輸出的文字 | 常接近原始抓取 |
Google 的渲染能力並不是可移植的承諾。其他答案引擎、企業內部檢索、瀏覽 Agent 與網頁擷取工具，可能只取得 HTML，也可能在慢速客戶端資料載入前就停止。把某一平台的能力當作網站架構前提，是沒有必要的賭注。
更穩妥的原則很簡單：與發現和引用有關的公開事實，應在首次回應中就能閱讀。
不要稽核框架，要稽核事實出現在哪一層
SSR 與 CSR 不是 GEO 的成績單。React、Vue 或 Next.js 網站可以對 Agent 友善；傳統伺服器端渲染網站也可能把重要事實藏在客戶端 API 呼叫之後。
應稽核每個重要內容區塊在哪一層才變得可用。
| 內容層級 | 常見例子 | GEO 風險 |
|---|---|---|
| 初始 HTML | 標題、正文、規格、FAQ、作者、日期 | 低 |
| 伺服器取得後輸出的 HTML | 即時價格、地區可用性 | 低到中 |
| 客戶端 API 請求 | 產品賣點、比較表、文件正文 | 高 |
| 使用者互動後顯示 | Tab、摺疊區塊、篩選、無限捲動結果 | 高 |
| 登入後可見 | 儀表板、私有知識庫 | 不應期待公開引用 |
如果你希望 AI 在公開回答中複述一項事實，它不應依賴使用者點擊、客戶端請求成功或冗長的 JavaScript 工作。互動功能可以保留，但解釋性內容必須前移。
常見失敗包括：只回傳載入外殼的產品頁、在 hydration 後才顯示比較表的比較頁、由客戶端路由載入正文的文件、只靠無限捲動的分類頁，以及結論只存在於圖片或 Canvas 的視覺模組。
渲染後頁面再漂亮，也可能在首次 HTML 回��中暴露了太少語意資訊。
用雙視圖檢查取代憑感覺判斷
不要問網站「是不是用了 React」。請保存同一 URL 的兩個版本：
- 不執行 JavaScript 時抓到的原始 HTML。
- 在瀏覽器開啟頁面、等待主要內容出現後匯出的
main文字。
基本抓取可以從這裡開始：
curl -sL "https://example.com/product" -o raw.html
比較時應看語意內容，不要把頁首、Cookie 橫幅與頁尾混進去：
- H1 與簡短回答
- 第一段說明
- 產品事實與限制條件
- 比較表
- FAQ 答案
- 作者與更新資訊
- 內部連結與 canonical URL
不要只以 networkidle 作為瀏覽器完成條件。分析腳本、客服元件與長連線可能讓頁面一直處於「忙碌」狀態。較可靠的條件是主要內容選擇器出現，或提供核心事實的特定資料來源已完成。
可以把這個比較變成發布指標：
核心內容曝光率 = 原始 HTML 中已有的關鍵內容區塊 / 頁面必備的關鍵內容區塊
目標不是把每個像素都塞進 HTML，而是確保理解頁面所需的證據不依賴客戶端執行成功。
先修正內容交付路徑，不必重寫整套前端
多數團隊不需要全站重構。應把穩定的公開資訊放進首次回應，同時讓 JavaScript 繼續負責篩選、儲存偏好、地圖、動畫與個人化。
| 頁面情境 | 較合適的交付模式 |
|---|---|
| 穩定的文章、教學與詞條頁 | 靜態生成或建置時預渲染 |
| 經常變動的價格、庫存或地區資訊 | 伺服器端渲染，加上快取與明確失效策略 |
| 以互動為主但說明內容穩定 | 伺服器輸出說明、事實與 FAQ；客戶端再水合互動 |
| 大型應用中的公開文件 | 預渲染公開路由，核心答案不依賴登入狀態 |
| 依賴多個內部 API 的頁面 | 在伺服器或 BFF 層彙整關鍵資料，供 HTML 與應用程式共用 |
JSON-LD 有幫助，但不能取代可閱讀的頁面正文。結構化資料應描述訪客與擷取器也能在文件中找到的事實。
GEO 團隊可採用的兩週節奏
第 1-2 天：列出影響自然發現、AI 引用、銷售支援或客戶支援的模板。文章、產品頁、文件、比較頁與分類頁通常就足夠。
第 3-5 天：每類模板抽樣 URL，保存原始 HTML 與渲染內容，標出缺少的 H1、說明、產品事實、FAQ 與內部連結。
第 6-9 天：優先修復價值最高且內容穩定的頁面。把定義、事實、比較結論與 FAQ 移到伺服器或建置產物。
第 10-14 天：重跑相同測試，並加入發布門檻。若初始 HTML 缺少 H1、主要答案、關鍵事實或 canonical 連結，該模板不應發布。
這不能保證每個 AI 產品都會引用你，但可以排除一個不必要的失敗模式：公開資訊無法被潛在 Agent 穩定讀取。
Auspia 的觀點
GEO 常從品牌提及、來源品質、實體清晰度與答案結構開始討論。這些都假設系統已經取得頁面。
JavaScript 本身不是問題。把公開說明當成客戶端執行的副產品，才是問題。HTML 應承擔內容責任，JavaScript 應承擔體驗責任。這樣的分工也會改善測試、技術 SEO 與 Agent 可存取性。
FAQ
Google 能渲染 JavaScript，還需要稽核原始 HTML 嗎？
需要。Google 的能力不代表其他爬蟲、閱讀工具與 Agent 走相同路徑。原始 HTML 檢查也能找出渲染延遲與客戶端請求失敗，讓技術除錯更容易。
對 GEO 而言，SSR 一定比 CSR 好嗎？
不一定。靜態生成、伺服器端渲染與預渲染都能達成目標；高互動元素仍可由客戶端渲染。判斷標準是公開頁面的核心事實是否已在首次 HTML 回應中可讀。
頁面所有部分都要避免 JavaScript 嗎？
不需要。篩選、動畫、地圖、儲存設定、個人化和登入體驗都可以繼續使用 JavaScript。應優先保障說明頁面主題、提供可引用事實的內容。
llms.txt 能解決只靠 JavaScript 顯示的內容嗎？
不能。即使某系統讀取 llms.txt，也不會自動取得完整正文或客戶端 API 資料。公開頁面本身仍必須提供可存取的核心內容。
來源說明
本文由 Adrian Skowron 的 SSR 與 CSR 可見內容比較推文 引發。推文圖表反映的是作者對自身頁面模板的測量，不是產業通用 benchmark。
作者：Julian Mercer，Auspia 14 年技術 SEO 實務者。Julian 關注爬取、渲染、結構化資料，以及讓搜尋與 AI 系統理解內容的技術基礎。
