robots.txt for Search, Training and Assistant Crawlers: What Each Block Prevents

Contents
robots.txt expresses preferences for automated access. Search indexing, model training and user-requested retrieval are different purposes, but a provider can reuse a crawl for several permitted purposes. A user-agent name describes a claimed role; it does not authenticate a request.
A useful policy starts with the desired result: retaining search visibility, declining specified training uses, or restricting direct retrieval. The relevant product tokens and enforcement methods differ.

Purposes and crawler identities
Googlebot and Bingbot crawl for search. A block can prevent fresh content from being processed and harm visibility, but does not guarantee removal from results within weeks. Known URLs can remain indexed. Restricting unhelpful crawl paths can also be intentional; a production-wide Disallow: / needs careful review.
GPTBot and ClaudeBot support model development. CCBot builds Common Crawl’s public dataset, which also serves purposes beyond training. Google-Extended is a usage-control token covering specified training and grounding uses, not a separate crawler. These services do not necessarily fetch every page or fetch only once.
OAI-SearchBot, PerplexityBot and Claude-SearchBot support search services. ChatGPT-User, Perplexity-User and Claude-User support user-requested retrieval. OpenAI says robots.txt rules may not apply to ChatGPT-User; Perplexity says its user fetcher generally ignores them. Anthropic states that its bots honor robots.txt. These are provider-specific behaviors.
What a block can and cannot change
| Purpose | What the rule addresses | Limits and possible effects |
|---|---|---|
| Search, including AI search | Limits crawling by the selected cooperating search service. | Freshness and visibility can suffer; deindexing is not guaranteed. |
| Training or product use | Signals the specified provider’s training or usage preference. | Effects depend on the token; Google-Extended also covers grounding. |
| User-requested retrieval | Can limit direct retrieval when the service honors the rule. | Provider-dependent: robots.txt is not a reliable universal access block. |
Blocking a training-specific token need not block search. However, “no visibility consequences” is too broad: Google-Extended also controls grounding, and a block cannot guarantee that no copy reaches any training dataset through another source.
Google-Extended is not Googlebot
Google-Extended controls use of crawled content for future Gemini generations powering Gemini Apps and the Vertex AI API for Gemini, plus grounding in Gemini Apps and Grounding with Google Search on Vertex AI. Grounding supplies retrieved information to an answer. Google states that this token does not affect inclusion or ranking in Google Search; that statement does not extend to every Google AI product.
OpenAI separates GPTBot training preferences from OAI-SearchBot search preferences. Opting out of OAI-SearchBot excludes the site from ChatGPT search answers according to OpenAI, although navigational links can remain. ChatGPT-User does not control search inclusion. An allowed crawl does not guarantee a citation or a visit.
Limits of retrospective control
New rules take effect after the service retrieves and processes the file. Cached copies can delay that change. A new disallow is not a command to erase previously collected archives or remove information from an already trained model.
Removal requests and access controls are separate measures. robots.txt alone provides no retrospective deletion guarantee, including for copies obtained through third parties.
llms.txt: content guidance
llms.txt offers a curated Markdown guide to useful content. The proposal’s August 2026 revision also supports files below the site root, such as /docs/llms.txt, covering that path.
The proposal does not require every crawler to use the file and does not define access authorization. Listing a URL neither grants a licence nor overrides robots.txt, authentication or other access controls. The guide needs accurate links and maintenance; creating it does not guarantee better search placement.
Limits of robots.txt
robots.txt is a protocol for cooperating automated clients, not an access-control mechanism. Noncompliant clients and some user-triggered fetchers can still request public content. Sensitive content needs actual authorization checks.
A blocked URL can still appear in search results without a fetched page description. For supported search engines, noindex requests exclusion from indexing, but the crawler must be able to retrieve that directive. Combining a crawl block with a new noindex can prevent its discovery.
Details that change the result
Google-Extended is not an HTTP identity
Google-Extended has no separate HTTP user-agent string. Google uses existing crawler identities and interprets the token as a product-use preference. A server rule matching only “Google-Extended” therefore does not implement that preference. Blocking the real fetching crawler can also affect Search; it is not an equivalent substitute.
CCBot feeds a public archive
Common Crawl identifies its crawler as CCBot/2.0 and documents compliance with robots.txt. Data is available through Amazon S3 under Common Crawl’s terms. The dataset samples the web rather than guaranteeing a complete archive of every site. Blocking individual model-provider crawlers leaves this separate distribution route open unless separately addressed.
Duplicate groups combine their rules
RFC 9309 combines groups matching the same product token, case-insensitively. Within the combined rules, the most specific matching path wins. Two GPTBot groups containing Disallow: / and Allow: /blog/ therefore permit /blog/. Duplicate groups should be reviewed together.
Questions and answers
Does a rule under User-agent: * also apply to a crawler that has its own group in the file?
A matching named group takes precedence over the fallback User-agent: * group; their rules are not merged. An OAI-SearchBot group containing only Allow: / therefore does not inherit the exclusions from the wildcard group.
Common exclusions must also appear in the applicable named groups. The longest matching rule wins; RFC 9309 says Allow should win an equivalent tie. Path matching is case-sensitive as recommended by the RFC, unlike product-token matching.
How can a fetch be confirmed as really coming from Googlebot or ChatGPT-User rather than merely using the name?
The HTTP User-Agent is freely writable. Origin verification should use the provider’s documented method and distinguish the relevant crawler category:
- For Google, reverse-resolve the source IP, check the documented hostname pattern for the relevant crawler category, and forward-resolve that hostname back to the original IP. Domain checks need a real label boundary: evilgooglebot.com is not googlebot.com. A failed check leaves the origin unverified, rather than proving forgery.
- Alternatively, match the source IP to the current official ranges for that specific crawler. Google and OpenAI publish machine-readable lists. An IP in a general cloud range is not sufficient.
For server-side exceptions, verification must precede any trust based on the claimed name. Shared cloud ownership alone does not prove that a request is Googlebot. Behind proxies, the source address also needs to come from a trusted network path.
What happens when robots.txt itself cannot be reached or returns an error?
RFC 9309 permits crawling when robots.txt is unavailable, for example with a 4xx response. For network or server errors it requires complete disallow unless a usable cached policy applies; after a long failure, such as 30 days, treating the file as unavailable is allowed. Cached rules should normally not be used beyond 24 hours, with an exception when robots.txt is unreachable.
Google documents concrete differences: 4xx responses other than 429 mean no crawl restrictions. After a robots.txt server failure, Google initially pauses crawling for 12 hours, then uses the last good file for up to 30 days while retrying; without a cached file, Google assumes no restrictions. Continued failure depends on general site availability. A 403 on robots.txt is therefore not a dependable way to enforce a crawl ban.
Does blocking Google-Extended also affect AI Overviews in Google Search?
Google-Extended does not govern AI Overviews or AI Mode in Search. Googlebot access and Search controls apply there. nosnippet, max-snippet and data-nosnippet limit eligible displayed content; noindex requests exclusion from indexing. These controls can also affect ordinary search presentation. Changes require recrawling and processing.
Sources
- RFC 9309: Robots Exclusion Protocol
- Google Search Central: crawlers
- RFC 8615: Well-Known URIs
- Google Search Central: Google’s common crawlers
- Common Crawl: FAQ
- OpenAI: Crawlers
- Perplexity: Crawlers
- Anthropic: Crawlers
- Google: robots.txt
- Google: AI features in Search
- Google: Crawler verification
- llms.txt proposal, v2