SPA網站做GEO：先讓初始HTML有正文

GEO，即生成式引擎優化，關注的是網站內容能否被生成式人工智能（AI）相關係統發現、讀取和理解。這裏的爬蟲，是平台用來自動訪問網頁、讀取資訊的程序。要判斷一個網站是否便於AI爬蟲讀取，不能只看頁面在瀏覽器裏顯示得是否完整。

如果網站採用SPA，即單頁應用，就更需要檢查伺服器第一次返回的內容。SPA通常先返回基礎頁面，再由瀏覽器執行JavaScript，也就是用於加載內容和實現交互的腳本語言，把產品介紹、服務範圍、案例、常見問題（FAQ）和文章正文填入頁面。

這會造成一種常見誤判：用戶打開頁面時，標題、圖片和正文一項不少，開發人員便認為爬蟲也能看到同樣的內容。實際上，用戶看到的是JavaScript運行後的頁面；爬蟲第一次請求時拿到的，可能只有一個根節點和幾行腳本地址。

真正需要檢查的是初始HTML。HTML，即超文本標記語言，是構成網頁內容和結構的基礎代碼。初始HTML，就是伺服器收到訪問請求後，第一次直接返回的網頁代碼。

判斷SPA網站是否滿足GEO的基本讀取要求，不必先爭論用了React、Vue還是其他前端開發工具。先回答一個更具體的問題：

伺服器返回的初始HTML裏，是否已經包含網頁標題、頁面一級標題、正文、主要連結和結構化數據？

JavaScript可以繼續負責篩選、彈窗、表單和局部刷新，但不應負責生成頁面上的全部事實內容。

不要假設所有爬蟲都以同樣方式運行JavaScript

“AI爬蟲都不執行JavaScript”並不是已經得到所有平台確認的規則。

這裏還涉及SEO，即搜尋引擎優化。Google在相關官方文檔中明確説明，Googlebot，也就是Google的網頁抓取程序，會把需要處理的頁面加入渲染隊列，再使用無頭Chromium執行JavaScript。無頭Chromium是沒有可視操作界面的瀏覽器程序，可以在後台加載和處理網頁。

但Google同時提醒，並不是所有機器人都能運行JavaScript，因此服務端渲染或預渲染仍是合適的處理方式。

OpenAI和Anthropic公開的爬蟲文檔，主要説明機器人的用途、robots.txt控制方式和來源IP資訊。robots.txt是網站用來告訴爬蟲哪些內容允許或禁止訪問的文件，IP則是訪問來源的網絡地址。兩家平台都沒有在這些文檔中承諾：爬蟲會像完整瀏覽器一樣執行頁面腳本，並等待所有內容加載完成。

因此，工程上沒有必要把驗收結果建立在猜測上。更穩妥、也更容易檢查的標準是：

關鍵公開頁面的初始HTML應當直接包含Title（網頁標題）、H1（頁面一級標題）、正文、主要連結和結構化數據。機器人即使不執行JavaScript，也能讀到頁面的主要資訊。

第一步不是更換框架，而是查看原始響應

一個典型的SPA頁面，第一次請求時可能只返回：

<div id='app'></div>
<script src='/assets/app.js'></script>

產品介紹、服務範圍、案例、FAQ和文章正文，都要等JavaScript運行並從數據接口取回資訊後，才會出現在頁面中。

普通用戶通常感覺不到這個過程，因為瀏覽器會自動執行腳本。對於不執行腳本、執行能力有限，或者不會等待頁面完成渲染的機器人來説，它第一次讀到的可能只有一個空的根節點和腳本地址。

檢查時，不能只看瀏覽器開發者工具中的Elements（元素）面板。這個面板顯示的是瀏覽器處理後的頁面結構，不是伺服器最初返回的HTML。

上線前至少要做三次檢查：

1. 查看“網頁源代碼”，確認伺服器第一次返回了哪些內容；
2. 使用命令行直接請求頁面地址，並保存原始響應；
3. 關閉JavaScript，或者使用純文本抓取方式再次查看頁面。

例如，可以使用curl直接請求頁面。curl是一種命令行網絡請求工具：

curl -L https://example.com/product/alpha -o page.html

這條命令會請求示例頁面，並把返回內容保存為page.html。隨後應在文件中查找產品名稱、H1、核心參數和正文首段。

