How to Block AI Web Crawlers From Your Website

If you've checked your server logs lately, you've probably noticed visitors that aren't quite human. Bots with names like GPTBot, ClaudeBot, and Bytespider are moving through the web at a scale that didn't exist three years ago — and by mid-2026, automated traffic will have actually pulled ahead of human traffic on parts of the internet, according to Cloudflare's network-wide data. Not all of that is AI, but a fast-growing and increasingly aggressive slice of it is.


How to Block AI Web Crawlers From Your Website


If you publish original content — articles, research, product descriptions, photography, code — you have a real decision to make: let AI companies scrape it for free, or take back some control. This guide walks through exactly how to block AI web crawlers, why some methods work better than others, and how to decide which bots are actually worth blocking.

Why This Matters Right Now

The numbers explain the urgency better than any warning could. Within the population of verified, well-behaved bots that Cloudflare tracks across its global network, AI-related crawlers made up roughly a quarter of that traffic by mid-2026, and the purpose of that crawling has shifted hard toward training. Across the first half of 2026, the share of AI crawler requests dedicated purely to model training climbed sharply — well over half of all AI bot activity by June, up from roughly two-fifths just months earlier.

That shift matters because training crawlers gives almost nothing back. Independent analysis of Cloudflare Radar data puts Anthropic's crawl-to-referral ratio at somewhere between roughly 4,500 and over 20,000 pages crawled for every single visitor sent back to the source site, depending on the measurement window. OpenAI's ratio, while better, is still lopsided compared to traditional search. Google's classic search crawler, by contrast, sends back roughly one visitor for every five pages it crawls — a bargain publishers have accepted for two decades. AI training crawlers don't offer that bargain. They take your words, images, and structure to make a model smarter, and the reader who eventually benefits never sees your site, your ads, or your byline.

That's the economic case for control. Whether you act on it is up to you — but you should at least be making the choice deliberately, not by default.

Training Crawlers vs. Search Crawlers: The Distinction Everyone Skips

Before you block anything, understand that "AI crawler" isn't one category. There are two very different jobs these bots do, and lumping them together is the most common mistake site owners make.

Training crawlers scrape your content to build or fine-tune a language model. Examples include GPTBot, ClaudeBot, CCBot (Common Crawl), Bytespider, and Meta-ExternalAgent. These bots typically crawl in bulk, permanently add your content to a training dataset, and send back essentially zero traffic.

Search/answer crawlers fetch a specific page in real time because a user asked an AI assistant a question and the assistant needs to check your page to answer it — and sometimes cite it. Examples include OAI-SearchBot, Claude-SearchBot, and PerplexityBot. These are more closely aligned with how Googlebot behaves, and, depending on the platform, they can send meaningful referral traffic back to you. Perplexity, for instance, is dramatically more "referral-efficient" than pure training crawlers because it surfaces cited sources inline.

This distinction should drive your whole strategy. Blocking a training crawler protects your content with little downside. Blocking a search crawler by mistake can quietly cut you out of AI-generated answers and any traffic that comes with them — a mistake that's easy to make if you copy-paste a "block all AI bots" list without checking what each user-agent actually does.

Step 1: Block AI Crawlers With Robots.txt

Robots.txt is the standard, industry-recognized way to tell a crawler "please don't access this." It's the first and easiest layer of control, and major AI operators — OpenAI, Anthropic, and Google among them — have publicly stated they honor it for their primary crawlers.

Create or edit the robots.txt file in your site's root directory (yoursite.com/robots.txt) and add rules like this:

User-agent: GPTBot

Disallow: /


User-agent: ChatGPT-User
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Diffbot
Disallow: /

User-agent: cohere-ai
Disallow: /


A few technical details trip people up constantly:

  • No blank lines inside a rule block. A blank line between User-agent and Disallow Breaks the association between them.
  • The filename is case-sensitive on most servers. It must be exactlyrobots.txt, not Robots.txt.
  • Folder paths are case-sensitive too. Blocking /blog/ won't stop a crawler from reading /Blog/.
  • Test it after publishing. Load yoursite.com/robots.txt in a browser and clear any caching layer (CDN or plugin cache) so the new file is actually being served.

