What WordPress Needs for the Agentic Web

For most of the web’s history, websites were built for simple interactions. A person opens a browser, lands on a page, reads the content, navigates through the site, and clicks on something to complete a task.

For most of the web’s history, websites were built for simple interactions. A person opens a browser, lands on a page, reads the content, navigates through the site, and clicks on something to complete a task.

WordPress®¹ has been incredibly successful in supporting this model. You create posts, pages, custom post types, fields, taxonomies, and blocks, then use a theme or frontend application to present that information to a visitor.

AI agents now require a different way of interacting with that same content.

An agent will never experience a WordPress site the same way a human does. It doesn’t care about the nav menu, hero image, layout, or even the page itself. Instead, it needs to retrieve specific information from the site, compare it with other information, present that context to the human user, and potentially use a tool or API to complete a task for the user.

Cloudflare describes agents as a new kind of visitor to the web and frames the agentic Internet around four concepts: readable, discoverable, callable, and payable. An agent may access the information behind a website without ever seeing the page the way a human visitor would. In many cases, that agent is acting on behalf of a person or organization, but other types of machine traffic, such as crawlers collecting content for model training, may access the same information without a person directly behind each individual request.

This does not mean webpages are going away. Humans still need interfaces, navigation, accessibility, design, and all the other things that make a website useful.

The difference is that the page is no longer the only way your content gets consumed.

For WordPress developers, that brings up an important question:

If AI agents are increasingly responsible for information retrieval and reasoning, what does WordPress need to expose beyond the frontend to support them?

Let’s get stoked and take a deeper look.

How the interaction model is changing

Before getting into WordPress specifically, it helps to understand how an AI agent interacts with information.

Anthropic makes an important distinction between traditional LLM workflows and agents. In an agentic system, the LLM can dynamically decide how to complete a task, including when to retrieve more information, which tools to use, and how to respond to the results of those tools.

A human might interact with a site like this:

Find a page
→ Read the page
→ Navigate
→ Interpret the information
→ Click something
→ Complete a task

An agent approaches the same problem differently:

Find a resource
→ Retrieve relevant information
→ Reason over that information
→ Retrieve more context if needed
→ Select a tool
→ Complete a task

That difference is important.

A webpage gives a human both the information and visual cues needed to understand the content. Labels, page hierarchy, navigation, headings, buttons, and surrounding text all help explain what the content means.

An agent does not need that same presentation layer. It needs access to the underlying information along with enough context to understand what that information represents.

What do we mean by context?

Context gets used a lot when talking about AI, so let’s define what it means.

Anthropic describes context engineering as the process of deciding what information should be available to a model at a given time. More context is not always better. LLMs have limited attention, so adding too much information can make it harder for the model to focus on what actually matters.

The goal is to make the right information available when the agent needs it.

For example, imagine a WordPress site for short-term rental properties.

A human might see something like this on the frontend:

Zilker Park Bungalow
Spacious rental with an open concept layout that will make you feel right at home. 

2 bedrooms make this a great stay for a small family retreat. The primary bedroom includes an en suite bathroom and a beautiful view of the Austin skyline. 

Free WiFi and parking are available to guests, who can end their evenings in a private, secluded 6-person hot tub.

Book your stay today at just $245/night!

That is easy for a person to understand because the page layout, attached images, and surrounding information provide context.

An agent may need something closer to this:

Entity: VacationRental
Name: Zilker Park Bungalow
City: Austin
Region: Zilker
Bedrooms: 2
Price: 245
Currency: USD
Price unit: night
Amenities:
  - WiFi
  - Parking
  - Hot Tub

The information is mostly the same, but the second version makes the structure and relationships more explicit.

For an agent, useful context can include things like:

• What type of entity this is
• What fields belong to it
• How it relates to other entities
• Metadata
• Taxonomies
• Dates and timestamps
• Where the information came from
• What other resources are available
• What actions can be performed

The important thing here is that context is more than the text on the page.

And WordPress already has a lot of this information underneath the frontend.

WordPress already has structured content

It would be easy to say that WordPress was built around pages and, therefore, does not have the kind of structured information AI agents need.

In reality, WordPress already has a strong content model.

Custom post types allow us to define specific types of entities. Taxonomies let us classify and relate content. Metadata gives us additional structured fields. Gutenberg blocks add another layer of structure because individual blocks can define their own attributes, metadata, context, and place within a block hierarchy. Users, media, terms, posts, pages, and blocks all exist as structured pieces of WordPress content that can be exposed beyond the final rendered page.

For example, a property site might already be modeled like this:

Property
├── Title
├── Description
├── Property Type
├── Region
├── Amenities
├── Price
├── Bedrooms
├── Bathrooms
├── Location
└── Rating

