The Next AI Protocol Won’t Save Your SEO Strategy

Shalin Siriwardhana

Summary

In the previous article in this series, I introduced Decision Coverage as a way to measure how completely an organization has. The practical question is what this changes for SEO, content quality, and AI search visibility.

A close-up of a single, outdated printed manual resting on a sleek, modern glass table, surrounded by several glowing, translucent digital tablets displaying fragmented code.

It is easy to get caught up in the noise of the "next big thing" in AI. Every few weeks, a new file format, a new protocol, or a new "readiness" assessment emerges, promising that if you just implement this one technical tweak, your brand will suddenly become the preferred answer for every LLM on the planet.

The problem is that most of these recommendations are treating the symptom rather than the disease. We are seeing a surge in technical checklists that promise visibility but ignore the actual substance of the information being shared. If your strategy is based on the delivery vehicle rather than the cargo, you are building on sand. The same pattern also shows up in search visibility, where the practical question is how the signal becomes visible.

The Cost of Chasing AI Trends

I recently encountered a situation where a senior executive was warned by a vendor that their company wasn't "AI ready" because they lacked an llms.txt file. Suddenly, a debated and emerging publishing format became a boardroom priority. The organization had to stop what they were doing to evaluate the risk, justify why it wasn't already done, and decide if engineering resources should be diverted to fix it. A useful companion note is to Get Cited & Stay Visible, because it looks at a nearby part of the same system.

This is what I call the AI FUD Tax. The actual technical effort to create a specific file might be low, but the organizational cost of constantly reacting to the latest audit or vendor pitch is immense. When we treat every new acronym or protocol as a critical gap in our strategy, we waste mental energy and resources on the plumbing while the water supply is empty.

The reality is that tools like MCP, markdown, or llms.txt serve different purposes. Some help machines find data, others change how that data is represented. Lumping them all into a single "visibility" checklist is a mistake because it confuses the method of delivery with the value of the content.

Expert Interpretation: The tradeoff here is between "perceived readiness" and "actual capability." Many companies choose the former because it's a checkbox that makes stakeholders feel safe. The decision you need to inspect is whether your team is spending more time on the how (the protocol) than the what (the knowledge).

Why Decision Coverage Matters More Than Formats

To understand why a new file won't save a bad strategy, we have to look at Decision Coverage. This is a measure of how well an organization has exposed the evidence an AI needs to actually recommend a product or service. Most companies have plenty of data, but very little "decision evidence."

There is a massive difference between a product specification and a decision driver. A spec tells an AI what a product is. Decision evidence tells the AI who the product is for, when it should be recommended over a competitor, and what the necessary trade offs are. When a user asks for the "best" version of something, the AI isn't looking for a superlative adjective on a landing page; it is synthesizing a set of requirements, constraints, and preferences.

For example, if someone searches for the best family friendly resort in a specific city, the AI has to evaluate room configurations, amenities, and proximity to the beach. If that data is missing or vague, no amount of fancy markup will make the AI confidently recommend that resort.

Expert Interpretation: This matters because AI doesn't "rank" content in the traditional SEO sense; it evaluates suitability. The tradeoff is that building decision coverage is harder than writing a blog post because it requires deep business intelligence. You must decide if you are providing data that describes your product or data that helps a customer choose your product.

A New Format Cannot Fix Missing Knowledge

The temptation when you realize you have a gap in your decision coverage is to plug that gap with the trendiest format available. You see it everywhere on LinkedIn: "Expand your schema," "Build an MCP endpoint," or "Deploy llms.txt."

While these can solve a publishing problem, they cannot solve a knowledge problem. If a customer's decision relies on five key criteria and you only have evidence for four, publishing those four pieces of evidence in a new format doesn't magically create the fifth. You've simply moved the same gap to a different location.

We are currently seeing a reversal of logic in the industry. People are focusing on the citations (the format) rather than the sources (the knowledge). An expanded schema can describe a relationship between two things, but it cannot invent the relationship if the business hasn't defined it. An llms.txt file can point a machine toward a page, but it cannot compensate for information that was never authored in the first place.

Expert Interpretation: The risk here is "digital lipstick." You can make your data look "AI friendly" while it remains functionally useless for making a recommendation. The decision to make is to audit your knowledge gaps before you invest in new delivery protocols.

Build the Base Once, Publish Everywhere

The only way to escape the cycle of chasing protocols is to adopt a simple principle: Build the canonical base once, then publish it everywhere.

