答案引擎的爬蟲確實在高頻抓取有資訊密度的頁面，頻率高到多數人沒有概念。我在 seo.whoops.com.tw 的邊緣部署了一個觀測層，實跑下來，一篇談實體 SEO 的單一頁面，七天內被 AI 爬蟲抓取超過 12,000 次。但這組數字有一條不能妥協的界線：被抓取，不等於被引用。把伺服器端收到的請求計數直接翻譯成「我的內容被 ChatGPT 引用了」，是 AEO 領域最常見、也最容易誤導決策的一種膨風。
這份報告只做一件事：把一套跑在 Cloudflare 邊緣的技術 SEO 觀測機制講清楚，把實測到的數字老實攤開，然後畫清楚界線：它代表什麼，以及更關鍵的，它不代表什麼。如果你正在思考要不要把資源投進答案引擎最佳化（AEO），這組第一手觀測是你目前能找到的少數有實際數字支撐的判斷依據。而它真正有價值的用法，是當基線，不是當戰績。
TL;DR：重點先看
Worker 記的是「請求」，不是「引用」。一次抓取是離引用最近的伺服器端代理，終究是代理，不是引用本身。這條界線貫穿整份報告。
實測頁七天被抓超過 12,000 次。站上 /entity-seo/ 那篇講實體 SEO 的長文，七天視窗內被 AI 爬蟲抓取超過 12,000 次，是單頁、單週、可在報告端點查證的第一手數字。
傳統分析根本看不到這一層。答案引擎的爬蟲在伺服器端完成取用，referer 經常被截斷、不觸發前端 JavaScript 追蹤，GA4 對這群流量幾乎是全盲的。
OAI-SearchBot 比 GPTBot 更接近「會被引用」。前者是為了搜尋引用而抓，後者是為了訓練而抓，兩者意義不同，不能混在一起算。
404 清單是答案引擎遞給你的需求單。AI 爬蟲來要、但站上回 404 的路徑，就是它明確表達「我想要這個內容」的訊號，比任何關鍵字工具都直接。
文章目錄
先說結論：AI 爬蟲在高頻抓取，但被抓取不等於被引用
把結論放在最前面。我在一個真實運作、有真實讀者的 SEO 內容站上，部署了一個會在每個請求進來時判讀 User-Agent 的邊緣 Worker。只要是已知的 AI 答案引擎或訓練爬蟲，就寫一筆紀錄進資料庫；不是 AI 的流量，零延遲放行。跑了一陣子之後，數字給出的第一個訊號非常清楚：答案引擎對有資訊密度的內容，是高頻、持續、不間斷地在取用。這不是偶發事件，是每天、每小時都在發生的常態。
把這件事講具體一點。你的網站是一座倉庫，AI 答案引擎的爬蟲是每天開來裝貨的物流車隊，你可以站在門口數車、記車牌、看它們載走哪幾箱貨，這就是 Worker 在做的事。但你手上沒有任何一張「這批貨後來被擺上哪一家店、被哪個消費者買走」的送貨回執。車隊很勤快，跟你有沒有做成生意，是兩件事。被抓取代表你的內容進入了答案引擎的取用範圍，這是必要條件；但它離「出現在某個使用者看到的回答裡」還有好幾步，每一步都有篩選、有排序、有我們看不到的黑箱。這也是為什麼 SEO 圈在談 AI 搜尋時代的 SEO 策略時，會把「被取用」和「被引用」拆成兩個層次來看。
這條界線之所以要反覆強調，是因為 AEO 這個領域充斥著把「被抓取」灌水成「被引用」的話術。看見一個 bot 來抓一萬次，就宣稱「內容被引用一萬次」，這在邏輯上站不住，在實務上會誤導你把資源投錯地方。請求是可數的、可查證的事實；引用是不可見的、只能靠人工抽樣去逼近的推論。這份報告從頭到尾都在講前者，並且不斷提醒你別把它當成後者。想從更宏觀的角度理解這波AI 搜尋大改版對 SEO 流量的重分配，這條界線是基本的閱讀前提。
退一步看，就算只到「被抓取」這一層，這個訊號本身的價值已經足夠大。它第一次讓「AI 到底有沒有看到我」這個問題，從信仰變成可量測的工程問題。在這之前，你只能靠「我寫了結構化資料，應該會被讀到吧」這種沒有反饋的猜測；在這之後，你至少知道哪些頁面被答案引擎當成持續取用的來源，哪些完全沒有進入它的視野。沒有觀測，所謂的 AI 搜尋 SEO 就只能閉著眼睛做。
為什麼傳統分析看不到 AI 爬蟲
大多數人判斷「AI 有沒有看到我的內容」，第一個直覺是打開 Google Analytics 或 Search Console 看。問題是，這兩個工具在 AI 爬蟲這件事上幾乎是完全失明的。原因不在工具本身做得差，而在測量機制從根上就看不到這群流量。
先講 GA。GA4 靠的是瀏覽器端載入一段 JavaScript，觸發一個事件回報伺服器。這套機制天生只看得到「會執行 JavaScript 的真人瀏覽器」。AI 爬蟲呢？它們在伺服器端就把 HTML 抓走了，根本不會去執行你頁面上那段分析指令碼。GPTBot 來抓你一千次，你的 GA4 流量數字一動都不動。GA 就像裝在店面正門的紅外線感應器，數的是走進來的客人；AI 爬蟲走的是倉庫後面的卸貨碼頭，感應器那一側根本覆蓋不到。這也是零點擊搜尋之外，另一個讓傳統流量數字越來越看不懂真相的原因。
再講 referer 的問題。就算某個使用者真的從答案引擎點了一條連結來到你的網站，你看到的 referer 經常是被瀏覽器或 App 截斷的、或掛在 GA4 沒辦法正確歸類的網域底下（像 chatgpt.com、claude.ai 這類），最後被併進 direct 或不明來源。你看到流量來源是 direct，不代表它真的沒有來源，只代表來源被抹掉或被誤分了。所以靠 GA 的來源分析去推論「AI 帶來多少流量」，得到的數字先天就會嚴重低估。
Search Console 的狀況又不一樣。它記的是 Google 搜尋結果頁上的曝光、點擊、CTR，完全不涵蓋 OpenAI、Anthropic、Perplexity 這些答案引擎的爬蟲活動。它甚至連 Google 自家用來餵 AI Overviews 與 Gemini 的 Google-Extended、Google-Other 都不會單獨標示出來給你看。Search Console 是 Google 搜尋的計分板，不是答案引擎生態的計分板，而這兩個範圍隨著 Google AI Mode 與各家答案引擎成熟，重疊得越來越少。
所以當有人跟你說「AI 搜尋流量很小，不值得投入」，你第一個該問的是：你用什麼測的？如果答案是 GA，那這個結論的基礎就是一個先天看不到 AI 爬蟲的工具，得出「看不到所以不存在」的結論一點都不意外。測量工具的盲區，會被誤讀成現象的缺席。這也是站上常見的被忽略的技術 SEO 盲點之一：不是問題不存在，是你手上沒有能看見它的儀器。要回答「AI 到底有沒有在抓我的內容」，唯一可靠的觀測點不在前端，而在伺服器端，在請求剛剛進來、還沒被任何前端邏輯污染的那一刻，這就是邊緣 Worker 的位置。搜尋從關鍵字比對走向AI Agent 化的檢索，這個觀測點只會越來越重要。
我們部署了什麼：一個跑在 Cloudflare 邊緣的觀測 Worker
具體的機制長這樣。seo.whoops.com.tw 的 DNS 託管在 Cloudflare，每個進站的請求都會先經過一個 zone 層級的 Worker。這個 Worker 做的事非常單純：讀請求的 User-Agent，比對一份已知 AI 爬蟲的清單，是 AI 就寫一筆紀錄，不是就立刻放行。沒有複雜的邏輯，沒有對回應內容的改寫，非 AI 流量的延遲趨近於零。
這個 Worker 就是站在高速公路收費站的那個收費員，每一輛車經過他都會瞄一眼車牌。一般車輛，他揮手放行，車速完全不減；AI 爬蟲的車牌，他認出來了，在旁邊的本子上記一行，時間、車牌、走了哪個閘道、從哪個國家來，然後一樣放行，車照樣過。AI 爬蟲在這個站上完全沒有被擋，這是刻意設定，因為你要量測的就是它們自然來訪的行為，擋掉就測不到了。
那一筆紀錄裡有七個欄位：時間戳記、爬蟲名稱、分類、HTTP 方法、路徑（含查詢字串）、回應狀態碼、國別。七個欄位就足以回答絕大多數「AI 在對我的站做什麼」的問題。紀錄寫進 Cloudflare D1，一個跑在邊緣的 SQLite 資料庫。所有判讀都在邊緣完成，所有紀錄都留在邊緣，不需要回源到你的主機，這意味著觀測層本身不會成為網站的效能負擔，也不會暴露你的原始伺服器。對一個跑在 WordPress 上、還需要做SEO 最佳化的站來說，把觀測放在邊緣、不碰主機，是負擔最小的選擇。
如果你想在面向 AI 爬蟲這件事上多做一步，還可以放一份 llms.txt，這是社群提案的純文字格式，用意是把站上內容的輪廓整理出來，當成一份主動遞給 AI 爬蟲參考的說明。要先把界線畫清楚：llms.txt 不會、也不能控制或保證答案引擎怎麼抓取、引用你的內容，它能不能發揮作用，各答案引擎的對待方式不一，目前也沒有定論。觀測 Worker 看的是「它有沒有來」這個可量測的事實，llms.txt 則是另一個方向的主動揭露，兩者不能混為一談。順帶一提，爬蟲抓到的頁面版本會不會被當成canonical 標籤指定的那一版，也是會影響它最終看到什麼的變數，只是 canonical 並非搜尋引擎一定遵守的指令。
這份清單涵蓋二十個 AI 爬蟲，分成三類。AI Search 是為了搜尋引用而抓的；AI Crawler 是訓練與建立索引的骨幹爬蟲；AI Assistant 是使用者觸發的即時抓取。三個分類的意義天差地別，後面會專門拆開講。把三類混在一起算總數，會得到一個漂亮但完全沒有行動指引的數字。分類的依據，是各家廠商在自己文件裡對這隻爬蟲用途的說明。
報告端點是隨選的，預設看過去七天，用 SQL 即時彙整。你下查詢的那一刻，它才 GROUP BY 算給你看，所以每次看到的都是當下的真實狀態，不是一份會過期的快照報表。另有站外排程會定期把結果彙整成每週觀測報告。觀測是活的，不是一份拍完就死的 PDF。
免費層的限制要先講清楚，免得你照著做卻在沒預期的地方撞牆。依 Cloudflare 的官方定價，Workers 免費層每天十萬次 invocation，D1 每天十萬次 row-write，兩個額度是獨立計算的。注意，這個 Worker 是 zone 層級的，每一個請求，不管是不是 AI，都會耗用一次 Worker invocation，免費額度吃的是你的總流量，不是只有 AI 流量。如果總流量超過十萬，你要嘛升到每月五美元的付費層（每月一千萬次內含，超出後每百萬次 0.30 美元，沒有每日上限），要嘛接受額度用完後觀測暫停的事實。不管哪種情況，原始伺服器都會繼續正常回應，影響的只有紀錄能不能寫進去。對絕大多數內容站來說，這套觀測的技術 SEO 地基價值遠大於每個月幾美元的成本。
把實測數字攤開來看
機制講完了，來看數字。這裡只公開站上一篇頁面的資料，其他頁面和全站彙總一律不寫，因為只有這個頁面經過確認可以對外。這是單頁實測，不是全站統計，這個前提請記住。
被當作樣本的，是站上 /entity-seo/ 那篇講實體 SEO 的長文。七天視窗內，AI 爬蟲抓取超過 12,000 次。同一段時間，站上另一篇探討「AI 會不會取代 SEO」的長文，AI 爬蟲來訪也落在萬次量級。會被抓到這個頻率的，都是資訊密度高的長文，主題都落在「AI 與搜尋」這個答案引擎最密集取用的地帶。
12,000 這個數字的作用，接近地震儀：地震儀不能告訴你哪一棟樓會裂、裂在哪一層，但它能讓你確定地底確實在動，而且動得很頻繁。它推翻了「AI 搜尋只是話題、沒有實際取用行為」的輕率判斷。主流答案引擎對有資訊密度的內容，是真的在高頻、持續地抓。你不需要相信任何人嘴上說的，數字就擺在那裡。
但地震儀同時也點出了界線：數字告訴你地底在動，不能告訴你哪棟樓受惠。12,000 次抓取，不代表這個頁面被 ChatGPT 引用了 12,000 次，甚至不能保證它被引用過任何一次。它只代表答案引擎的爬蟲，七天內把這個頁面抓走了 12,000 次。至於抓走之後，這些內容有沒有進入模型的取用範圍、有沒有在生成回答時被檢索到、有沒有真的出現在使用者眼前，全部是 Worker 看不到的黑箱。想理解這中間經過了哪些篩選，可以對照搜尋引擎檢索、索引、排名的完整拆解，爬蟲抓取只是這條鏈最前面的那一環。
為什麼只給單頁數字、不給全站彙總？兩個原因。第一，全站彙總會把不同主題、不同資訊密度的頁面混在一起，平均值會掩蓋掉「哪些主題被高頻取用、哪些根本沒被理會」這個真正有用的訊號。單頁數字比全站平均誠實，它讓你看清楚具體的、可歸因到主題的差異。第二，全站彙總牽涉的變數太多，容易在沒有控制條件的情況下被過度解讀。在你自己的站上跑一輪單頁觀測，得到的訊號會比任何人的全站數字都更貼近你的真實處境。
AI 爬蟲分類表：不是所有抓取都一樣
把二十個爬蟲分成三類，不是為了好看，是因為不同分類的抓取，代表的意義天差地別。你如果把 AI Search 和 AI Crawler 混在一起算總數，會得到一個漂亮但完全沒有行動指引的數字。分類的依據，是各家廠商在自己文件裡對這隻爬蟲用途的說明。
| 分類 | 爬蟲 | 角色 | 離「被引用」多近 |
|---|---|---|---|
| AI Search | OAI-SearchBot、Claude-SearchBot、YouBot、PerplexityBot | 為了搜尋引用而抓，把內容搬進答案引擎的引用候選池 | 最近。這類爬蟲抓的內容，目的是在搜尋結果裡被引用 |
| AI Crawler | GPTBot、ClaudeBot、Google-Extended、Google-Other、CCBot、Bytespider、Amazonbot、Applebot-Extended、Meta-ExternalAgent、cohere-ai、ImagesiftBot、Diffbot | 訓練資料收集與索引建立，把內容喂進模型或知識庫 | 較遠。抓的目的是訓練或建索引，不直接等於搜尋引用 |
| AI Assistant | ChatGPT-User、Perplexity-User、Claude-User、Meta-ExternalFetcher | 使用者觸發的即時抓取，為了回答當下這個人的問題 | 視情況。代表真實使用者的需求當下觸發了一次取用 |
把這張表讀進去，你會發現一個關鍵判斷：OAI-SearchBot 比 GPTBot 更接近「會被引用」。差別在哪？依 OpenAI 的爬蟲說明，GPTBot 用來爬取和訓練，它抓你的內容，目的是放進訓練資料集，讓未來的模型「吸收」這些知識，這是一個漫長、間接、而且你完全看不到輸出的過程。OAI-SearchBot 不一樣，它是 ChatGPT 搜尋功能用來抓取網頁以便在回答裡引用的爬蟲，抓的目的是在可見的搜尋結果裡放一條引用。前者像把你的食材收進中央廚房的冷凍庫，後者像當場拿你的菜上桌給客人。這也是為什麼認真做結構化資料標記的頁面，會優先期待被搜尋型爬蟲看見。
所以當你在觀測報告裡看到 OAI-SearchBot 或 Claude-SearchBot 高頻來抓某個頁面，那個訊號的含金量遠高於 GPTBot 來抓同樣次數。搜尋型爬蟲的高頻來訪，比較接近「你的內容在答案引擎的引用候選池裡」。訓練型爬蟲的高頻來訪，比較接近「你的內容被收進了訓練資料」，這當然也是好事，但它離「被引用」更遠，中間隔了一整個模型訓練週期和檢索層。
這裡要特別幫 PerplexityBot 說清楚：依 Perplexity 自己的爬蟲說明文件，PerplexityBot 是為了在搜尋結果裡連結、引用網頁而抓，並不用來訓練基礎模型。所以它雖然名字裡有「Bot」，分類上其實更靠近 AI Search，不是 GPTBot 那種訓練爬蟲。Meta-ExternalFetcher 同理，它是使用者觸發時才去抓單一連結的 fetcher，屬於 AI Assistant，跟同家族用來訓練的 Meta-ExternalAgent 不是同一回事。至於 AI Assistant 那一類，ChatGPT-User 或 Perplexity-User 會觸發抓取，代表真實的使用者在答案引擎裡問了一個問題，而引擎為了回答，當場來抓了你的頁面，這是最接近「有人正在消費你的內容」的訊號，雖然它同樣不等於「你的頁面出現在最終回答裡」。三個分類，三種距離，混在一起算就是把自己最重要的判斷維度丟掉。答案引擎在決定引用誰之前，往往會先把一個查詢擴充成好幾個子查詢分頭去找，這時候分類的差異會直接決定你看到的數字該怎麼解讀。
這組數字代表什麼
畫完界線，來講這組數字真正能支撐的判斷。第一個、也是最實在的一個：高頻被抓取，代表你的內容已經進入答案引擎的取用範圍，這是 AEO 任何作為的前提。如果連抓都沒人來抓，你把結構化資料做到天花亂墜也沒有用，因為內容根本沒進入答案引擎的視野。沒有入場券，就連上場的機會都沒有。
答案引擎在決定引用誰之前，會先把候選內容放進一個取用範圍裡。你的頁面被高頻抓取，等於它已經被擺上了貨架。上了貨架不代表會被買走，但連貨架都上不了，就絕對不會被買。所以觀測數字的第一層價值，是讓你確認哪些內容已經在貨架上、哪些還在外面。還在外面的，問題可能出在索引、出在 robots.txt、出在答案引擎根本沒發現這個頁面，這些都是可以修的。
第二個判斷是排優先順序。七天破萬次抓取的頁面，和七天只被理會幾次的頁面，你該把答案段、問答 schema、問答型結構化資料的力氣花在哪裡？答案很清楚。被高頻取用的頁面，值得把答案友好度做到最完整。什麼叫答案友好度？就是把內容組織成答案引擎最容易消化成引用的形態：清楚的問句對答、結構化的資料標記、明確的定義和步驟、簡潔可以直接被摘錄的段落。其中結構化資料能幫答案引擎更有效率地讀懂你的內容，但「直接決定會不會被引用」的因果，目前沒有可靠證據佐證，別把它當保證。這些事情在已經被高頻抓取的頁面上做，投資回報率最高，因為取用管道是通的。標題結構也是同一回事：清楚分層的H1、H2 標題標籤，對人與對答案引擎都是更好的閱讀路標。
第三個判斷是主題層面的訊號。哪些主題的頁面被高頻取用，代表答案引擎在這個主題上有持續的需求。需求在哪裡，供給就該往哪裡補。如果你發現某一個主題 cluster 底下的頁面普遍被高頻抓取，那就是答案引擎告訴你「我在這個領域很缺內容」，你該做的是用主題叢集的方式加深這個 cluster、補上它還缺的子主題，而不是平均分散力氣。這比任何關鍵字工具告訴你的「搜尋量」都更貼近答案引擎的真實需求，因為這是它用實際行動、一次一次的抓取，投出來的票。怎麼把叢集內容做紮實，可以參考站上對叢集內容策略的完整拆解。
這套排優先順序的邏輯，跟一般SEO 內容優先順序怎麼排的框架是相通的：先看哪裡有被取用的證據，再把力氣往那裡集中，而不是平均撒在每一篇。差別只在於，傳統看的是搜尋量和排名，這裡看的是答案引擎的取用行為。把視角再拉高一點，這整個方向其實就是 AI SEO 的生存指南想講的事：流量從「被人搜到」逐漸分一部分給「被答案引擎引用」，而你必須兩頭都顧。
這組數字「不」代表什麼
Worker 記錄的是伺服器端真正收到的那一個請求，這是它最硬的優點。但請求是請求，引用是引用，中間隔著一整個答案引擎的黑箱。一次抓取之後會發生什麼？內容可能進了索引池、可能被去重、可能被排名篩掉、可能根本沒進入生成階段。你看到的 12,000 次抓取，可能有 11,990 次從未出現在任何使用者看到的回答裡。你不知道，我也不知道，這就是現狀。
這裡必須提一個前車之鑑。Glasp 曾經公布一組數字，一度在行銷圈瘋傳。他們觀察到自家 ChatGPT 引薦流量在幾個月內暴增數十倍，這個數字被廣為轉發，當成「AEO 已經碾壓傳統 SEO」的鐵證。但同一批作者後來用更嚴格的介入時序分析重新檢驗，效應下修到大約 1.82 倍，而且 p 值 0.16，在統計上根本不顯著。一份一開始喊到數十倍的研究，重新分析後落到 1.82 倍還不顯著，你就能理解這個領域的數字有多容易被過度解讀。把來訪說成被引用，是 AEO 資料最常見的膨風手法，而 Glasp 這個案例是最好的反面教材。
你開了一間店，門口經過一萬個人，你不能跟房東說「我今天做了一萬筆生意」。經過是經過，消費是消費，差別在那一萬個人裡，有多少真的走進來、拿起商品、結帳。答案引擎的爬蟲來抓，是路過；出現在使用者看到的回答裡，才是結帳。Worker 只能數路過的人，數不到結帳的人。路過的人多是健康的訊號，但它離實際被引用，中間還有索引、排名、檢索、生成好幾層篩選。這也是為什麼傳統的SEO 排名因素和答案引擎的引用機制，不能直接套用同一套計分邏輯，兩者的計分板根本不在同一層。
所以這組數字不能拿來做什麼？不能拿來跟客戶說「你的內容被 AI 引用了一萬兩千次」，這是假的。不能拿來宣稱「AEO 的回報已經超越 SEO」，這沒有證據。不能拿來當成「我的最佳化成功了」的證明，因為你沒有觀測到引用端。它能做的，是告訴你取用管道通不通、哪些主題被答案引擎重視、哪些頁面還沒進入視野。超出這個範圍的推論，數字不背書。Google 自己也多次提醒，不要為了迎合 AI 而盲目改寫內容，真正的危機不在這裡，而在垃圾結果正在侵蝕搜尋品質；同理，過度解讀爬蟲數字，也是另一種「為 AI 做 AI」的變形。
這組數字最有價值的用法，是當基線。你記下這個月的被抓取次數，做完一輪答案友好度最佳化，下個月再看。如果取用頻率上升了，代表你的最佳化方向至少讓答案引擎更頻繁地來抓，這是一個正向訊號。如果沒變甚至下降，代表你的調整沒有打動答案引擎的取用邏輯。相對趨勢比絕對數字有用，因為絕對數字的膨風空間太大。
答案引擎遞給你的需求單：404 清單怎麼讀
觀測報告裡有一個被嚴重低估的功能：top404 需求清單。它列出的是 AI 爬蟲來要、但站上回 404 的路徑，這等同答案引擎自己遞給你的一張需求單。它用實際的請求告訴你：我在找這個內容，但你這裡沒有。
一個客人走進店裡問「你們有沒有賣 X」，你說沒有，他走了。又一個客人進來問同樣的東西，你又說沒有。一個月下來同一個問題被問了五十次，你還不進貨嗎？404 清單就是那個被問了五十次的品項。答案引擎不是隨機亂敲 URL，它的請求路徑反映了使用者的查詢需求，和它自身的連結推斷。某一條路徑被反覆請求卻一直 404，代表在答案引擎的認知裡，這個站「應該」有這個內容，或者使用者在相關查詢裡表達了對這個內容的需求。
這份清單比任何關鍵字工具都直接。關鍵字工具告訴你的是「有人在搜尋引擎裡打了這個詞」，這是搜尋行為；404 清單告訴你的是「答案引擎的爬蟲為了回應某種需求，主動來找這個內容」，這是取用行為。取用行為已經是答案引擎主動發起的動作，離引用只差最後一步。這也是為什麼它比單純看長尾關鍵字的搜尋量，更貼近「答案引擎會不會引用」這個問題：前者是意圖的影子，後者已經是行動本身。做關鍵字最佳化時，把 404 清單當成補充的需求來源，會比只看搜尋量更準。
拿到這份清單之後該怎麼用？三個層次。第一層是判讀：哪些 404 路徑是真的有需求、值得補的，哪些只是爬蟲的 URL 猜測噪音。被多個不同 bot 反覆請求的路徑，含金量高於只被一個 bot 偶爾敲一次的。報告裡會標出每條 404 是哪些 bot 來敲的，這個維度很關鍵，多個答案引擎同時來要同一條路徑，就是跨引擎的共識需求。第二層是決策：補上這個內容，還是設一個 301 轉址把它導向最接近的現有頁面。第三層是生產：確認缺口之後，把這個主題寫成一篇有資訊密度的頁面，背後對應的其實是搜尋意圖判讀的功夫，然後在下一輪觀測裡確認 404 變成了 200，而且開始被取用。
你可以怎麼做
講了這麼多觀測的機制和界線，落實到你自己的站上，行動順序是這樣的：
- 先部署觀測，再談最佳化。沒有伺服器端的爬蟲計數，所有 AEO 投入都是在看不見回報的情況下燒資源。Cloudflare 免費層就跑得起一個 Worker，門檻低到沒有理由不做。你不需要等「準備好」才開始量，量本身就是準備的第一步。
- 把「被抓取」和「被引用」分開追。前者用 Worker 記，這條線你已經有了。後者要靠答案引擎引用監測和人工抽樣，定期去 ChatGPT、Perplexity、Claude 問你的目標查詢，看自己的內容有沒有被引用、被引用的是哪一段。兩條線不能混為一談，混了就會得到 Glasp 那種膨風結論。
- 用 404 需求清單找內容缺口。觀測報告裡 AI 來要但站上回 404 的路徑，就是答案引擎明確表達的需求訊號。多個 bot 反覆敲同一條路徑的，優先補上。這比猜測性的關鍵字研究更貼近答案引擎的真實需求。
- 把分類拆開看，別只看總數。OAI-SearchBot 來抓和 GPTBot 來抓，意義不同。搜尋型爬蟲的高頻來訪更接近引用訊號，訓練型爬蟲的高頻來訪離引用更遠。只看總抓取次數，會把最有判斷價值的維度丟掉。連內部連結的錨文字都該這樣拆開檢查：你以為傳遞的主題訊號，和答案引擎實際讀到的，不見得一致。
- 把觀測迴圈化。觀測、調整內容、再觀測，這個閉迴圈是讓 AI 內容策略能長期演進的骨架。單次觀測是快照，持續觀測才是趨勢，而趨勢才是判斷方向對不對的依據。把它當成常態性的改善 SEO動作，而不是一次性專案。
觀測、調整、再觀測，為什麼這本身就是一個閉迴圈
把前面所有段落串起來，你會發現這套觀測機制天然形成一個迴圈。觀測哪些頁面被答案引擎高頻取用，調整那些頁面的答案友好度，再觀測取用頻率有沒有變化。看到 404 需求清單，補上缺口的內容，再觀測 404 有沒有變成被取用的 200。發現搜尋型爬蟲在某個主題上特別活躍，加深那個 cluster，再觀測取用範圍有沒有擴大。每個動作都有一個對應的觀測指標可以驗證。
這個迴圈就像恆溫器：恆溫器不是設定一次就永遠不再管，它持續量測當前溫度，跟目標比較，偏高了就開冷氣，偏低了就關掉，再量、再比、再調。觀測 Worker 之於 AEO，就是那個持續量測的感測器。沒有感測器還硬要調，那不叫最佳化，叫賭博：你開了冷氣就走人，可能回到家發現冷到結冰或熱到流汗，因為你完全不知道中間發生了什麼。AEO 也一樣，沒有觀測的最佳化，就是閉著眼睛開冷氣。這和講求飛輪模型那種累積成長的邏輯是同一回事：每一次量測和調整都在幫飛輪加一點動量，單次看不出來，長期累積成別人難以複製的經驗曲線。
這個迴圈的關鍵不在某一輪的數字大小，而在它讓你的每一個調整都變成可驗證的假設。你不再靠「我覺得這樣寫答案引擎比較喜歡」來決策，而是靠「上個月被抓取 8,000 次，做完結構化資料調整後這個月 11,000 次」這種有對照的證據。每一輪觀測都讓你對答案引擎的取用邏輯多理解一點，累積下來就是別人無法輕易複製的經驗曲線。
這也是為什麼觀測不能是一次性的。單次觀測告訴你當下的狀態，但狀態會變：答案引擎的爬蟲策略在變、你的競爭者在變、使用者的查詢習慣在變。只有把觀測變成定期循環，你才能分清楚「這個變化是我的最佳化造成的」還是「這個變化是整個環境在動」。沒有迴圈，你就永遠在猜；有了迴圈，每一次猜測都能在下一輪被驗證或推翻。想看一套把這種觀測迴圈實作到 SEO 與內容產製的完整做法，可以從迴圈工程的完整指南看起，那份講的是整個閉迴圈的設計哲學，這份實測報告看的則是其中「觀測層」的一個具體實例。
常見問題
觀測 Worker 會不會拖慢網站速度？
實測下來對非 AI 流量的延遲趨近於零。Worker 只做一件事：讀 User-Agent、比對清單，不是 AI 就立刻放行，連資料庫都不碰；是 AI 才寫一筆紀錄，而且是非同步寫入，不會擋住回應。瓶頸不在 Worker 本身，而在免費層的 invocation 額度。
「被抓取」和「被引用」到底差在哪裡？
被抓取是答案引擎的爬蟲來你的伺服器把頁面內容抓走，這發生在伺服器端，Worker 看得到。被引用是你的內容真的出現在某個使用者看到的 AI 回答裡，這發生在答案引擎的黑箱裡，Worker 完全看不到，任何伺服器端工具都看不到。中間隔著索引、排名、檢索、生成好幾層篩選，把被抓取直接說成被引用，是這個領域最常見的資料膨風。
Cloudflare 免費層能撐多久？流量超過怎麼辦？
Workers 免費層每天十萬次 invocation，D1 每天十萬次 row-write，兩個額度獨立計算。因為 Worker 是 zone 層級的，每個請求都算一次 invocation，包括非 AI 流量。總流量超過十萬的那一天，觀測會暫停，但原始伺服器繼續正常回應，不影響網站。要持續觀測，可以升到每月五美元的付費層，每月一千萬次內含、超出後每百萬次 0.30 美元、沒有每日上限，對絕大多數內容站綽綽有餘。
OAI-SearchBot 和 GPTBot 有什麼不同？哪個更值得追？
GPTBot 是 OpenAI 的訓練爬蟲，抓內容是為了放進訓練資料集，離「被引用」很遠。OAI-SearchBot 是 ChatGPT 搜尋功能用的爬蟲，抓內容是為了在搜尋回答裡引用，離「被引用」近得多。如果只能追一個指標，OAI-SearchBot 的來訪頻率比 GPTBot 更貼近你的內容在答案引擎裡的引用潛力。Claude-SearchBot 之於 ClaudeBot、PerplexityBot 之於訓練型爬蟲，也是同樣的關係。
404 需求清單上的路徑，我要全部補上嗎？
不用，先判讀再決策。被多個不同 bot 反覆請求的路徑，含金量遠高於只被一個 bot 偶爾敲一次的。報告會標出每條 404 是哪些 bot 來敲的，優先處理跨引擎共識需求。確認是真缺口之後，再決定是補一篇新內容，還是用 301 導向最接近的現有頁面。
沒有部署在 Cloudflare 的網站，能做這種觀測嗎？
概念一樣，實作路徑不同。不在 Cloudflare 的站，可以在原始伺服器的存取日誌裡用 User-Agent 過濾 AI 爬蟲，自己寫腳本彙整。差別在邊緣 Worker 的優勢是判讀和紀錄都在邊緣完成，不回源、不增加主機負擔、不暴露原始伺服器。不管用哪條路，關鍵是開始量測，而不是繼續用看不到 AI 爬蟲的 GA 來猜。如果你也關注語音搜尋這類新入口的流量，伺服器端觀測同樣是唯一看得到真相的地方。
robots.txt 會影響 AI 爬蟲來不來抓嗎？
會。GPTBot、OAI-SearchBot、Google-Extended、ClaudeBot、PerplexityBot 各有獨立的 robots.txt token，你可以在裡面允許或封鎖任何一隻。本站的觀測刻意把 AI 爬蟲全部放行，因為要量測的是它們自然來訪的行為；一旦你在 robots.txt 拒絕某隻爬蟲，它在觀測報告裡就會消失，但那代表你選擇不讓它抓，不代表它本來就不會來。
被高頻抓取的頁面，要不要特別改寫成「給 AI 看」的格式？
不必為了 AI 另寫一套內容。把既有頁面的答案友好度做好就夠了：清楚的問句對答、結構化的資料標記、明確的定義和步驟。Google 自己也反對為了迎合 AI 而盲目改寫，真正的重點是把內容寫給看得到的人，同時讓答案引擎讀得懂。觀測數字告訴你哪些頁面值得投資這些調整，而不是叫你把內容改成機器口味。
