Agent Experiences

AI Opt-Out Controls

Pick a posture, publish the right signals, and enforce them where enforcement actually happens. Covers robots.txt and Content Signals, Cloudflare's 2026 access categories and Pay Per Use, the licensing standards worth knowing about, and bot verification.

AI Crawling Scale

57.5%
of HTML requests come from bots rather than people
44.5%
of AI crawling is for model training; only about 2.7% is a live fetch on behalf of a user
1,800:1
Anthropic's crawl-to-refer ratio; OpenAI roughly 850–1,300:1, Perplexity 111–186:1, Google about 5:1

Those ratios are the core of the opt-out decision: AI crawlers fetch far more from you than they send back. Training crawlers and search/citation crawlers are separate tokens, though, so you can block one and keep the other.

Dated: September 15, 2026 — Cloudflare's new default

From September 15, 2026, newly-onboarded ad-monetized domains on Cloudflare default to allow Search, block Training and Agent. If you are onboarding a site around that date, you inherit that posture unless you set one yourself.

The trap most people will hit

Several important crawlers serve more than one purpose. Googlebot, Bingbot and Applebot feed conventional search and AI systems, so a broad Training block can catch them too — and quietly cost you ordinary search visibility, which is almost never what a publisher intends. Before you rely on a category default, check how your CDN classifies each mixed-purpose crawler and confirm in your logs that classic search crawlers still get 200s.

Source: TechCrunch, July 1 2026

Reality Check

  • robots.txt is widely respected by reputable crawlers, but not universally enforced.
  • ai.txt and llms.txt are emerging proposals; adoption varies across vendors.
  • Some crawlers may spoof or rotate user-agents. Consider server-side controls and monitoring.
  • "Training" vs. "inference" are different activities—decide which you want to allow or block.
  • Some fetchers ignore robots.txt by design, not by accident: Google documents that Google-Agent (added March 2026) does not consult robots.txt because it acts on a specific user's instruction. ChatGPT-User, Claude-User, and Perplexity-User are in the same category.

robots.txt Is a Request, Not Enforcement

This is the single most common misunderstanding on this topic. robots.txt is a published preference that well-behaved bulk crawlers choose to honor. It is not an access control, and there are two large classes of traffic it does not govern at all.

1. User-triggered fetchers, which are out of scope by design

ChatGPT-User, Claude-User, Perplexity-User and Google's Google-Agent (introduced March 2026) fetch a page because a specific person asked for it. Their operators generally do not treat them as crawlers, and Google documents that Google-Agent does not consult robots.txt by design — not as a bug or an oversight.

A Disallow aimed at these tokens is a statement of preference. Some operators honor it anyway; you should not assume it.

2. Agentic browsers, which carry no bot signal at all

Perplexity Comet, Claude in Chrome and ChatGPT browsing drive a real browser on the user's machine. They present ordinary browser user-agents with no bot identifier at the HTTP layer. There is no token to match, so there is nothing for robots.txt to address.

Any control you build on user-agent strings is blind to this traffic by construction.

Where enforcement actually lives

  • WAF rules at the edge — the only layer that can actually return a 403 or a 402 rather than ask nicely.
  • Rate limits — effective against bulk extraction even when the user-agent is unrecognizable, because volume and access patterns give it away.
  • Bot verification — cryptographic signatures or IP/reverse-DNS checks that confirm a bot is who it claims to be. See Web Bot Auth below.

Treat robots.txt as the public statement of your policy — it is genuinely worth publishing, and honoring crawlers do read it — but pair it with edge controls if the outcome matters to you commercially.

Training vs. On-Demand Fetch

Training Crawlers

  • GPTBot - OpenAI model training
  • ClaudeBot - Anthropic training data
  • Google-Extended - Gemini training/grounding opt-out token
  • Applebot-Extended - Apple AI training opt-out token
  • CCBot, meta-externalagent, Amazonbot, Bytespider
  • • Bulk, systematic crawling; usually respect robots.txt

