如果你是一家面向北美、歐洲和澳洲市場的 B2B SaaS 或專業服務企業，官網可能由 React、Vue、Headless CMS，或經過深度客製的 WordPress 搭建。用戶打開產品頁時，可以正常看到功能介紹、服務範圍、FAQ、價格說明和行業解決方案，但當團隊查看網頁原始碼、使用 curl 請求，或把頁面交給文字提取工具時，拿到的卻可能只有標題、頁面容器、導覽和頁尾。
人能看到內容，不等於抓取系統能穩定獲得內容。
我看到不少 B2B 出海企業在排查 GEO 問題時，會先去改文章、補關鍵字或增加頁面數量。但當官網依賴 JavaScript 載入核心資訊時，問題可能不在內容數量，而在內容能不能被穩定讀取。對這種場景，我通常會先檢查“用戶可見內容”和“抓取可得內容”之間的差異，再決定是調整技術架構、頁面範本，還是內容結構。
為什麼頁面顯示正常，抓取結果卻可能只有一個空殼
伺服器首次回傳的 HTML 不包含主要正文
用戶訪問一個網頁時，瀏覽器首先向伺服器請求 URL。理想情況下，伺服器回傳的 HTML 中已經包含產品定位、服務說明、FAQ 和關鍵結論。但在部分 React、Vue 或 Headless CMS 網站中，伺服器回傳的可能只有標題、空容器節點和 JavaScript 檔案位址。
產品介紹、價格說明和服務範圍，要等瀏覽器下載腳本、執行腳本並呼叫內容介面後，才會寫入頁面。普通瀏覽器通常能夠完成這一過程，但部分抓取系統可能不會執行全部腳本，也可能不會等待所有非同步請求完成。最終得到的頁面，就只剩下外層框架。
內容依賴額外條件才會出現
有些頁面雖然會載入正文，但內容出現需要額外條件。例如用戶必須滾動到某個區域、點擊標籤、展開摺疊模組，或者接受 Cookie 後，腳本才會繼續請求內容。
頁面還可能根據登入資訊、本地儲存、瀏覽器語言或地區判斷回傳不同內容。懶載入模組只有進入可視區域後才開始請求正文。如果抓取請求無法觸發這些條件，就可能只能獲得不完整內容。
安全配置讓不同訪問者得到不同結果
CDN、WAF 或 Bot 管理策略可能針對不同 User-Agent 回傳不同頁面。普通瀏覽器可以獲得完整內容，但自動化請求可能收到驗證碼、挑戰頁面、空白回應、403 或 429 狀態。
內容介面也可能存在跨域限制、鑑權要求、頻率限制或地區規則。團隊在自己的瀏覽器中測試正常，並不能證明無 Cookie、不同地區和不同 User-Agent 的請求也能獲得相同正文。
需要注意的是，HTTP 狀態碼為 200，不代表正文已經成功回傳。頁面進入搜尋索引，也不代表其中每一段內容都能被穩定提取。頁面可以被訪問，也不等於頁面結構足以支援準確理解。
如果官網較少被 ChatGPT、Gemini、Google AI Mode、Perplexity 或 Google AI Overview 引用，可訪問性可能是原因之一，但不能只憑引用變化判斷技術問題。引用結果還會受到問題表達、頁面品質、外部來源和平台更新等因素影響。
不要先改內容，要先確認內容在哪個環節消失
在我們的方法論裡，這類問題通常按照以下順序檢查：伺服器回應、原始 HTML、JavaScript 與 CSS 資源、渲染後 DOM、內容介面、安全策略和伺服器日誌。
重點不是判斷網站用了什麼框架，而是確認核心資訊在哪個環節出現，又在哪個環節消失。只有把問題位置縮小，開發團隊和 GEO 團隊才能選擇合適的改造方式。
判斷一：內容有沒有從伺服器直接回傳
先取得核心 URL 的原始回應，並搜尋產品名稱、服務類型、FAQ 問題或一段有辨識度的正文。
如果原始 HTML 已經包含主要內容，問題可能發生在文字解析、頁面結構或安全配置，而不一定是客戶端渲染。如果原始 HTML 中只有空容器，就需要繼續檢查 JavaScript 和內容介面。
判斷二：內容能否在無互動條件下完成載入
新建無痕視窗，清除 Cookie，不登入、不滾動、不點擊標籤，也不展開彈窗，觀察產品介紹、服務範圍和 FAQ 是否仍會自動出現。
如果核心資訊必須透過滾動、點擊或 Cookie 授權才進入頁面，那麼抓取系統就可能無法穩定獲得這些內容。需要優先調整內容的預設載入方式。
判斷三：資源和介面有沒有穩定回傳
開啟瀏覽器開發者工具，檢查 JavaScript、CSS、字型、圖片和內容 API。重點查看是否存在 4xx、5xx、跨域錯誤、請求超時或載入順序異常。
還要確認內容介面是否要求 Token、Session、登入狀態、特定請求頭或本地儲存資訊。有些頁面框架載入成功，但負責回傳正文的介面沒有回應，最終仍然只有空頁面。
判斷四：不同請求是否得到不同頁面
使用不同 User-Agent、無 Cookie 環境，以及不同地區或網路條件請求同一個 URL，然後比較狀態碼、回應體大小、正文數量和資源請求數量。
如果普通瀏覽器獲得的是完整頁面，而自動化請求獲得的是驗證頁面或明顯較小的回應體，就要優先檢查 CDN、WAF 和 Bot 管理規則。
判斷五：技術可訪問後，內容是否仍然值得引用
技術可訪問只是基礎條件。頁面還需要清楚表達產品定位、服務範圍、適用對象、地區範圍、使用場景和差異點。
如果關鍵結論只存在於圖片、Canvas、影片或互動元件中，抓取系統仍然可能無法理解。頁面也需要有明確的標題、段落、列表、問答結構和實體資訊，避免正文被導覽、頁尾和範本內容淹沒。
五組排查與改造動作：從確認問題到恢復內容可提取性
動作一：對照原始 HTML、渲染後 DOM 與正文文字
對同一個 URL 產生三份結果：伺服器首次回傳的原始 HTML、瀏覽器執行腳本後的 DOM，以及去掉導覽、樣式和腳本後的正文文字。
原始 HTML 可以透過 curl、瀏覽器 View Source 或抓取工具儲存。渲染後 DOM 可以在開發者工具的 Elements 面板中查看，也可以使用支援 JavaScript 的無頭瀏覽器產生。正文文字則用於檢查頁面中的主要資訊能否被連續提取。
三份結果需要搜尋同一組識別點，例如產品名稱、服務類型、FAQ 問題和關鍵結論。
如果原始 HTML 沒有正文，但渲染後 DOM 有，說明內容主要由客戶端產生。如果渲染後 DOM 已有正文，但文字提取結果仍缺失，問題可能在頁面結構、隱藏屬性或範本雜訊。如果三份結果都沒有內容，就要繼續排查內容介面、權限和地區邏輯。
這種對照可以避免把“正文缺失”“腳本沒有執行”和“正文結構不清楚”當成同一個問題。
動作二：檢查 HTTP 回應與抓取控制指令
確認核心 URL 能穩定回傳 200，並檢查是否存在多次重新導向、軟 404、登入跳轉、地區跳轉或安全驗證頁面。
有些頁面表面上能夠打開，但自動化請求會被引導到另一個版本。例如訪問者被跳轉到地區選擇頁、Cookie 頁面或帳號登入頁，最終獲得的正文就會與普通用戶不同。
隨後檢查 robots.txt 是否錯誤限制頁面、腳本目錄或介面路徑，再檢查頁面中的 meta robots 和回應頭中的 X-Robots-Tag。桌面端、行動端和無 Cookie 請求應分別測試，不能只驗證一種環境。
這一動作主要用於定位抓取被阻止、請求被改寫，或核心資源無法訪問的問題。
動作三：排查 JavaScript、資源檔案與內容介面
在 Network 面板中篩選 JS、Fetch 和 XHR 請求，查看正文依賴的腳本和介面是否能夠穩定回傳。
檢查過程中，要記錄 4xx、5xx、跨域錯誤和載入超時。暫停滾動、點擊和 Cookie 授權，觀察正文介面是否仍會自動請求。使用較慢網路環境重新載入頁面，也可以判斷內容是否因為等待時間不足而缺失。
如果網站使用 Headless CMS 或自研內容介面，還要檢查 API 是否要求登入狀態、Token、Session 或特定請求頭。部分網站在瀏覽器中能夠正常顯示，是因為用戶此前已經留下 Cookie 或本地儲存資訊，但新的抓取請求並不具備這些條件。
還可以暫時關閉部分第三方腳本，觀察是否有廣告、追蹤或聊天工具的報錯阻斷後續渲染。頁面主體可能依賴多個資源，只要其中一個關鍵腳本失敗，瀏覽器仍然可能顯示頁面框架，但正文不會出現。
動作四：把需要被理解的內容調整為伺服器可輸出形式
產品定位、服務範圍、適用場景、FAQ、價格說明和關鍵結論，應盡量進入首次 HTML，或者透過穩定的渲染方式獲得。
根據網站架構，可以選擇伺服器端渲染、靜態產生、增量靜態產生或重點頁面預渲染。使用 Headless CMS 的網站，可以設定能夠直接輸出到 HTML 的正文區域。如果網站不適合全面改造，可以先為重要產品頁、服務頁和 FAQ 頁提供穩定的靜態內容版本。
內容層面也要同步調整。不要把關鍵結論只放在圖片、Canvas 或影片中，也不要把主要說明隱藏在必須點擊的彈窗或標籤頁裡。頁面應使用清楚的 H1、H2、段落和列表。
FAQ 頁面可以根據實際內容採用合適的結構化資料，但結構化標記不能代替頁面正文。產品和服務頁面也可以補充與真實內容相符的 Organization、Product、Service、Article 或 BreadcrumbList 等 Schema。
這樣做的目的不是迎合某一個平台，而是讓不同訪問環境都能獲得一致、可識別的核心資訊。
動作五：檢查 CDN、WAF 與伺服器日誌
使用不同 User-Agent、無 Cookie 和不同地區環境請求同一個頁面，對比普通瀏覽器和自動化請求的狀態碼、回應體大小和正文數量。
重點檢查是否出現驗證碼、挑戰頁面、403、429、空白回應或內容降級。隨後進入 CDN 和 WAF 配置，核對 Bot 管理、頻率限制、IP 規則和地區策略。
伺服器日誌可以進一步說明真實訪問結果。檢查請求時間、來源、User-Agent、狀態碼、回應大小和介面呼叫情況，可以判斷抓取請求是否到達伺服器、是否成功回傳正文，以及是否在某個資源請求階段失敗。
對於確認屬於正常訪問的抓取請求，可以設定更合理的規則，但不建議為了提高可訪問性直接關閉安全防護。更合適的做法是先明確哪些請求被錯誤攔截，再有針對性地調整。
技術改造完成後，不能只測試頁面能不能打開
技術修復不是交付終點。完成調整後，需要分別監測頁面回應、內容提取和 AI 引用三個層次。
第一層：頁面回應監測
建議記錄 HTTP 狀態碼、重新導向次數、回應時間、HTML 回應體大小，以及主要腳本和介面的失敗情況。同時比較不同 User-Agent、Cookie 狀態和地區環境下的回應差異。
如果狀態碼正常，但回應體突然明顯變小，或者關鍵介面開始出現超時，也可能說明頁面正文再次缺失。
第二層：內容提取監測
為每個核心頁面設定固定檢查項，包括產品定位是否能被提取、服務範圍是否完整、FAQ 問題和回答是否存在、標題層級是否清楚，以及正文是否被導覽和範本內容淹沒。
還需要比較首次 HTML 與渲染結果，確認兩者的主要資訊保持一致。可以每週抽查一組核心 URL，並在範本、CMS 或前端元件改動後進行迴歸測試。
第三層：AI 引用監測
圍繞真實用戶問題建立查詢集，例如“某類 B2B SaaS 適合哪些企業”“某項專業服務包含哪些內容”“兩類解決方案有什麼區別”“選擇供應商時應評估哪些條件”。
海外這邊，可以分別觀察 ChatGPT、Gemini、Google AI Mode、Perplexity 和 Google AI Overview 是否開始讀取官網產品頁、服務頁、FAQ 頁或行業解決方案頁。
平台回答會受到問題表達、地區、時間和可用來源影響，因此監測重點應放在趨勢、引用頁面類型和內容缺口，而不是承諾固定出現。
如果 HTML 已完整但文字提取仍然較差，應調整標題、段落和正文結構。如果正文依賴介面，應優先處理介面權限和伺服器輸出。如果只有部分地區失敗，需要檢查 CDN 和地區規則。如果頁面已經可以提取，但相關問題中仍然較少出現，就要補充問題型內容、比較說明、適用場景和事實依據。
這類技術問題修復後，可以觀察哪些階段性變化
下面的區間是基於行業技術實施過程的方法論推演，不代表固定結果。通常伺服器回應和正文提取會先改善，AI 提及與頁面引用的變化出現得更晚。
| 觀察維度 | 優化前的典型狀態 | 優化後的合理狀態區間 | 常見觀察週期 |
|---|---|---|---|
| 原始 HTML 內容 | 主要只有頁面框架、標題或容器 | 主要產品、服務、FAQ 和場景說明可在首次 HTML 或穩定渲染結果中獲得 | 1—4 週 |
| 頁面回應穩定性 | 部分請求出現空頁面、資源失敗、安全驗證或不同版本 | 核心頁面較穩定地回傳 200，異常回應和內容差異逐步減少 | 2—8 週 |
| 正文提取完整度 | 抓取結果以導覽、頁尾和通用範本為主 | 主要標題、服務說明、FAQ 和關鍵結論可以被連續提取 | 2—8 週 |
| AI 提及與頁面引用 | 高相關查詢中較少引用官網頁面 | 部分相關問題開始引用產品頁、服務頁、FAQ 頁或行業解決方案頁 | 8—12 週或更長 |
| 團隊排查效率 | 遇到問題後反覆改內容或依賴單次測試 | 能根據伺服器回應、HTML、資源、介面、安全策略和日誌縮小問題範圍 | 4—12 週持續改善 |
1—3 週通常用於完成抓取、渲染過程和伺服器配置的系統檢查。4—8 週通常用於完成核心範本的伺服器端渲染、靜態產生或預渲染調整。8—12 週或更長時間用於觀察內容提取穩定性和 AI 引用變化。
如果網站範本複雜、頁面數量較多或涉及多地區部署，週期可能進一步延長。技術可訪問性是必要條件，但不是引用結果的承諾。頁面內容品質、問題相關性和外部資訊一致性，也會影響後續表現。
B2B 出海網站渲染問題排查清單
- 使用 curl 或同類工具儲存核心 URL 的原始 HTML，並搜尋產品名稱、服務描述和 FAQ 文字。
- 對照瀏覽器渲染後的 DOM，確認缺失內容由伺服器回傳，還是由客戶端腳本產生。
- 在無 Cookie、未登入、不滾動和不點擊的條件下重新測試頁面。
- 檢查頁面、JavaScript、CSS 和內容介面是否存在 4xx、5xx、跨域錯誤或超時。
- 核對 robots.txt、meta robots 和 X-Robots-Tag，確認頁面及主要資源沒有被錯誤限制。
- 使用不同 User-Agent 和地區環境請求頁面，比較狀態碼、回應大小和正文數量。
- 將產品定位、服務範圍、FAQ 和關鍵結論放入首次 HTML 或穩定可渲染的正文區域。
- 檢查 CDN、WAF 和伺服器日誌，確認正常抓取請求沒有被驗證碼、頻率規則或地區策略攔截。
- 為核心頁面建立每週迴歸測試，記錄回應狀態、正文提取和 AI 引用頁面變化。
- 技術修復後重新評估內容結構，補充問題型標題、明確回答、事實依據和適用場景。
當官網在瀏覽器中顯示正常，但抓取工具只能獲得頁面框架時，繼續增加文章不一定能解決問題。更合適的做法，是先選擇 5—10 個核心產品頁、服務頁和 FAQ 頁，確認內容在伺服器回應、原始 HTML、資源載入、渲染結果、內容介面還是安全策略中出現了缺失。
如果你正在判斷要不要做 GEO，先做一份基線診斷——自己手動測或用我們免費 Audit 都行。我們團隊在 GEO 領域有多年實戰經驗，會從技術訪問和內容可理解性兩個方向整理問題清單，但不會對具體平台的引用結果作固定承諾。
相關問題
頁面可以被 Google 收錄，為什麼 AI 工具仍可能抓不到正文？
收錄通常只能說明頁面曾被發現和處理，不代表所有正文都能在不同抓取環境中穩定獲得。如果主要內容依賴 JavaScript、介面權限或互動觸發，部分系統可能只能讀取頁面框架或不完整文字。
React 或 Vue 網站一定要改成伺服器端渲染嗎？
不一定。需要先檢查核心內容是否已經存在於原始 HTML、渲染是否穩定，以及介面和安全策略是否正常。只有確認客戶端產生方式持續影響內容提取後，才需要評估伺服器端渲染、靜態產生或預渲染。
為什麼 curl 回傳空內容，但瀏覽器裡頁面是完整的？
curl 預設不會像瀏覽器一樣執行 JavaScript。如果伺服器只回傳頁面容器，正文由腳本呼叫介面後產生，curl 得到的內容就可能很少。這說明需要繼續檢查渲染方式，但不能單憑一次請求判斷整個頁面無法抓取。
robots.txt 沒有禁止抓取，為什麼頁面還是提取不完整？
robots.txt 只是一個檢查點。頁面還可能受到 meta robots、X-Robots-Tag、介面鑑權、跨域配置、懶載入、Cookie 條件、CDN 或 WAF 策略影響，需要結合資源請求和伺服器日誌排查。
修復 JavaScript 渲染後，多久可能看到 AI 引用變化？
技術訪問和正文提取通常可以在 1—8 週內分階段驗證。AI 引用變化可能需要 8—12 週或更長時間，並受到問題相關性、頁面品質、平台更新和其他可用來源影響，因此應觀察趨勢，而不是固定次數。
GEO 團隊和開發團隊應該怎樣分工？
GEO 團隊負責定義需要被提取的頁面、關鍵內容和測試查詢，並建立檢測基線。開發團隊負責檢查伺服器輸出、資源請求、介面權限、渲染方式和安全配置，雙方再根據監測結果共同安排範本和內容調整。