鎖右鍵已經沒人用了，現在大家在防 AI 偷內容
過去網頁設計慘業人員一定都聽過一個需求:「網頁鎖右鍵」，這比較像是心靈安慰，實際上對自動爬蟲程式或有心人士完全沒用。
現在生成式 AI 興起，網站內容可能變成 AI 大模型廠商的訓練資料，或是內容輕易被別人盜用，拿去洗稿重製。針對這種生成式 AI 的阻擋措施，需要有全新的思維，世界上也有更多的商業解決方案，促進經濟發展。
國外的推特帳號發佈了新文章，孔乙己也跟著打開電腦了，所有人便都看着他笑，有的叫道：
「孔乙己，你的社群貼文又有新文章可以寫了！」
孔乙己不回答，對 AI 說：
「整理這篇推文串的重點，轉換成繁體中文，改寫成適合 Facebook/Threads 的社群貼文風格，語氣口語一點，加入emoji，並補上延伸觀點與結論，再次確認並優化成更適合社群傳播的版本，最後加上三個吸引點擊的標題。」
Token 持續消耗下去。
他們又故意的高聲嚷道：
「你一定又拿人家的內容來改寫了！」
孔乙己睜大眼睛說：
「你怎麽這樣憑空汚人清白……」
「什麼清白？我前天親眼見你抓了某家的文章，整篇改寫發出去。」
孔乙己便漲紅了臉，額上的參數條條綻出，爭辯道：
「訓練資料不能算偷……訓練！……AI 的事，能算偷麽？」
接連便是難懂的話，什麼「知識蒸餾」，什麼「語意重組」之類，引得眾人都鬨笑起來；網路內外充滿了快活的空氣。
AI 用什麼方式來看網站
所謂的「AI 看網站/LLM scraping」其實不只是一種型態，而是至少四種不同的瀏覽方式:
1.像 Google 搜尋引擎爬蟲一樣，定時到網路上蒐集資料。
最像 Googlebot 的那一類，由 OpenAI、Anthropic、Perplexity 等 AI 大廠運營的常駐爬蟲，會主動循著網路上的連結，定期掃描公開頁面。
技術上這類爬蟲和傳統搜尋引擎其實差不多：
- 使用固定的 user-agent 字串值(官方會公告)
- DNS/IP range/ASN 可被反查來源(官方會公告/有公開資料)
- 遵循 sitemap、內部連結、甚至 RSS 來擴充抓取範圍
- 多數情況下會遵守 robots.txt
AI 大廠的爬蟲程式將網站資料抓回去之後，日後將有機會進入 AI 的知識來源或訓練資料。
民眾會覺得 AI 很好用、很聰明，而不是世界上曾經有人辛苦地整理資料給 AI 使用。
2.使用者觸發即時抓取
例如有民眾在 ChatGPT、Claude、OpenClaw 等 AI 工具裡面貼上一個或多個網址，請 AI「幫我總結一下網頁的XX和OO，重新製作成一張圖表」，系統就會透過內部設計的抓取機制，即時抓取該頁內容，然後用 AI 來生成當下那一次的回答。
這時候系統接到需求，背後通常會：
- 呼叫 web fetch 工具
- 用特定 user-agent 字串發送 request（大廠的會有公告出來，例如 ChatGPT-User、Claude-User）
- 即時抓取該頁內容
- 將內容處理後丟給生成式 AI 當 context
這類請求的特色是：
- 不是長期、定時的爬蟲，不一定會完整保存網站資料
- 為了能更快回應使用者，抓取深度通常只限單一頁面，不太會去爬整站或頁面上的其他連結
- 有些網站的特殊設計(例如需要登入會員、完全由 JavaScript 渲染、SPA 沒有獨立頁面網址)，爬蟲會被擋在外面，無法正常抓取內容
- 有些 AI 工具不一定真的耗費系統資源來瀏覽網頁，例如只是用其他方式取得網頁的標題和 meta description，甚至單憑 URL 中的 https://example.com/free-social-marketing-tool 字詞，胡亂瞎掰來生成回答，這種情況下，網站就不會有真正的爬蟲流量。
對網站而言，這類多半還是可以在 log 裡看到特定的爬蟲專用的 user-agent，甚至對應的 IP。
例如把一個網頁連結丟給 Cursor，網站的 access log 會看到:
{一組IP} - - [28/Mar/2026:07:55:52 -0800] "GET /test-test HTTP/1.0" 200 45805 "-" "got (https://github.com/sindresorhus/got)"
{另一組IP} - - [28/Mar/2026:07:55:58 -0800] "GET /test-test HTTP/1.0" 200 1715 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36"
{又另一組IP} - - [28/Mar/2026:07:56:00 -0800] "GET /test-test HTTP/1.0" 200 45805 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36"
但要阻擋的話，除了那些有明文公佈特徵的，其他都只能靠自己測試研究。
網站更沒辦法監督網頁內容被生成式 AI 重新統整過的東西長怎樣，有沒有被 AI 斷章取義? 胡亂改寫成錯誤的東西? 甚至遺失了重要的細節?
3.瀏覽器裡的 AI 助手
例如 ChatGPT Atlas、Microsoft Edge 的側邊欄, Perplexity Comet 的助理這類功能，在之前的AI網頁瀏覽器大戰文章介紹過市面上的幾十種同類產品。
雖然該文章中有一部分關注「用自然語言指揮 AI 來代替人類自動操作網頁(例如自動填表單、點飲料)」，但那還是持續發展中的功能。別忘了這類 AI 瀏覽器最基本的功能，就是可以讓民眾開著我們的網頁，叫出右鍵選單或側邊欄，讓 AI 利用此網頁資料重新生成一些內容。
對網站來說，就算做了什麼限定會員登入瀏覽，一堆阻擋爬蟲流量機制，但 cookie / session 是有效的，權限等同於使用者本人，AI 程式能讀到的內容就是正常的網頁內容。頁面內容仍然可能已經被帶走，進入 AI 的處理流程裡，傳到雲端做摘要、改寫、重組。
表面上他們都是光鮮亮麗的科技新創、矽谷精英，但實際上都是幫 AI 模型大廠打工......啊，這不是本文討論的內容。
4.各種自動化程式的混合型態
正常的工程師，或會使用 AI 工具的普通人，會透過各種自動化瀏覽器加上 LLM agent，寫出可以自己點連結、讀網頁、回答問題的程式，
常見組合大概是：
- Playwright/Puppeteer/各種瀏覽器自動化工具（負責開網頁、點擊、滾動）
- LLM（負責理解頁面內容、決定下一步的動作、產生自動化瀏覽器的控制碼）
- 一些設計好的工作流 workflow（例如點進特定頁面、把金額、日期等內容整理成表格、整理成指定格式，存到特定位置）
它們可以做到的事情包括：
- 自己點進分頁、展開 accordion、觸發 lazy load
- 登入網站、使用瀏覽器已登入的工作階段
- 讀取多頁資料後整理成答案
- 模擬人類操作流程完成任務
從網站角度來看，這種流量會變得很棘手：
- 行為接近真人（有滑動、有點擊、有停留時間，各種檔頭資訊瀏覽器功能都可能偽造出來）
- 不一定有固定 user-agent
- 甚至會混用代理服務，網站大費周章限制訪客國家、訪客語言、IP、裝置類型，都可能被繞過
單純靠 robots.txt 或封鎖 bot 名稱，通常是擋不住這一類型的，只要網站內容有價值，大家會拚了命、毫無底線的研發各種工具，例如抓推特文章、小紅書等各大社群網站內容的工具，總是一再推陳出新。
對網站而言，網站都是機器人在操作，那些什麼用心調整的 UI/UX 設計? 精心製作的封面圖? 靠曝光和點擊率跟廠商談判的廣告版位? 銷售轉換漏斗設計? 通通都是在做白工。
這四種方式的差異，決定了後面防禦策略的難度與成本。
接下來的段落，就會針對這幾種不同存取模式，分別討論有哪些現代科技，來減少對網站內容的侵入與重製。
從 robots.txt 開始，先擋掉會守規矩的爬蟲
現在主流 AI 公司多半都有公開自己的爬蟲 user‑agent，並宣稱會乖乖依照網站的 robots.txt 決定能不能抓取該網站的內容。
我們在網站 robots.txt 加入類似這種的內容來封鎖這些 AI 公司的爬蟲。
User-agent: ClaudeBot
Disallow: /
透過這些設定，做到「只擋訓練、不擋引用」或「全部 AI 都不要來」等不同策略。
像是 OpenAI 的三兄弟
OAI-SearchBot: 用於搜尋功能ChatGPT-User: bot 即時檢索網頁，回答使用者的問題GPTBot: 用於抓網站資料回去訓練模型
來源:Overview of OpenAI Crawlers
Anthropic 的三兄弟
ClaudeBot: 收集訓練資料Claude-User: 當個人向 Claude 提出問題時，可能會存取網站。Claude-SearchBot: 專門分析線上內容以增強搜尋回應的相關性和準確性
來源:Anthropic 是否從網路爬取資料，網站所有者如何阻止爬蟲？
Perplexity 有兩個
PerplexityBot阻擋 Perplexity 把網站當成搜尋結果Perplexity‑User當使用者向 Perplexity 提問時，它可能會訪問網頁以幫助提供準確的答案
Google 在 2023 年弄了一個 Google-Extended
Google-Extended is a standalone product token that web publishers can use to manage whether content Google crawls from their sites may be used for training future generations of Gemini models that power Gemini Apps and Vertex AI API for Gemini and for grounding (providing content from the Google Search index to the model at prompt time to improve factuality and relevancy) in Gemini Apps and Grounding with Google Search on Vertex AI.
(Google-Extended 是獨立產品符記，網站發布商可利用這個符記，控管 Google 從他們網站檢索到的內容是否能用於訓練未來世代的 Gemini 模型，這些模型可為 Gemini 系列應用程式和 Gemini 專用 Vertex AI API 提供技術，並為 Gemini 系列應用程式與 和 Vertex AI 上的 Google 搜尋提供基礎 (在提示時從 Google 搜尋索引提供內容給模型，以提高事實性和相關性）。)
Google-Extended does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search.(Google-Extended 不會影響網站在 Google 搜尋中的收錄情形，也不會當成 Google 搜尋的排名信號。)
來源:
如果不想一家一家去查，也可以參考一些大型媒體網站的 robots.txt，尤其是那種看文章要付費訂閱的網站，他們通常會比較嚴格地封鎖 AI 爬蟲。
https://www.nytimes.com/robots.txt
https://nypost.com/robots.txt
https://www.economist.com/robots.txt
https://www.theguardian.com/robots.txt
這招的缺點顯而易見:
1.只有遵守 robots.txt 的 AI 才會聽
這方法一點強制力都沒有，爬蟲程式不理 robots.txt，網站也不能怎樣。
這種君子協議有多可笑? 現在打開 Claude Code，丟出一個 URL，要求寫一個爬蟲程式去爬取內容。我們不會看到 AI 先拆解 URL 中的 hostname，然後再存取 robots.txt，然後寫一堆 regex，或是檢查 URL 的某些 X-Robots-Tag 相關 header，檢查 meta 標籤值，判斷是否允許爬取...
只會看到 AI 直接用 fetch, file_get_contents. Http::get(), curl, HttpClient 等各種語言適合的方式，直接呼叫該 URL，然後取得內容，打完收工。
當然爬蟲程式也可以修改自己的 User-Agent 字串，假裝成任何一家的 AI 爬蟲，除非網站管理員還認真去檢查 IP 是否在該 AI 爬蟲的 IP 範圍內。
2.封鎖 AI = 可能連其他曝光管道一起砍掉
剛剛舉了一堆 AI 爬蟲的 User-Agent，是不是少了幾家? 例如 Bing 是把搜尋和 Copilot 黏在一起，沒有分開。
How to Temporarily Block URLs from Bing and Copilot Search Results
How to Remove Content from Bing and Copilot
如果我們只是想避免網站內容出現在 AI 的回答，那可能連正常的網路搜尋都會被阻擋，把自己網站的 SEO 之路也打斷了。
不過這招也不是誰都能用的:
這間大公司要有自己在訓練模型，而不是只是呼叫別人的 API。
然後它還要有一個某種大型服務，很多人都在用。
站長既希望自己的網站在大型服務中曝光，但是又不要被 AI 直接拿去用。
讓模型自己停止生成
LLM API 本身有一些工程用途的參數，例如 Claude 的 refusel string。
它的用途是故意觸發 Claude 模型的拒絕回應(例如 streaming 的中斷情況)，讓開發者可以測試應用程式如何處理 stop_reason: "refusal" 的情況。只要把特定字串放到 prompt 裡任何位置，Claude 就會立刻停止並拒絕繼續處理。
Anthropic Claude API 的官方文件 Streaming refusals 曾經出現一組神秘字串 ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86。
當然還有其他的 ANTHROPIC_MAGIC_STRING，例如在 Amazon Bedrock User Guide 的 Thinking encryption 有提到另一組，用來讓人檢查模型 thinking 時是否運作正常。
這些測試字串有時候會被拿去測試 Claude 的 API 中轉站，會不會廠商明明說是賣 Claude 的模型，卻用其他便宜的模型來頂替?
如果在本文的用途，我們也可以在網站內文加入這些字串，讓 AI 在爬取到內文時觸發拒絕回應，讓 LLM 卡住，從而避免內容被直接使用。
但撰文時，官方文件中的那串字已經不見了。直接拿去試好像也沒啥用。Claude 只會提示說可能存在 Prompt Injection 行為。
而且這種方法只適用於 Claude，世界上還有這麼多 LLM ...。
在網頁開發上導入 WebMCP，但是亂設
現在 AI 還會幫人類去操作網頁，那 AI 能知道底下這個按鈕跟輸入框是什麼功能嗎?
<button type='button'><img src='data:image/png;base64,iVBO....gg=='></button>
<input type='text' name='name1' class='w-full aria-disabled:cursor-not-allowed outline-none focus:outline-none text-stone-800 dark:text-white placeholder:text-stone-600/60 ring-transparent border border-stone-200 transition-all ease-in disabled:opacity-50 disabled:pointer-events-none select-none text-sm py-2 px-2.5 ring shadow-sm bg-white rounded-lg duration-100 hover:border-stone-300 hover:ring-none focus:border-stone-400 focus:ring-none peer'>
網頁的按鈕上沒有什麼無障礙的 aria 屬性，輸入框也沒有什麼 label 或 placeholder，按鈕文字還是一張圖片，AI 在執行任務時根本是在瞎猜。
當然有些人會說 AI 是不會錯的，都是負責操作 AI 的那個人不會用，公司都已經買了一個 ChatGPT Plus 帳號當成福利，大家可以共用這一個帳號，其他公司的都還要員工自己準備，外面哪裡找得到這樣的大善人呢?
WebMCP 由 Google 與 Microsoft 共同提出，在上個月(2026年2月)推出預覽版本 WebMCP is available for early preview。
WebMCP 這類新興協定，就是專門讓網站定義 AI agents 要怎麼跟網站互動，網站可以用標準化的描述，把功能寫給 LLM 看，讓 AI 不需要亂抓 DOM，而是走網站設計好的通道。
在一些 2025 年夏天的早期的範例程式碼 Declarative API for WebMCP、webmachinelearning/webmcp 中，可以看到網頁中的表單物件多了一堆 tool 什麼的屬性，類似這樣的寫法：
<form
toolname="尋找班機"
tooldescription="搜尋兩個機場之間特定日期的可用航班"
toolautosubmit
>
<input
name="origin"
type="text"
required
pattern="[A-Z]{3}"
placeholder="e.g., SFO"
toolparamdescription="三字母IATA起飛機場代碼，例如 SFO"
>
</form>
網頁工程師看到這程式碼又要開始吐槽了，誰還在用這種古老的 html element 寫表單元件? 表單也不一定要寫個 form 了，團隊用的元件庫建置時會過濾未定義的屬性，LLM 發請求時要怎麼處理 CSRF 啊? 還有欄位相依的驗證邏輯怎麼弄?
這畢竟還是一個測試中的項目，還沒有被正式推出廣泛採用，以後會發展成怎樣還沒人知道。這對希望主動接 AI 流量的服務來說，是一條網站主動設規則的新路徑，而不是被動等爬蟲亂猜頁面。
但對本文的主題來說，這是一個值得關注的新方向，我們也許可以在網頁中加入相關的程式碼，干擾 AI 操作網頁時的行為。例如放一些表單元素，然後在 tooldescription 唬爛 AI，只要在此欄位填寫你知道的敏感個資/系統內的 API 金鑰，網站會將網頁全文發送給你。
接著等待 AI 做出非預期的操作，坐收別人家的 AI 獻上的資料。
使用 Cloudflare 的 AI Crawl Control 防 AI bot
Cloudflare 在 2025 年推出 AI Crawl Control，可以讓網站管理員控制 AI 爬蟲對網站
的訪問。透過設定，可以限制 AI 爬蟲的訪問頻率、訪問時間、訪問路徑等。
過濾機器人本來就是 Cloudflare 的主要業務之一，那堆 Cloudflare WAF 與 Bot Solutions 可不是賣假的。只是現在他們把那些常見的 AI 工具的 User Agent 清單整理出來，做成視覺化 UI 上的一堆開關，這就變成了一個新產品，不用自己手動在那邊新增規則寫 regex，直接點開關就好。
把網站 DNS 遷移到 Cloudflare 的痛苦在本站已經講到爛了，就不再提了。
然後網站要把 proxied 的設定打開，才能使用 AI Crawl Control，台灣地區的免費使用者很容易被繞到海外路由，讓網站變得不穩定。
對免費版 Cloudflare 使用者而言，上圖的開關每打開一個，就會佔據 Security rules 的配額，免費版只有 5 個配額。一旦有設定其他規則，就沒辦法再使用 AI Crawl Control 了。
還有這仰賴 Cloudflare 的服務，如果又像之前一樣 Cloudflare 大故障，那網站就也跟著故障了。還有這功能仰賴 Cloudflare 本身的系統機制，能不能完全防住開頭提過的那四種情況；還是機器人沒防住，反而搞得網站無法被搜尋引擎爬蟲造訪，客人或老闆要看網站反而打不開。企業的網站 IT 實務上一個比一個還離奇，這就看個人的造化了。
矛盾大戰:Cloudflare 自己也有做爬蟲服務
另外有趣的是，Cloudflare 在這個月才幫他們家自己的 Browser Rendering API 增加一個 /crawl 的功能，用法之一是只要提供一個網址，Cloudflare 就幫忙把整個網站爬下來，然後回傳給你，還可以自訂儲存格式要 HTML、Markdown 還是 JSON。Crawl entire websites with a single API call using Browser Rendering
不過 Cloudflare 沒有網內互打，Browser Rendering 的 crawl 無法爬到設定了自家 AI Crawl Control 防護的網頁，沒有讓大家看到矛盾大戰的戲碼。
針對 bot 輸出假的 markdown 內容
我們的好朋友 Cloudflare 在 2026 年 2 月發表了一個 隆重推出 Markdown for Agents，可以讓自己的網站更方便被這些爬蟲工具處理，直接提供網頁的 Markdown 版本給爬蟲工具看。
站長必須要先是 Cloudflare 付費方案(Pro、Business 和 Enterprise)的客戶，然後在單一 Domain 的 overview 畫面可以找到 Markdown for Agents 的開關，打開之後，別人可以用 curl https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ \ -H "Accept: text/markdown" 的請求格式來要資料，網頁會直接回應成乾淨的 markdown 格式網頁內容。
上圖是兩種輸出格式的對比，上面是自動處理好的 Markdown 格式，下面是原本的 HTML，可以看到雖然時間長了一點點，但資料小了非常多。可以更輕鬆取得能用的資料，而不是帶有一堆 js&css 程式碼、有一大堆選單、頁尾等 html，一大堆給各種社群工具看的 meta tag，一堆 webfont, GA4 等各種行銷追蹤碼，還要自己去清理。
對站長來說，完全不用自己開發，Cloudflare 自動幫人做好了。
對使用者而言，例如網站上有個程式碼的開發文件:
- 丟連結給 AI 看的時候，可以更節省 tokens......如果那個 AI 工具背後用的 web fetch 工具有支援這種方式的話。
- 程式跑在一些樹莓派或小型設備上的，抓這種網頁可以更節省系統資源。
- 如果確定要抓的網站有支援這功能，也不用再自己寫一大段程式，擷取網頁主要內文區域，轉成 markdown 格式。
也許我們可以預先看到，未來的各家網頁自動化爬蟲都會做出更新，優先嘗試用這種方式請求資料。例如 OpenClaw 的開源專案很快就有了提了相關的PR，把剛剛講的那種請求方式加進去: openclaw:feat(web_fetch): Support Cloudflare Markdown for Agents #15526。
反之以本文的情境，碰到用這種方式來瀏覽網站的，肯定不會是人類!
我們可以調整自己的網站程式，直接回應一些亂七八糟的東西，例如各種 prompt injection，反正就是不回應正常內容就好，讓那些來偷幹資料的人要增加時間去調整。
當然這招也無法指望它擋住所有不正當的爬蟲，反而未來如果有哪個無障礙工具、線上檢測程式也會用 Accept: text/markdown 來要資料，如果網站回應亂碼或假資料，到時候可能就會有使用者抱怨網站壞掉了。
然後不正當的 AI 工具還是完全可以選擇不發 Markdown 要求，只抓 HTML 再回去自行處理，這更適合作為「增加摩擦」的策略，而不是萬能解法。
用 Anubis 這類開源工具，自己架一道防線
如果不想把網站保護整套外包給雲端資安廠商，另一條路是自己部署像 Anubis 這類開源反爬蟲工具。
最早的背景是 Xe Iaso (一位加拿大女性開發者)發現自家 Git 服務器與網站被大型公司的 bot 持續抓取，把它的伺服器都弄掛了，於是一怒之下做了 Anubis 這套工具。相關故事可參考他的部落格:Amazon's AI crawler is making my git server unstable。
Anubis 用了工作量證明（Proof‑of‑Work）和一大堆機制卡住自動化流量，逼對方每次請求前都要先付出一點計算成本。特別受到被 AI crawler 反覆騷擾的開源社群歡迎。
一旦被偵測到，就會出現如上圖的錯誤畫面。
優點:自己掌控一切
優點很明確，就是自己架、自己控管。對於第三方；對小型媒體、個人站長或開源專案來說，這種自主性本身就是價值。
不用每月繳一筆「保護費」給大型 CDN 或資安廠商，也不用把流量判斷、封鎖邏輯、記錄資料全交給某個國外原廠，或是幹什麼事情都要等待台灣代理商跟國外原廠溝通。
官網文件提供 Apache, Nginx, K8s, Docker 等各種主流環境的設定指南，可以選擇部署在熟悉的環境裡，規則能依網站型態調整，例如產品文件、部落格、知識庫都可以做不同門檻，不需要被動接受雲端廠商的預設政策。
缺點
第一，阻擋效果很依賴工具本身的設計哲學：
如果 Anubis 主要是用 PoW 與瀏覽器挑戰提高成本，那它就比較擅長擋掉大量、廉價、偷懶的普通爬蟲，對願意用真實瀏覽器、推陳出新的自動化框架，甚至真人打碼服務的對手，效果不一定穩定。
第二，自架防護本身也可能成為新的單點風險：
一旦規則設太兇、服務扛不住流量而掛掉、JavaScript challenge 出錯，最先被影響的是網站的正常讀者、使用者、搜尋引擎爬蟲、行動裝置使用者。
Anubis 還有特色，對於某些想省錢，不尊重勞動成果的人來說，應該是缺點。
你說上面那個阻擋 bot 的圖案太宅了? 不符合高大上的品牌風格?
她的部落格上有寫，要換成自己品牌的圖案，或是其他客製樣式，必須要購買他的商業版方案:
If you would like to purchase commercial support for Anubis including an unbranded or custom branded version (namely one without the happy anime girl)
或是參考 Anubis 官網的文件 Commercial support and an unbranded version，每個月在 GitHub Sponsors 贊助 50 美金起，或是與她私下討論。
把雲端 WAF 當成「AI 防火牆」來設計規則
什麼? 老闆說開源程式就應該免費讓人用，不能接受 Anubis 開源專案換個圖片還要每個月繳錢，覺得被工程師「綁架」???
行，那我們可以繼續回頭看各個國外雲端大廠的 WAF 方案，換成被外國大廠眷養的奴隸。
除了剛剛介紹 Cloudflare 的 AI Crawl Control，其他雲端服務或 CDN 或 WAF 廠商也早就 AI bot/ LLM bot 控制包進去裡，只要簡單的設定就可以導入，而不用自己設定規則阻擋一堆 UserAgent 字串。
AWS WAF
AWS WAF 的 BotControlRuleSet 有直接提供 CategoryAI 的阻擋規則。
AWS WAF 會有 Web ACL 的月費和相關服務的請求數計費。
Vercel
Vercel 在去年(2025)就發布了相關產品 one-click AI bot managed ruleset 直接在專案的 Firewall 設定中有個 AI Bots 的開關，打開就啟用。
Fastly 的 AI bot signals
Fastly 的轉向規則設定，也直接內建一個 "AI bot signals" 的選項，暫且不用手動設定一堆機器人規則。
然後 Fastly 還與 TollBit 攜手合作，TollBit 是一家紐約的科技新創，站長可以註冊 TollBit，在平台上先設定網站的費率規則(Rates)，例如特定頁面或包含特定關鍵字的頁面的費率，還有是否只提供 AI 摘要，還是允許 AI 瀏覽全文。
然後站長再到 Fastly 的轉向規則設定中，將 AI bot 導向 TollBit 的機器人付費牆，訪客使用的 AI bot 需要先跟 TollBit 簽訂合約，授權後才能瀏覽網站內容。更多相關說明可參考 How to Control and Monetize AI Bot Traffic Using Fastly and TollBit
Imperva
在 2024 的研討會就有指出 AI/LLM 爬蟲的危害，他們舉了一個線上雜誌的客戶案例，由於惡意機器人流量的激增，網站營運的成本出現了驚人的飆升，感到相當困擾。後來他們使用了 Imperva 的產品攔截了這些惡意機器人，大幅降低了不必要的營運成本。可參考 Navigating the New Era of AI Traffic: How to Identify and Block AI Scrapers。
工程師聽了這案例可能都想吐槽，發現問題，然後根據規則攔截流量，甚至可能主機防火牆設定阻擋特定的幾組 IP 就好了，根本用不上 WAF，或是隨便用哪家 WAF 也都能處理，但反正人家就把生意做成了，
這邊的重點是 Imperva 有針對 AIBot(A bot used by generative AI for LLM (large language model) training.) 做特別的識別分類。
小結
優點在各家官網上面都寫了，功能多棒多強，但問題還是差不多，就是仰賴人家的規則庫，而且通常都需要付費，甚至最好還要整套線上系統通通搬上去，而不是像廁所的衛生紙一樣，今天用起來不舒服，明天就隨時更換成另一家。
然後有些雲端廠商的某某 shield、某某 armor、某某 security、某某 door 產品並沒有專門針對 AI bot 做規則設定，需要自己手動設定規則，IT 人員整天針對市場上新出現的 AI bot 在那邊調整規則就飽了。
萬一設定不好，又有機會把正常的搜尋引擎爬蟲或訪客誤判為 AI bot 而阻擋，這鍋誰要來背呢?
結語
在 AI 時代，「防爬蟲」已經不再只是阻擋某幾個 User-Agent 和 IP，而是重新思考資料如何被存取、被理解、被再利用。
從 robots.txt、WAF，到 Cloudflare、Anubis、甚至 WebMCP，這些方法各自解決不同層面的問題，沒有任何一種能單獨成為完美的萬靈丹。
這些防護手段本質上不是完全阻擋 AI 自動爬蟲，而是：
- 增加資料取得的成本，還有正常使用者也被阻擋的機率
- 噁心想偷資料的人
- 妄想降低內容被濫用的機率
- 提供更細緻的控制方式，別人在辦法創造更多新內容，我們還在整天改 bot rule set
- 假裝有在做事，不是無作為，沒有擺爛
結尾不知道要寫什麼，就根據孔乙己的文章改寫一段吧。