Diagram showing knowledge built once at a canonical base and published everywhere
Diagram showing knowledge built once at a canonical base and published everywhere Credit: original article.

Organizations need to stop rebuilding their knowledge every time a new destination emerges. The foundation should be a canonical knowledge source containing the facts, policies, expertise, and decision criteria that the organization can authoritatively provide. This base should be governed and updated independently of any specific markup or file format. This connects with Beyond Brand Sovereignty when the same signal needs a clearer operating decision.

When you have a centralized source of truth, the various AI protocols simply become delivery mechanisms. Whether the current requirement is a Merchant Center feed, an API, a markdown file, or a specific AI agent protocol, you are simply pushing the same verified knowledge through a different pipe.

Expert Interpretation: This is a shift from "content management" to "knowledge architecture." The tradeoff is a higher upfront investment in organization and governance. However, the decision to build a canonical base removes the need to panic every time a new AI protocol is announced.

Publication Is Not the Same as Capability

There is a dangerous conflation happening between being "AI ready" and having "organizational capability." Supporting an agent oriented protocol makes it easier for an agent to talk to your systems, which is useful infrastructure. But it does not mean the agent will find anything useful to say.

We have to separate two distinct problems:

  • Organizational Capability: The ability to capture, connect, govern, and retrieve the knowledge that customers and machines actually need.
  • Publication: The ability to express that knowledge in the format required by a specific platform or agent.

Many vendors sell "AI readiness" as a deliverable because it's easy to package. They can spin up a format quickly. What they cannot do is wrangle your internal organizational knowledge, because no protocol can create knowledge that doesn't exist.

Expert Interpretation: If a vendor promises "AI visibility" through a technical implementation without asking about your decision criteria or knowledge gaps, they are selling a delivery vehicle without a passenger. You should inspect whether your "readiness" is purely technical or actually substantive.

Shifting Knowledge Around Customer Decisions

For decades, the web was built around the "page." CMS platforms and SEO strategies were designed to optimize product pages, category pages, and FAQs. The page was the primary unit of consumption and retrieval.

AI has changed the unit of retrieval. A single query now prompts an AI to pull fragments from multiple sources: product feeds, structured data, reviews, and databases. The targeted webpage is still useful, but it is no longer the center of the universe. The new organizing principle is the customer decision.

Instead of asking "How do I optimize this page?", the question should be: "What does the customer need to know to make a decision? Which criteria determine if my product qualifies? What evidence supports those criteria?" When you organize knowledge around the decision rather than the page, you create a durable asset that survives changes in search technology.

Expert Interpretation: This requires a mental shift from "traffic" to "utility." The tradeoff is that you can no longer rely on a few "power pages" to do all the heavy lifting. You must decide to map the entire customer journey and identify every piece of evidence required at each step.

Infrastructure Over Tactics

This isn't a new AI tactic; it is a fundamental approach to growth infrastructure. Sustainable performance in search has always depended on capabilities embedded across the organization rather than isolated projects. When product, technology, and business strategy are aligned around how customers actually choose solutions, search performance follows naturally.

There is a "Search Equity Gap" that occurs when organizations fail to capture the visibility they should reasonably earn because they lack the infrastructure to support it. In an era of zero click experiences and AI mediated search, this gap widens. Visibility is no longer just about getting a click; it's about being the evidence the AI uses to form a recommendation.

Expert Interpretation: The decision here is to stop treating SEO as a marketing layer and start treating it as a business intelligence layer. The tradeoff is that it requires cross departmental cooperation between product, engineering, and marketing.

The Cycle of Protocols Will Continue

It is unlikely that any of today's emerging standards, whether it's MCP, llms.txt, or Agents.md, will be the final word. Some will become foundational, some will merge, and many will disappear as quickly as they arrived.

If you build your AI strategy around a specific format, you are committing yourself to a cycle of constant rebuilding. You will be forced to rediscover and reconcile your knowledge every time the industry pivots to a new "essential" technology.

However, if you build a governed knowledge source based on your business expertise and customer decisions, you are in a position of strength. When the next useful format appears, you won't need to recreate your knowledge. You will simply need to determine if the new format is a useful way to deliver the knowledge you already possess.

Expert Interpretation: The ultimate goal is decoupling. By decoupling your knowledge from its publication format, you eliminate the "AI FUD Tax." The decision is simple: do you want to be a follower of protocols, or an owner of knowledge?

Comments

Comments are reviewed before they are published. Links are not allowed inside comments.

Only your name, optional LinkedIn profile, and comment will be shown.