--- title: "WordPress is ready for the agentic web, but our ecosystem isn’t" date: 2026-08-27 modified: 2026-08-31 author: "Miriam Schwab" url: "https://miriamschwab.me/wordpress-ready-for-agentic-web/" markdown_url: "https://miriamschwab.me/wordpress-ready-for-agentic-web.md" type: post excerpt: "I gave a talk at WordCamp US about whether WordPress is ready for the agentic web. My answer: core has the plumbing, the plugin ecosystem hasn't shown up yet, and most of the agent-readiness checklist we're all chasing does nothing at all right now." categories: - "Artificial Intelligence" - "WordPress" tags: - "agent-readiness" - "agentic-web" - "ai" - "specification-website" - "wordcamp" - "wordpress" --- On August 19 I gave a talk at [WordCamp US](https://us.wordcamp.org/2026/) in Phoenix called [“The Agentic Web Is Coming – Is WordPress Ready?”](https://us.wordcamp.org/2026/session/the-agentic-web-is-coming-is-wordpress-ready/). The [video is on YouTube](https://www.youtube.com/watch?v=35gk5eWui9E) and the [slides are here](https://speakerdeck.com/miriamschwab/the-agentic-web-is-coming-is-wordpress-ready). In it I look at what it means for a site to be agent-ready, what the technical implementation involves, whether WordPress supports agentic activity, and what impact agent readiness actually has on a site’s performance in AI. https://www.youtube.com/watch?v=35gk5eWui9E Here’s my full talk## Most web traffic is bots now More than half of web traffic is now bots rather than people. Most of that is training, not agents interacting with anything, but regardless, the share keeps climbing. Around 68% of US Google searches end without a click, which we all feel on our sites, and Google AI Mode is somewhere around a billion users with AI query volume roughly doubling. ![Slide showing that 57% of web traffic is now bots, not humans, sourced to Cloudflare Radar in June 2026, next to a Cloudflare Radar chart of bot versus human traffic.](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab.webp)All of this matters for WordPress, and WordPress, with its market share of over 40% of the web, matters for everyone else. Whatever happens to the web happens to us, and at that size, what we do shapes the web back. ## Read, query, act Agent readiness breaks into three things a site needs to support. 1. **Reading** – an agent accessing your content at all. 2. **Querying** – pulling a specific answer out of that content rather than swallowing the whole page. 3. **Acting** – an agent doing something on your site instead of a person. E-commerce is the obvious case here: find me shoes, buy the shoes. ![Slide titled "What does agent-ready mean?" with three cards: Read, Query, and Act.](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-1.webp)Before any of that, though, there’s a fair question: why help AI, if the agents are just going to take my work and answer people without sending them to me (as per the above-mentioned low click-through rate from Google)? It’s a real objection, and blocking agents is a legitimate choice. There are ways to do it, and Cloudflare and others are building models where agents pay for access. The way I see it, it’s a question of relevance. This is the web we have now, and increasingly people find things through AI. If my site isn’t in there, it isn’t anywhere. It also isn’t all or nothing: the specifications let you say what agents may do with your content, so you can allow search and retrieval while refusing training. Being agent-ready doesn’t mean open season: it means you set the terms instead of being invisible. I want the models reading my writing, so that when someone asks about the things I write about, my site is one of the sources. Here’s what that looks like in practice. The Content Signals proposal splits agent access into three separate permissions instead of one blanket yes or no, declared per bot in robots.txt. This is what mine says: ``` User-agent: ClaudeBot Allow: / Content-Signal: search=yes, ai-input=yes, ai-train=no ``` `search` covers appearing in a search index. `ai-input` covers an agent reading the page live to answer someone’s question. `ai-train` covers using the content to train a model. Mine is yes, yes, and no, and I have the same block for GPTBot, PerplexityBot, GoogleOther, and a few others. Almost no provider acts on this signal today, so for now it’s a stated preference rather than an enforced rule. I set it anyway, because opting in later costs nothing, while opting out after a model has already trained on your writing doesn’t undo it. ![Slide reading "Agent-ready doesn't mean open season. It means you're the one setting the terms, instead of being invisible."](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-2.webp)## The AI optimization loop I run on my own site My favorite resource for optimizing my site, both for general best practices and for agent readiness, is [specification.website](https://specification.website), built by [Joost de Valk](https://joost.blog/), the founder of Yoast. It collects the current web specifications, tracks whether each item is required, recommended, optional, or something to avoid, and keeps itself updated as things change. The best part is that it’s also an MCP server, so you don’t have to sit and read it; you can send your agent to read it for you. ![The specification.website homepage, headlined "What a good website does," with a navigation menu that includes an Agent Readiness section.](https://miriamschwab.me/wp-content/uploads/2026/08/Monosnap-The-Website-Specification-2026-08-27-15-54-47-1024x519.webp)That turns site optimization into a loop instead of a checklist you work through by hand, which I wrote about in more detail in [the monthly routine I run on this site](https://miriamschwab.me/monthly-routine-that-improves-site-health/). In my case, Claude reads the specification, connects to my WordPress site through the [WordPress MCP Adapter plugin](https://github.com/WordPress/mcp-adapter), analyzes what’s actually there, finds the gaps, and reports back. I run it as a scheduled routine in Claude Code, and it ranks what it finds by what will help my site specifically, not just by whether the spec says required or recommended. Claude knows my site is a content site, so it doesn’t push me toward things that would cost me valuable time and bring little benefit. ![Slide showing agent readiness as a four-step MCP loop: read the standard, read my site, find the gap, fix it, with an arrow curving back to the start.](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-3.webp)Then Claude can implement the fixes, because my site has the WordPress AI Abilities it needs, thanks to my [MS WordPress Abilities plugin](https://miriamschwab.me/plugins/ms-wordpress-abilities/). Note that running this kind of loop needs ongoing attention and tweaking. I’ve had to re-tune the routine several times when I noticed it doing something slightly off, and I read the reports before approving anything. ## WordPress AI plumbing Since WordPress 7, core has what is needed for this type of workflow: the [Abilities API](https://developer.wordpress.org/apis/abilities-api/), which defines what an LLM can do on a site, and the [MCP Adapter](https://github.com/WordPress/mcp-adapter), which connects that to an agent. (There’s also the [WP AI Client](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/), but it’s more limited for this kind of work, closer to click-here-get-an-alt-tag.) ![Slide titled "WP AI plumbing gives us the tools": the Abilities API registers what a site can do, the MCP Adapter exposes it to outside agents, and the WP AI Client, greyed out, lets WordPress consume AI itself.](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-4.webp)The catch is that core ships only three abilities out of the box, and they’re basic. If you upgrade to 7.0, install the MCP Adapter, and expect magic, the experience can be very underwhelming. While the infrastructure is real, we need to supply the tools that work on top of it and actually make it useful. I built [a plugin for my own site that adds the abilities](https://miriamschwab.me/plugins/ms-wordpress-abilities/) I wanted, and I keep adding to it whenever I hit something I can’t do from Claude Code. At a certain point I [wrapped the WordPress REST API as an ability](https://miriamschwab.me/claude-wp-rest-api-access-with-limitations/), because the ability format on its own is constrained, and I didn’t want any limits on what I can do on my site with an AI agent. Feeling uncomfortable about letting an agent loose on your live site is very reasonable, and it’s a real trade-off. AI is non-deterministic, so the same instruction can produce different results, and even with a lot of guardrails, agents can make decisions you didn’t want. The Abilities API helps here, because part of an ability’s configuration is declaring whether it’s destructive, which tells the agent to be careful with it. In all the time I’ve been using Claude on my site, it has deleted something it shouldn’t have exactly once, and my backup saved the day. In general, it’s a good idea to back up, and test on staging or local first. ## I was excited about being agent-ready, and then I wasn’t I put in a lot of work to make my site agent-ready: markdown versions of every page, llms.txt, the machine-readable references in the head and in robots.txt, and [a contact form rebuilt as a proper API endpoint](https://miriamschwab.me/my-contact-form-is-now-an-agent-ready-api/) with [WebMCP](https://developer.chrome.com/docs/ai/webmcp) support. As a result, my score on Cloudflare’s [isitagentready.com](https://isitagentready.com/) [went from 51 to 86](https://miriamschwab.me/how-i-improved-by-my-sites-ai-readiness-score-from-51-to-86/). (The only reason it’s not higher is that I refused to change DNS records, which would bring no value to my site or its readers and is relatively invasive and risky to do.) Then I tested whether any of these shiny agent-ready features were being used by agents. They mostly weren’t! It turns out that the agents aren’t waiting for us. If they only read sites that had done all this agent-ready stuff, they’d be stuck reading a tiny portion of the web, so they figured out their own way in. When I sent Claude Code to access my site, I watched it announce it was going to use its [WebFetch tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-fetch-tool), and then it went straight for the HTML of my pages, completely ignoring the four places where I reference the existence of .md file versions. It took the HTML and converted it to markdown itself, in milliseconds, preferring that to my files, and then it shaped its version around the question it was trying to answer. When I asked whether it had noticed that my site offers markdown, it said no. I’d think it would prefer my markdowns because they can be around 15 times smaller than the HTML pages they came from, which is the kind of efficiency I assumed a model would want. But nope. My contact form went the same way. I told Claude to reach out to me about speaking opportunities. It found the form API only because it read my blog post about building the API (!), not through any of the signals I’d planted for it. When I pushed it to use the endpoint, it filled in the front-end form instead. It did identify itself as an agent in the submission, which was a nice touch, and it did that because the API asks agents to say so. It clearly didn’t need its own special endpoint or WebMCP implementation – it knows how to fill out forms like the rest of us. Because I had put in all this work to make my form agent-ready, I implemented a thoroughly inelegant workaround, in the hopes that it would lead agents to use the darn thing: I wrote a line on my contact page, in the visible content, practically yelling at the agents to tell them the form is agent-ready, so they should use it! ![Slide reading "Claude takes content very seriously," beside a screenshot of my contact page with a highlighted line telling agents the form is also available as an API.](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-6.webp)My testing led me to realize that LLMs read, and really care about, the actual content on your site. That’s where they look, not llms.txt, not the alternate link headers, and definitely not the four places where I politely pointed them to the files. ## Agent readiness is human readiness In the end, there’s nothing new under the sun, and there’s nothing new under the WWW. It’s the same story it’s been for the last 20 years: build user-friendly, accessible sites and make sure they have stable URLs, clean semantic HTML with a sensible heading structure, structured data, and markup without junk in it. In fact, if you look at the agent readiness checklist on specification.website, you’ll see it has 21 items, and only one is required: stable URLs. Yes, you should have URLs that lead somewhere, just like you always should have since the dawn of the web. That’s it. ![Slide titled "It makes your site better overall" with four cards: stable URLs, clean semantics, structured data, and clean markup, above the line "Bots want what humans want."](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-7.webp)I had a bit of a crisis when I realized this, so I went to discuss it with some of the sharpest professionals in the SEO/GEO space. They said the same thing: the pages that win in agent answers are the ones that are easy to fetch, easy to parse, and easy to trust. Same old, same old. ![Slide titled "Agent readiness is human readiness," quoting that the pages winning in agent answers are easy to fetch, parse, and trust, and naming two common mistakes: treating agent readiness as separate from SEO and accessibility, and writing for the model rather than the reader.](https://miriamschwab.me/wp-content/uploads/2026/08/The-Agentic-Web-Is-Coming-—-Is-WordPress-Ready_-Miriam-Schwab-8.webp)Turns out there are some advantages to making your site agent-ready, not because it helps agents but rather because it helps humans. For example, rebuilding my contact form for agents made it more accessible to people too, and removed its JavaScript dependency along the way. The mistake I was making is the same one people made with SEO: writing for the machine instead of the reader. Make it good for humans and the agents do just fine. The more human-accessible a thing is, the more machine-readable it turns out to be too. This doesn’t mean we should ignore the agent-ready specifications; they’re in progress, and there’s a real chance the big models and browsers will converge on some of them. Several are cheap to implement and harmless to have. If someone flips a switch one day, sites that already did the work will be ready. ## Great questions during the Q&A I always love a good Q&A after I give a talk, and this time the audience really delivered. Someone asked whether we’ll end up writing hidden text for agents, the way screen reader text lives in a span. Probably not hidden, is my guess, because agents strip out everything around the main content when they convert a page. If we do this, it will have to live where humans can see it. On llms.txt, I told the person who asked what I had found: I could not get Claude to see mine. I put it everywhere it’s supposed to go, then put it in the footer twice out of sheer stubbornness, and it still didn’t care. Build it if you like, but it’s more cosmetic than anything else at this point. I liked the comparison someone in the audience made: this is [Google AMP](https://developers.google.com/amp) all over again. Side files drift out of sync with the original pages they represent, so the HTML becomes the source of truth. Same here with markdown files – you have to make sure they accurately reflect the original files. Or we’ll just end up where we did with AMP, going full circle back to good old HTML that works just fine for everyone, whether they’re humans or bots. ## Where the WordPress ecosystem is Our ecosystem, though, is lagging behind. My site has 67 abilities on it. Three come from core. I wrote 41 of them, spread across five plugins of my own. Another 21 come from [Angie, Elementor’s agentic AI plugin](https://elementor.com/ai-page-builder/), which added a large set of abilities in a recent release. From every other plugin on my site, including widely used ones, there are two, both from Yoast. Turn on the Abilities Explorer in your own WP Admin and you’ll probably see a much shorter list. Our ecosystem hasn’t picked this up yet, and adding abilities to a plugin isn’t hard. Doing it means people can manage your plugin through an agent, which is how I now manage most of mine. That gap is also the opportunity. WordPress is 23 years old, which is ancient for software, and this is one of the few moments where the ground is open again. The models know WordPress unusually well because it’s open source and they’ve been trained on all of our code and all of our writing about it. The CMS structure works well. The plugin architecture is a good fit for tools an agent can call. Building AI capability into an existing product, or building something new for the ecosystem, is available to anyone who wants to get ahead now. I built a handful of plugins for myself doing exactly this, and they’re listed at [miriamschwab.me/plugins](https://miriamschwab.me/plugins/) if you want to look. Fair warning: I’m the only person using them, so try them on a local or staging site first, and tell me what breaks.