The frontend would eventually turn all of that into one property page, but WordPress still knows about each piece of the underlying data.

The WordPress REST API gives external applications another way to access that information by exposing posts, pages, taxonomies, users, and other WordPress data as structured JSON.

WPGraphQL takes this even further by exposing WordPress as an application data graph. Posts, pages, users, terms, and media become nodes, and the relationships between those objects can be queried as connections.

A post, for example, is not just a URL.

It can be represented as:

Post
├── Author → User
├── Categories → Terms
├── Featured Image → Media
└── Related Content → Other Nodes

The block editor also contains more structure than a normal HTML document might suggest. Blocks have their own names, attributes, metadata, context, and relationships. The Block Bindings API can also connect block attributes to underlying WordPress data, such as post meta and taxonomy information.

So WordPress doesn’t need to start from scratch; a lot of the structure agents are seeking already exists.

The next question is whether that structure gives an external agent enough information to understand what the data actually means.

Structure is not the same as meaning

Let’s go back to the property example.

Suppose we have an ACF field called:

price_per_night

with a value of:

245

That is structured data.

WordPress can store it. REST or GraphQL can expose it. And the field name already gives an API consumer useful information: this value represents a price per night.

But there is still some context missing.

What currency is 245 in? Does the price include fees? Is it the normal rate or a discounted rate? What type of entity does this price belong to?

This is where semantics start to become important.

In a previous article, I wrote about ACF and machine-readable content. I used an Austin rental property site to show how ACF fields could be mapped to Schema.org and output as JSON-LD.

Instead of requiring an external system to infer what a field means based on a custom developer-defined naming structure, Schema.org provides a shared vocabulary for describing the entity and its properties.

The progression looks something like this:

Data
245

↓

Structure
price_per_night: 245

↓

Meaning
This field represents the price of a VacationRental.

↓

Context
This is the nightly price for this property,
in this location,
with these amenities.

Schema.org by itself does not make a WordPress site agent-ready, but agents will perform better when we make meaning explicit.

Context also matters when content is retrieved

Even if we structure the content correctly, there is another issue to think about: retrieval.

AI applications often use Retrieval-Augmented Generation (RAG) to search a larger knowledge base, so the model receives only the information most relevant to the current request.

This usually involves splitting content into smaller chunks, creating embeddings, indexing those chunks, and retrieving the most relevant results when someone asks a question.

The problem is that splitting content into chunks can also remove some of the information that makes those chunks understandable.

Anthropic gives a good example of this in its Contextual Retrieval research.

Imagine a retrieved chunk that says:

The company's revenue grew by 3% over the previous quarter.

That information might be correct, but once it is separated from the larger document, we may no longer know which company it refers to, which quarter is being discussed, or which document the statement came from.

The same thing can happen with WordPress content.

Imagine retrieving this:

$245 per night

That value does not mean much on its own.

A more useful result would preserve information like:

Property: Zilker Park Bungalow

Type: VacationRental

Location: Austin, Texas

Price: $245

Price unit: night

This is where WordPress content architecture starts to matter to AI retrieval systems.

Taxonomies, metadata, custom post types, relationships, semantic fields, and content hierarchy can help retrieval systems keep important context attached to the content an agent extracts.

The way we model content in WordPress can directly affect how useful that content is once it enters a semantic search or RAG pipeline.

From retrieving WordPress content to using WordPress functionality

So far, we have mostly been talking about helping an agent find and understand information, but agents can also take actions.

Let’s say an agent understands that a WordPress site contains a vacation rental in Austin.

The next questions might be:

Is this property available?

How much would a three-night stay cost?

Can I reserve it?

Can I cancel the reservation?

On a traditional website, those actions are represented through the user interface.

A human finds a date picker, enters some dates, clicks a button, fills out a form, and continues through the workflow.

An agent can try to operate that interface through a browser, but would have to understand how the frontend works.

Another approach is to expose the underlying capability directly.

Cloudflare describes this part of the agentic web as making sites callable. Today, an agent may have to parse a page, determine which interface controls perform an action, and simulate the same clicks or inputs a human would use. Emerging standards such as WebMCP offer another approach, allowing websites to expose actions as structured tools that agents can discover and call upon.

WebMCP also includes a declarative approach that can turn existing semantic HTML forms into agent-accessible tools. By adding annotations to a standard form, the browser can derive a structured tool definition from the form and its inputs instead of forcing the agent to reverse-engineer an interface.

This is where some of the newer work happening in WordPress becomes really interesting.

The WordPress Abilities API and MCP

The WordPress Abilities API provides a standardized way for WordPress Core and plugins to describe functionality.

An ability can define:

• A unique name
• Description
• Category
• Input schema
• Output schema
• Permission callback
• Execution callback

