Agent Readiness: How Publishers Declare AI Policy in 2026

Agent Readiness is the emerging category of publisher-declared AI policy across multiple site surfaces. It covers every place a publisher can tell AI operators what to do with their content: robots.txt Content Signals, AGENTS.md instruction files, llms.txt manifests, 404 recovery blocks, Markdown content negotiation, structured data, and a growing set of MCP-era signals. Both Cloudflare (with its Agent Readiness scanner at isitagentready.com) and SEObolt (with its Agent Readiness Score inside the WordPress admin) use the same category name because the industry has coalesced around it. Here is what the category includes today, what is shipping now, what is coming, and how to declare it on WordPress.

Twelve months ago, the phrase “telling AI bots what to do with your site” meant one thing: setting robots.txt to allow or block GPTBot and ClaudeBot. Today it means something much larger. Publishers now declare AI policy across at least seven different surfaces on their site, and the list keeps growing.

The industry name for this category is Agent Readiness. Cloudflare launched an Agent Readiness scanner at isitagentready.com in April 2026 and now surfaces it inside the Cloudflare dashboard as part of its Diagnostics tool. SEObolt’s Agent Readiness Score ships the same concept as a WordPress admin dashboard covering seven signals. The AGENTS.md project was taken under stewardship by the Linux Foundation’s newly-formed Agentic AI Foundation in December 2025, alongside Anthropic’s Model Context Protocol. Different companies, same category name, converging conclusions about what belongs in it.

This post is the anchor guide to the category. It covers the surfaces publishers can declare on today, the enforcement layers that make declaration matter, what our own SEO research says about which signals actually move the needle, and what appears to be coming next.

The Category Is Real and Multi-Vendor

Three independent references now define Agent Readiness the same way. That convergence matters because it is what turns a marketing phrase into an industry category.

Two of the largest edge providers on the web plus one neutral standards body have independently landed on the same category name. That is what turns a marketing phrase into an industry category. WordPress publishers now have their own first-class implementation via SEObolt’s Agent Readiness Score, a dashboard inside wp-admin that tracks seven declaration surfaces with colored state indicators (green, yellow, red, gray) and one-click activation for the signals under the plugin’s direct control.

The category exists. The name is settled. What is still moving is which specific signals belong inside it and how much each one matters. Adoption is early enough that the answer to “which signals should I ship first?” still depends on your goals, and honest coverage of what actually moves the needle requires acknowledging that some signals have real impact while others are still speculative bets on the future.

Signal 1: Content Signals (robots.txt Directive)

Content Signals is a robots.txt extension published by Cloudflare at contentsignals.org and further documented in Cloudflare’s managed robots.txt docs. It defines a single Content-signal directive that publishers add to their existing robots.txt, declaring per-purpose AI-access preferences.

User-agent: *
Allow: /

Content-signal: search=yes, ai-train=no, ai-input=yes

Three signals, each set to yes or no:

The spec also supports advanced parameters (for example, a use= directive with values immediate, reference, and full for finer-grained control over how allowed content may be consumed) that are documented in the Cloudflare docs but out of scope for the introductory case.

Why Content Signals matters more than the other declaration surfaces right now

Content Signals is the only signal in the Agent Readiness category with an active edge-enforcement layer. On September 15, 2026, Cloudflare rolled out a three-category AI-bot taxonomy (Search, Training, and Agent) that maps one-to-one onto the three Content Signals directives. Sites behind Cloudflare with the older “Block AI Bots” or “Managed Robots.txt” toggles enabled were auto-migrated to the new three-category system.

For publishers, the practical implication is that declaring Content-signal: search=yes, ai-train=no, ai-input=yes in robots.txt combined with setting the matching category controls in the Cloudflare dashboard produces real edge enforcement. Requests from training-focused crawlers get blocked before they reach the origin. See the Cloudflare-and-MCP write-up for the specific failure mode when the Agent-category block hits an unexpected endpoint (mostly relevant for sites running an MCP server).

Signal 2: 404 Recovery Block for AI Agents

When an AI agent fetches a URL that returns a 404 on your site, the default WordPress 404 page tells the agent two things: the requested page does not exist, and here is a wall of theme HTML with no useful recovery information. The agent has no structured way to figure out what URL it should have fetched instead, so it either fails silently, hallucinates a similar URL, or reports back to the user that your site does not have the content it asked about.

