Beyond Citation: Why the Next SEO Layer May Be Callability

Hi everyone, this is Guo Shu.

A while ago I wrote a short note on WebMCP and whether Google’s new protocol will change WebApp, PLG, and SEO marketing logic. That article mainly answered a basic question: what WebMCP actually is.

In the past few days, I rethought it in the context of Google’s public positioning on AI Search, AEO, and GEO, and I realized the most important discussion is broader than “Can a webpage expose an interface for AI tools?”

The more meaningful question is: if AI can read webpages, summarize them, and cite them, and then later execute actions directly on those pages, what will the next layer of SEO competition look like?

Put simply: we used to care about whether a page is discoverable when someone searches. Then we started to care about whether ChatGPT, Gemini, or Perplexity mention us in responses, and whether they cite our page. But if agents keep advancing, the next practical question becomes whether AI can complete a task directly on your site.

That means the next stage might be: can it choose the right action, execute it, and return a result with user confirmation?

This is the central point I want to discuss.

The Next Layer of SEO Could Be Action Optimization

I’ll put the conclusion first. WebMCP is not an urgent must-have SEO standard you need to implement tomorrow. It is still at an early stage. The official report is still in draft form and the browser-facing implementation remains in early preview. So you do not need to panic and force your frontend team to ship it overnight.

But WebMCP does make one important direction visible: webpages are increasingly becoming capability containers, not just content containers, and AI may call those capabilities in the future.

Classic SEO asks: can search engines discover, understand, and rank you? GEO and AEO ask: can AI absorb you, cite you, and consistently represent you? If the same agent line continues, the next layer will ask: can an AI safely and reliably call your site’s actions?

That sounds like a developer problem, but it will eventually become a growth problem. User entry points are changing.

Historically users came directly to a site, scanned pages, found buttons, and filled forms themselves. With AI search, many users may first ask a model, then click through. In the next step, if an agent can perform tasks, the journey could become: user states intent, agent finds the right site and capability, then calls actions directly and asks for final confirmation.

Page views can still matter, but they will no longer be the only meaningful entry metric.

Whether your site is callable, whether your actions trigger correctly, and whether your workflow reaches completion under agent orchestration will become growth factors.

This is what I call action optimization. It does not replace content optimization; it adds a layer of product-ability optimization on top.

Don’t Mythologize WebMCP

Whenever a new term appears in the industry, people often wrap it in mystique: GEO, AEO, and now MCP. Then we get anxiety loops: if we do not adopt it, we lose. If we do not integrate it today, we are obsolete.

I am wary of that framing.

WebMCP is worth watching, but it is not yet at a “must-have across the whole site” stage. A more accurate frame is that it is trying to create a structured path between webpages and AI agents.

The core idea in the spec is straightforward: a web application can expose selected capabilities as JavaScript-based tools so that AI agents can execute actions with more reliability and less ambiguity.

The key word is structured. AI no longer has to infer everything by guessing at page layout. It can call declared capabilities: what can be done here, what inputs are required, and what output to expect.

Much of current web automation is effectively visual guessing: the agent sees a button and infers intent, sees a form and guesses field meaning, checks page states to infer whether a task is finished.

This can work, but it is fragile. A slight button copy change, a layout shift, an extra modal, and one extra step can break the flow.

WebMCP is trying to solve this DOM-guessing failure mode by making pages declare high-level actions explicitly.

The underlying idea resembles the semantic work we used to do for SEO. Previously, semantics served content understanding: title, body meaning, author, pricing, FAQ location.

As we move toward an agent era, semantics can extend into action. What task does this button trigger? What parameters are needed? What are success and failure conditions? Is user confirmation required? Can the action be reverted?

These used to belong mostly to product, frontend, and UX teams. In the future, they may become SEO and growth concerns too.

From Visibility to Quoteability, and Then to Callability

I prefer to see this as a continuum.

First is visibility: traditional SEO fundamentals. Crawlability, indexability, rankings, click-through, and relevance to search intent. That layer remains important.

Do not throw away classic SEO just because AI search exists. Google’s own statements around AEO and GEO make this clear: optimizing for generative outputs is still search experience optimization. Core SEO has not vanished. It is now embedded in a larger interface.

The second layer is quoteability. After AI search emerged, teams began to focus on whether AI responses mention their content, cite their pages, and surface their brand. This is real. For content sites, SaaS, tool platforms, and specialized service providers, citation affects brand presence and pre-purchase trust, even if it does not convert immediately.

But this layer is easy to misuse. Some try to game GEO by writing AI-optimized phrases or injecting fake brand mentions. I disagree with that approach. AI citing your page still depends on trust, distinctiveness, stable comprehensibility, and external evidence.

The third layer is callability. This is where WebMCP becomes meaningful. If AI agents stop at answering “which tool fits” and start doing work itself, competition shifts again.

Before, you optimized content so it ranked. Then you optimized snippets so it was cited. The next step is to optimize task endpoints so they can be called correctly by agents.

