# 上線前SEO（搜尋引擎優化）與AI（人工智能）爬蟲9項檢查

> 這裏所説的“爬蟲”，是搜尋引擎或人工智能平台用來自動訪問網頁、讀取內容的程序。

來源：https://www.starbox.work/zh-hant/insights/geo-guide/geo113/（星盒AI 知識中心，更新於 2026-10-04）

這裏所説的“爬蟲”，是搜尋引擎或人工智能平台用來自動訪問網頁、讀取內容的程序。

網站內容寫完了，頁面也能在瀏覽器裏打開，並不代表爬蟲一定能夠發現、訪問和讀懂它。爬蟲可能找不到頁面，可能在訪問時被攔截，也可能只拿到一個沒有正文的空頁面。

要理解這套檢查，先分清幾個動作：

- 發現：平台知道這個網頁地址存在；
- 抓取：爬蟲實際訪問並取得頁面內容；
- 索引：平台把頁面資訊存入可檢索的數據庫；
- 引用：人工智能平台在回答問題時使用並展示頁面資訊。

這幾個動作不會自動連續發生。頁面被發現，不等於一定會被抓取；抓取成功，也不等於一定會被索引或引用。

HTTP（網頁請求與響應所使用的通信規則）狀態碼返回200，通常只表示伺服器成功處理了請求。它不能證明爬蟲拿到的HTML（網頁源代碼）中一定含有正文。

因此，網站上線前至少要回答四個問題：

1. 頁面能否被發現；
2. 頁面能否正常訪問；
3. 頁面內容能否被讀取；
4. 真實訪問結果能否通過伺服器日誌複核。

伺服器日誌，就是網站或內容分發節點保存的真實訪問記錄。它可以顯示誰在什麼時間請求了哪個頁面，以及伺服器返回了什麼結果。

還有四個常見誤區需要先排除：

- `robots.txt`（網站根目錄中的爬蟲訪問規則文件）寫了`Allow`，不代表頁面一定會被抓取；
- HTTP狀態碼返回200，不代表頁面正文一定可讀；
- 搜尋爬蟲可以訪問，不代表訓練爬蟲和用戶觸發的訪問也採用相同規則；
- User-Agent（訪問方在請求中聲明的身份名稱和用途）寫得正確，不代表請求一定來自官方爬蟲。

不少人工智能平台會分別設置搜尋、訓練和用戶觸發訪問所使用的User-Agent。網站需要按用途逐一決定是否放行，不能用一條規則處理所有爬蟲。

下面這9項，應當從伺服器響應一直查到真實日誌。關鍵項不合格，應先修復，再發布。

| 檢查項 | 合格狀態 | 常見問題 |
|---|---|---|
| 1. 公網訪問 | 頁面無需登錄，域名與HTTPS正常 | 登錄限制、證書錯誤、地區攔截 |
| 2. HTTP狀態 | 正式URL直接或最終穩定返回200 | 4xx、5xx、軟404、重定向循環 |
| 3. `robots.txt` | 按不同User-Agent明確允許或禁止 | 一條通配規則誤封整站 |
| 4. `noindex` | 需要收錄的頁面沒有“不加入索引”指令 | 模板或響應頭遺留限制 |
| 5. WAF與CDN | 官方爬蟲不會被驗證程序攔截或誤封 | 只檢查`robots.txt`，忽略安全規則 |
| 6. HTML正文 | 伺服器最初返回的網頁源代碼中含有關鍵事實 | 只返回空容器，正文依賴瀏覽器加載 |
| 7. URL關係 | 首選網址聲明、跳轉和站內連結保持一致 | 多個網址版本互相沖突 |
| 8. `sitemap` | 網站地圖只包含正式網址，更新時間可信 | 混入404、`noindex`或測試頁 |
| 9. 日誌複核 | 能查到真實請求及伺服器響應 | 只用在線工具檢測，不查伺服器記錄 |

## 1. 正式頁面是否真正向公網開放

驗收的第一步，不是在網站後台預覽頁面，而是在未登錄、未使用瀏覽器舊緩存的環境中，訪問準備發佈的正式URL。URL就是網頁地址。

需要逐項確認：

- DNS（域名系統，用來把域名指向伺服器地址）是否指向正式環境；
- HTTPS（加密的網頁訪問方式）證書是否有效；
- 頁面是否要求登錄；
- 訪問時是否出現驗證碼；
- 網站是否設置了地區限制；
- 網站是否只允許白名單中的IP訪問。IP是設備或伺服器在網絡中的地址。

