首頁 / 技術文章 / 判斷 AI 搜尋是否取得網頁的四個關卡

技術文章

判斷 AI 搜尋是否取得網頁的四個關卡

網站管理者應把「AI 搜尋有沒有取得網頁」拆成發現、抓取、內容理解、生成／引用四個關卡逐項查證。AI 搜尋取得網頁不是可直接觀察的單一事件；可觀察的是各階段留下的證據。若只看 Sitemap、robots.txt 或 AI 答案有沒有引用，容易把不同層級的問題誤判成同一種問題。

本文由 AI 協助撰寫：自動化編輯流程依文末的資料來源起草後直接發布，發布前未經人工審閱，也不以品質分數篩選。技術細節請以一手來源為準；發現錯誤請見更正政策。

核心答案：不要用單一成功或失敗判斷

「AI 搜尋取得網頁」至少可能包含四件事：系統知道 URL、crawler 能讀到內容、系統能解析主要內容、回答時選中並引用該頁。這四件事的證據不同，控制項也不同。

較安全的除錯方式，是把問題改寫成：URL 是否被發現、頁面是否被抓取、內容是否能被理解、答案是否選擇引用。Google Search Central 將 Google 搜尋描述為抓取、索引、呈現搜尋結果三個階段，且不是每個網頁都會經歷全部階段；這可作為拆解問題的基本參考，但不能直接代表所有 AI answer engines 的內部流程。

四個關卡的定義與可觀測證據

關卡一：發現不是索引，也不是引用

發現階段只回答一個問題：系統是否有機會知道這個 URL 存在。Google 說明，抓取階段包含網址發現，並可透過已知網頁上的連結與 Sitemap 發現其他頁面。Google 也在 crawling and indexing 文件中說明，Sitemaps 可用來告知 Google 網站上新增或更新的頁面。

• 可檢查：重要頁面是否有站內連結，而不是只存在於搜尋框、表單或 JavaScript 事件後。
• 可檢查：Sitemap 是否包含正確 URL，且最後更新時間與實際內容一致。
• 可檢查：canonical、noindex、重導向與分頁設定是否把訊號導向其他 URL。
• 不能推論：URL 在 Sitemap 內，不代表 Google 或 AI 搜尋一定會抓取、索引或引用。

關卡二：抓取要看 robots.txt、HTTP 回應與日誌

RFC 9309 是 Robots Exclusion Protocol 的標準來源，用來讓服務擁有者控制 crawler 對內容的存取方式。這代表 robots.txt 的可靠定位是抓取控制，不是排名控制、引用控制，也不是對所有 AI 生成行為的完整保證。

抓取階段應從伺服器端證據開始：目標 user-agent 是否請求過 URL、robots.txt 是否允許、HTTP 回應是否成功、是否被轉址到不相關頁面、是否回傳錯誤或空內容。若需要辨識 AI crawler，可搭配站內的 伺服器日誌辨識 AI 爬蟲方法。

OpenAI 官方文件列有 OpenAI Crawlers 頁面，並說明 OpenAI crawlers 與 robots.txt 標記如何關聯到網站內容可否被 AI 搜尋系統存取或被訓練模型使用。不同 crawler 可能有不同用途，因此應避免把單一 user-agent 的行為推論成所有 AI 產品的行為。

關卡三：內容理解要看 crawler 讀到的是什麼

抓取成功後，下一個問題是系統是否能取得主要內容。頁面若高度依賴 JavaScript、複雜導覽、廣告區塊或動態載入，瀏覽器畫面看起來完整，不代表 crawler 取得的文字也完整。llms.txt 提案也指出，HTML 頁面常把資訊包在導覽、廣告與 JavaScript 中，轉成乾淨文字可能困難且不精確。

• 主標題與段落應存在於可讀 HTML，而不是只由前端執行後產生。
• 標題層級應反映內容結構，避免只用樣式製造視覺層級。
• 產品、價格、作者、日期、FAQ 等內容若使用結構化資料，應與可見文字一致。
• 頁面主文應避免被大量模板文字、側欄、推薦卡片與彈窗稀釋。
• 重要內容不應只藏在圖片、影片、PDF 預覽或需要互動後才出現的元件中。

