Guide
How to Check Whether Competitors Block AI Crawlers
The short answer
How do I check whether my competitors block AI crawlers?
Fetch each competitor's /robots.txt and check it against the 11 crawler product tokens with a retrieval stake — GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Googlebot, Google-Extended, bingbot — then tabulate who allows what. It reads public files only, at one HTTP request per domain, and tells you eligibility, never motive.
A competitor's crawl posture is one of the few strategic facts about them that is genuinely public. Every site publishes robots.txt at a fixed path for crawlers to read, so checking which AI crawlers an incumbent allows costs one HTTP request per domain and the time it takes to read one small text file. How long a whole market takes is a function of how many incumbents you list, and we are not going to quote you a number we have not timed.
This page is the method, its single legitimate inference, and the several inferences it cannot support. It reads other people's files; deciding your own posture is a different question, answered in should publishers block AI crawlers, and auditing your own brand's visibility is a different exercise again.
Which product tokens should you look for?
The 11 tokens with a retrieval or training stake, copied verbatim from the platforms' own crawler documentation. Guessing at a token name is the most common way this audit produces a wrong table — a misspelled token matches nothing, and a token nobody publishes does not exist.
| Token | Platform | Documented job |
|---|---|---|
| GPTBot | OpenAI | Crawling web content for model training |
| OAI-SearchBot | OpenAI | Surfacing and linking sites in ChatGPT search results |
| ChatGPT-User | OpenAI | Fetches triggered by a user's request in ChatGPT |
| ClaudeBot | Anthropic | Collecting web content that may contribute to training |
| Claude-User | Anthropic | Fetches triggered by a Claude user's request |
| Claude-SearchBot | Anthropic | Crawling for Claude's search results |
| PerplexityBot | Perplexity | Indexing content for Perplexity's search results |
| Perplexity-User | Perplexity | Fetches triggered by a Perplexity user's request |
| Googlebot | Google's main crawler; builds the index Search draws from | |
| Google-Extended | A control token, not a crawler — governs Gemini training and grounding | |
| bingbot | Microsoft Bing | Builds the Bing index |
Three entries in that table behave unlike the rest. Google-Extended has no user
agent string of its own, so no request will ever arrive under that name — it is
a policy line only, and Google documents that it does not affect Search
inclusion. And the -User tokens are the protocol's gray zone: OpenAI states
robots.txt rules "may not apply" to ChatGPT-User and Perplexity states
Perplexity-User "generally ignores" them, while Anthropic documents Claude-User
as respecting them. A disallow on those two lines is a request, not a
mechanism, and your table should say so.
This checklist is the crawl-posture subset, not the full census — the complete inventory of who fetches what, including tokens outside these 11, is in the complete AI crawler list.
How does robots.txt matching actually work?
A crawler picks the group whose user-agent line matches the product token it declares, and falls back to the wildcard group when no specific group matches. RFC 9309 standardizes that format and the matching rules, including case-insensitive token matching and the most-specific-group-wins behavior.
Three parsing details decide whether your table is right:
- A specific group replaces the wildcard group; it does not add to it. A site
with a permissive
User-agent: *group and a restrictiveUser-agent: GPTBotgroup is blocking GPTBot completely, and a site with a restrictive wildcard group and no GPTBot group is blocking GPTBot too — via the wildcard. - Path rules are prefix-based. A disallow on a section is not a site-wide block, so record "partly disallowed, /section/" rather than flattening it to a yes or no.
- The file is a declaration, not an enforcement mechanism. RFC 9309 defines the format and how conforming crawlers match it; whether a given client obeys it is that client's choice, which each platform states in its own crawler documentation.
Record the fetch date next to every row. Robots.txt is edited without announcement, and a table without a date is an assertion about a moment nobody can identify.
What can you legitimately conclude?
Eligibility, and nothing beyond it. A site that disallows a search-index crawler is not in that engine's retrieval pool for as long as the rule stands — that is the vendors' own documented behavior for their own crawlers, and it is a fact about mechanics rather than a prediction about anyone.
| What the file shows | Sound conclusion | Unsound conclusion |
|---|---|---|
| A search-index token disallowed | That engine cannot retrieve those pages while the rule stands | "They are losing AI traffic" |
| A training token disallowed | That platform's documented training use is declined | "They are invisible in that assistant" |
| Everything allowed | No robots-level restriction exists | "They have an AI strategy" |
| A wildcard disallow on a section | Those paths are excluded for conforming crawlers | "They are hiding something" |
The distinction in the second row is where most competitor analyses fail. OpenAI documents GPTBot and OAI-SearchBot as separate tokens for separate jobs, and Google documents Google-Extended as governing Gemini training and grounding rather than Search. A site can decline training and remain fully retrievable, so "they block AI" is almost always an imprecise reading of a file that says something narrower. The decision logic behind those distinctions is laid out in the robots.txt decision framework for AI.
What must you never conclude?
Motive, and consequences. A robots.txt file records a rule, not a reason: a disallow can come from a licensing negotiation, a legal policy, a server-load decision, a CDN default nobody reviewed, or a contractor's copy-paste. Writing down why a competitor blocks is inventing a fact about a company you have not spoken to, and it belongs nowhere in an evidence file.
Traffic consequences are equally off limits. Cloudflare's crawl-to-click analysis measured crawl-to-refer ratios varying enormously by platform in July 2025 (Cloudflare, 2025), which means the referral value of being crawlable is not a constant you can apply to someone else's site. Nobody controls answer-engine output, so no reading of anyone's robots.txt supports a forecast about their rankings, citations, or traffic — or yours.
Finally, do not publish the table with domains attached. We keep competitor crawl-posture tables internal and describe markets in aggregate, because a page naming a site as "blocking AI" is a claim about that business built on a file that may have changed the same afternoon.
Is a market where incumbents block a better market?
Our reading is yes, and we state it as reasoning rather than as a measured result [our data]. If the established sites in a niche disallow the search-index crawlers, they are not in the retrieval pool for those engines, which changes which sources are available to cite for that market's questions. We use that as one input to niche selection alongside demand and the state of the existing content — never as a projection of what any of it will produce.
The honest caveat, stated because it undermines our own use of the method: retrieval pools are not limited to a niche's obvious incumbents. General publishers, forums, and reference sites answer commercial questions constantly, and none of them appears in a competitor list built from the commercial SERP. A market with a blocked front page can still have a crowded retrieval pool.
Run the audit anyway — it is one request per domain, it uses only files their owners published, and it occasionally explains why a market looks emptier in AI answers than it does in search results. Then treat the output as one page of an evidence file, which is exactly the role it plays in the operating system this library documents.
Frequently asked questions
How do I check whether a competitor blocks AI crawlers?
Fetch their /robots.txt in a browser and look for the documented product tokens — GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Googlebot, bingbot and their siblings. The file is public. Record what you find with the date, because robots.txt changes without notice.
Is reading a competitor's robots.txt allowed?
Yes. Robots.txt is a public file at a fixed path that site owners publish deliberately for crawlers to read, and RFC 9309 standardizes its format. You are reading one small text file per domain, not crawling their site or collecting anything private.
What can you conclude from a competitor's robots.txt?
Eligibility, and only eligibility. A site disallowing a search-index crawler is not in that engine's retrieval pool while the rule stands. You cannot read motive, strategy, or traffic effects from the file, and guessing at them is where this audit goes wrong.
Does blocking GPTBot remove a site from ChatGPT answers?
Not necessarily. OpenAI documents GPTBot and OAI-SearchBot as separate product tokens for separate jobs, so a site can block one and allow the other. Check both tokens before concluding anything about a site's presence in an assistant's answers.
Is a niche where everyone blocks AI crawlers a good opportunity?
That is our reading, and it is reasoning rather than a measured result [our data]. If the incumbents disallow the search-index crawlers, they are not in the retrieval pool for those engines — which changes who is available to cite, and promises nothing about outcomes.
Sources
- Robots Exclusion Protocol — RFC 9309 — IETF
- OpenAI crawlers and user agents — OpenAI
- Does Anthropic crawl data from the web, and how can site owners block the crawler? — Anthropic
- Perplexity crawlers — Perplexity
- Google crawlers and fetchers overview — Google
- Bing Webmaster Guidelines — Microsoft Bing
- The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals — Cloudflare