Search Index & On-Demand Fetchers

  • • Search/citation indexes: OAI-SearchBot, Claude-SearchBot, PerplexityBot, DuckAssistBot
  • • User-triggered fetches: ChatGPT-User, Claude-User, Perplexity-User, Google-Agent, MistralAI-User
  • OAI-AdsBot - OpenAI ads crawler (added January 2026)
  • • User-triggered fetchers may skip robots.txt entirely
  • • Blocking these removes you from AI answer citations, not just training sets

The Cloudflare Regime: AI Crawl Control and Pay Per Use

Cloudflare sits in front of a large share of the web, so its defaults function as de facto policy for many sites. AI Crawl Control has been generally available since August 2025, and customers now send over a billion HTTP 402 (Payment Required) responses a day to AI crawlers. If you are behind Cloudflare, these controls are the most consequential lever you have.

Pay Per Crawl became Pay Per Use (July 1, 2026)

On "Content Independence Day 2," Cloudflare replaced Pay Per Crawl with Pay Per Use. The change is conceptual, not cosmetic: compensation is tied to your content appearing in an AI answer, rather than to the fetch itself. Charging for the fetch never matched the economics — one crawl can serve an unbounded number of answers.

Ceramic.ai and You.com are the early partners, with broader availability promised later in 2026. Treat it as a real but early-stage program, not a revenue line you can plan around yet.

Access control split into three categories

Rather than one on/off switch for "AI," access control is now split by purpose — Search, Agent and Training — available on all plans, including free. This matches how the crawler roster actually works: the same vendor typically runs distinct tokens for training, search indexing and live user fetches.

Most publishers land on allow-Search, decide Agent case by case, and block Training unless they are paid for it.

The robots.txt use parameter

Alongside the category controls, Cloudflare introduced a use parameter for robots.txt with three values — immediate, reference and full — escalating from the narrowest permitted use to the broadest. It is new and Cloudflare-originated rather than an established standard, so check the current definitions in Cloudflare's post before you deploy it, and do not treat it as a substitute for the access controls themselves.

Source: Cloudflare, Content Independence Day: new AI options

Choose a Posture First

Do not start from the config. Start from one question: what is your content worth to you, and where does its value come from? If your business runs on reach, blocking costs you more than it protects. If your content is the product, being an unpaid training input is a straight loss. Four coherent postures follow from that; pick the one that matches your economics, then copy the config.

1. Open — maximize reach

For: documentation, SaaS marketing sites, B2B content, anyone whose content exists to generate demand for something else. Being cited and being trained on both work in your favor. The content is a cost center that pays off downstream.

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

2. Search-only — be citable, not trainable

For: most publishers and most commercial sites. This is the default posture in 2026. You want to appear in AI answers with a link, but you do not want to be absorbed into a model. Note the tradeoff you are accepting: citation crawlers still send far fewer visitors than they take pages.

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

# Training crawlers blocked
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: meta-externalagent
Disallow: /
User-agent: Bytespider
Disallow: /

# Training opt-out tokens (not crawlers)
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /

# Deliberately allowed: OAI-SearchBot, Claude-SearchBot,
# PerplexityBot, DuckAssistBot — these are what put you in
# AI answers with a citation.

3. Licensed — access is available, but on terms

For: news organizations, research publishers, data providers, archives — anyone with content that is expensive to produce and valuable to ingest. You are not trying to disappear; you are trying to get paid. Publish the signal, publish machine-readable terms (RSL below), and enforce at the edge, because none of these files bind anyone on their own.

User-agent: *
Content-Signal: search=yes, ai-input=no, ai-train=no
Allow: /

# Machine-readable licensing terms
License: https://yourdomain.com/license.xml

# Block AI ingestion pending a commercial agreement
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: meta-externalagent
Disallow: /
User-agent: Bytespider
Disallow: /

Pair this with edge enforcement (402 or 403) and, if you are behind Cloudflare, the Training category block. Consider listing in a marketplace — see the licensing section below.

4. Closed — no AI use of any kind

For: subscription products, sensitive or member-only material, sites with a legal or contractual reason to refuse. Understand what you are giving up: you disappear from AI answers entirely, and that channel is growing. Also understand what this file cannot do — user-triggered fetchers and agentic browsers will still reach you, so this posture is only real if you enforce it at the edge with a WAF and authentication.

User-agent: *
Content-Signal: search=yes, ai-input=no, ai-train=no
Allow: /