關卡四：生成與引用只能推估，不能等同於抓取證據

生成／引用階段最難直接驗證。AI answer engine 可能查詢既有索引、即時讀取網頁、使用合作資料、使用第三方資料源，或混合多種來源；公開資料通常不足以逐一確認。

因此，答案中沒有引用某頁，合理解讀是「此查詢、此時間點、此產品沒有顯示該頁為來源」。它不能直接推出頁面沒有被發現、沒有被抓取或沒有被索引。相反地，日誌中看到 crawler 成功抓取，也不能推出該頁會在答案中被選中。

llms.txt 的位置：內容導覽提示，不是存取控制標準

llms.txt v2 提案建議網站提供 /llms.txt Markdown 檔案，用來協助 agents 使用網站。它適合被視為內容導覽與摘要提示：列出重要文件、核心頁面、API 說明、限制與建議閱讀順序。

但 llms.txt 不應被寫成與 RFC 9309 同等地位的存取控制標準。就目前可用來源，能安全說明的是：llms.txt 是一個提案；是否被主要 AI 搜尋產品在 production retrieval 或 fetch 階段讀取，仍不能一概而論。

適用範圍與限制

這套四關卡檢查法適合網站管理者、SEO／AEO／GEO 實務工作者、技術文件團隊與伺服器維運人員，用來定位「沒被抓」、「被抓但未索引」、「可能被索引但未被引用」這些不同問題。

• 適用：檢查 robots.txt、Sitemap、HTML 主文、伺服器日誌與引用觀察之間的關係。
• 適用：區分 Google Search 的抓取／索引／呈現與 AI answer engine 的檢索／生成／引用問題。
• 限制：各家 AI 搜尋產品的內部檢索、排序、摘要與引用規則通常不完整公開。
• 限制：沒有單一外部訊號能證明某頁必定會被 AI 答案引用。
• 限制：本文沒有使用真實觀測資料，因此不主張任何特定產品的即時行為。

常見誤解與陷阱

結論：用證據定位問題，不用單一結果下判斷

• AI 搜尋取得網頁應拆成發現、抓取、內容理解、生成／引用四個關卡檢查。
• Sitemap 主要是發現線索；robots.txt 主要是抓取控制；兩者都不是引用保證。
• 伺服器日誌能證明特定 user-agent 曾請求頁面，但不能證明答案生成時使用該頁。
• HTML 主文、標題層級、可讀文字與結構化資料會影響內容可解析性。
• AI 答案是否引用只能作為結果觀察，不能反推整條取得流程都成功或失敗。

延伸閱讀：從伺服器日誌辨識 AI 爬蟲　·　robots.txt 對 AI 搜尋與模型訓練的限制　·　AI 爬蟲目錄　·　GPTBot 與 OAI-SearchBot 的差異

常見問題

Sitemap 裡有頁面，為什麼 AI 搜尋還是不引用？

Sitemap 只屬於發現線索。它不能保證 crawler 一定抓取，也不能保證內容被索引，更不能保證 AI answer engine 在特定查詢中引用該頁。應再檢查 robots.txt、HTTP 回應、伺服器日誌、頁面主文可讀性與查詢意圖。

日誌看到 AI crawler 抓過頁面，是否代表頁面會進入答案？

不代表。日誌只能證明特定 user-agent 曾經請求該 URL。後續是否被索引、是否成為候選來源、是否在答案中顯示來源連結，屬於不同階段。

robots.txt 能不能阻止 AI 搜尋引用網站內容？

robots.txt 的標準定位是控制 crawler 對內容的存取。它可用於允許或封鎖遵守規則的 crawler，但不能直接保證所有 AI 生成、摘要或引用情境都被阻止。

llms.txt 是否能提高 AI 搜尋引用率？

目前較保守的說法是：llms.txt 可作為 agent 友善的內容導覽與摘要提示，但不能保證主要 AI 搜尋產品一定讀取，也不能保證引用率提升。

資料來源

• RFC 9309: Robots Exclusion Protocol
• Google Search Central: How Search Works
• Google Search Central: Crawling and indexing topics
• OpenAI: Overview of OpenAI Crawlers
• llms.txt proposal