若要阻止 GPTBot 爬取 WordPress 網站，請在 robots.txt 中加入以下幾行：
User-agent: GPTBot
Disallow: /對於行為端正的爬蟲來說，這就是完整的解法。但你得對自己誠實，看清楚剛剛做了什麼：robots.txt 是一個請求，不是一道圍籬。OpenAI 的 GPTBot 會抓取這個檔案並遵守它，而不尊重這項標準的抓取程式，一樣會抓取同一個檔案，卻對裡面每一行都視而不見。在你花一個下午調整這東西之前，請把這個區別牢記在心。
如果你想一次涵蓋主要的 AI 爬蟲，常見的 user-agent 標記如下：
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Bytespider
Disallow: /GPTBot 是 OpenAI 的訓練爬蟲，CCBot 是 Common Crawl（許多模型後續會拿它來訓練），ClaudeBot 是 Anthropic，Google-Extended 是 Google 的 AI 訓練標記，Bytespider 則是 ByteDance。要注意其中兩個已經打破了「客氣請求」的模式：Bytespider 和 PerplexityBot 都曾被公開記錄到會去爬取已將它們封鎖的網站。把它們列出來，對誠實的機器人仍有幫助，但對那些一開始就謊報自己身分的機器人則毫無作用。
WordPress 實際上是如何提供 robots.txt 的
這裡正是多數人的修改悄悄失效的地方。如果你的網站根目錄裡沒有實體的 robots.txt 檔案，WordPress 會即時產生一個。這個請求由 wp-includes/functions.php 中的 do_robots() 處理，其輸出會經過 robots_txt 過濾器。在「設定 → 閱讀」底下的「阻擋搜尋引擎索引這個網站」核取方塊會切換 blog_public 選項，而那正是讓這個虛擬檔案輸出 Disallow: / 的機制。
所以你可以用程式化的方式附加 AI 爬蟲規則：
add_filter( 'robots_txt', function ( $output, $public ) {
$output .= "User-agent: GPTBot\nDisallow: /\n";
return $output;
}, 10, 2 );這裡有個會吃掉你好幾個小時的陷阱：一旦你的網站根目錄存在一個靜態的 robots.txt 檔案，Apache 或 nginx 就會直接提供那個檔案，WordPress 根本不會執行。 robots_txt 過濾器、Yoast/Rank Math 的 robots 編輯器、閱讀設定——通通被略過。如果你在外掛裡編輯了 robots.txt，但線上的檔案卻始終沒變，幾乎都是這個原因。請用無痕視窗開啟 https://yoursite.com/robots.txt，拿它跟你以為設定的內容比對。如果磁碟上真的有實體檔案，那就去編輯那個檔案；過濾器在這種情況下毫無意義。
依序解決它
第一，寫出乾淨的規則。 把語法和爬蟲清單弄對，才不會不小心把 Googlebot 也封鎖了。我們的 robots.txt 產生器 會替你建立 AI 爬蟲封鎖規則，並顯示可直接貼上的完整檔案內容，這樣就能避開虛擬檔案與實體檔案的混淆——因為你最終會得到一份具權威性的檔案。
第二，確認它已生效。 直接抓取那個網址，不要相信外掛的預覽窗格。
第三，如果你需要的是強制執行而不只是客氣地請求，那就往上層走。 robots.txt 位於應用層，依賴的是機器人的善意。若要真正拒絕一個連線，就在伺服器層依 user agent 封鎖。在 .htaccess 中：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|CCBot|ClaudeBot|Bytespider) [NC]
RewriteRule .* - [F,L]
</IfModule>這會對任何送出這些 user agent 的請求回傳 403。我們的 .htaccess 產生器 可以幫你組出這條規則。不過要理解它的極限：user agent 可以被輕易偽造，所以這只能擋住那些誠實到願意表明自己身分的機器人——而那些正是本來就會遵守 robots.txt 的機器人。真正穩健的選擇，是使用能依已驗證的爬蟲身分或 IP 範圍來封鎖的 CDN 或 WAF。Cloudflare 一鍵式的「Block AI Scrapers and Crawlers」代管規則，是這種做法中最省力的版本，它在邊緣運作，早在請求抵達 WordPress 之前就把它擋下。
不該做的事
不要以為封鎖 Google-Extended 就能讓你不出現在 AI Overviews 中。 這是個值得糾正的誤解。Google-Extended 是一個產品標記，不是爬蟲。它只控制你的內容是否會被用來訓練與支撐 Gemini 模型。根據 Google 自己的文件，它對你的網頁如何被爬取、索引，或在 Google 搜尋中的排名毫無影響。 而 AI Overviews 是建立在 Googlebot 所爬取的一般搜尋索引之上——不是來自 Google-Extended。封鎖 Google-Extended 不會把你從 AI Overviews 中移除，也不會讓你在搜尋中損失任何一個排名。要不出現在 AI Overviews 中，唯一的方法是封鎖 Googlebot 或對該頁面加上 noindex，但這同時也會把你從搜尋中徹底刪除。這幾乎絕不會是你想要的交換。
不要把 robots.txt 當成安全控制手段。 它是公開的、只具建議性質。把 /wp-admin/ 或某個私密路徑列在裡面，只是公布了一張「該往哪裡找」的地圖。請用驗證機制來保護真正的端點，而不是靠一行 disallow。
不要依賴 noai / noimageai meta 標籤。 它們只是被提議過，並未成為標準，而且只有少數平台會遵守。它們不是通用的防禦手段。
不要假設某個「封鎖 AI」外掛做的事情比寫入 robots.txt 更多。 它們大多只是寫入你自己手動也能寫的相同幾行，並繼承了同樣的侷限。在信任它之前，先看清楚這個外掛實際改了什麼。
還是卡住嗎？
如果你的修改沒有顯示出來，答案幾乎都是網站根目錄裡有個多出來的實體 robots.txt，蓋過了 WordPress 的虛擬版本——直接抓取那個網址檢查一下。如果守規矩的機器人已經消失，但抓取程式仍不斷打你的網站，那你就碰到了 robots.txt 能力的天花板，下一步就是改用能依已驗證身分（而非客氣詢問）來封鎖的 WAF 或 CDN 規則。