A 404 Recovery Block is a semantic markup block emitted on every 404 page that gives the agent an explicit fallback: your home URL, your sitemap URL, and a curated list of recovery pages (typically 5 to 10) that are likely to be relevant substitutes for what the agent was looking for. Agents that parse the block can retry against those URLs or return the recovery list to the user.

SEObolt 2.4.167 ships a 404 Recovery Block for AI Agents feature under 404 Monitor. It emits a semantic recovery <aside> on every 404 page containing the home link, the sitemap link, and up to 10 recovery pages you pick (the plugin also supports auto-suggested recovery based on URL similarity). The output is machine-readable while remaining human-visible, so it works for both audiences without cloaking.

Adoption at the operator level is not yet universal, but the pattern is spreading. The 404 recovery block is one of the signals Cloudflare includes in its Diagnostics tool at the Quick Wins tier, and its inclusion there signals that other tooling vendors expect it to become a table-stakes surface for Agent Readiness in 2026.

Signal 3: llms.txt

llms.txt is a Markdown manifest at yoursite.com/llms.txt that tells AI language models where the important content on a site is and how to describe the business. It was proposed by Jeremy Howard (fast.ai founder) and lives at llmstxt.org. Full walkthrough on how to set one up.

llms.txt has near-universal declaration availability. Every major WordPress SEO plugin now generates one. Every static-site generator has a template. Every AI-forward CMS has support built in. So the practical question is not “how do I ship one” but “does shipping one actually change anything.”

That finding does not mean llms.txt is useless. It means llms.txt is a policy surface, not a citation booster. Shipping one creates a machine-readable record of publisher intent for AI operators who eventually adopt it, and the cost of shipping is trivial (a text file at the site root). Ship it for future-proofing and for the record, but do not expect it to move the needle on today’s AI-answer visibility.

Signal 4: AGENTS.md

AGENTS.md is a plain-Markdown instruction file that lives at the site root (or a repo root) and tells AI coding agents how to work with your project. It was released by OpenAI in August 2025 and adopted rapidly across the AI-coding-agent ecosystem: the spec site reports use across 60,000+ open-source projects.

Where a README explains a project to humans, AGENTS.md explains it to agents. Build commands, test commands, code style conventions, testing frameworks, architectural decisions, and anything else an agent needs to work effectively. Typical structure:

# AGENTS.md

## Build commands
- Install: npm install
- Dev server: npm run dev
- Build: npm run build

## Test commands
- Run all tests: npm test
- Lint: npm run lint

## Code style
- 2-space indentation, no tabs
- Import order: external, internal, relative

## Architecture notes
- All API routes live in /api
- Never import server-side code into /components
- Auth state managed via /lib/auth.ts

On December 9, 2025, the Linux Foundation announced the Agentic AI Foundation (AAIF), which now stewards AGENTS.md alongside Anthropic’s Model Context Protocol (MCP) and Block’s goose. Cross-vendor stewardship under a neutral body is the strongest single signal that a proposed spec is becoming industry infrastructure. AGENTS.md has that; llms.txt does not (yet).

For WordPress publishers, AGENTS.md is not primarily a coding-agent artifact. It is an instructions surface for any AI agent (search, retrieval, MCP-based, or otherwise) that wants to understand how to work with your site. Publishers should adapt the format: instead of build/test/lint commands, use it for site-navigation instructions, content-discovery hints, primary contact endpoints, brand voice guidance, and anything else an AI agent needs to represent your business accurately.

Signal 5: Markdown Content Negotiation

Markdown content negotiation is the pattern where a site serves a Markdown version of a page in response to a request carrying an Accept: text/markdown header, instead of the full HTML representation. AI systems that request Markdown get clean, structured text with none of the HTML markup, CSS classes, navigation chrome, or script tags that carry zero semantic value for machine processing.

Cloudflare released the productionized version of this pattern as Markdown for Agents on February 12, 2026. The feature intercepts requests carrying Accept: text/markdown, fetches the HTML from the origin, converts to Markdown on the fly, and serves the Markdown response. Real usage data shows Anthropic’s infrastructure is a heavy consumer: Claude represents roughly 35% of Markdown-request traffic per public tracking data. Reported 80% token reduction for AI systems that receive the Markdown version versus the equivalent HTML page.

