Did SEO Die Too? No: It Became the API for Agents

For years, SEO was accused of writing for robots.

The irony is that robots now talk to us, read pages, query tools, combine data, and execute actions. They no longer merely rank links. They are beginning to mediate between a person and almost any digital capability.

A person can say:

Review my transactions from the last quarter, detect unusual spending, and show me in a chart what I should examine first.

The agent does not only need to find a page that explains what a bank transaction is. It needs to discover which system it can query, which accounts it is authorized to read, how to request a date range, what structure each transaction will use, which currency applies, and which part of the information should become an explanation, a table, or a chart.

That is where a new frontier of SEO appears.

Not because pages have stopped mattering. On the contrary: visible content remains the place where a company explains what it knows, what it offers, what its limits are, and why it deserves trust. But an explanation is no longer enough when the user expects the agent to do something.

The capability needs two representations:

1. A visual and conversational representation that lets a person understand, evaluate, and control it.
2. A structured, typed, invocable representation that lets an agent select and use it reliably.

The second representation resembles the SEO of data taken to its operational conclusion: an API, a tool, or an MCP server that does not merely describe what exists, but also what can be done.

The sentence is deliberately provocative. Structured data is not an API, and an API is not SEO. The conceptual leap is elsewhere: both reduce ambiguity so that an automated system can discover meaning, choose an option, and act without having to guess.

In summary

SEO did not die with agents. It split into two complementary layers.

The first is the SEO we already know: useful content, accessible text, clear architecture, descriptive titles, links, authority, structured data, and crawler access. Its purpose is to help systems find and understand a source.

The second is an emerging layer that I propose calling operational SEO: tool contracts, APIs, schemas, permissions, structured results, and actionable errors that let an agent discover a capability, select it, invoke it, and check its result.

A page answers:

What is this, who is it for, and why should I trust it?

A tool answers:

What can I do, with which parameters, under which permissions, and what will I return?

And a generated interface answers:

How can a person understand, explore, correct, or approve what just happened?

The future does not pit content, API, and interface against one another. It forces them to share the same truth.

SEO has always been an interface between two ways of reading

SEO is often reduced to rankings, keywords, or traffic. That reduction hides its most useful function: translating a page so that people and automated systems can understand it at the same time.

A person interprets visual hierarchy, tone, examples, reputation, and context. A crawler needs accessible links, available text, semantic HTML, descriptive titles, relationships between URLs, and signals it can process consistently.

Google defines SEO as the set of practices that help search engines discover and understand content. It also insists that this optimization creates value when it is applied to content made primarily for people, not when content exists to manipulate the system.

That balance matters because it anticipates the current problem.

When we add structured data to a page, we do not create a second, secret reality for the robot. We add explicit clues about the reality the person can also see. Google requires the markup to represent the main content, remain relevant, and avoid describing hidden or misleading information.

The rule can be generalized:

The machine representation should be a more precise expression of the same capability promised to people.

On the classic web, that representation helps classify and present information. In an agentic system, it can also become the contract that enables an action.

The change is not that the agent reads the web: it is that it can continue after reading

A traditional search engine finds a page and hands the next step to the person. The person opens the result, interprets the interface, and performs the action.

An agent can chain together more of the process:

1. Understand intent expressed in natural language.
2. Search for relevant sources or tools.
3. Compare information and constraints.
4. Choose a capability.
5. Prepare parameters.
6. Request authorization when appropriate.
7. Execute a query or action.
8. Turn the result into an explanation or interface.
9. Ask for confirmation before a sensitive change.
10. Preserve evidence of what it did.

Visiting a page is no longer always the final goal. It can become a discovery, trust, or documentation stage within a larger task.

This does not eliminate the web. It changes the destination of part of its traffic: from clicks toward pages to delegations toward capabilities.

The interface stops being only the place where we perform work and becomes the place where we define, supervise, and verify a delegation. SEO is undergoing a parallel transformation: it stops optimizing only the entrance to a page and begins to participate in the legibility of what the agent can do next.

The dual-representation model

