Should I block AI crawlers like GPTBot in robots.txt?

Last updated: Oct 4, 20265 min read
RockingGEO questions and answers

Usually, do not block AI crawlers as one group. Decide based on what each crawler actually does.

For OpenAI specifically, GPTBot and OAI-SearchBot serve different purposes. GPTBot crawls content that may be used to train OpenAI’s generative AI models. OAI-SearchBot is used to surface websites in ChatGPT Search. That means you can block GPTBot if you do not want your content used for model training, while still allowing OAI-SearchBot so your content remains eligible to appear, be cited, and linked in ChatGPT Search.

AI crawlers and robots.txt: training and AI search are different decisions

The term AI crawler hides several very different functions.

OpenAI currently documents separate user agents for different purposes. GPTBot crawls content that may be used to train its foundation models, while OAI-SearchBot supports ChatGPT’s search features. OpenAI explicitly says the two controls are independent.

So this configuration is possible:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

In this example, you are telling OpenAI that your content should not be crawled by GPTBot for model training, while keeping it accessible to OAI-SearchBot for ChatGPT Search.

That distinction matters for GEO and AI search visibility. Blocking GPTBot does not, according to OpenAI’s current documentation, mean blocking your site from ChatGPT Search. Blocking OAI-SearchBot does: OpenAI says sites opted out of that crawler will not appear in ChatGPT search answers, although they may still appear as navigational links in some circumstances.

Should you block GPTBot?

You can block GPTBot if you do not want OpenAI crawling your site for potential model training.

The important part is understanding what you are opting out of.

OpenAI describes GPTBot as a crawler for content that may be used to make its generative AI foundation models more useful and safe. Disallowing GPTBot signals that your site’s content should not be used through that crawling route for training those models.

Whether that is the right choice is a business and content-policy decision. Publishers whose content itself is the product may reach a different decision from a B2B SaaS company whose priority is broad brand discovery.

From a RockingGEO perspective, access should have a purpose. AI visibility is about making it easier for AI systems to find, understand, retrieve, trust, cite, and recommend your brand. Training access and search/retrieval access contribute to different parts of that ecosystem, so they should not automatically receive the same rule.

Should you block OAI-SearchBot if AI visibility matters?

If visibility in ChatGPT Search is part of your GEO strategy, blocking OAI-SearchBot works against that objective.

OpenAI says publishers should allow OAI-SearchBot if they want their content included in summaries and snippets in ChatGPT Search.

Recent technical SEO guidance reaches the same practical distinction. Search Engine Journal’s September 2026 review recommends treating crawler access as a business decision rather than applying one blanket AI-bot policy, and notes that robots.txt controls depend on the individual crawler’s user agent.

This also fits a broader shift in AI search measurement. Recent research and industry analysis increasingly treats citations, mentions, referral traffic, conversions, and the sources AI systems choose as distinct visibility signals rather than assuming traditional rankings tell the whole story. 

In other words: if you want AI systems to retrieve your content, make sure the crawlers responsible for retrieval can actually reach it.

AI crawler blocking goes beyond GPTBot

OpenAI is only one part of the picture.

Google, for example, provides Google-Extended, a robots.txt token publishers can use to control whether content Google crawls may be used for future Gemini model training and certain Gemini grounding uses. Google states that Google-Extended does not affect inclusion or ranking in Google Search.

This is another reason a blanket block AI bots strategy is becoming increasingly difficult to defend technically. Different user agents can represent training, search, grounding, or user-triggered retrieval, and those functions can have very different consequences for visibility.

Cloudflare has moved in the same direction. In September 2026 it introduced controls intended to let publishers remain discoverable in search while expressing that content should not be used for AI training. 

The useful framework is therefore: Training access → Search/retrieval access → User-triggered access.
Decide what you want for each rather than making one decision for every bot containing the letters “AI.”

robots.txt may not be the only thing blocking your AI crawlers

There is another technical SEO issue worth checking before changing your robots.txt.
Your robots.txt file can say Allow, while your infrastructure effectively says No.

CDNs, WAFs, bot-management systems, CAPTCHAs, JavaScript challenges, and other anti-bot systems can prevent legitimate AI crawlers from reaching a page. OpenAI specifically recommends checking web-protection and bot-mitigation configurations because these systems can return 403 errors or otherwise block its crawlers even when robots.txt permits access. 

So an AI crawler audit should examine more than /robots.txt. Check server logs, HTTP responses, CDN/WAF rules, bot-management settings, and whether the relevant pages can actually be fetched by the crawler you intend to allow.

And remember that robots.txt is a crawler instruction rather than an access-control mechanism. If content genuinely must remain private or inaccessible, authentication and server-level controls are the appropriate tools. Recent technical guidance makes the same distinction: robots.txt depends on crawler compliance, whereas server/CDN/WAF blocking actually prevents access.

AI crawlers, GEO and AI visibility: what should brands do?

For most brands working on GEO and AI search visibility, start with a crawler-by-crawler policy rather than a universal block.

  • Identify the crawler’s purpose. Is it training, AI search/retrieval, or a user-triggered fetch?
  • Keep retrieval/search crawlers accessible when visibility on that platform matters to your business.
  • Make a separate decision about training crawlers such as GPTBot based on your copyright, licensing, content, and business strategy.
  • Audit your CDN and WAF, because an Allow directive is useless if another layer returns a 403.
  • Measure the outcome. Look at AI citations and mentions, referral traffic, conversions, and server logs before deciding whether crawler access is creating business value.

This is very much the RockingGEO approach to technical GEO: AI visibility starts with access, but access alone does not create visibility. Your content still has to communicate clear meaning, connect your brand with the right entities and topics, and build enough authority across your site and third-party sources for AI systems to understand where your brand belongs. That’s why SEO and technical accessibility remain part of the AI visibility stack rather than disappearing from it.

share this answer

have a question of your own?

Ask us anything about SEO, GEO, and brand visibility. We read every question and answer the good ones right here.