# Every AI token, both training and citation
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ChatGPT-User
Disallow: /
User-agent: OAI-AdsBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Claude-SearchBot
Disallow: /
User-agent: Claude-User
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Perplexity-User
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: meta-externalagent
Disallow: /
User-agent: Amazonbot
Disallow: /
User-agent: Bytespider
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: MistralAI-User
Disallow: /
User-agent: DuckAssistBot
Disallow: /

# Conventional search left allowed — remove these two lines
# only if you also want out of Google and Bing.
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /

Whichever posture you pick, keep conventional search crawlers explicitly allowed unless you have decided to leave search too. The most expensive mistake in this area is an over-broad AI block that also removes you from Google.

robots.txt Templates

Place at /robots.txt. These examples target common AI-related crawlers. Adjust to your policy.

Block Specific AI Crawlers

# Block AI training crawlers, keep search/citation crawlers
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

# Opt-out tokens, not crawlers: these signal "no AI training"
User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

# Left allowed on purpose — these index you for AI answers and
# citations. Disallowing them removes you from ChatGPT search,
# Claude search, and Perplexity results:
#   OAI-SearchBot, Claude-SearchBot, PerplexityBot, DuckAssistBot

# Allow everyone else
User-agent: *
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

Block All Except Major Search

# Allow conventional search engines only; block AI crawling entirely
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /

User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ChatGPT-User
Disallow: /
User-agent: OAI-AdsBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Claude-SearchBot
Disallow: /
User-agent: Claude-User
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Perplexity-User
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: meta-externalagent
Disallow: /
User-agent: Amazonbot
Disallow: /
User-agent: Bytespider
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: MistralAI-User
Disallow: /
User-agent: DuckAssistBot
Disallow: /

User-agent: *
Disallow: /

Content Signals Policy: Stating Permitted Use, Not Access

The Content Signals Policy is a Cloudflare-originated robots.txt extension introduced in September 2025. It addresses a real gap: Allow and Disallow only express whether a crawler may fetch a page, and say nothing about what it may then do with what it fetched. Content Signals adds that second dimension, so you can let a crawler in while still declaring that training is not a permitted use.

It is live on 3.8 million or more domains, largely because Cloudflare added it to managed robots.txt files by default — so adoption reflects a platform rollout more than a considered choice by each site owner. Three signals are defined:

search

Building a search index and returning results that link back to the source.

ai-input

Feeding your content into an AI model at answer time — the retrieval step behind AI answers.

ai-train

Training or fine-tuning a model on your content.

Syntax

A Content-Signal line goes inside a robots.txt group, alongside the usual Allow/Disallow rules. Each signal takes yes or no; omitting a signal expresses no preference on it, which is different from saying no.

# Content Signals Policy — https://contentsignals.org/
#
# search:    building a search index and providing search results
# ai-input:  inputting content into one or more AI models
# ai-train:  training or fine-tuning AI models
#
# Yes/no here express the site operator's preferences about how
# content may be used after it is accessed.

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

Per-crawler signals

Because it lives in a robots.txt group, you can state different permitted uses for different crawlers — useful if you have an agreement with one vendor and not others.

# Default: citable, not trainable
User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

# A vendor you have licensed to: full permitted use
User-agent: ExampleLicensedBot
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /

What it is and is not. Content Signals is a clear, machine-readable expression of your terms — which matters, because "we never said you could" is a weaker position than "we published that you could not." It is not a technical control and no vendor is obliged to honor it. Publish it because it is cheap and unambiguous, not because it stops anyone.

Specification: contentsignals.org

ai.txt (Emerging)

Place at /ai.txt. The ai.txt file communicates site AI usage policies. It is not a universal standard, but some vendors check it.

# ai.txt — Site policy for AI usage
# Scope: training (model development) vs inference (runtime usage)

owner: Your Company Name
contact: legal@yourdomain.com
policy: https://yourdomain.com/policies/ai-usage

# Explicit preferences
allow: inference
disallow: training

# Notes for crawlers
note: Please respect robots.txt and do not store content for model training.
updated: 2026-08-17

Tip: Keep your policy URL live and human-readable. Log requests to /ai.txt to see which clients check it.