A mature digital capability will need two coordinated representations.

1. Visual and conversational representation

This is how a person understands the capability and its result.

It can take many forms:

• An editorial page that explains a service.
• A conversation that summarizes an analysis.
• A table that preserves precision.
• A chart that reveals a trend.
• A map that supports spatial exploration.
• A form for editing several options at once.
• A diff that shows what changed.
• An approval panel that separates reading from writing.

This representation is not decorative packaging. It organizes meaning, reduces cognitive load, and makes it possible to verify what the agent interprets or executes.

Conversation is excellent for expressing intent, requesting a synthesis, and refining a goal. It is worse for comparing twenty values, detecting an anomaly across hundreds of rows, or reviewing the details of an irreversible action. That is why the agentic interface will not be only voice or chat. It will be a dynamic combination of language, controls, and visualizations.

2. Structured and invocable representation

This is how an agent discovers and uses the capability without depending on fragile visual interpretation.

Depending on the system, it includes:

• A stable, action-oriented name.
• A description that explains when it should be used.
• An input schema with types, limits, and allowed values.
• An output schema that preserves structure and meaning.
• Stable identifiers that let the flow continue.
• Authorization and access scope.
• A declaration of effects on data or external systems.
• Actionable errors that allow parameters to be corrected.
• Versioning, availability, and operational limits.
• Metadata that distinguishes reads, writes, and destructive actions.

OpenAI recommends treating names, descriptions, and parameter documentation as product copy: they are the texts that help ChatGPT or Codex decide whether a tool matches the user’s intent. MCP formalizes that surface through name, description, inputSchema, outputSchema, and structuredContent.

This layer is not trying to help the agent “see a button better.” It is trying to prevent the agent from needing to find the button.

Structured data is not the same as an API

It is worth pausing here because the metaphor can be misleading.

Structured data on a page is primarily descriptive. It indicates which type of entity appears, who authored it, when it was published, which properties it contains, or how it relates to other elements.

An API or tool is operational. It defines a possible interaction with a service: what it receives, what it returns, which permissions it verifies, which state it can change, and which errors it can produce.

Layer	Main question	Expected result
Visible content	What does it mean and why does it matter?	Human understanding, trust, and context.
Structured data	Which entity or information does this page describe?	Classification and explicit clues for systems.
API or tool	Which capability can be executed and under which contract?	Repeatable query or action.
Result interface	How can the output be understood, explored, or approved?	Visual evidence and human control.

That is why “structured representation is the SEO of data turned into an API” works as an editorial thesis, not as a technical definition.

The accurate analogy is this:

SEO reduces ambiguity when discovering and understanding content. A tool contract reduces ambiguity when selecting and invoking a capability.

The shift is from descriptive semantics to operational semantics.

From keyword to executable intent

Modern SEO has spent years moving away from literal keyword repetition. A useful page should satisfy an intent, demonstrate knowledge, and provide a useful answer.

Tools for agents take that logic to a stricter level.

A description such as “Gets financial data” is too broad. It does not explain:

• Whether it retrieves balances or transactions.
• Whether it works with one account or all accounts.
• Which period it accepts.
• Whether it returns net or gross amounts.
• Which currencies it can combine.
• Whether the data is real time.
• Whether it only reads or can also modify.
• In which cases it should not be used.

An intent-oriented description would look more like this:

Use this tool when the user wants to analyze spending already recorded in one or more authorized accounts. Do not use it to initiate transfers, modify categories, or estimate future transactions.

The technical equivalent might include a contract like this:

{
  "name": "finance.get_spending_summary",
  "description": "Analyzes recorded spending in authorized accounts within a date range. Read-only; does not initiate payments or modify transactions.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "account_ids": {
        "type": "array",
        "items": { "type": "string" }
      },
      "date_from": { "type": "string", "format": "date" },
      "date_to": { "type": "string", "format": "date" },
      "currency": { "type": "string" }
    },
    "required": ["account_ids", "date_from", "date_to"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "totals_by_category": { "type": "array" },
      "anomalies": { "type": "array" },
      "source_period": { "type": "object" }
    },
    "required": ["totals_by_category", "anomalies", "source_period"]
  }
}

