WordPress already has the hard part: the words, the blocks, the authors, the dates, the topics. It has spent more than twenty years helping people publish them.

Now an agent arrives and has to work out where the useful content is, how to find more, and what it is allowed to do. I want WordPress to make those answers obvious.

The work is familiar web work: serve the content cleanly, make it findable, label it well, and give the owner a clear say in what happens next. WordPress is unusually well placed to do it because the content is already there, in a structured form.

Teddy opens a colorful book as helpful little robots follow bright page-shaped paths from a welcoming publishing workshop.

Give every page a Markdown door

An HTML page carries the article along with theme markup, navigation, styles and scripts. Some agents now ask servers for Markdown with Accept: text/markdown. In the versions Checkly tested, three of seven agents sent that header: Claude Code, Cursor and OpenCode. Its own page comparison reported 99.7% fewer tokens for Markdown. Separately, Cloudflare’s own article reports an 80% reduction for the page it measured. Results depend on the page and setup, but those numbers show why offering a clean text version is worth doing. Checkly documents its test and the agents it tested. Cloudflare describes its Markdown measurement.

WordPress should honor that header and offer a .md version for agents that don’t send it. A <link rel="alternate" type="text/markdown"> tag would make the option discoverable. WordPress also has a useful starting point: block content is already structured. Core could add a Markdown rendering path alongside the existing HTML rendering path, instead of trying to reconstruct the blocks from finished HTML. The savings are not a promise for every page; they are a good reason to make the choice available.

An API needs a signpost

WordPress REST API infrastructure entered core in 2015. Public content endpoints followed in 2016. That is a strong foundation, but an agent still needs to know which routes exist and what they can safely do. The 4.4 and 4.7 release notes mark those two steps. The later release added public REST endpoints for content.

The Abilities API and MCP Adapter give WordPress a way to describe and expose capabilities. They are useful plumbing. The current Abilities REST endpoints require authentication, and the MCP setup guide covers authenticated connections. That suits an agent working inside an owner’s site. It leaves a simpler public question unanswered: “What can I read here?” The adapter guide itself recommends read-only abilities for public MCP endpoints. The access rules are documented here. The MCP guide explains the public, read-only pattern.

Core should publish a small, read-only public menu: search, fetch a public post, list terms, and read comments the site has chosen to make public. Put it in a manifest at a predictable address such as /.well-known/wordpress. Include the search route, MCP endpoint if available, Markdown support and the site’s stated AI policy. Let an agent find the front door without getting a key to the house. This is a proposal for discovery; it does not replace the REST API or WordPress permissions.

Teddy points a little robot to a public directory of search, articles, topics and comments while the editor remains safely at work.

Send what the page needs

A page should download what it uses. WordPress already supports loading some block styles only when their blocks appear. A lean-markup option could build on that work: let themes avoid global styles they do not need and keep optional assets out of the page unless its blocks or features call for them. The theme handbook describes on-demand block stylesheets. Core’s style system also combines theme and user settings.

That means less to download and parse, and often a faster page for people too. Make the site lighter and everybody gets the benefit.

Facts belong in the page

WordPress exposes a post’s type, author, dates and terms through its content model and REST API. Breadcrumbs depend on the site’s chosen hierarchy, so they need theme or plugin input. Core could publish the facts it knows as JSON-LD using Schema.org vocabularies, with settings and hooks to avoid duplicate markup when an SEO plugin already emits it. The REST reference lists core post fields. Schema.org documents JSON-LD as one supported format.

Structured facts give search tools and new site interfaces a clearer description of a page. NLWeb, for example, is designed to use sources such as Schema.org and RSS to build natural-language interfaces for websites. Publish the facts once; let more tools use them.

Accessibility is what makes the page make sense

The same basic structure helps people and software make sense of a page: meaningful landmarks, headings in a sensible order, labelled forms, descriptive links and dates marked up as dates. W3C’s guidance explains how good page structure helps people using screen readers, keyboard navigation and other ways of browsing. WAI’s page-structure tutorial is a practical checklist.

That is why the default theme matters. The proposal for WordPress’s next default theme, Ipsum, says every style combination passes WCAG AA; development review is still ahead. That is a testable commitment, not proof that the finished theme or WordPress as a whole meets every accessibility requirement. The proposal describes both the target and its current status.

Teddy and a little robot follow the same clear, welcoming path through an accessible web garden.

Forms can be more than buttons

WebMCP is a draft Community Group report for letting web applications provide tools to AI agents. WordPress search and comment forms would be sensible places to experiment if the draft matures. The declarative form section is still marked TODO, so any form-based feature is especially tentative.

For now, treat it as experimental. The current document is a Community Group draft, not a W3C Recommendation. Core can follow the work and test ideas without promising compatibility with a moving proposal. The draft and its status are published by the Web Machine Learning Community Group.

Owners set the terms

A site owner should be able to state, in plain language, whether agents may read public content, use it for training, or perform actions. Those are different questions, and no single setting can enforce all three across every crawler or model. WordPress could give owners one place to record their choices, publish crawler rules for named bots, and control public abilities separately from authenticated ones. A machine-readable policy would need a defined format and willing clients before it could do more than state intent.

Be honest about the limit: robots.txt is a request to crawlers, not access authorization. If a site allows an agent to act, that should require a separate, scoped permission with an audit trail. Reading a post should never quietly grant permission to change one. RFC 9309 says this explicitly.

RSS still works

RSS is already structured, public and easy to check. WordPress already defaults to full-content feeds; keep that useful default, and make sure themes and plugins do not silently replace it with excerpts. The rss_use_excerpt option defaults to off. Sites should also send accurate ETag and Last-Modified validators and real update dates in sitemaps, so agents and ordinary clients can check for changes efficiently. Those dates must reflect actual changes, not be refreshed just to look active.

It is familiar plumbing, and that is its strength. Feeds and cache validators make the whole web cheaper to use.

Put llms.txt last

WordPress could generate an llms.txt, but it belongs near the end of the list. Anthropic describes using one to point readers toward LLM-friendly documentation. Google says its Search systems do not use the file. Ahrefs found that 97% of the files it observed received no requests during the measured month; that is one dataset, not a verdict on every site. An optional index may help some documentation workflows, but it is not a substitute for accessible pages, feeds or a discoverable API. Ahrefs explains its study’s limits. Google’s position is explicit. Anthropic’s example is here.

The work is already in WordPress

I don’t want WordPress to chase every new agent protocol. I want it to make the web it already publishes easier to read, easier to find and safer to use.

The block tree is there. The REST API is there. Feeds, themes and metadata are there. Core can bring them together so agents can read without guessing and owners stay in control of what agents can do.

Make the page lighter. Make the public routes obvious. Make the meaning accessible to everyone. Keep reading public and actions permissioned. That is a practical, exciting future for WordPress: more people can publish once, and have their work make sense wherever it goes.