Licensing and Preference Standards, Honestly Assessed

Several efforts are trying to turn "please don't" into "here are the terms." They are at very different stages of maturity, and vendor marketing tends to blur that. Here is where each one actually stands as of August 2026.

RSL (Really Simple Licensing)

Publisher adoption only

A machine-readable licensing vocabulary — think RSS, but for terms rather than content. Version 1.0 was ratified in late 2025, and roughly 1,500 media organizations have endorsed it, including the AP, Yahoo, Reddit, Ziff Davis, BuzzFeed and Vox. That is genuine momentum on the supply side.

The part that matters: as of August 2026, no AI company had signed an RSL payment deal. Adoption is entirely publisher-side. A licensing standard with no licensees is a well-formed offer that nobody has accepted. Publishing RSL costs you little and documents your terms clearly — just do not model revenue from it.

IETF AIPREF

Not deployable today

The IETF's working group on AI content preferences. It has two halves: a vocabulary draft defining the terms, and an attach draft defining how you actually express them on the wire via a Content-Usage header.

The vocabulary draft is on the standards track. The attach draft expired without a newer revision — which means the half that would let you deploy anything is currently stalled. A vocabulary with no attachment mechanism is not something you can implement. Watch it, but do not plan around it, and be skeptical of anyone describing AIPREF as imminent.

IAB Tech Lab CoMP

Public comment, March 2026

The Content Monetization Protocol, released as v1.0 for public comment in March 2026. It inverts the default: content is blocked unless licensed, and an accompanying LLM Ingest API requires commercial terms to be agreed before crawling happens at all. This is the most publisher-favorable proposal on the list and, unsurprisingly, the one furthest from AI-vendor adoption. It is a draft under comment, not something to implement yet.

Microsoft Publisher Content Marketplace

Live, February 2026

The one on this list that is actually operating. Launched February 2026 as a pay-per-use licensing marketplace with Copilot as the first buyer. Participants include the AP, Business Insider, Vox, Hearst and Condé Nast. If you are a publisher of a size that a marketplace will take seriously, this — and Cloudflare's Pay Per Use — are the two live routes from "blocked" to "paid." For everyone else, the practical takeaway is that licensing markets are forming around large rightsholders first.

How to read the state of play. Standards work is moving faster than vendor adoption, which means the reliable move today is still the boring one: publish clear signals (robots.txt plus Content Signals), enforce whatever you actually care about at the edge, and treat licensing standards as positioning for a market that is still being built. Nothing on this list is a substitute for a WAF rule.

Server-Side Controls (Optional)

Add mitigations beyond policy files. Examples shown for Nginx; adapt to your stack.

Block by User-Agent

# nginx.conf
map $http_user_agent $block_ai {
  default 0;
  ~*(GPTBot|OAI-SearchBot|ChatGPT-User|OAI-AdsBot|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Google-Agent|meta-externalagent|Amazonbot|Bytespider|CCBot|MistralAI-User|DuckAssistBot) 1;
}

server {
  if ($block_ai) { return 403; }
  # ... rest of config
}

Rate Limit Suspicious Bots

# nginx rate limit example
limit_req_zone $binary_remote_addr zone=botlimit:10m rate=1r/s;

server {
  location / {
    if ($block_ai) { limit_req zone=botlimit burst=5 nodelay; }
  }
}

Warning: User-agents can be spoofed. Combine with IP reputation, behavior analysis, and WAF rules if this is critical.

Verifying Bots: What Works Now, and Where It's Going

Every user-agent-based rule above shares one weakness: the user-agent is just a string the client chose to send. If your policy has commercial consequences — allowing a paying partner, blocking an unpaid one — you need to verify identity rather than accept a claim.

What you can actually use today

Published IP ranges

The major AI vendors publish JSON files listing the IP ranges their crawlers fetch from, and they generally separate the files by crawler purpose — so you can verify that a request claiming to be a training crawler really came from one.

Fetch these on a schedule rather than hardcoding them; the ranges change. Link them from each vendor's current crawler documentation rather than from third-party copies, which go stale silently.

Forward-confirmed reverse DNS (FCrDNS)