The example does not represent a real banking API. It shows the level of semantic precision an agent needs in order not to confuse analysis with action.

The description attracts the correct intent. The schema prevents improvised parameters. Authorization limits the accounts. Structured output allows the process to continue. The UI turns the result into something a person can review.

The tool catalog is a new results page

A connected agent may have dozens or hundreds of tools available. Given a request, it must decide which one to use, which ones to discard, and whether several tools must be combined.

That problem resembles a miniature search system.

OpenAI proposes evaluating metadata with a set of direct, indirect, and negative prompts. It then recommends measuring precision and recall:

• Precision: when a tool was activated, was it actually the right one?
• Recall: when the tool was necessary, did the agent find and use it?

These metrics belong to information retrieval as much as to product design.

The comparison with SEO helps reveal the parallel, as long as the layers are not confused:

Documentary SEO	Tool discovery
title and H1 describe the page	name and title identify the action
Meta description summarizes relevance	description explains when to invoke
Headings develop the topic	Parameters document scope and limits
Internal links connect content	Relationships and sequences connect tools
Schema.org provides explicit clues	JSON Schema defines inputs and outputs
Canonical URL stabilizes the reference	ID and version stabilize the contract
Robots and sitemap control discovery	Registry, permissions, and availability control exposure
Search Console reveals performance	Evals and analytics reveal selection and failures

This is not “SEO for tricking the model.” It is information architecture that prevents the model from having to guess.

Discover, understand, invoke, and verify

The complete journey of an agentic capability can be summarized in four verbs.

Discover

The agent needs to locate a candidate source or tool.

On the web, that still depends on crawling, indexing, links, sitemaps, accessible text, and crawler permissions. Google says existing SEO practices continue to apply to AI Overviews and AI Mode, and that no special file or exclusive schema is required to appear in those experiences.

OpenAI distinguishes OAI-SearchBot, used to surface sites in ChatGPT search features, from GPTBot, which is related to training. This confirms that accessibility to search systems remains a concrete technical decision, not an abstraction.

Understand

Finding a URL is not enough. The agent must identify what the source claims, with which evidence, on which date, and in which context.

Original content, authorship, clear definitions, tables, HTML semantics, dates, references, and consistency between visible text and structured data all matter here.

Quality content is not a leftover from the pre-agent era. It is the foundation from which the agent builds an answer, compares sources, or decides whether a capability is appropriate.

Invoke

When a repeatable action exists, the agent needs a stricter contract than a page.

OpenAPI defines a standard description that lets people and systems discover and understand HTTP capabilities. MCP exposes tools with input and output schemas. Structured results allow steps to be chained without extracting information again from prose or pixels.

Invocation adds dimensions that classic SEO did not have to resolve directly:

• Identity.
• Authorization.
• Scope.
• Side effects.
• Idempotency.
• Usage limits.
• Errors and recovery.
• Human confirmation.

Verify

The agent may have called the right tool and still produced the wrong conclusion.

Valid JSON does not guarantee that its values are true. OpenAI warns that Structured Outputs may conform to a schema and still contain errors within values. A schema guarantees form; evidence, validation, and review sustain meaning.

That is why the last layer becomes human again: showing sources, period, filters, assumptions, anomalies, changes, and actions awaiting approval.

What agents show us is also UX, and it is also SEO

The agent does not only need to read better. It also needs to decide how to return what it found.

A spoken response may be enough for:

This month you spent 18% more on software than your average over the previous six months.

But a person may need to verify:

• Which subscriptions make up the increase.
• Which months were compared.
• Whether the amount includes taxes.
• Which account produced each charge.
• Which categories were inferred.
• Which transactions remained unclassified.
• Which action the system recommends and why.

That is where the interface generated or selected by the agent appears.

MCP Apps allows tools to deliver charts, forms, and dashboards inside a conversation. OpenAI recommends adding UI when people need to inspect, compare, edit, confirm, or navigate structured information. It also proposes separating tools that retrieve or process data from those that render the final presentation.

