Original research · Pre-registered

The robots.txt AI-Blocking Census

How many of the web's most important sites block AI crawlers, and how that's changing — measured directly from robots.txt files rather than quoted from a report with no visible sample.

Several figures already circulate claiming a specific share of sites block AI bots. None of the versions we checked disclosed a reproducible sample. This page is the pre-registration for an independent census that will.

Ritik Namdev Ritik Namdev ·Published September 2026 ·v0 — design stage ·12 min read
The short version

Multiple "X% of websites block AI crawlers" figures are already in circulation. We checked several and none disclosed a reproducible sampling frame — which domains, how many, from when. Rather than add another unsourced number, this page pre-registers a census we can actually run and verify.

Why a census, not another statistic

"What share of sites block GPTBot?" is one of the most commonly asked questions in AI-search technical SEO, and one of the least reliably answered. Reports exist that quote a specific percentage. But tracing them the way the provenance audit traces other claims, the sampling frame, which domains, how many, what date, is rarely stated clearly enough to reproduce or even sanity-check.

That doesn't mean the existing figures are wrong. It means nobody — including us, without doing the work below — is in a position to say whether they're right.

What is actually at stake in this number

A robots.txt blocking rate sounds like a narrow technical curiosity. But it functions as an early indicator for a much bigger, actively unfolding negotiation between publishers and AI companies over how content gets used. A rising blocking rate signals growing publisher resistance. A falling one could signal either resolved licensing arrangements or simple resignation. Getting this number right, tracked consistently over time, matters to more than one audience.

For site ownersA real baseline to compare their own robots.txt policy against, instead of guessing at industry norms.
For AI companiesVisibility into how much of the web is actually opting out, by which crawler category.
For policy discussionsA reproducible number for a debate currently running on unreproducible ones.
For this siteA direct application of the provenance standard argued for elsewhere on this site.

What is currently claimed

Hypothesis

A meaningful and rising share of large sites block at least one major AI crawler. Consistent with the broader publisher-hostility narrative around AI crawl-to-referral economics, but the specific percentage in circulation could not be traced to a disclosed, reproducible sample.

Hypothesis

Blocking correlates with publisher category — news and media sites are widely assumed to block more aggressively than e-commerce or SaaS sites. Plausible, but we found no rigorous cross-category breakdown with a stated method.

Existing figures, compared

Applying the same provenance-tracing method used elsewhere on this site to two figures currently in circulation illustrates exactly the gap this census is meant to close:

ClaimStated sample?Stated date?Grade
Coverage citing a rising share of top sites blocking at least one AI crawlerNot disclosed at the level needed to reproduceApproximate onlyPartial
Coverage citing a specific crawl-to-refer-derived blocking estimateNot disclosedApproximate onlyPartial

Neither source is being singled out as unusually weak — this is the norm for the category, not the exception, which is precisely the point.

Census design

Collection pipeline
  1. 01 Sample domains A published top-N list, stratified by category
  2. 02 Fetch robots.txt Direct HTTP fetch, no cache, dated
  3. 03 Parse directives Per-bot Allow/Disallow, structured
  4. 04 Classify Blocked / allowed / no rule, per crawler
  5. 05 Publish raw CSV of every domain × bot × rule

What a sample row will look like

To make the eventual dataset concrete rather than abstract, here is the shape of a single row, using invented values to illustrate structure only:

domain: example-news.com
category: news
robots_txt_exists: true
last_modified: 2027-01-09
GPTBot: disallow
OAI-SearchBot: allow
ClaudeBot: disallow
Claude-SearchBot: allow
PerplexityBot: no_rule
collected_at: 2027-01-14T00:00:00Z

A dataset of thousands of rows in this shape supports exactly the kind of cross-tabulation — by category, by bot type, by presence of any rule at all — that a single aggregate percentage cannot.

What will be recorded

Per domainDomain, category (news / e-commerce / SaaS / other), whether robots.txt exists at all, and its last-modified date if exposed.
Per crawlerBlocked / allowed / no explicit rule, checked against every bot in the registry.
Sample sizeA stated top-N domain list — the exact N and source will be published alongside the first results, not decided after seeing the data.
Published outputRaw CSV of domain × bot × rule, plus the aggregate report — same standard as the Citation Index.

Why per-bot differentiation matters more than a single blocking number

A single "X% block AI crawlers" figure conceals the distinction this whole site's technical-SEO cluster argues is the most important one in the field. Training bots and retrieval bots are different decisions with different consequences, covered in full in the AI Bot Registry. A domain that blocks GPTBot but allows OAI-SearchBot has made a coherent, defensible choice. That's visible only if the census records per-bot data, rather than a single yes/no "blocks AI" flag.

Hypothesis C4 below is a direct test of whether that kind of differentiated policy is actually common in practice, or whether most site owners are applying an undifferentiated rule regardless of what the registry recommends.

Pre-registered hypotheses