測試環境可以打開，只能證明測試環境可用，不能證明公網爬蟲能夠訪問正式頁面。後台預覽地址和內部測試地址，也不能代替正式URL完成上線驗收。

![上線前SEO（搜尋引擎優化）與AI（人工智能）爬蟲9項檢查](/static/img/insights/geo-guide/geo113-2.jpg)

## 2. HTTP狀態碼是否反映真實結果

HTTP狀態碼是伺服器用數字表示的請求結果：

- 200通常表示請求成功；
- 3xx表示頁面發生跳轉；
- 4xx表示請求有誤、頁面不存在或訪問受限；
- 5xx表示伺服器出現問題。

Google列出的最低技術要求包括：Googlebot（谷歌搜尋爬蟲）沒有被阻止、頁面返回HTTP 200、頁面中含有可以被索引的內容。

滿足這些要求，只能説明頁面具備被索引的基本資格，並不保證一定會被索引。具體説明見：[Google搜尋技術要求](https://developers.google.com/search/docs/essentials/technical)。

檢查狀態碼時，不能只看瀏覽器能否顯示頁面。有些錯誤頁面使用了正常頁面的外觀，伺服器也返回200，但正文表達的卻是“頁面不存在”。這種情況叫作“軟404”。

重定向，也就是從一個網址自動跳到另一個網址，同樣要檢查完整過程。有的頁面會連續跳轉多次，有的循環跳轉只在移動端出現。如果只記錄最後打開的頁面，就可能漏掉中間的問題。

至少應記錄以下資訊：

| 字段 | 需要核對的結果 |
|---|---|
| 原始URL | 是否為準備發佈的正式地址 |
| 首次狀態 | 返回200、3xx、4xx還是5xx |
| 跳轉過程 | 是否只有必要跳轉，最終是否到達正式URL |
| 最終狀態 | 是否穩定返回200 |
| 內容類型 | HTML、PDF（版式固定的電子文檔）、圖片等類型是否正確 |
| 響應時間 | 是否存在明顯超時或間歇性失敗 |

![上線前SEO（搜尋引擎優化）與AI（人工智能）爬蟲9項檢查](/static/img/insights/geo-guide/geo113-3.jpg)

## 3. `robots.txt`是否按爬蟲用途分別配置

`robots.txt`主要用於告訴爬蟲哪些路徑允許訪問、哪些路徑禁止訪問。它管理的是抓取行為，不能被當作可靠的去索引工具。

Google明確説明，`robots.txt`主要用於管理爬蟲流量。如果不希望某個網頁被Google索引，應當在允許爬蟲讀取頁面的前提下使用`noindex`，或者直接設置訪問權限。具體説明見：[Google robots.txt指南](https://developers.google.com/search/docs/crawling-indexing/robots/intro)。

人工智能平台通常會針對不同用途設置不同的User-Agent。上線前不能複製一份“允許所有爬蟲”的通用模板就結束，而應先確定自己的業務選擇：

- 是否允許頁面進入搜尋結果；
- 是否允許平台抓取內容用於訓練；
- 是否允許用戶提問時訪問頁面。

確定之後，再按照各平台最新的官方文檔分別配置。

| 平台 | User-Agent | 官方説明中的用途 |
|---|---|---|
| OpenAI | OAI-SearchBot | 用於ChatGPT搜尋結果 |
| OpenAI | GPTBot | 可能用於抓取基礎模型訓練內容 |
| OpenAI | ChatGPT-User | 由用戶或自定義人工智能助手觸發的頁面訪問，不是自動網頁抓取 |
| Anthropic | Claude-SearchBot | 用於改善搜尋結果 |
| Anthropic | ClaudeBot | 可能用於收集模型訓練數據 |
| Anthropic | Claude-User | 由用戶提問觸發的頁面訪問 |
| Perplexity | PerplexityBot | 用於在Perplexity搜尋結果中展示並連結網頁 |
| Perplexity | Perplexity-User | 由用戶請求觸發的訪問，不用於自動抓取或訓練 |

OpenAI允許網站分別控制OAI-SearchBot與GPTBot；Anthropic分別列出了Claude-SearchBot、ClaudeBot和Claude-User；Perplexity則分別列出了PerplexityBot與Perplexity-User。

具體説明見：[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)、[Perplexity爬蟲文檔](https://docs.perplexity.ai/docs/resources/perplexity-crawlers)。

## 4. `noindex`和`X-Robots-Tag`是否誤傷正式頁面

`noindex`是一條“不把頁面加入索引”的指令。需要被檢索的正式頁面，應同時檢查三個位置：

- HTML中的robots元標籤，也就是寫在網頁源代碼裏的索引指令；
- HTTP響應頭中的`X-Robots-Tag`，也就是伺服器隨頁面返回的索引指令；
- CMS（內容管理系統）後台的頁面可見性設置。

測試站複製到正式站時，整站`noindex`很容易被一併帶過去。如果只檢查正文，不檢查頁面模板、伺服器響應頭和後台設置，就可能漏掉這個問題。

還要注意，`robots.txt`與`noindex`不能混為一談。如果先通過`robots.txt`阻止爬蟲訪問，爬蟲可能根本無法讀取頁面中的`noindex`。

對於確實不希望公開的頁面，密碼保護和權限控制更直接。對於可以公開訪問、但不希望進入特定搜尋索引的頁面，再按照相應平台的官方規則配置。

## 5. WAF、CDN和反爬規則是否另行攔截

WAF是Web應用防火牆，用於識別和阻止可疑請求；CDN是內容分發網絡，負責通過不同節點向訪問方提供網站內容。兩者都可能設置獨立於`robots.txt`的訪問規則。

因此，`robots.txt`允許訪問，只能説明網站的抓取規則沒有主動拒絕，不能證明WAF、CDN、安全插件和訪問頻率限制也會放行。

常見問題包括：

- 把數據中心IP誤判為惡意請求；
- 對非瀏覽器User-Agent彈出驗證碼；
- 單位時間內允許的請求次數設置得過低；
- 只允許白名單地區訪問。

核對官方User-Agent時，還應結合平台公佈的IP範圍或驗證方式。User-Agent只是一個可以被偽裝的字符串，不能單獨作為放行依據。

Perplexity官方建議在WAF中同時核對User-Agent與官方IP範圍，並持續使用其最新公佈的IP範圍文件；OpenAI也公佈了各爬蟲的IP範圍。

修改訪問規則後，還要回到伺服器或CDN日誌中查看真實請求結果，不能只根據控制台顯示的“已允許”作出判斷。

## 6. 關鍵正文是否已經存在於HTML中

瀏覽器取得HTML後，可以繼續執行JavaScript。JavaScript是一種控制網頁交互和動態加載的腳本語言，它可以讓正文、表格和其他內容在頁面打開後再顯示出來。

但不能假設所有爬蟲都會用相同方式執行這些腳本。Google可以處理JavaScript，不同人工智能平台、用戶觸發訪問和搜尋爬蟲的處理能力卻不完全相同。

檢查時應直接查看伺服器最初返回的HTML，確認其中已經包含：

- 頁面標題；
- 主要結論；
- 表格；
- 常見問題；
- 作者資訊；
- 關鍵連結。

如果初始響應只有一個空容器，正文必須等瀏覽器執行JavaScript後才出現，就不能認定爬蟲一定可以讀取。

建議分別檢查三種結果：

1. 查看伺服器返回的原始HTML；
2. 關閉JavaScript後訪問頁面；
3. 使用目標User-Agent發出請求。

如果三次取得的內容差異很大，就要評估是否需要調整頁面生成方式：

- 服務端渲染：由伺服器先生成包含正文的頁面，再發送給訪問方；
- 靜態生成：在發佈前生成包含完整內容的HTML文件；
- 預渲染：提前生成可供爬蟲讀取的完整頁面。

瀏覽器最終能夠顯示，不等於爬蟲實際取得了相同內容。驗收應以爬蟲收到的原始內容為準。

## 7. 首選網址聲明、跳轉和站內連結是否一致

同一份內容可能同時存在多個地址版本，例如：

- 帶參數與不帶參數；
- 字母大小寫不同；
- 帶末尾斜槓與不帶末尾斜槓；
- HTTP與HTTPS；
- www與非www。

首選網址聲明（canonical）是頁面用來説明“哪個URL才是正式版本”的標記。

上線前，應先確定唯一的正式地址，再讓canonical、301永久重定向、網站地圖、導航和正文內鏈統一指向這個地址。301永久重定向，是伺服器告訴訪問方“這個頁面已經長期遷移到新地址”的狀態。

重點排除三類衝突：

1. A頁的canonical指向B頁，B頁又指回A頁；
2. 移動版與桌面版互相跳轉；
3. 網站地圖提交舊URL，站內連結卻指向新URL。

如果不同配置同時給出多個正式地址，爬蟲只能自行判斷。它最終選擇的URL，未必符合網站的發佈意圖。

## 8. 網站地圖和站內發現路徑是否完整

網站地圖文件（sitemap）用於集中向平台提供網頁地址。其中只應放入正式、可以訪問並且希望被索引的URL。

以下頁面不應混入網站地圖：

- 404頁面；
- 重定向地址；
- `noindex`頁面；
- 測試環境頁面；
- 重複參數頁。

網站地圖中的`lastmod`表示頁面最後一次發生實質更新的時間。頁面內容沒有實際變化時，不要每天批量把日期改成當天。

同時，還要檢查網站地圖與站內發現路徑是否一致。導航、正文內鏈和網站地圖應使用同一個正式URL，避免網站地圖提交一個版本，站內連結卻長期指向另一個版本。

## 9. 是否通過日誌和平台工具完成複核

上線驗收不能停在配置文件和在線檢測結果上。最終應以伺服器或CDN保存的真實訪問記錄為依據。

日誌至少要回答三個問題：

1. 目標User-Agent是否真的來過；
2. 它請求了哪個URL；
3. 伺服器最終返回了什麼狀態。

建議保留以下字段：

- User-Agent；
- 請求時間；
- IP；
- 請求路徑；
- 狀態碼；
- 響應時長。

這些記錄齊全後，才能區分三種情況：

- 爬蟲沒有來；
- 爬蟲來了，但被攔截；
- 爬蟲訪問成功，但取得的內容異常。

Google頁面可以通過URL檢查、網頁索引報告和抓取統計繼續複核。OpenAI、Anthropic和Perplexity則應結合各自公佈的User-Agent、IP説明和站點日誌檢查。

規則剛修改後，不要立即下結論。OpenAI與Perplexity官方都提示，`robots.txt`或爬蟲設置的變化可能需要約24小時才能反映。

## 上線判定：四類關鍵問題出現一個，就先暫停

| 檢查結果 | 上線判定 |
|---|---|
| 紅牌 | 正式頁面不是200、關鍵爬蟲被誤封、需要收錄的頁面含有`noindex`，或者HTML中沒有關鍵正文：暫停上線 |
| 黃牌 | 存在多次跳轉、canonical衝突、網站地圖仍含舊URL，或者WAF規則沒有通過日誌複核：修正後複測 |
| 綠牌 | 公網可以訪問、狀態穩定、規則與業務選擇一致、正文可讀，並且日誌中有真實記錄：可以發佈 |

這9項檢查解決的是網站自身的技術問題。全部通過，只能確認頁面具備被發現、訪問和讀取的基本條件，不能保證頁面一定會被抓取、索引、引用或推薦。

平台是否訪問、何時更新、最終如何展示，仍由各自系統決定。上線驗收能夠完成的，是把網站自身可以發現和修復的問題逐項排除。

## 常見問題（FAQ）

### 1. `robots.txt`寫了`Allow`，就一定會被人工智能爬蟲抓取嗎？

不一定。`Allow`只能説明`robots.txt`沒有阻止訪問。WAF、CDN、網絡、狀態碼、頁面質量和平台調度，都可能影響實際訪問。是否真正發生過抓取，應以伺服器日誌為準。

### 2. 屏蔽GPTBot，會不會同時退出ChatGPT搜尋？

按照OpenAI當前官方説明，GPTBot與OAI-SearchBot可以分別控制。GPTBot用於可能進入訓練的數據抓取，OAI-SearchBot用於ChatGPT搜尋結果。配置時應按照最新官方文檔分別編寫規則。

### 3. `robots.txt`能讓網頁徹底不出現在Google嗎？

不能把`robots.txt`當作可靠的去索引工具。Google説明，`robots.txt`主要用於管理抓取。要阻止網頁被索引，應使用`noindex`並允許爬蟲讀取，或者通過密碼等方式設置訪問權限。

### 4. 瀏覽器可以正常顯示，為什麼爬蟲仍可能讀不到？

頁面可能依賴客戶端JavaScript、登錄狀態、Cookie、地區設置或驗證碼。Cookie是網站保存在瀏覽器中的狀態數據。需要檢查伺服器返回的原始HTML、關閉JavaScript後的頁面，以及目標User-Agent的請求結果，才能判斷爬蟲實際取得了什麼內容。

### 5. User-Agent對了，就能確認是真實爬蟲嗎？

不能。User-Agent可以偽裝。還應結合平台公佈的IP範圍或驗證方法，在WAF和日誌中同時核對。

### 6. 技術檢查全部通過後，多久能看到收錄或引用？

沒有統一時間，也沒有結果保證。技術檢查只能確認頁面具備被訪問和讀取的條件；平台是否抓取、索引和展示，還取決於平台調度、質量判斷和產品規則。