That separation is fundamental.

The data tool should return a precise, reusable representation. The agent can analyze it, combine it, or filter it. Only then does it choose an appropriate view: chart, table, map, form, diff, or confirmation card.

The UI is no longer necessarily a fixed screen everyone enters through. It becomes a contextual evidence view, built for the specific question.

Content, data, and interface remain connected:

• Content explains the capability before it is used.
• The schema allows it to be executed without ambiguity.
• Structured data preserves precision throughout the flow.
• The interface makes the result understandable and controllable.
• Conversation connects everything to the original intent.

An example: “review my accounts and show me what I need to see”

Imagine a person saying that sentence to their computer.

A well-designed system should not begin by opening random tabs and reading numbers from the screen as its only strategy. It could follow a flow like this:

1. Identify that the request concerns analysis, not a transfer.
2. Show which financial sources are connected and ask for scope when several exist.
3. Invoke a read-only tool to retrieve authorized accounts.
4. Query transactions with dates, currencies, and stable identifiers.
5. Normalize categories without modifying the original record.
6. Calculate trends and flag anomalies using explicit criteria.
7. Preserve the period and sources inside the structured result.
8. Choose an appropriate visual representation.
9. Summarize the two or three main findings by voice.
10. Let the person open every category or transaction from the chart.
11. Separate any later action—such as canceling a subscription—into a write tool with its own confirmation.

The person receives a simple experience: a conversation and a chart.

Underneath sits a complex architecture: focused tools, permissions, schemas, sources, calculations, states, and traceability.

Good design does not mean hiding that complexity completely. It means showing the necessary part at the right moment.

The same source of truth must feed the page, tool, and interface

The greatest risk in this model is creating three incompatible versions of the business:

1. The commercial promise on the page.
2. The technical contract in the tool.
3. The system’s actual behavior.

I propose calling this the semantic parity triangle.

Vertex	What it should express	Typical failure
Visible promise	What it solves, for whom, with which limits and evidence.	Marketing promises real-time data, but the data updates once a day.
Structured contract	Inputs, outputs, permissions, effects, errors, and scope.	The description says “read-only,” but the endpoint can modify state.
Actual behavior	The operation and result the system executes.	The output omits currency, time zone, or source and produces a misleading visualization.

Consistency should not be maintained by manually copying text between a CMS, documentation, and code. Whenever possible, the representations should derive from a shared source of truth:

• A canonical capability catalog.
• Versioned data types.
• Stable IDs.
• Centralized authorization policies.
• Verifiable usage examples.
• Shared business definitions.
• Contract tests.
• Tool-selection evals.
• Parity checks between content and behavior.

SEO, design, and engineering stop being separate phases. They participate in the same semantic architecture.

What operational SEO is

Operational SEO is not an existing standard. It is a framework for naming an emerging responsibility.

I define it this way:

Operational SEO is the design of content, metadata, schemas, and contracts so that agents can discover, understand, select, invoke, and verify a digital capability without sacrificing clarity, trust, or human control.

It does not replace technical or editorial SEO. It extends them when a page represents an executable capability.

A company does not need to turn every article into a tool. An opinion, research piece, or story can remain content. The operational layer makes sense when a repeatable, authorizable result exists:

• Check availability.
• Calculate a rate.
• Retrieve an order.
• Analyze transactions.
• Create a booking.
• Prepare an estimate.
• Update a record.
• Generate a report.
• Open a support incident.
• Schedule a meeting.

The practical question is:

After understanding this page, is there a concrete capability the user will want to delegate?

When the answer is yes, designing its invocable representation probably makes sense.

The maturity matrix: page, contract, and action

We can classify a capability according to the representations available.

Human representation	Invocable contract	State of the capability
Yes	No	Understandable, but the person must still execute manually.
No	Yes	Operable through integration, but opaque and hard to assess or govern.
No	No	Invisible capability or one that depends on internal knowledge.
Yes	Yes	Delegable capability: it can be understood, invoked, and verified.