For WordPress publishers on Cloudflare’s Pro / Business / Enterprise plans (Markdown for Agents is not available on the free tier), enabling the feature is a dashboard toggle. For non-Cloudflare sites, implementing the same pattern requires either a plugin that supports content negotiation or a custom rewrite rule in the web server. As of writing, no WordPress SEO plugin ships Markdown negotiation as a first-class feature, so most sites off Cloudflare cannot participate yet.

Additional Agent Readiness Signals

Beyond the five main declaration surfaces above, several supporting signals round out the Agent Readiness category. Most are longer-standing SEO-adjacent concepts that have gained new relevance as AI agents increasingly rely on structured site metadata to represent publishers accurately.

SEObolt’s Agent Readiness Score tracks these signals alongside Content Signals, 404 Recovery, and llms.txt in a single dashboard with colored state indicators and one-click fixes for the signals under WordPress’s direct control. This is the practical answer to the “seven surfaces to manage” problem: one control panel instead of seven separate integrations.

What’s on the Horizon

The Agent Readiness category is still expanding. Cloudflare’s Diagnostics tool now includes signals that most sites do not yet support and that most WordPress publishers do not yet think about. Some are clearly the future; some are speculative bets. Here is what appears to be coming, per Cloudflare’s current diagnostic checklist and public roadmap signals from Anthropic, OpenAI, and the Linux Foundation.

MCP-era declaration surfaces

Agent commerce protocols (further out)

An entire sub-category is emerging around agent-driven commerce: standards for AI agents to inspect inventory, initiate checkouts, and settle payments on behalf of users without human intervention at the transaction step. Cloudflare’s Diagnostics tool lists these as an optional tier because most publishers do not need them yet, but they represent where the category is heading for e-commerce sites. Two protocols have real backers and public specifications as of writing:

• ACP (Agentic Commerce Protocol): Open standard maintained by OpenAI and Stripe, launched September 2025 alongside ChatGPT’s Instant Checkout feature. Covers checkout, payment delegation, cart, feed, and authentication for AI-agent purchases.
• AP2 (Agent Payments Protocol): Open-source protocol from Google, being donated to the FIDO Alliance, with 60+ launch partners. Defines the trust and authorization layer for agent-led payments using cryptographically signed mandates. Complementary to ACP rather than competing.

Additional protocols in this space (x402, UCP, A2A, and several others named in Cloudflare’s Diagnostics tool) are earlier-stage and still consolidating. Publishers running WooCommerce or another e-commerce stack should track ACP and AP2 first because they have the strongest backers, but do not need to implement any of them today. Most WordPress e-commerce plugins have not yet added support. Adoption is likely to concentrate first in enterprise-agent scenarios and publisher paywalls.

The shape of the near future

The pattern across all these emerging signals is consistent: the Agent Readiness category is expanding both vertically (more sophisticated signals within existing surfaces) and horizontally (new surfaces entirely, like commerce protocols). Publishers who ship the core five signals today are well-positioned. Publishers who wait until the category stabilizes will discover that stabilization keeps receding, because the category is inherently in growth mode as long as AI agents keep getting more capable.

How to Declare Agent Readiness on WordPress

Publishers have two paths: manual per-signal setup, or a one-dashboard plugin that manages all the WordPress-controllable signals in one place.

Manual per-signal setup

For each signal, there is a WordPress-native path to enabling it without a dedicated Agent Readiness plugin:

• Content Signals: add a Content-signal: line to robots.txt via the robots_txt filter hook in a child theme or custom plugin. If you have a physical robots.txt file in your webroot, edit that instead (physical file overrides WordPress’s dynamic generation).
• llms.txt: create a Markdown file at your webroot named llms.txt, or use a plugin that generates one. WordPress core does not ship this natively.
• AGENTS.md: create a Markdown file at your webroot named AGENTS.md. The format is documented at agents.md. WordPress core does not ship this either.
• 404 Recovery Block: modify your theme’s 404 template to emit a semantic recovery aside with your home URL, sitemap URL, and a curated list of recovery pages. No WordPress core support.
• Organization schema: use any WordPress SEO plugin that outputs Organization JSON-LD, or add it via a theme hook.
• sitemap.xml: WordPress core generates this since 5.5. No action needed unless you have disabled it.
• Markdown negotiation: not achievable at the WordPress layer alone; requires either Cloudflare’s Markdown for Agents feature (paid tier) or a custom web-server rewrite rule.