So, SEO may gradually move from content optimization toward action optimization. That does not mean every page must become a tool. Pure content pages still exist to educate, prove, be referenced, and build trust. They do not always need complicated actions exposed.

But for WebApps, SaaS, tool sites, e-commerce, scheduling platforms, design tools, data dashboards, support systems, and project management products, this distinction matters because a lot of valuable behavior is already action-centric.

The crucial question is no longer just “Do you have an intro page?” and more about “Can your core capabilities be interpreted and called by machines with stability and clarity?”

Not Every Site Is Equally Affected

A more grounded point: not every website will be affected in the same way. If you run a pure information site, your near-term priorities remain content reliability, topical authority, citation quality, and AI traffic measurement. Chasing tool-exposure logic for every page is likely to be a distraction.

If you run a WebApp, especially PLG products, the story changes.

PLG has always relied on users discovering value inside the product: activation, onboarding, product-led guidance, and referral loops. Historically we optimized for above-the-fold clarity, onboarding flow, templates, demos, activation path, paywall decisions, and in-product guidance.

But if more users encounter your product through AI agents, PLG gains a new layer: can the agent understand your product and execute the first value path on behalf of the user?

To ground this, here are several possible scenarios.

On an SEO service site, users might not open pages one by one; they may ask an AI to analyze a specific URL and generate a repair plan.

On a design tool, a user may ask for help creating a LinkedIn image from an existing product description instead of starting from a blank canvas.

On an e-commerce site, a user may ask for a gift idea for an 8-year-old girl within a $40 budget and fast shipping, instead of browsing dozens of SKUs manually.

On a B2B SaaS site, a user may ask, “Compare these plans and tell me which suits a 12-person team.”

If these flows are common, your page cannot just be a human-readable landing page. It must express capability boundaries, input requirements, state feedback, consent checkpoints, and failure handling clearly. That is agent-ready product design.

I prefer not to call it “AI-friendly copywriting”. The term sounds shallow, like changing a few sentences is enough.

A better phrase is “collaborative product interface”: pages designed to work for both humans and agents.

Beyond Content Assets, a Third Type: Capability Assets

In SEO, we long spoke of content assets: articles, landing pages, glossary pages, comparison pages, and use cases. Their value comes from traffic, education, trust, and conversion support over time.

In the AI search era, evidence assets became equally important: definitions, reliable data, third-party references, and structured factual statements AI can absorb.

If agent workflows continue to deepen, I expect a third asset type: capability assets. A capability asset is not a post; it is an action that is interpretable, callable, and verifiable.

Examples include:

• generating a report for a user
• shortlisting options
• auditing a page
• creating a new project
• booking a time slot
• converting one set of media assets into another format

These actions are already core product value, traditionally completed by users clicking UI elements step by step. In an agent era, the question is whether these actions are exposed as clear tool capabilities.

A mature capability asset answers these questions: what is it called, what task it solves, what inputs are required, what state it changes, whether user authorization is needed before execution, how the user confirms results, what failure feedback looks like, and whether there is rollback.

This is no longer solvable by SEO copy alone. It needs product, frontend, backend, growth, and SEO working together.

That is why WebMCP does not matter because it adds a technical checklist. It matters because it extends SEO outward toward product mechanics.

The old SEO craft of content, keywords, links, and crawling was once considered quite complete.

The next rare skill may be to understand a product’s task architecture: which pages are informational, which pages are capability entrypoints, which tasks should be call-ready, and which must be carefully gated.

This sounds tedious, but growth itself is becoming more complex. Commodity ranking strategies are becoming less effective, and the era of ranking through template-heavy pages is already fading.

Don’t Build Demos First, Map Your Task Flows First

If you run a WebApp, SaaS, or tool platform today, I do not recommend shipping multiple half-baked demos just because WebMCP is in fashion.

That often becomes technical hype. A polished demo looks impressive on social posts but can become a stale marker three weeks later with no maintenance.

A more practical first step is task mapping. What tasks exist in your website? Which are most common? Which are highly standardized? Which can be pre-executed by an agent before user confirmation? Which are high cost if wrong and must stay manual? Which require login, permissions, payment, or sensitive data, and therefore need strict controls?

This map is more important than WebMCP syntax itself. Protocols change, platform implementations change, browser details change; your product’s task architecture does not have to be reinvented from nothing.

If you can map your task structure today, any future integration will be easier, whether WebMCP, traditional MCP servers, OpenAPI, or private platform agents. If your product actions are currently chaotic, labels are unclear, status feedback is ambiguous, and success conditions rely on user guesswork, then adopting any new protocol only wraps chaos into a new API surface.

AI does not magically clarify a messy product. Often, it amplifies it.

SEO Teams Need to Learn “Action Semantics”

I believe SEO teams need a new lens: action semantics.

Before, our review checklist emphasized title structure, heading quality, keywords, internal links, schema, coverage, intent matching, performance, and indexability. Those remain important.