The last category is not automatically good. It also needs authorization, security, observability, and recovery. An agent should not be able to act merely because it found an endpoint.

As I explain in Controlling AI Agents Like Codex in the Work Environment, instructions and annotations do not replace technical controls. Permissions must be enforced on the server, sensitive actions must be separated, and the person must retain the ability to review and revoke.

How the work of SEO, UX/UI, and development changes

SEO stops ending at the page

SEO professionals will continue working with intent, architecture, content, semantics, indexing, links, authority, and measurement.

But for agentic products, they will also need to collaborate on:

• Capability taxonomies.
• Tool names and descriptions.
• Differentiation between similar operations.
• Positive and negative activation examples.
• Consistency between promise, schema, and result.
• Discovery in tool catalogs.
• Precision and recall evals.
• Semantic versioning of capabilities.

It is a natural evolution. Writing a tool description is not so different from writing a title and meta description: both condense meaning to help a system choose. The difference is that a bad tool choice can modify data, send a message, or spend money.

UX/UI designs evidence and control

The designer no longer works only on the interface before the action. They also design what happens after delegation:

• How scope is expressed.
• How sources are shown.
• How results are compared.
• Which visualization fits each data type.
• When a textual answer is enough.
• When a form or dashboard is necessary.
• How confirmation is presented.
• How a task is interrupted or reversed.
• How an inference is distinguished from an observed fact.

The interface may be ephemeral and generated for one specific request, but its principles cannot be improvised every time.

Development turns internal functions into product contracts

Not every internal endpoint should be exposed as a tool. OpenAI recommends starting from the user’s objective and grouping coherent operations, while separating reads from writes and actions with different levels of risk.

The work includes:

• Modeling explicit inputs and outputs.
• Returning stable IDs.
• Avoiding text blobs when the result must be reused.
• Designing errors that allow correction and retry.
• Enforcing real authorization.
• Declaring and testing side effects.
• Maintaining compatibility and versioning.
• Separating data processing from rendering.

In An LLM Predicts Tokens; an Agent Executes Tasks, I explain that an agent’s value does not come only from the model, but from the system around it. The tool contract is one of those decisive layers.

How to measure this new SEO

Ranking alone does not describe agentic visibility.

It is useful to measure three levels.

1. Documentary discovery

• Crawlable and indexed pages.
• Sitemap coverage.
• Impressions and clicks.
• Traffic from search engines and assistants.
• Queries in which the source appears.
• Content freshness and accessibility.
• Consistency of structured markup.

2. Selection and invocation

• Tool-selection precision.
• Recall for relevant prompts.
• False activations on negative prompts.
• Argument validity.
• Percentage of successful calls.
• Retries caused by schema or business errors.
• Time to complete the task.
• Correct use of read versus write operations.
• Execution cost.

3. Human understanding and control

• Time required to verify the result.
• Ability to locate the source of a data point.
• Confirmation errors.
• Reversed actions.
• Requested corrections.
• Understanding of limits and permissions.
• Satisfaction with the visual representation.
• Incidents or unwanted actions.

The unit of success is no longer only a visit. It can be a task completed correctly, understandably, and reversibly.

What not to do

Create “agent content” that does not help people

Google maintains a clear position: SEO practices are useful when applied to helpful, people-first content. The arrival of agents does not justify producing empty pages, repeated definitions, or text designed only to appear inside a generative answer.

Treat llms.txt as a magic solution

Some sites publish model-readable indexes, and they may be practical as documentation. But Google says there is no need to create new “AI text” files or special markup for its AI features. An auxiliary file does not replace accessible content, links, architecture, crawler permissions, or a well-designed API.

Copy the internal API without thinking about the objective

A tool with twenty modes and ambiguous parameters forces the model to guess. Capabilities should be designed from the result the person expects, not from the convenience of the existing backend.

Return only prose when the data will be reused

A paragraph may be pleasant to read, but it loses IDs, types, units, and relationships. The structured response should preserve precision; conversation can summarize it afterward.