如果這些內容不在文件裏，即使瀏覽器最終顯示正常，該頁面也沒有達到“初始HTML可讀”的驗收標準。

原始HTML檢查結果	判斷	處理建議
包含Title、H1、正文、主要連結和關鍵事實	通過	保留現有方案，繼續檢查狀態碼和內容一致性
只有摘要，主要正文依賴JavaScript	有風險	優先把關鍵頁面改為靜態生成、服務端渲染或預渲染
只有根節點和腳本地址	不通過	先調整渲染方式，不要只修改頁面文案

SPA不必全部重做，可以按頁面選擇方案

發現初始HTML沒有正文後，不一定要推翻整個SPA。可以根據內容更新頻率、公開頁面地址（URL）的數量和現有技術條件，在SSG、SSR和按路由預渲染之間選擇。

URL就是網頁地址。產品頁、文章頁和案例頁都應擁有能夠單獨訪問的URL。

SSG：在構建網站時生成完整HTML

SSG是Static Site Generation的縮寫，中文通常稱為靜態站點生成或靜態生成。

它會在網站構建時，為公開URL提前生成完整HTML。用戶或爬蟲訪問時，伺服器可以直接返回已經生成的頁面，不必等待瀏覽器執行腳本後再補充正文。

Next.js官方文檔説明，靜態生成會在構建時生成HTML，之後可以通過CDN重複使用這些頁面文件。CDN，即內容分發網絡，可以從不同位置向訪問者提供已經生成的文件。

SSG通常適合以下內容：

• 產品介紹、服務説明、品牌介紹和案例頁；
• 知識文章、幫助中心等公開內容；
• 內容來自CMS，但發佈後不會頻繁變化；
• 頁面URL能夠在構建時確定；
• 需要讓大量公開頁面穩定返回完整HTML。

CMS，即內容管理系統，是用來編輯、發佈和管理網站內容的後台工具。

SSG的限制也很明確：內容發生變化後，通常需要重新構建頁面；動態URL則需要提前生成，或者配置增量更新機制。

需要登錄才能訪問的後台頁面，不應為了靜態化而變成公開頁面。

SSR：每次收到請求時生成HTML

SSR是Server-Side Rendering的縮寫，中文稱為服務端渲染。

用戶或爬蟲每次請求頁面時，伺服器都會讀取當前數據，並生成對應的完整HTML。Next.js官方文檔將其定義為每次請求時生成頁面HTML。

SSR通常適合：

• 價格、庫存、時效等變化較快的公開資訊；
• 頁面需要根據當前數據生成，但不涉及用戶私有資訊；
• 每個URL都需要直接返回當下的完整內容；
• 團隊已經具備穩定的服務端運行環境。

SSR需要處理伺服器計算、緩存、接口超時和故障恢復等問題。它不是把部分前端代碼移到伺服器就結束了。

如果數據接口超時、返回空數據或發生錯誤，伺服器仍然可能輸出一個正文為空、狀態碼卻顯示正常的頁面。因此，改為SSR後，還要同時處理緩存更新、空數據、錯誤頁面和狀態碼。

按路由預渲染：先處理重點頁面

如果短期內無法重構整個SPA，可以先為重點公開URL生成完整HTML快照。這裏的路由，可以簡單理解為網站中不同頁面地址與頁面內容之間的對應關係。

可以優先處理：

• 首頁；
• 核心產品頁；
• 核心服務頁；
• 品牌介紹頁；
• 重點案例頁；
• 已經有訪問量或業務價值較高的文章。

這種方式適合作為過渡方案：先讓重點頁面的初始HTML可讀，再逐步遷移到原生SSR或SSG。

需要注意的是，如果只在識別到機器人時返回靜態頁面，而用戶訪問時看到另一種頁面，這類動態渲染被Google視為變通方案，不建議長期依賴。

無論採用哪種方式，機器人和用戶看到的核心事實都必須一致，不能長期維護兩套內容不同的頁面。

方案	HTML生成時間	適合頁面	主要代價
SSG靜態生成	構建網站時	產品、服務、文章、案例等穩定內容	更新時需要重新生成或增量更新
SSR服務端渲染	每次收到請求時	公開且變化較快的內容	伺服器計算、緩存和故障處理
按路由預渲染	發佈或定時任務執行時	暫時無法整體改造的重點URL	快照更新和內容一致性維護

