home / notes / AI 爬蟲流量不是 AI 能見度：創辦人該看的五層漏斗

Note

AI 爬蟲流量不是 AI 能見度：創辦人該看的五層漏斗

AI crawler access 不是 AI 能見度，只是漏斗前段的存取訊號。創辦人若把 server log 裡的 bot request 當成 answer visibility，會高估內容策略成效，也可能把工程與行銷資源放錯位置。我的判斷是，AI 能見度應拆成五層漏斗，每一層都需要不同證據。

普遍看法的盲點：把能抓取誤當成有曝光

現在很多討論會從 robots.txt、user-agent、allowlist 或 blocklist 開始。這是合理的入口，因為網站主確實能控制一部分 crawler access，也能在伺服器日誌裡看見請求事件。問題是，這些資料回答的是「AI 系統能不能碰到我的內容」，不是「使用者問問題時，我有沒有被提到、引用或推薦」。

我認為這裡最容易出錯的地方，是把低層的技術可存取性，推論成高層的商業能見度。爬蟲請求可以是診斷線索，卻不是曝光報表；回答截圖可以證明某個 query 的呈現，卻不能代表整體市場；referral traffic 可以證明有人點擊，卻不能反推沒有點擊就沒有被提及。

五層漏斗：每一層都不是同一種證據

我會把 AI 能見度拆成五層：政策允許度、技術可讀性、實際 retrieval 或 indexing、回答層 mention／citation／recommendation、使用者點擊與採信。這不是操作流程，而是管理判斷用的分層模型：同一個網站可能在第一層通過，卻在第四層完全沒有存在感。

這個漏斗的重點，是避免用單一資料替代整個決策。server log 最多能說明某個 user-agent 曾向網站請求資源；它不能單獨證明該頁進入模型訓練資料集、搜尋索引、RAG corpus，或最後成為回答候選來源。從目前公開資訊來看，這些步驟由不同系統與不同目的支撐，不能混成同一個 KPI。

公開文件支持的部分：robots.txt 控制的是存取，不是回答呈現

RFC 9309 把 Robots Exclusion Protocol 定義為讓 service owners 控制 crawlers 是否以及如何存取其服務提供內容的方法。這個規格處理的是 automated clients 對內容的存取規則，不是 AI 回答中是否出現品牌、是否附 citation、或是否把某個供應商排在推薦名單裡。

這個分界很重要。robots.txt 可以表達網站對 crawler access 的允許或拒絕；但回答層的呈現，還涉及 query 意圖、檢索候選、排序、生成、引用策略，以及產品介面的顯示規則。我的判斷是，把 RFC 層級的存取控制解讀成 AI answer visibility 的保證，是類別錯置。

Anthropic 的 bot 區分，說明 request 不是同一種訊號

Anthropic 的官方文件 把不同 robot 用途分開：支援模型開發、搜尋網路、以及依使用者指令擷取網頁內容。文件中提到 ClaudeBot、Claude-User 與 Claude-SearchBot，這表示同一家公司底下的 crawler request，也可能代表不同流程。

這對管理判斷的意義是：不能只把「Anthropic bot 來了」視為單一能見度訊號。若請求來自訓練相關 crawler，它比較接近資料使用與模型開發的議題；若是使用者觸發的 retrieval，它才更貼近當下查詢情境。Anthropic 也表示，停用 Claude-User 會防止系統為回應使用者查詢而擷取該網站內容，並可能降低 user-directed web search 的可見度。這支持一個較保守的判斷：可存取與可見之間有關聯，但不是同一件事。

AI 搜尋讓漏斗中段變得更重要

傳統 SEO 的直覺常把 crawler、index、ranking 串成相對熟悉的路徑；AI assistant 的情境更複雜，因為回答可能同時受到預先索引、即時 retrieval、第三方來源、使用者提供內容與模型既有知識影響。從目前公開資訊來看，AI 能見度不只取決於網站是否被預先抓取，也取決於使用者查詢時是否被檢索與選用。

