Is It Agent Ready? 一個月後的 bot 流量實測
先說結論，就目前一個月的觀察來看，最基本的方法最有效：透過傳統的 robots.txt 和 HTTP Link header 來宣告「歡迎引用、拒絕訓練」，才是真正帶來 AI 流量的關鍵。
一個月前我把這個 blog 從 isitagentready.com 8 分推到 58 分，文末憑直覺寫了三條觀察。做完當下其實沒資料可以驗證，只是覺得「哪幾個改動我自己看起來最有用」。
那篇做的事大致分三類。第一類是 robots.txt + Link header：明確告訴 bot 哪些頁面可以爬、sitemap 在哪，robots.txt 配上 Cloudflare 的 Content Signals 標 ai-input=yes, ai-train=no，意思是「歡迎被 LLM 即時引用，但不要拿去當訓練資料」。第二類是 markdown 內容協商（content negotiation）：agent 在 HTTP 請求帶 Accept: text/markdown 這個 header，伺服器就回 markdown 而不是 HTML，省掉 LLM 從 HTML 裡 parse 出乾淨內文的雜訊。第三類是放在 /.well-known/* 下的 agent-skills index，描述這站可以怎麼被 agent 使用。當時刻意沒做 API Catalog / OAuth / MCP Server Card / WebMCP 這幾個分數很高、但沒有對應後端的端點，原文有寫為什麼。
為了之後能回頭驗證，順手在 Vercel edge middleware 加了 logging：每次 .well-known/* 被打、每次帶 Accept: text/markdown 的請求、每次被 bot UA 抓走的文章，都寫一筆到 Supabase。
28 天後資料堆到 4,266 筆。
打開 dashboard 後的第一眼就發現跟我原先的預期不一樣。
打開 dashboard：social 把 AI 壓著打
改造前隱約覺得 AI 流量做出來會有明顯一塊。
打開分類圖第一眼有點意外，最大宗的還是 social unfurl（fb / LINE 在你貼連結時抓 OG 預覽圖的動作），接近一半（2,041 / 4,266 ≈ 48%）。
我在 dashboard 上把 AI bot 分成三類：ai-input 是 LLM 即時回答 user query 時抓的（如 ChatGPT-User、PerplexityBot、OAI-SearchBot），ai-train 是訓練爬蟲（如 GPTBot、ClaudeBot、Amazonbot），ai-readiness 是 agent 評分掃描器（如 AgentReadinessScanner）。三類加總約佔 22%，比想像中少，而且非常集中，大部分都是 ChatGPT-User 跟 PerplexityBot 兩家在打。Anthropic 的 ClaudeBot 跟 Google 的 Google-Extended 都有出現，但流量幾乎可以忽略。
第一個校正：AI 流量起來了，但 social 流量本來就是這個 blog 的大宗，不會被壓過去。
well-known 的 666 次請求看起來最熱鬧，拆開全是同一個東西
上面那張圖是按請求者（UA）切的，換個維度按事件類型再看一次：
bot_article 3,557 / well_known 666 / markdown_negotiation 43，加總一樣是 4,266。well-known 是 markdown 的 15 倍，當下覺得「咦這麼受歡迎？」
把 666 拆開來看：
- 187 次來自
AgentReadinessScanner/1.0，就是 isitagentready.com 自家的定期掃描器 - 346 次來自
Chrome Privacy Preserving Prefetch Proxy在打/.well-known/traffic-advice - 真正的 AI bot（ChatGPT-User、PerplexityBot、ClaudeBot、GPTBot）幾乎沒打過 well-known
更妙的是 dashboard 上 "unpublished paths" 那欄列了 629 次 404，掃描器在問我沒實作的 /oauth-protected-resource、/mcp/server-card.json、/api-catalog、/acp.json、/ucp 這幾個 agent 標準端點（就是前情提要裡那批「分數很高、但沒有對應後端」的）。乍看好像是市場需求，但翻一翻請求者欄位，問這些 path 的也都是同一個 AgentReadinessScanner。
當初為了衝分硬刻那五個端點，做了之後不會多任何真實 agent 流量，只會讓掃描器再多打幾下、把分數從 58 推到 80。 原文裡決定不做的判斷站得住，補一句的話：判 demand signal 之前先看請求者是誰，光看次數會被掃描器灌爆。
那個我最得意的改造，採用率 1%
這條比較難寫。
原文裡我把 Markdown Negotiation 寫成「改造項目裡最有實用價值的一個」，論點是：對 AI agent 來說省掉 HTML parsing 是最有感的改善。
28 天的資料反過來說：
markdown_negotiation全部 43 次，佔所有事件 1%- AI live answer 那 530 個請求裡，只有 10 個帶
Accept: text/markdown，採用率 2% - 其他 8 個 UA 類別（ai-train、search、social 之類）的 markdown 採用率全是 0%
- 唯一 100% 採用 markdown 的是 human browsers
笑死，仔細查 human browsers 那 33 個事件，幾乎全部都是我自己拿 curl / httpie 戳測試的痕跡。 所以唯一一個 100% 採用我設計的 markdown 通道的，幾乎都是我自己。
設計上我仍然喜歡 markdown negotiation 那一塊：Vercel rewrite 規則乾淨、Vary header 正確、agent 真的送 Accept: text/markdown 過來就拿得到不帶 HTML 雜訊的版本。 但喜歡歸喜歡，主流 LLM 還是吃 HTML，沒有任何一家把「主動送 markdown」當預設行為，這跟我一開始的猜測有滿大的落差，算是意外的發現。
當初是把「設計乾不乾淨」直接外推成「會不會被用」，跳得太快。技術判斷本身沒錯，這塊基礎建設值得留著、維護成本也接近零；但當作 killer feature 在賣是錯的，比較像長線下注，當下就是 1% 採用率。
5/8 那天到底發生什麼事
每日事件量大概在 70–323 區間、中位數約 130，唯一一個明顯的流量峰值是 5/8 衝到 277 次。當天沒發新文，看到 spike 第一反應是「哪個爬蟲爆掉了」。
把那天拆開：
| UA | 命中數 | 類別 |
|---|---|---|
| SERankingBacklinksBot | 63 | seo |
| PerplexityBot | 61 | ai-input（單日新高） |
| GPTBot | 45 | ai-train |
| facebookexternalhit | 21 | social |
| Amazonbot | 16 | ai-train |
| Chrome Prefetch Proxy | 14 | unknown |
集中在台北時間 23:00（UTC 15:00）與隔天 06:00（UTC 22:00）兩波。命中的全是文章本體，沒 well-known，連兩三年前的 Vue v-for 老文章也被回頭抓過一輪。
訊號很乾淨：上線兩週後，PerplexityBot、GPTBot、Amazonbot 已經把這個 blog 排進固定的 crawl rotation，連 sitemap 裡的舊文都會回頭重爬一輪。「被找得到」這件事是在第二週才真的成立的。
順便發現的：上線後一到兩週才是看效果的窗口期。再早看資料沒意義（ecosystem 還沒索引到），再晚看（一個月後）多數機制已經穩定下來，看不出哪一個改動帶來了什麼差異。
原本寫最短的那條，反而帶量最大
回頭看當初的第三條：「robots.txt + Link header 這套基礎建設值得做」。
原文裡這條寫得最短、最沒戲，結果把資料攤開看，這條才是主角。
bot_article 3,557 個事件佔全部 83%。真正帶 bot 流量的就是這層：bot 透過正常爬蟲管道進來抓 HTML 文章頁。 前面講的 well-known、markdown negotiation 加起來都不到 20%。
深入看，bot_article 裡 520 個是 ai-input（ChatGPT-User、PerplexityBot、OAI-SearchBot），232 個是 ai-train（GPTBot、ClaudeBot、Amazonbot）。「被 LLM 即時引用」的次數比「被當訓練資料抓」多 2.2 倍。
把鏡頭縮到「agent-ready 改造原文」那篇文章自己，比例更極端。299 個 hits 裡：
- 235 是 social（fb / LINE unfurl，這篇被分享得多，預期之內）
- 30 是 ai-input（ChatGPT-User、PerplexityBot）
- 6 是 ai-train（GPTBot、ClaudeBot）
- 剩下零星 search / seo / generic-bot
ai-input vs ai-train 的比例變成 5:1。
當初寫 robots.txt 那條 Content-Signal: ai-input=yes, ai-train=no 其實不會物理上擋下 fetch，那 6 次 GPTBot / ClaudeBot 還是有抓到內容；這條規則只是宣告「歡迎拿去即時回答、不要拿去訓練」的用途偏好，bot 認不認、要不要照做，是 bot 自己的事。從 5:1 比例看，這個 trade 仍是設對方向的：拒絕掉的是少數的訓練用途，保留下來的是多數即時引用的綠燈。如果比例倒過來，這條設定就會變成擋錯方向。
看到這個比例，下次寫文章策略要調整：與其追長尾關鍵字、寫超深度長文（追「被索引」），不如把每一段都寫到能被單獨摘錄、結論明確（追「被引用」）。一篇文章被 ChatGPT-User 抓 30 次，意味著它至少在 30 個 user query 裡被命中過，這個感覺跟「被 Google 索引」差很多，更接近「被即時引用」。
下一步想搞清楚：能不能從 LLM 那邊拿到「具體在回答什麼 query」的 referrer 訊號。 目前手上只有「我被抓 N 次」這種純請求計數，看不到被誰在哪段對話裡引用了什麼，這條資料要另一條 channel 才拿得到。
Is It Agent Ready? 真的 Ready 嗎
isitagentready.com 給的分數是 58 分 Level 4 Agent-Integrated，看起來 ready 了。
但經過這 28 天收集的資料讓我想把這件事拆成兩半。
真正被用到的那層是 robots.txt + Link header：83% 的 agent 流量循這條進來。 所有主流 AI bot 都認這條，因為它本來就是 web 通用協定的延伸，bot 知道怎麼讀、也習慣讀。
讓我從 8 分推到 58 分的那些「進階」改造則是另一回事。markdown negotiation 採用率 1%、agent-skills index 沒人查、well-known 端點 99% 都是掃描器自己在打。
分數上最 agent-ready 的部分，被真實 agent 使用的次數接近零。
這個分數其實是在量「掃描器能不能在你的站上找到正確的標記」，跟「agent 會不會真的用你的站」是兩件事。 前者已經到位，後者目前還在等 ecosystem 接上來。
或許半年後再回來看 markdown_negotiation 採用率有沒有從 1% 動，如果有，就是 ecosystem 開始接這條的訊號。