But if a page also hosts a user task, you also need to evaluate whether the action semantics are explicit: what can users do on this page, is the action clearly explained, are input requirements visible, are results verifiable, is state progression observable, is failure feedback explicit, and are human confirmation points clear.

These were mostly product experience questions before. In the future they may become core checks for agent usability.

Consider a simple example.

A page might say “Start optimization”. A human can infer intent from context. An agent may not know whether that means generating a recommendation, directly editing content, saving draft only, publishing, consuming credits, or something else.

For users, those differences matter. For agents, they matter even more. So better future pages are not only beautiful; they also clearly define action boundaries. That is not verbosity. It is semantic stability.

If SEO teams engage here early, they become uniquely valuable. SEO has always been good at translating complexity into language users understand. In the past, that translation targeted search engines and readers. In the future, it may also target agents.

Where This Gets Fake Fast

I also want to flag where the discussion can become dishonest.

First, presenting WebMCP as a fully landed mainstream trend. It is not there yet. The spec is still in draft, browser support is still early preview, and adoption pathways remain uncertain. So this is not “WebMCP will replace SEO tomorrow.”

Second, treating callability as controlled only by a single protocol. That is also inaccurate. Even without WebMCP, agents can use browser automation, existing APIs, MCP servers, plugins, or private integrations to call services. WebMCP matters because it tries to standardize and platform this front-end callable space on the web. It is a signal, not a single solution.

Third, predicting SEO will immediately become an engineering-only job. It is not realistic to overdramatize. SEO will not disappear, and not every SEO professional needs to become a JavaScript tool author.

A more realistic shift is that SEO and growth teams will need stronger product-task literacy and earlier participation in information architecture and capability expression, not just post-launch title tweaks and FAQ patches.

Fourth, fitting every website type into one framework. Content sites, tooling sites, e-commerce, SaaS, communities, media, and B2B service sites all have different paths by which agents will call them.

A news or insights site may prioritize citation quality. A tool site may prioritize callability. A commerce site must additionally manage permissions, inventory, payment risk, and liability boundaries. Erasing these distinctions produces generic analysis that is not useful.

What Founders Can Do Right Now

If you are a founder or running a small WebApp, you do not need to panic. But there are practical actions you can start now.

First, split pages into two groups: content pages and task pages. Content pages explain, educate, prove, and support discoverability. Task pages help users complete actions.

Then evaluate task pages by asking: Is the core task clear? Can a first-time user understand what can be done? Is the action behind each button unambiguous? Are form inputs clearly labeled? Are outcomes observable? Can users undo or revise decisions?

These are basic, not glamorous.

Next, create a list of tasks that may be suitable for agent execution. Not all tasks should be.

Suitable tasks usually have standardized steps, structured inputs, previewable outputs, limited failure cost, and a handoff point for user confirmation.

Examples include drafting, option screening, report generation, issue checking, recommendation generation, and data consolidation.

Also list unsuitable tasks: direct charging, deleting core data, publishing irreversible content, submitting legally sensitive documents. These should not be delegated to agents without strict controls.

That is no longer only SEO. But it will affect customer acquisition because AI entry points are becoming action-first. Users may ask “What is the best option?” less often and more often “Do it for me now.” Whoever is better at entering that execution loop gains advantage.

Why This Is the Key Thing to Watch

Back to the opening question. Will WebMCP and AI agents become the next SEO layer?

My view is that WebMCP may not independently become the single “next layer” by itself, but the direction it signals could become a major part of it: webpages shifting from passive reading objects to collaborative tools.

More concretely, it means moving from visibility to quoteability to callability.

People are still debating whether GEO is a separate category from SEO, whether AEO is practical, whether llms.txt adds value, whether schema improves AI citation. These debates matter.

But I think a better preemptive question is whether your site is ready to be used as an execution environment when AI starts to perform tasks for users.

We should not let agents freely click buttons, guess layout, and bypass user control. A better path is to make capabilities understandable and reliable under explicit user authorization and confirmation.

If done properly, SEO boundaries expand further: from content production to evidence construction to capability expression.

For many people who only chase keyword trends, this is not easy news. If you expect growth from AI search and agent entry, changing titles and adding FAQ content will not be enough.

For teams building real products, this can be good news. Your site is no longer just a page waiting to be clicked. It can become a workbench that AI and users operate together.

That is why I think this topic is still worth following closely.

Do not only watch whether AI will cite you. The next question is whether it can call you directly.

The important condition is that there is truly something worth being called. It is not easy to hear, but it is crucial. AI will not reward hollow sites. It will redistribute attention toward what is clear, useful, trustworthy, and executable in the new entry model.

Whether your site becomes a content asset, evidence asset, or capability asset depends on how you build it now.

References

• WebMCP Draft Community Group Report: https://webmachinelearning.github.io/webmcp/
• Chrome for Developers: An early preview of WebMCP: https://developer.chrome.com/blog/webmcp-epp