Field guide / By CiteVisor Editorial / Updated 2026-10-09

Block AI crawlers in WordPress and stay in AI search

WordPress serves a virtual robots.txt that lets every crawler in apart from the admin area. You can block AI training crawlers in a few lines and still appear in ChatGPT, Claude and Perplexity search, as long as you block the right user agents and do not reach for the wrong switch.

How WordPress serves robots.txt

Unless a physical file exists, WordPress answers /robots.txt itself. The core function do_robots() builds this output:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

The Sitemap: line comes from WordPress's built-in sitemaps (since version 5.5) and is only added when the site is public. SEO plugins often replace it with their own sitemap URL. Everything passes through the robots_txt filter before it is sent, which is how plugins add rules.

On typical Apache and nginx setups, a real robots.txt file in the site root is served directly and the virtual output, including any filter or plugin rules, is not used.

Choose the policy first

Training and search use different user agents, so you can treat them separately:

PurposeUser agentsEffect of blocking
AI searchOAI-SearchBot, Claude-SearchBot, PerplexityBotYou stop appearing in that engine's search answers
Classic searchGooglebot, BingbotYou leave Google or Bing, including their AI features
AI trainingGPTBot, ClaudeBot, Google-Extended, CCBot, Applebot-Extended, BytespiderOpts out of that operator's training use

The rest of this guide blocks the training group and leaves search alone. Our AI crawler list has each operator's own description.

Option 1: Add rules with the robots_txt filter

Put this in a small custom plugin or a child theme's functions.php. It appends one group per training crawler and leaves WordPress's own rules untouched:

add_filter( 'robots_txt', function ( $output, $public ) {
	if ( ! $public ) {
		return $output;
	}
	$training_bots = array( 'GPTBot', 'ClaudeBot', 'Google-Extended', 'CCBot', 'Applebot-Extended', 'Bytespider' );
	foreach ( $training_bots as $bot ) {
		$output .= "\nUser-agent: {$bot}\nDisallow: /\n";
	}
	return $output;
}, 20, 2 );

The $public check skips the rules when the site is set to discourage search engines. Search crawlers keep following the User-agent: * group. Do not add an Allow: / group for a search bot: a bot with its own group ignores the * group, including the /wp-admin/ rule.

Option 2: Use your SEO plugin's editor

If you already use Yoast SEO, go to Yoast SEO, then Tools, then File editor, and create or edit robots.txt there. Yoast notes the menu is hidden when file editing is disabled on the WordPress install. Other SEO plugins offer similar editors; check their documentation, because some write a physical file and some filter the virtual one. Paste the same training-bot groups below the existing rules.

Option 3: Upload a physical robots.txt

You can place a plain robots.txt in the web root by SFTP or your host's file manager. It replaces the virtual file completely, so copy WordPress's default lines and your sitemap URL into it, then add the training-bot groups. From then on, plugin and filter changes to robots.txt have no effect until you remove the file.

Don't use "Discourage search engines" for this

Settings → Reading → Search engine visibility is for staging sites. Since WordPress 5.3 it no longer outputs Disallow: /; it adds a noindex robots meta tag to your pages instead. That asks every search engine to drop the site, which also removes it from AI Overviews and other search-backed answers. It is not a training opt-out.

Hosting and CDN rules

robots.txt is a request. If you need enforcement, or a host or CDN already filters bots, check that layer too: a firewall rule that blocks OAI-SearchBot will hide you from ChatGPT search even when robots.txt allows it. If your site runs behind Cloudflare, see our guide to Cloudflare AI Crawl Control.

Verify the change

  1. Clear page and CDN caches, then open https://your-site.com/robots.txt in a private window.
  2. Confirm the User-agent: * group and sitemap line are still present, followed by your new groups.
  3. Check the robots.txt report in Google Search Console for fetch errors.
  4. Run the free AI visibility checker on a key page to see, crawler by crawler, which of 11 AI and search bots your live robots.txt allows.

Sources

Reviewed on 2026-10-09. Plugin menus change between versions; check your plugin's documentation if a label differs.

Frequently asked questions

Does WordPress block AI crawlers by default?

No. The virtual robots.txt that WordPress core generates has one User-agent: * group that disallows the admin directory and allows admin-ajax.php, plus a Sitemap line on public sites. AI crawlers follow that group, so they can crawl your public pages unless a plugin, host or CDN adds rules.

Will 'Discourage search engines from indexing this site' block AI crawlers?

It is the wrong tool. Since WordPress 5.3 the setting no longer writes Disallow: / to robots.txt; it adds a noindex robots meta tag instead. That asks search engines, including the ones behind AI search, to drop your pages, and it does not opt you out of AI training by name.

Should I block ClaudeBot?

It is a training decision. Anthropic documents ClaudeBot as its training crawler and Claude-SearchBot as the crawler for Claude's search results. Blocking ClaudeBot opts out of training without blocking Claude-SearchBot.

Why don't my robots.txt changes show up?

A physical robots.txt file in the site root replaces the virtual one, so filter and plugin changes will not appear while it exists. Page caching and CDN caching can also serve an old copy. Check the live file in a private window after clearing caches.

How can I see which AI bots visit my WordPress site?

WordPress itself keeps no log of crawler visits. Check your host's access logs or your CDN's analytics for user-agent tokens such as GPTBot, ClaudeBot, OAI-SearchBot and PerplexityBot, then confirm the source IP against the operator's published list, because a user-agent string is easy to fake.