arXiv 論文〈Do Generative AI Assistants Respect robots.txt? Tracing Web Access Beyond Visible Answers〉 的摘要指出，AI assistants 越來越會在 inference time 擷取網頁內容，以提供更新且有根據的回答。該摘要也描述研究者針對十個宣稱具備 web-search capabilities 的 AI assistants 進行 controlled empirical study，並記錄 retrieval 時暴露的 user-agent。

我不會把這篇摘要延伸成所有 AI 產品的通則；但它至少支持一個方向：AI 能見度的觀測點不能只停在 crawler hits。若 inference time retrieval 成為重要路徑，那麼「內容當下能不能被找到、能不能被理解、會不會被選為回答依據」會比單純累積 bot request 更接近商業問題。

創辦人應該問的不是有沒有 bot，而是哪一層卡住

如果一家公司的 AI visibility 報告只呈現 crawler hits，我認為它很容易把早期訊號包裝成最終結果。這會讓團隊優先修 user-agent、robots.txt 與 log dashboard，卻忽略內容本身是否能回答高意圖問題、是否有足夠可信來源支撐、以及品牌在回答層到底以什麼方式出現。

• 內容網站與媒體：應區分開放 crawler access 與實際被引用之間的落差，否則可能高估開放策略的效果。
• SaaS、電商與品牌官網：不應把 AI crawler hits 直接解讀成需求增加或推薦增加。
• SEO／AEO／GEO 團隊：需要把技術可抓取性與 answer visibility 分開，否則診斷會失準。
• 產品與資料團隊：若要做 AI visibility dashboard，應把 access、retrieval、mention、citation、recommendation 與 referral 拆成不同口徑。
• 法務與治理團隊：robots.txt 比較接近 crawler access 與資料使用偏好的控制，不等於能控制模型一定不提到品牌。

不確定性：這個框架在哪些情況下會失效

我的判斷仍有邊界。不同 AI 搜尋或 assistant 系統如何從可抓取頁面選出實際引用來源，目前公開資訊不足以完整確認。單一網站在 server log 裡看見某個 AI crawler，也不能只靠這件事判斷該頁已進入訓練資料集、搜尋索引、RAG corpus 或回答候選集。

另一個不確定性，是各層之間的轉換率。AI crawler access、answer citation、品牌 mention 與 referral traffic 之間，可能存在關聯；但本篇依據的公開來源沒有提供可泛化的因果證據。我的保守看法是，crawler traffic 可以當成前段診斷訊號，但不適合單獨當成 AI 搜尋成效指標。

結論：把 AI 能見度當漏斗，而不是把 log 當排行榜

AI crawler access 是必要的前段條件之一，但不是 AI answer visibility 的充分證據。創辦人要避免把看得見的 request 當成看不見的曝光結果；比較穩健的管理方式，是把政策允許度、技術可讀性、retrieval／indexing、回答層呈現與使用者採信分開判斷。我的結論很簡單：server log 可以告訴你門口有人來過，不能告訴你市場上誰真的聽見了你的名字。

常見問題

AI crawler 流量完全沒有價值嗎？

不是。它可以作為前段診斷訊號，說明某個 user-agent 曾請求網站資源；但它不能單獨證明內容已被引用、推薦或出現在 AI 回答中。

robots.txt 允許 AI crawler，是否代表 AI 回答會引用我？

不代表。robots.txt 處理的是 crawler access；回答層還涉及檢索、選源、生成、citation 呈現與產品介面規則。

如果沒有 AI referral traffic，是否代表沒有 AI 能見度？

不一定。referral traffic 只能證明點擊；AI 回答可能提到品牌但沒有導流，也可能透過第三方來源形成回答。本篇不主張用沒有點擊反推沒有曝光。

創辦人最該避免的指標誤用是什麼？

把 server log 裡的 AI bot request 當成 AI answer visibility。這會讓團隊把前段存取事件誤當成後段商業成果。

來源

• Robots Exclusion Protocol
• Does Anthropic crawl data from the web, and how can site owners block the crawler?
• Do Generative AI Assistants Respect robots.txt? Tracing Web Access Beyond Visible Answers