If you want to allow search-purpose crawlers while still blocking training crawlers, add explicit Allow rules for the search bots (OAI-SearchBot, Claude-SearchBot, PerplexityBot) rather than leaving them ambiguous.

Step 2: Reinforce With .htaccess (Self-Hosted Sites)

Here's the part most beginner guides gloss over: robots.txt is a request, not a lock. It relies on the crawler choosing to behave. Well-known operators mostly comply, but plenty of scrapers — especially smaller, less transparent, or outright malicious ones — ignore it entirely.

If your site runs on Apache (common with self-hosted WordPress), you can add server-level rules to your .htaccess file that actively deny access based on the crawler's User-Agent string:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ClaudeBot|CCBot|Bytespider|Amazonbot|Diffbot) [NC]
RewriteRule .* - [F,L]

This returns a "Forbidden" response to any request carrying one of those user-agent strings, regardless of whether the bot respects robots.txt. It's a meaningfully stronger layer of enforcement — but it only works on servers where you have file-level access, which brings us to a limitation a lot of guides don't mention.

Step 3: Use a CDN or WAF for Real Enforcement

For bots that spoof their user-agent or rotate IP addresses to get around basic blocking, robots.txt and .htaccess both have a ceiling. This is where a CDN or web application firewall earns its keep.

Cloudflare, for example, offers a managed robots.txt feature available on every plan tier that automatically maintains disallow rules for known AI crawlers, plus a separate AI Crawl Control feature for sites that want actual enforcement rather than a polite request — it can block or rate-limit AI bots at the network edge, before they even reach your server. Other CDNs like Fastly and Akamai, along with dedicated bot-management services, offer similar tools.

If you're serious about content protection and your traffic or revenue justifies it, layering a CDN-level block on top of robots.txt closes most of the gap that voluntary compliance leaves open.

Special Case: Blogger and Other Hosted Platforms

If you're publishing on Blogger, Wix, Squarespace, or another hosted CMS, you don't have server-level access for .htaccess — but you're not out of options.

  • Blogger lets you customize robots.txt directly: go to Settings → Crawlers and indexing → Custom robots.txt, enable it, and paste in your AI-crawler disallow rules. You can also set custom robots header tags per post if you want more granular control (for example, noai or noimageai tags where supported).
  • Wix has a built-in Robots.txt Editor under SEO & GEO settings, plus a robots meta tag option per page.
  • For any hosted platform without direct server access, routing your domain through a CDN like Cloudflare (which sits in front of your site regardless of where it's hosted) is the practical way to add enforcement-level blocking.

Decision Framework: What Should You Actually Block?

Not every site has the same goals, so don't just copy a "block everything" list without thinking it through. Use this quick framework:

Your PriorityRecommended Approach
Maximize content protection, don't care about AI-search visibilityBlock all AI crawlers, training and search alike
Stay visible in AI-generated answers (ChatGPT Search, Claude, Perplexity) but stop training useBlock training crawlers (GPTBot, ClaudeBot, CCBot, Bytespider) — allow search crawlers (OAI-SearchBot, Claude-SearchBot, PerplexityBot)
Traditional Google/Bing SEO is your main channel and you're unsure about AILeave Googlebot and Bingbot untouched (they're not AI training crawlers) — block dedicated AI training bots only
Running a monetized content site (ads, affiliate) where scraped content undercuts your trafficBlock aggressively, monitor logs monthly for new bot names, and consider CDN-level enforcement