初始HTML有正文，不等於放棄SPA交互

調整渲染方式後，頁面仍然可以保留篩選、計算器、輪播、表單、登錄狀態和局部刷新等功能。

常見做法是，先由伺服器或構建流程輸出完整HTML，再由JavaScript接管頁面交互。這個接管過程通常稱為“水合”。

改造時，可以把頁面內容分成兩類：

• 事實內容：品牌介紹、產品名稱、服務範圍、參數、案例、FAQ、作者和發佈日期。這些內容應當出現在初始HTML中；
• 交互功能：篩選、排序、彈窗、登錄後數據和個性化結果。這些功能可以繼續由JavaScript處理。

必須登錄才能查看的頁面，本來就不屬於公開抓取範圍。不能為了讓爬蟲讀取，把用戶私有數據或後台內容寫進公開HTML。

正文可以讀取後，還要檢查六項基礎設置

初始HTML包含正文，只解決了最直接的問題。URL、狀態碼、頁面頭部資訊、結構化數據、連結和接口容錯，也會影響頁面能否被發現和正確讀取。

1. 每個頁面都要有獨立URL

產品、服務、文章和案例應當擁有獨立、穩定、可以直接訪問的URL，不要只依賴#/product/1一類地址片段切換內容。

Google建議SPA使用History API，也就是瀏覽器的歷史記錄接口，並通過帶有href屬性的真實連結連接各個頁面。這樣，每個URL才能被發現、複製和單獨請求。

2. 狀態碼要反映真實結果

狀態碼是伺服器對訪問結果的簡短説明。正常頁面應返回200，表示請求成功；不存在的頁面應返回404，表示沒有找到；頁面跳轉則應返回合適的3xx重定向狀態碼。

SPA的常見問題是，所有路徑都返回200和同一個空頁面。這樣一來，不存在的地址也會被當成正常頁面處理。

3. 頁面頭部資訊要隨URL變化

每個公開URL都應在初始HTML中正確輸出以下資訊：

• Title，即網頁標題；
• Meta description，即頁面內容摘要；
• canonical，即用於聲明當前頁面規範網址的資訊；
• 必要的robots指令，即對爬蟲訪問或收錄方式的控制要求。

不要等頁面加載完成後，再由前端腳本統一替換這些資訊。

4. 結構化數據必須與正文一致

結構化數據是按照固定格式説明頁面內容的資訊。JSON-LD是其中一種常用格式，可以直接放在初始HTML中。

JSON-LD中的品牌、產品、作者、日期、價格和FAQ，必須與頁面可見正文一致。結構化數據不能代替正文，也不能證明頁面一定會被AI引用。

5. 重要連結必須能夠直接解析

重要頁面之間應使用正常的<a href='...'>連結。

如果連結只綁定點擊事件，卻沒有href；或者必須完成鼠標交互後才會出現，機器人發現這些頁面的難度就會增加。

6. 頁面不能依賴接口每次都請求成功

API，即應用程序接口，是不同程序之間請求和傳遞數據的入口。

進行服務端渲染時，如果API請求失敗，頁面不應返回空正文和200狀態碼。網站需要設置緩存、降級內容和明確的錯誤狀態，避免機器人在故障期間抓到一個看似正常、實際沒有內容的頁面。

一套可以直接執行的改造順序

第一步：整理全部公開URL

導出網站所有公開URL，按首頁、產品、服務、文章、案例和其他頁面分類。

第二步：逐類檢查原始HTML

記錄每類頁面的Title、H1、正文首段、核心事實、主要連結和結構化數據是否存在。

不要用一個頁面的檢查結果代表整個網站。同一套SPA中，不同路由可能採用不同的數據加載方式。

第三步：確定改造優先級

不必一次重寫整個前端。可以先處理首頁、核心產品頁、核心服務頁、品牌介紹頁、重點案例頁和已有訪問量的文章。

第四步：為每類頁面選擇渲染方式

• 內容發佈後較穩定：優先使用SSG；
• 公開內容變化較快：考慮SSR；
• 暫時無法重構：先對重點路由進行預渲染。

第五步：把關鍵資訊寫入初始HTML

至少應包括Title、H1、正文、canonical、JSON-LD和核心連結，同時保留原有前端交互。

第六步：對比三份頁面結果

在測試環境中同時檢查：