The long-established method for Google, Bing and Apple crawlers. Reverse-lookup the request IP, check the hostname belongs to the vendor's domain, then forward-resolve that hostname and confirm it returns the original IP. The round trip is what makes it trustworthy — a spoofer can control one direction but not both.

# Verify a claimed Googlebot request
host 66.249.66.1
# -> crawl-66-249-66-1.googlebot.com
host crawl-66-249-66-1.googlebot.com
# -> must resolve back to 66.249.66.1

Web Bot Auth: the direction of travel

IP lists and reverse DNS both scale poorly — every site operator maintains their own copy of everyone else's infrastructure. Web Bot Auth replaces that with cryptographic proof: the bot signs its requests, and you verify the signature against a key the operator publishes.

How the mechanism works

  • Requests are signed using RFC 9421 HTTP Message Signatures, with Ed25519 keys.
  • A Signature-Agent header names the domain the signing agent is acting for.
  • That domain publishes its public keys at /.well-known/http-message-signatures-directory, which you fetch and cache to verify against.
  • The result: identity is proven per request, and a spoofed user-agent fails verification immediately — no IP list to maintain.

Standardization status — read carefully

  • The IETF chartered a WEBBOTAUTH working group in 2026, but there is no RFC yet. This is a draft in progress, not a ratified standard.
  • The drafts are still moving: the original architecture draft was superseded by an httpsig protocol draft. Expect details to change before publication.
  • Despite that, it is already deployed in production — Cloudflare, Vercel, Shopify, Akamai and AWS all support it, and OpenAI signs its agent requests. Deployment is running ahead of the paperwork.
  • There is no confirmed Anthropic implementation. Coverage is real but partial, so Web Bot Auth is an additional verification signal today, not a complete one.

Practical guidance: if you are behind a CDN that supports it, turn on verified-bot handling and let the platform track the drafts for you. If you are self-hosting, keep FCrDNS and IP-range checks as your primary verification and treat a valid signature as a bonus rather than a requirement — refusing unsigned traffic today would block most legitimate crawlers.

Monitoring & Verification

  • Log access to /robots.txt, /ai.txt, and high-value content paths.
  • Alert on spikes in known AI user-agents (GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot, ClaudeBot, Claude-SearchBot, Claude-User, Google-Agent, PerplexityBot, Perplexity-User, meta-externalagent, Amazonbot, Bytespider, CCBot, MistralAI-User, DuckAssistBot). Note that Google-Extended and Applebot-Extended are robots.txt opt-out tokens only—they never appear in your logs.
  • Watch for mismatches between user-agent and behavior (e.g., excessive parallel fetches).
  • Document policy changes and include lastmod in your sitemap.xml for transparency.

The Legal Backdrop, Briefly

None of this is settled law, and the most important recent ruling cuts against the assumption that you can freely block agents acting for a user. This is context for your decision, not legal advice — talk to counsel before relying on it.

Amazon v. Perplexity: a user-directed agent is the user acting

Amazon won an injunction on March 10, 2026 blocking Perplexity's Comet agent from shopping on Amazon on users' behalf. The Ninth Circuit vacated that injunction on August 4, 2026, holding that a user-directed agent is the user acting.

Why it matters here: it bears directly on whether blocking user-directed agents is defensible. If an agent fetching a page on someone's instruction is legally that person visiting your site, then blocking ChatGPT-User, Claude-User, Perplexity-User or Google-Agent starts to look less like blocking a crawler and more like refusing a customer who used the wrong browser. That is a very different posture to defend — and it is one reason the Search / Agent / Training split matters: the Agent category is the legally contested one.

Cloudflare v. Perplexity: unresolved

In August 2025 Cloudflare publicly accused Perplexity of stealth crawling — fetching content from sites that had blocked its declared crawlers, using undeclared user-agents. Perplexity disputed the characterization. The dispute was never formally resolved. It stands as the clearest public example of why declared-identity controls are only as good as the operator's willingness to declare, and why the enforcement layer matters.

Training vs. Inference

"Training" means using your content to create or update models. "Inference" means models consult your content at runtime. You may choose to block training but allow inference (or vice versa). Policies and enforcement are evolving—review vendor docs and legal guidance regularly.

References & Further Reading