Common Mistakes to Avoid

  • Blocking Googlebot or Bingbot by mistake. These are not AI training crawlers. Blocking them removes you from search results entirely — a completely different (and far more damaging) outcome than blocking GPTBot.
  • Assuming robots.txt is airtight. It stops well-behaved bots. It does nothing against scrapers that ignore it, which is why layered enforcement matters for anyone serious about protection.
  • Using an outdated crawler list. New AI user-agents appear regularly — Claude-SearchBot, for instance, only showed up as a distinct crawler in 2026. Revisit your list every few months.
  • Blocking everything without checking the referral value first. If a bot like Perplexity's is sending you real traffic, blocking it on principle may cost you more than it protects.
  • Forgetting hosted-platform limitations. If you're on Blogger or Wix, .htaccess rules simply won't apply to you — don't waste time implementing something your platform can't run.

The Pay-Per-Crawl Shift

One development worth watching: some infrastructure providers are now piloting "pay-per-crawl" systems, where AI companies must pay to access content instead of scraping it for free, using HTTP response codes to signal that payment is required before a crawler can proceed. It's early — adoption is still limited — but it signals where the industry may be headed: from binary "allow or block" toward a licensing relationship between publishers and AI companies. Keeping your robots.txt current now puts you in a better position to take advantage of these systems as they mature.

Frequently Asked Questions

Does blocking AI crawlers hurt my Google or Bing rankings? No. Google-Extended, GPTBot, and ClaudeBot are separate from Googlebot and Bingbot. Blocking AI training crawlers has no effect on your traditional search rankings.

Will blocking AI crawlers remove content that's already been scraped? No. Robots.txt and server-level blocking only affect future crawling. They can't retroactively remove your content from a dataset a model has already been trained on.

Is it legal to block AI crawlers? Yes. Robots.txt is an industry-standard opt-out mechanism, and blocking crawlers at the server level is a normal, legal exercise of control over your own infrastructure. This isn't legal advice — if you have specific licensing or IP concerns, consult a qualified attorney.

Do AI companies actually respect robots.txt? Major operators — OpenAI, Anthropic, and Google among them — have publicly committed to honoring robots.txt for their primary crawlers. Smaller, less transparent scrapers may not, which is why layered enforcement exists.

How do I know if AI bots are already crawling my site? Check your server access logs or hosting analytics for user-agent strings like GPTBot, ClaudeBot, Bytespider, or CCBot. Cloudflare and similar CDNs also provide bot-traffic dashboards if you're routed through them.

Should I block AI crawlers on a brand-new blog with little traffic? It's optional but low-risk to do early. Setting your crawler policy from day one is easier than retrofitting it later, and it costs nothing but a few minutes editing robots.txt.

Key Takeaways

  • AI training crawlers (GPTBot, ClaudeBot, CCBot, Bytespider) take content and give almost nothing back in traffic; AI search crawlers (OAI-SearchBot, Claude-SearchBot, PerplexityBot) behave more like traditional search engines and can send referral traffic.
  • Robots.txt is the baseline, industry-standard way to request that crawlers stay out — but it's voluntary and not all bots comply.
  • .htaccess (for self-hosted sites) and CDN/WAF-level blocking (Cloudflare AI Crawl Control and similar) provide actual enforcement against bots that ignore robots.txt.
  • Hosted platforms like Blogger and Wix have their own built-in robots.txt and meta-tag controls — no server access needed.
  • Blocking Googlebot or Bingbot by mistake is the costliest error; make sure you're targeting AI-specific user-agents only.
  • Review and update your blocked-crawler list every few months, since new AI user-agents appear regularly.

Conclusion

Blocking AI web crawlers isn't about being anti-technology — it's about making a deliberate choice instead of an accidental one. With training crawlers now taking far more than they give back, and new bots appearing every few months, a five-minute robots.txt update is one of the highest-leverage changes you can make to protect the content you've worked to build. Start with robots.txt today, layer in stronger enforcement if you need it, and revisit your bot list regularly as the landscape keeps shifting.

Ready to take control of your site's crawler policy? Update your robots.txt file today, and bookmark this guide to check back as new AI crawlers emerge.

Post a Comment

Previous Post Next Post