1. 伺服器返回的原始HTML；
2. 瀏覽器執行腳本後的頁面結構；
3. 用戶最終看到的頁面。

三者的核心事實應當一致。

第七步：上線後檢查伺服器日誌

確認相關機器人是否實際訪問網站，並檢查返回狀態碼、響應內容大小和被訪問頁面是否正常。

User-Agent是請求資訊中用於標識客戶端的字段，但它只能作為判斷線索，不能單獨證明請求來自某個平台。還需要結合平台官方公佈的IP驗證方式進行確認。

第八步：保存記錄並觀察結果

保存改造前後的原始頁面樣本、發佈日期和版本，再觀察頁面是否被納入可檢索範圍、是否獲得引用，以及是否出現來自相關平台的訪問。

改成SSR或SSG，只解決“內容能否被讀取”的問題，不保證頁面一定會被抓取、納入索引或引用。

上線驗收清單

1. 每個重要頁面都有獨立、穩定的URL；
2. 直接請求URL時，伺服器返回200和完整正文；
3. 原始HTML包含Title、H1、正文首段和核心事實；
4. 頁面內的重要連結使用真實href；
5. 不存在的頁面返回真實404；
6. canonical指向正確URL；
7. JSON-LD與可見正文一致；
8. 關閉JavaScript後仍能讀到主要內容；
9. 瀏覽器中的交互功能仍然可用；
10. 原始HTML與執行腳本後的頁面不存在事實衝突；
11. robots.txt沒有誤攔截關鍵頁面和必要資源；
12. 上線後可以在伺服器日誌中看到正常訪問和響應。

改造解決的是“可讀取”，不是“保證被引用”

SPA網站是否便於AI爬蟲讀取，關鍵不在於用了哪種前端框架，而在於伺服器第一次響應時有沒有返回真實正文。

與其反覆猜測某個機器人能否執行JavaScript，不如採用可以直接檢查的標準：公開頁面的初始HTML包含完整事實內容，JavaScript負責後續交互。

內容穩定時優先考慮SSG；公開資訊變化較快時考慮SSR；短期內無法整體重構時，先預渲染重點路由。

改造完成後，還要逐項檢查原始HTML、狀態碼、URL、連結、結構化數據和伺服器日誌。只有這些檢查結果都符合預期，才能確認網站已經解決內容可讀取的問題。至於頁面會不會被抓取、收錄或引用，還需要結合訪問控制、內容質量、事實依據、來源關係和平台自身機制繼續觀察。

FAQ

1. AI爬蟲都不執行JavaScript嗎？

不能一概而論。

Googlebot明確會執行JavaScript；OpenAI和Anthropic公開的爬蟲文檔，則沒有承諾提供與完整瀏覽器相同的腳本渲染能力。

工程驗收應以關鍵正文能否從初始HTML中直接讀取為標準，而不是等待機器人替網站完成腳本運行。

2. SPA網站一定要全部重做嗎？

不一定。

可以先處理首頁、產品頁、服務頁、案例頁和重點文章，為這些公開路由增加SSG、SSR或預渲染，再逐步擴大改造範圍。

3. SSG和SSR怎麼選？

內容發佈後較穩定，優先考慮SSG；公開內容需要隨請求更新，再考慮SSR。

兩者都能讓初始響應包含完整HTML，主要區別在於HTML的生成時間、緩存方式和運行成本。

4. 可以只給機器人返回靜態頁面嗎？

Google把動態渲染視為變通方案，不建議長期依賴。

機器人版和用戶版的核心內容必須一致。長期方案應考慮SSR、SSG，或者預渲染後再由JavaScript接管交互。

5. 改成SSR後就會被AI引用嗎？

不能保證。

SSR只解決內容能否從初始響應中讀取。頁面是否會被抓取、納入索引或引用，還取決於訪問控制、內容質量、事實依據、來源關係和平台自身機制。

6. 怎麼證明改造已經生效？

保存同一URL的原始響應，確認其中包含Title、H1、正文和連結；再檢查狀態碼、關閉JavaScript後的頁面、結構化數據和伺服器日誌。

不能只看瀏覽器最終顯示的頁面。

官方資料

• Google JavaScript SEO基礎
• Google動態渲染説明
• OpenAI爬蟲説明
• Anthropic爬蟲説明
• Next.js靜態生成
• Next.js服務端渲染