#HypothesisPrediction
C1Training crawlers (GPTBot, ClaudeBot) are blocked more often than retrieval crawlers (OAI-SearchBot, PerplexityBot) on the same domainsSupported
C2News and media domains block at a higher rate than e-commerce domainsSupported
C3Blocking rate has increased since the prior year across the same domain set, re-checkedSupported
C4A large majority of domains apply a uniform "block all AI" policy rather than differentiating by bot categoryNot supported

C4 predicts against the intuitive assumption. Our expectation, unverified until the census runs, is that most site owners either take no action or apply a blanket rule copied from a template — not the differentiated per-bot policy that the registry recommends.

Multiple reports quote a specific percentage of sites blocking AI crawlers. None we checked disclosed a reproducible sample. So instead of repeating one, we're pre-registering a census that will.

Share on X

Schedule

First collection targeted alongside Index v1 in Q1 2027, re-run semi-annually against the same domain list so year-over-year change is comparable rather than an artifact of a different sample.

What this means for publishers, whichever way the numbers land

Suppose C1 and C4 both hold: training bots blocked more than retrieval bots, but most sites still applying an undifferentiated policy. Then a large share of publishers are leaving citation-driving retrieval bots blocked alongside training crawlers they meant to restrict. That's an easily fixable mistake, once the census makes the pattern visible.

Suppose C4 fails instead, and differentiation turns out to be common. That would be a genuinely positive finding about how quickly nuanced technical-SEO guidance has actually been adopted, worth reporting with equal enthusiasm to a null result, consistent with this site's registry of pre-registered null predictions.

Will this cover sites outside English-language, US/EU markets?

Not comprehensively at first. A top-domain list skews toward large, globally-recognized properties, which themselves skew toward English-language and Western markets in most published rankings. Do sites in markets with different data-protection and AI-training regulation apply different blocking policies? That's a genuinely interesting question this initial design can't answer well. It's registered as a candidate expansion for a later edition, not solved here.

Limitations

  • A top-domain list is not a random sample of the web — findings describe large, established sites, not the long tail.
  • robots.txt states policy, not enforcement. Whether a "disallowed" bot actually complies is a separate, harder question — see the registry's behavior section.
  • A domain's robots.txt can change between the census date and when you read this — every figure will carry its collection date.
  • Deliberate vs. default-template rules cannot be distinguished from the file alone, as noted in the FAQ — a genuine measurement gap this design does not close.
How to cite this
Namdev, R. (2026). The robots.txt AI-Blocking Census (v0). Retrieved from https://ritiknamdev.com/blog/robots-txt-ai-blocking-census

Published under CC BY 4.0 — reuse freely with attribution.

Related work on this site

This follows the same discipline as the AI Citation Index — publish the method before the number. See the AI Bot Registry for the crawlers this census will check for.

FAQ

Frequently asked questions

Has this census actually been run yet?
No. This page is the design and pre-registration, published before collection, for the same reason the AI Citation Index is. A census run without a published method invites exactly the cherry-picking this site exists to push back against.
Why not just quote one of the existing "X% of sites block AI crawlers" figures?
Because those figures vary by which crawlers are counted, which domain list was sampled, and when. None of the versions we found disclosed their sampling frame clearly enough to reproduce. That gap is exactly what this census is designed to close.
What domain list will be used?
A published, reproducible top-domain ranking, not an arbitrary or undisclosed list. The specific source will be named at collection time, so the sample itself is checkable.
How is this different from Cloudflare's reporting?
Cloudflare reports request volume and behavior across its own network. This census reads the declared policy, robots.txt, directly from each domain's origin, independent of any single CDN's customer base. A different, complementary measurement.
Will the census distinguish between a deliberate block and a default template setting?
Not directly from the robots.txt file alone, since a rule looks identical whether a site owner wrote it deliberately or copied it from a CMS default. This is registered as a limitation, not solved. A follow-up survey of site owners is a candidate way to address it in a later edition.
Why measure this semi-annually rather than more often?
robots.txt policy changes slowly relative to how often other AI-search metrics move. A monthly re-check would mostly measure noise. Semi-annual re-measurement against the same domain list is frequent enough to catch a real trend without over-sampling a slow-moving variable.
Could this census itself get blocked or rate-limited while collecting data?
Fetching a domain's own robots.txt file is a single, lightweight, publicly-intended request. The file exists specifically to be read by automated clients. So this is a low risk relative to a full-site crawl. But collection will still respect reasonable rate limits, to avoid any appearance of the kind of extractive behavior this site's own research criticizes elsewhere.
Ritik Namdev
Written by

Ritik Namdev

Growth · SEO · GEO

Growth marketer documenting a brand-new site's climb into Google and the AI engines - in public, with real numbers. Every tactic here is tested on real sites before it's published.

The Lab · Weekly

One experiment. Every week.

The field notes in your inbox - one thing I tested, the raw numbers behind it, and what it means for getting cited by AI.

Free forever. Unsubscribe anytime.