The one-dashboard approach

SEObolt’s Agent Readiness Score ships all seven WordPress-controllable signals as a single dashboard inside wp-admin. Each signal has a colored state indicator (green = declared and correct, yellow = present but incomplete, red = missing, gray = not applicable) and a one-click activation for the signals under the plugin’s direct control.

Specifically, SEObolt’s Agent Readiness dashboard covers: Content Signals (via a native robots.txt editor with Service, Ecommerce, and Publisher presets), llms.txt (auto-generated with edit-in-place support), 404 Recovery Block for AI Agents (auto-emits the recovery aside on every 404 page), Organization JSON-LD schema (auto-populated from Local Business data when configured), front-page H1 detection, sitemap presence check, and social profile sameAs chain verification.

The plugin fires an seobolt_agent_readiness_signal_change action every time a signal transitions between states (for example, from red to green), which the built-in activity logger records so publishers have an audit trail of when Agent Readiness posture changed.

How to Enforce Agent Readiness

Declaration and enforcement are different layers. Declaring intent creates a machine-readable record; enforcing intent makes non-compliant bots actually stop. Today, only Content Signals has a real enforcement layer. The other signals in the category are declarations that operate on the honor system, and the enforcement layer for those is expected to emerge over the next 12 to 24 months as edge providers and application-layer plugins catch up.

Edge enforcement (Content Signals only, for now)

For sites behind Cloudflare, setting the Search / Training / Agent category controls in the dashboard to match your Content-signal declaration produces automatic edge enforcement. Requests from AI bots that fall into the blocked categories get stopped before they reach your origin. See the Cloudflare Setup section of the Royal AI Firewall docs for the specific dial-down guidance.

Application-layer enforcement (per-bot detection at the WordPress level)

Royal AI Firewall is a free WordPress plugin that classifies AI bot traffic at the application layer using a bundled catalog of 72 recognized AI bots, cryptographically verifies signed operator requests via Web Bot Auth, tracks whether bots respect declared Content Signals, and lets publishers set a per-bot policy (allow / block / log-only). It complements Cloudflare’s edge layer rather than replacing it: Cloudflare handles the coarse category-level decision at the network, Royal AI Firewall handles the fine-grained per-bot decision inside WordPress and gives publishers a Violations tab showing exactly which bots honored or violated their declared signals over the last 7 days.

The plugin also ships a search-engine guard that keeps verified search crawlers (Googlebot, Bingbot, Applebot, DuckDuckBot) allowed even in aggressive block modes, so accidental over-blocking cannot damage traditional SEO. An optional auto-block engine can escalate any bot that violates the same signal three times within 24 hours; manual per-bot policies always override auto-block decisions.

TL;DR · Agent Readiness Checklist

Ship in this order for a WordPress site starting from zero. Roughly ordered by impact per unit of effort based on 2026 evidence:

1. Content Signals: add Content-signal: line to robots.txt with your chosen values for search, ai-train, ai-input. If on Cloudflare, mirror the settings in the Cloudflare dashboard for edge enforcement.
2. AGENTS.md: create the file at your site root with basic site-navigation and brand instructions. Two-minute task, backed by Linux Foundation stewardship.
3. Organization schema + sitemap + social profiles: use any WordPress SEO plugin. Non-negotiable Agent Readiness hygiene.
4. 404 Recovery Block: install SEObolt or add the recovery aside to your 404 theme template manually.
5. llms.txt: ship for record-keeping and future-proofing. Do not expect citation impact today per our own research.
6. Enforcement layer: install Royal AI Firewall for application-layer per-bot detection. If on Cloudflare, verify the September 15 category controls match your Content Signals declaration.
7. Markdown negotiation: optional; enable if on a paid Cloudflare plan and comfortable with the cloaking debate.
8. MCP Server Card: install Royal MCP if your site should expose tools to Claude, ChatGPT, Cursor, or other MCP clients.

The whole checklist is about 30 minutes of work for a WordPress site if handled via SEObolt’s Agent Readiness Score dashboard plus Royal AI Firewall for the enforcement side, and about half a day if done manually per signal. Either path gets a site to well-declared Agent Readiness posture; the plugin path just centralizes the ongoing management.