That means a plugin can describe not only the data it contains but also what it can do.

The WordPress MCP Adapter can then expose those abilities to MCP-compatible AI clients, so an agent can actually use the tool. 

For example, a WordPress plugin could expose specific abilities on our rental site,  like:

get_property

check_availability

calculate_price

create_reservation

When an agent can discover what tools exist and understand what inputs they require, it can call the appropriate one to execute a task.

This adds another layer to the architecture we have been building:

Content
What information exists?

↓

Structure
How is the information organized?

↓

Meaning
What does the information represent?

↓

Context
What information is relevant to this request?

↓

Abilities
What can the agent do?

There is also an important security piece to consider here.

Giving an agent access to a WordPress site should not mean giving it unrestricted control.

The Abilities API includes permission callbacks, and the MCP Adapter documentation recommends using proper WordPress capabilities, dedicated users, scoped permissions, authentication, and care when exposing actions.

The same WordPress permissions model that developers already work with becomes even more important when an AI system takes action on behalf of a user. But permissions are only part of it. 

When an agent can modify content, being able to audit and potentially undo those changes becomes important as well. WordPress revisions provide a built-in way to review and restore earlier versions of content, while activity logging tools such as Stream can provide a broader audit trail of what changed, who changed it, and when. Together, permissions, revisions, and activity logs give developers more visibility and control over actions performed by AI systems.

What could an agent-ready WordPress stack look like?

WordPress has always been about the ecosystem: there are tons of different ways to build the functionality you need. This also means that there probably won’t be one single plugin or API that makes all WordPress sites agent-ready.

Instead, we can think about agent readiness as a set of layers.

WORDPRESS CONTENT

Posts
Pages
Custom Post Types
Taxonomies
Fields
Blocks
Users
Media

        ↓

STRUCTURE

REST API
WPGraphQL
Block Metadata
Schemas
Relationships

        ↓

MEANING

Schema.org Vocabulary
JSON-LD Structured Data Output
Semantic Metadata
Entity Identity
Relationships


        ↓

CONTEXT

Search
Embeddings
Hybrid Search
RAG
Reranking
Just-in-Time Retrieval

        ↓

CAPABILITIES

Abilities API
MCP
Tools
Authentication
Permissions

        ↓

AI AGENT

Discover
Retrieve
Understand
Reason
Act

The important thing about this stack is that none of it requires WordPress to stop doing what it already does well.

We still need posts, pages, blocks, the REST API, and GraphQL.

We still need good frontend experiences for humans.

What changes is that we add, not what we remove. Developers have to start thinking more intentionally about the machine-facing representation of a site’s  content and functionality.

What WordPress developers can start thinking about now

You don’t need to rebuild every WordPress site for AI agents.

Much of the work starts with best practices we already use.

If something is an important concept in your application, consider modeling it as a content entity instead of burying all of its meaning inside arbitrary page markup.

Use custom post types, blocks, taxonomies, fields, and relationships to preserve structure.

Expose that structure through REST, WPGraphQL, or another API when external systems need access to it.

Use semantic metadata where it helps clarify the meaning of that content.

If you are indexing WordPress content for AI search or RAG, think about what metadata and relationships need to travel with each chunk so the content still makes sense after retrieval.

And when an agent needs to perform an action, think about exposing that action as a clear, permission-aware ability instead of expecting the agent to reverse engineer a user interface.

These ideas are useful for more than just agent readiness.

They generally make WordPress applications better structured and easier to integrate with other systems as the web continues to change.

From pages to context

WordPress became one of the foundations of the web by making it easier to publish content for people.

That part of the web is not going away.

People will continue to visit WordPress sites, read articles, browse stores, watch videos, and use interfaces built for humans.

AI agents merely add another way for that content to be consumed and acted upon.

Agents are already retrieving site information, reasoning over its relationships and metadata, and using tools exposed by the site to complete actions for a user, and WordPress already has many of the building blocks they need to make it possible.

The next step is making the structure, meaning, and context behind our pages easier for machines to discover and use.

That does not mean WordPress needs to move away from pages.

It means we need to start thinking about what exists behind the page, and how we expose that context to the next generation of machine users.

1. WP Engine is a proud member and supporter of the community of WordPress® users. The WordPress® trademarks are the intellectual property of the WordPress Foundation, and the Woo® and WooCommerce® trademarks are the intellectual property of WooCommerce, Inc. Uses of the WordPress®, Woo®, and WooCommerce® names in this website are for identification purposes only and do not imply an endorsement by WordPress Foundation or WooCommerce, Inc. WP Engine is not endorsed or owned by, or affiliated with, the WordPress Foundation or WooCommerce, Inc. ↩︎