01
What robots.txt specifies
Applies to marketplace onlyown storefronthybrid
The Robots Exclusion Protocol is published as RFC 9309, a Standards Track document specifying robots.txt syntax, crawler caching expectations, parsing limits, and how an unreachable file is handled.1 The semantics are written down rather than conventional.
Two properties of the document carry further than its syntax. It specifies conformant crawler behavior, so a client that ignores it is non-conformant rather than in breach of anything the document enforces. And it states that the protocol is not a substitute for valid content security measures.1 A path whose exposure matters is behind authentication rather than behind a disallow line.
02
The fetches robots.txt does not govern
Applies to marketplace onlyown storefronthybrid
The operators document this themselves. OpenAI’s crawler documentation states that robots.txt rules may not apply to user-initiated ChatGPT-User fetches.2 Google publishes a separate category for user-triggered fetchers, invoked on a person’s request, and states that these generally ignore robots.txt rules.3
Both describe the same distinction. A client crawling on its own schedule and a fetch made because a person asked a question about a specific page are treated differently, with the second handled closer to a browser request. The consequence for an audit is that reading robots.txt covers scheduled crawling and leaves this category unaccounted for.
| Traffic | Does robots.txt apply? | Where that is stated |
|---|---|---|
| Scheduled crawling | Yes, for conformant clients | The operator’s crawler documentation |
| User-triggered fetch | Documented as generally not | The operator’s own statement |
| Anonymous fetching | Only where the client conforms | Not documented by any operator |
So a robots.txt covering every named AI crawler is a rule set covering those named crawlers, with a documented class of fetches outside its scope.
03
Rules that are not in the file
Applies to marketplace onlyown storefronthybrid
Access decisions are made at several layers, and one of them is a text file readable in a browser. The rest are settings screens.
- Host or CDN bot rules, which can act on categories rather than on named clients.
- Per-crawler allow and block rules, which some infrastructure exposes alongside crawler-activity visibility.4
- Rate limiting, which names no client and produces the same result under load.
- Geographic or ASN restrictions added for fraud reasons and not revisited since.
- Platform-level toggles on hosted storefronts, sometimes labeled as an AI or scraping setting.
Verified-bot machinery sits alongside these. Infrastructure maintaining verification criteria for bots and agents supplies a category that rules can be written against, and the same documentation states that verification places no obligation on a site owner to admit the client.5 The list is an input to a policy rather than the policy.
04
Running the inventory
Applies to marketplace onlyown storefronthybrid
The exercise takes an afternoon and requires no tooling. The output is an inventory of what is currently live, produced before any decision about whether to keep it.
- Fetch the site’s own robots.txt and read every line, including lines nobody in the business wrote.
- For each disallow, name the client it targets and the reason it is there. A rule with no available reason is recorded as such.
- Open the CDN or host bot settings and capture the current state before changing anything.
- Check whether a category-level rule catches clients the seller would admit.
- Confirm that paths whose exposure matters are behind authentication rather than a disallow line.
- Record the result with a date, so the next run has something to compare against.
| Rule found | Where it lives | Stated reason | Current status |
|---|---|---|---|
| Disallow on /search | robots.txt, line 4 | Added during the 2024 load incident | Keep — it covers a bulk path |
| Disallow on /products/ | robots.txt, line 6 | None recorded; arrived with the theme | Blocks the item pages themselves |
| Category block on AI bots | CDN dashboard toggle | No one in the business set it knowingly | Unknown — predates the current account |
| Rate limit, 20 requests a minute | CDN dashboard | Set for checkout, applied site-wide | Wider in scope than the stated reason |
The second row is a rule with no recorded author covering the pages that carry the one-of-one detail. The third stays Unknown until someone with older account access can answer, and recording it as Unknown assigns it to a person rather than leaving it as an unexamined toggle.
05
Classifying what the inventory returns
Applies to marketplace onlyown storefronthybrid
Findings sort into three groups. A rule with a current reason stays. A rule whose reason has ended — an incident two years ago, a theme default — is removed one at a time with a date recorded. A rule that cannot be classified is assigned an owner and a date rather than a guess.
Opening everything is a separate decision from removing a rule nobody set. The cited sources do not state that admitting more clients produces more sales, and unrestricted fetching of a small storefront has costs that are observable directly: bandwidth, rate-limit exhaustion during a sale, and bulk copying of photography and copy.
For a reseller, the product pages are usually the only public record of one-of-one stock and are the pages a shopping surface would read. Where restriction is applied, bulk paths — search result pages, exports, partner feeds — are a different category from the item pages.
06
Re-running it
Applies to marketplace onlyown storefronthybrid
Access configuration changes without producing a visible failure. A plugin update adds a rule, a host changes a default, a limit tightened during an incident stays tightened. A dated inventory is what makes the change visible on the next pass.
The audit is re-run on a fixed schedule and after three events: a platform migration, a security incident, or an operator publishing new crawler documentation. The third is the one specific to this area, since the operator documentation cited here is described as updated over time, and a rule verified last quarter was verified against the text as it then stood.
07
The access rules and where they are documented
Applies to marketplace onlyown storefronthybrid
RFC 9309 specifies robots.txt and states that it is not a substitute for content security measures.1 OpenAI documents user-initiated fetches as possibly outside those rules,2 and Google documents user-triggered fetchers as generally ignoring them.3 Cloudflare publishes verification criteria for bots and agents5 and separate per-crawler controls with crawler-activity visibility.4
Between them these cover what a conformant client does, which fetches fall outside that, and where a site owner’s controls sit. None of them states what a given storefront currently allows, which is what the inventory records.
08
Practice
Exercise
Inventory every access rule on one storefront
- Save your current robots.txt and CDN bot settings to a dated file, unchanged.
- Annotate each rule with the client it targets, the reason, and whether that reason still applies.
- List the paths you would keep restricted even if every client were verified, and confirm each is authenticated.
Check yourself
Every named AI crawler is disallowed. What does that cover?
Scheduled crawling by those clients. Both OpenAI and Google document a class of user-triggered fetches stated not to follow robots.txt, so a person asking about a page can still cause a fetch.
Why is a disallow line not the mechanism for a sensitive path?
Because the standard states the protocol is not a substitute for valid content security measures. The file is publicly readable and names the path, and conformance is a property of the client.
The inventory returns a block nobody can explain. What is recorded?
The rule, an owner, and a date. Removing it on its own keeps the effect attributable; removing it alongside other changes made the same day does not.
Progress is saved in this browser only. No account, nothing sent anywhere.
09
Common questions
How often is this re-run?
On a fixed schedule, plus after a platform migration, a security incident, or new crawler documentation from an operator whose behavior the rules depend on.
Is allowing everything the right setting?
The cited sources do not state an outcome either way. What they do establish is that access is a precondition for a page being read, and the costs of unrestricted bulk fetching are observable on the seller’s own infrastructure.
Does blocking a crawler remove a store from that platform’s results?
It changes what is available to be read. The cited sources do not describe a mapping from access to placement, so the two are recorded separately.
What if robots.txt cannot be edited on a hosted storefront?
Record what is visible, find what the platform sets by default, and note that the file is outside the seller’s control. A constraint recorded is still part of the inventory.
10
Research and sources
Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.
Claim evidence
- RFC 9309 specifies robots.txt syntax, caching, parsing limits, and unreachable-file handling for conformant crawlers, and states that the protocol is not a substitute for valid content security measures.
- technical requirement. Supported by RFC 9309: Robots Exclusion Protocol .
- OpenAI states that robots.txt rules may not apply to user-initiated ChatGPT-User fetches, and Google states that its user-triggered fetchers generally ignore robots.txt rules.
- current external fact. Supported by Overview of OpenAI crawlers , Google user-triggered fetchers .
- Per-crawler allow and block rules and crawler-activity visibility are exposed as infrastructure controls separate from robots.txt, and a verified-bot list is an input to those rules rather than a rule itself.
- current external fact. Supported by AI Crawl Control , Verified bots .
- RFC 9309: Robots Exclusion Protocol Internet Engineering Task Force · Tier D · published Standards Track RFC · RFC 9309
robots.txt syntax, crawler caching expectations, parsing limits, and unreachable-file handling. Limit: Specifies conformant crawler behavior. It binds no operator, and it states explicitly that the protocol is not a substitute for valid content security measures.
- Overview of OpenAI crawlers OpenAI · Tier A · current documentation · unversioned live documentation
Named OpenAI crawlers, their stated purposes, robots.txt behavior, and published IP ranges. Limit: Documents OpenAI’s stated crawler behavior only. It does not establish what any other operator’s client does, and it states that robots.txt rules may not apply to user-initiated ChatGPT-User fetches.
- Google user-triggered fetchers Google · Tier A · current documentation · unversioned live documentation
Google fetchers invoked on a user’s request and their stated robots.txt behavior. Limit: Covers Google’s user-triggered fetchers only. The stated behavior is that these fetchers generally ignore robots.txt rules; it is not a statement about Google’s indexing crawlers or about any other operator.
- AI Crawl Control Cloudflare · Tier A · current documentation · unversioned live documentation
Per-crawler allow and block rules, pay-per-crawl monetization, and crawler-activity visibility on Cloudflare zones. Limit: One provider’s control surface; pay-per-crawl is described as private beta. It establishes what the product can do, not what any given zone is currently configured to do.
- Verified bots Cloudflare · Tier A · current documentation · unversioned live documentation
Cloudflare’s verification criteria for bots and agents, and its Web Bot Auth and IP-validation paths. Limit: Describes one infrastructure provider’s allowlist and its criteria. Verification by Cloudflare is not verification anywhere else, and it confers no obligation on a site owner to admit a verified client.