# SPA網站做GEO：先讓初始HTML有正文
> GEO，即生成式引擎優化，關注的是網站內容能否被生成式人工智能（AI）相關係統發現、讀取和理解。這裏的爬蟲，是平台用來自動訪問網頁、讀取資訊的程序。要判斷一個網站是否便於AI爬蟲讀取，不能只看頁面在瀏覽器裏顯示得是否完整。
來源：https://www.starbox.work/zh-hant/insights/geo-guide/geo127/（星盒AI 知識中心，更新於 2026-10-10）
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頁面，第一次請求時可能只返回：
```html
```
產品介紹、服務範圍、案例、FAQ和文章正文，都要等JavaScript運行並從數據接口取回資訊後，才會出現在頁面中。
普通用戶通常感覺不到這個過程，因為瀏覽器會自動執行腳本。對於不執行腳本、執行能力有限，或者不會等待頁面完成渲染的機器人來説，它第一次讀到的可能只有一個空的根節點和腳本地址。
檢查時，不能只看瀏覽器開發者工具中的Elements（元素）面板。這個面板顯示的是瀏覽器處理後的頁面結構，不是伺服器最初返回的HTML。
上線前至少要做三次檢查：
1. 查看“網頁源代碼”，確認伺服器第一次返回了哪些內容；
2. 使用命令行直接請求頁面地址，並保存原始響應；
3. 關閉JavaScript，或者使用純文本抓取方式再次查看頁面。
例如，可以使用`curl`直接請求頁面。`curl`是一種命令行網絡請求工具：
```bash
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. 重要連結必須能夠直接解析
重要頁面之間應使用正常的``連結。
如果連結只綁定點擊事件，卻沒有`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基礎](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [Google動態渲染説明](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering)
- [OpenAI爬蟲説明](https://developers.openai.com/api/docs/bots)
- [Anthropic爬蟲説明](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)
- [Next.js靜態生成](https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation)
- [Next.js服務端渲染](https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering)