There’s a lot of talk about the agentic web, and what it means for both website owners and users. How can we make sure websites are ready for the agentic web, or “agent-ready”, and how will users experience our sites in the new reality?

But first let’s take a step back: what does agent-ready even mean?

Well, it means a lot of things, and its specific technical definition is still very much in flux because it’s such a new space. But you know the saying “there’s nothing new under the sun”? In this case, while AI and agents are new, their basic needs are pretty similar to what we’ve had for twenty years or more:

Machine-readable websites.

Agent readiness does have more requirements than just that, since AI agents read and act on sites differently than bots, but none of that fancy AI stuff can happen if the site isn’t machine readable.

Guess which platform was built almost from day one to offer content in a machine-friendly format?

That’s right – WordPress.

Most of what an AI agent needs from a website, WordPress has been shipping for years, and some of it for over two decades. None of it was designed with agents in mind, but it was designed so that other software could read, find, and write content on a WordPress site without a human in the loop…which is exactly what an agent needs!

I’ve always loved the challenge of building sites that are semantic and well structured so that machines (and therefore screen readers for accessibility) can access them, so this new era with its new challenges is fascinating. I spend way too much time researching and testing agent readiness (I’m a nerd, just to be clear) and the more I look at what the specifications ask for, the more often I’m like “WordPress does that already!” Sometimes it’s been doing it since before most of the people building agents had a website. Or had graduated high school. Or were born. But I digress.

Machine-readable is an open source value

WordPress has so much machine-readable functionality because it’s part of the open source ethos: the idea that your content belongs to you and shouldn’t be locked inside the tool you used to make it. WordPress is licensed under the GPL open source license, which gives you the freedom to run, study, change, and share the software. Portability and agent readiness are the same property seen from two directions: to make a site easy to leave, the content needs to be highly machine-readable so that software can read your posts, categories, authors, and media in a standard format.

A site that’s easy to leave is also easy for an agent to read, because both need content in a format that doesn’t depend on one vendor’s interface. Closed platforms that make leaving hard tend to make agents’ lives hard too. WordPress made content readable so people could truly own it, which proved to lay the groundwork for an ecosystem that was born ready for agents when they came along.

WordPress has talked to machines since day one

WordPress was launched in 2003 as a blogging tool, and blogs thrived on syndication. So every WordPress site got all the RSS feeds you could dream of: a main one at /feed/, a feed for comments, a feed for every category and tag (/category/news/feed/), even a feed for every author (/author/yourname/feed/). That’s a structured, date-ordered list of your latest posts, filtered by category, tag, or author. Anyone can request it without an account or an API key, and an agent doesn’t have to pull your content out of the page’s HTML to read it.

And an agent doesn’t have to scrounge around trying to find all this machine-readable goodness – it’s served to them as soon as they enter the front door. An agent that lands on a WordPress homepage immediately sees the HTML <head> which links to the site’s feeds with rel=”alternate”. That’s discovery: the site announces its own machine interfaces to anything that asks.

Some other machine-readable formats bundled natively in WordPress:

  1. XML Sitemap: since WordPress 5.5, core also generates an XML sitemap at /wp-sitemap.xml, broken down by post type, taxonomy, and author.
  2. robots.txt: the robots.txt file is virtual and filterable, so a plugin (or a few lines of code) can add rules like Content Signals without touching the server (and many do).
  3. oEmbed: WordPress has been an oEmbed provider since 4.4, which means any post can describe itself as a title, author, and embeddable summary to whoever requests it.
  4. Pingbacks: oh the nostalgia. Remember pingbacks? They were machine-to-machine too: one WordPress site telling another “I linked to you” with no human involved.
  5. XML-RPC: XML-RPC let desktop editors and, in 2008, the first WordPress iPhone app publish posts remotely. These were the early 2000s versions of an agent acting on a site, and WordPress built for them because bloggers wanted to post from anywhere and be untethered from the website itself.
  6. Predictable URLs: archives by date, author, category, and tag are built automatically, and permalinks follow predictable rules (/category/news/, /author/yourname/), so an agent can work out where things live without crawling every page.

Every piece of content has a REST API endpoint

The REST API arrived in WordPress 4.7 in December 2016. Posts, pages, media, users, categories, tags, comments, and search all have endpoints under /wp-json/wp/v2/, and they return clean machine-readable JSON instead of HTML an agent has to dig through and parse. Agents find it the same way they find the feeds: every page points to the REST API with a Link header and a <link rel=”https://api.w.org/”> tag.

The API also describes itself clearly for agents. Request /wp-json/ and you get a list of every route on the site, including routes added by plugins. An OPTIONS request sent to any endpoint returns a JSON Schema of the arguments it accepts and the fields it returns. That’s what an agent needs to use a newly accessed API it has never seen before, and WordPress had it built in nearly a decade before anyone was talking about tool definitions for LLMs.

This API is also easy to extend because of how WordPress is built. Almost everything in WordPress is made from the same few building pieces: posts, taxonomies, and metadata. In most WordPress sites, a recipe, a product, an event, a job listing, and a course lesson are all stored the same way: as a post with its own post type, its own categories, and its own custom fields. The REST API is built on those same pieces, so opening one up to agents usually just needs a single argument: register a custom post type or taxonomy with show_in_rest and it gets its own endpoints; register a custom field with show_in_rest and it appears in the JSON right next to the title and content. Site settings work the same way, through /wp/v2/settings.

If an endpoint is missing or needed, a plugin can add its own fields to existing responses with register_rest_field, or create a whole new endpoint with register_rest_route. Either way it inherits core’s authentication, permission checks, argument validation, and self-describing schema without having to build any of it from scratch. That’s how WooCommerce exposes products, orders, and carts, and how Yoast adds each post’s SEO metadata (yoast_head_json) to the standard post response. Core keeps adding endpoints of its own too, and plugins, themes, menus, block types, templates, and global styles all have one now.

Basically, all the data and content in a WordPress site can easily become an endpoint for agents to happily ingest.

Even the content inside a post is structured

The structure goes all the way into the body of each post and page. Since WordPress 5.0, content is saved with block markers in it, like <!– wp:image {“id”:482} –>. Plain HTML already indicates if something is an image, but the marker says which image in the media library it is, with its settings, and it gives things a name that HTML can’t, like an embed, a product price, or a recipe card.

An agent reading a WordPress post gets a list of labeled pieces: this is a heading, this is image 482 from the media library, this is a button that links here. It can pick out one piece to read or change and leave the rest of the page exactly as it was.

Agents can get their own logins with Application Passwords

Application Passwords arrived in WordPress 5.6 in December 2020. They let you create a separate password for each app or agent, use it only for API requests, and revoke it on its own without touching your real login. It’s like this feature was just sitting there waiting for agent connectors!

They also come with a built-in way for an app to ask for access. Instead of you copying and pasting a password, a tool can send you to an approval screen on your own site (/wp-admin/authorize-application.php), where you see which app is asking and click to approve or reject it. If you approve, WordPress creates the password and hands it back to the app. It’s a simple version of the “Sign in with…” flows people know from other services, and it’s been in every WordPress site for years.

Once an app has its password, you can keep an eye on it. Your profile page lists every Application Password with when it was created, when it was last used, and the IP address it was last used from, so you can spot an agent you forgot about, or one that’s being used from somewhere it shouldn’t be. An Application Password also can’t be used to log into wp-admin, and by default WordPress only allows them on sites served over HTTPS, so the password isn’t sent in plain text.

Roles and capabilities keep agents in their lane

Giving an agent access to your site can be scary, since it’s hard to define and enforce what exactly it can and can’t do. WordPress solved a version of this problem a long time ago, for people. A site with lots of writers, editors, and admins needed a way to let each one do their job without being able to break everything else, and that’s what the roles and capabilities system has done since WordPress 2.0 in 2005. And now it’s ready to help guide and control agents.

It works on two levels. Capabilities are individual permissions, like edit_posts, publish_posts, upload_files, edit_others_posts, install_plugins, or manage_options (which controls site settings). Roles are bundles of those capabilities. WordPress ships with five: Administrator, Editor, Author, Contributor, and Subscriber. An Author can write, publish, and upload images for their own posts, but can’t edit anyone else’s posts or touch plugins or settings. A Contributor can write drafts but can’t publish them or upload files.

When an agent connects with an Application Password, it acts as a specific user and gets exactly that user’s capabilities, nothing more. The safest setup is a separate user account just for the agent, rather than giving it access to your own admin login. If none of the default roles fit, you can create a custom role, with a few lines of code or a plugin like Members or User Role Editor, that has exactly the permissions you want. For example, you could create an “AI assistant” role that can edit posts and pages but can’t publish or delete anything.

WordPress capabilities can get pretty granular, which gives you a lot of control over what agents can and can’t do. For example, WordPress doesn’t just check whether a user can edit posts. It checks whether they can edit this post, based on who wrote it and whether it’s already published. On top of that, post statuses like draft and pending give you a built-in human approval step, and revisions mean that if an agent rewrites a page badly, you can roll it back in two clicks. None of this was built with AI in mind, but it’s exactly the kind of control you want over an agent.

Open source means the models already know WordPress

WordPress’s code, its Trac tickets, its developer handbooks, its support forums, and the code of the roughly 70,000 plugins in the WordPress.org plugin directory have all been public for years because sharing code is how the WordPress ecosystem has always worked. So have two decades of published blog posts, tutorials, and Stack Exchange answers about how to do things in WordPress.

Language models trained on all of it. Ask any of them to write a WordPress plugin, register a custom post type, or query the REST API, and they know what to do because they’ve seen thousands of examples. Closed platforms don’t get this: a model can’t learn an API whose docs sit behind a login or whose code is not publicly available. 

WordPress hooks made it easy to add the new AI stuff

WordPress has had actions and filters since version 1.2 in 2004, so almost everything core does can be changed or extended by a plugin. That’s why the agent-specific pieces could arrive quickly and be tested in the wild as plugins first. The Abilities API, which lets a plugin declare what an agent may do on a site (with a clear schema and a flag for whether an action is destructive), started as a plugin and is now in core. The MCP Adapter, which turns those abilities into tools any MCP client can call, is still a separate plugin which is now available for download in the WordPress.org plugin directory.

Our ecosystem was born ready – let’s make the most of it

WordPress has a head start in the agentic era because it was built to be read and written by software long before that software acquired “intelligence” and could think. Now it’s up to the rest of us to extend our own thinking – and our products – to making content and functionality accessible to agents in the most efficient and seamless ways possible.

That’s what we’re already doing at Elementor, and there’s more to come 🙂