Show a chart without exposing its provenance

A convincing visualization can hide filters, periods, or excluded data. The UI should make it possible to trace the result back to its sources and assumptions.

Trust the schema as a guarantee of truth

The schema validates form, not necessarily meaning. Business validation, evidence, tests, and risk-proportionate review are still required.

Let the description substitute for authorization

Calling a tool read-only does not make it technically read-only. Restrictions must be enforced through real permissions, endpoints, and policies.

A practical architecture for agent-readable capabilities

An organization can begin with seven layers.

1. Canonical page: explains the capability, audience, limits, examples, sources, and evidence.
2. Technical SEO: ensures accessible text, semantics, links, canonical URL, sitemap, performance, and crawling policies.
3. Structured data: describes visible entities and content without inventing a parallel reality.
4. Capability catalog: maintains names, descriptions, owners, status, and version.
5. Invocable contract: exposes tools or APIs with schemas, authorization, effects, and errors.
6. Structured result: preserves IDs, units, sources, and reusable fields.
7. Evidence rendering: transforms the result into conversation, table, chart, form, or approval panel according to the task.

Observability, security, and governance must be added across these layers. Every call should be able to answer who requested the action, which tool was used, with which arguments, which data it returned, and which part was inferred by the model.

The web does not disappear: it becomes living documentation of capabilities

The prediction that agents will eliminate websites confuses navigation with meaning.

We may visit fewer pages to perform routine tasks. But organizations will still need canonical places to explain:

• What they offer.
• How it works.
• Which data they use.
• Which limits they apply.
• Which evidence supports their claims.
• Who is responsible.
• What changes between versions.
• How access is revoked.
• What the agent can do on the user’s behalf.

The page becomes even more important as a public source of truth, even when the agent is the first reader.

The difference is that content should no longer live in isolation from the product. The visible definition, the schema, and the behavior need to evolve together.

The uncomfortable conclusion: SEO is moving closer to product design

SEO began as a discovery discipline. With agents, part of that discovery leads directly to action.

That forces us to broaden the question.

It is no longer enough to ask:

Can a search engine find and understand this page?

We will also have to ask:

Can an agent discover this capability, distinguish it from others, invoke it with the correct parameters, and return a result that a person can verify?

At that point, SEO touches information architecture, API design, documentation, UX, security, and product analytics.

Not because all those jobs become SEO, but because they all participate in the same struggle: making human intent reach the right capability with as little ambiguity as possible.

The web for people and the interface for agents are not separate worlds.

One explains.

The other executes.

And both must tell the truth.

Frequently Asked Questions

Will SEO disappear when agents answer and act on our behalf?

No. Agents still need to discover sources, interpret content, assess authority, and retrieve reliable information. That documentary SEO is joined by a new operational layer: describing capabilities through tools, APIs, and schemas that can be selected and invoked without guessing.

Is structured data on a page the same as an API?

No. Structured data describes the meaning of a page or entity. An API or tool exposes an executable capability, with inputs, outputs, authorization, errors, and possible effects on state. The relationship is a semantic analogy, not a technical equivalence.

What does operational SEO for agents mean?

It is a framework proposed in this article for designing content, metadata, and tool contracts so that an agent can discover, select, invoke, and verify a capability while preserving a clear and useful representation for people.

Does a company need to turn its entire website into an API?

No. Editorial, institutional, and explanatory content can remain documentary. An invocable layer makes sense when there is a repeatable, authorizable capability, such as checking availability, calculating a proposal, retrieving transactions, creating a booking, or updating a record.

Are visual interfaces still necessary if the agent can speak?

Yes. Conversation is useful for expressing intent and receiving a synthesis. Visual interfaces remain better for comparison, dense-data exploration, editing options, reviewing evidence, confirming actions, and preserving a persistent record.

How do you measure the visibility of a capability to agents?

In addition to indexing, impressions, and traffic, measure tool selection, activation precision and recall, argument validity, task success, retries, human verification time, confirmation errors, and recovery capability.