The Next AI Protocol Won’t Save Your SEO Strategy via @sejournal, @billhunt

Recently, I found myself in another conversation that has become increasingly familiar. A senior executive had received a warning from an AI visibility assessment vendor that the company was not sufficiently prepared for AI search. Among the recommendations was something I have seen appearing more frequently: the company needed an llms.txt file.

Suddenly, an emerging, and still-debated publishing format had become an executive concern. Someone now needed to determine whether the recommendation was valid, assess the potential impact, explain why the company had not already implemented it, and decide whether marketing and engineering resources should be redirected to address it.

I recently wrote about this phenomenon as part of what I call the AI FUD Tax. The cost of the individual recommendation may be relatively small, but the organizational cost of repeatedly responding to the latest external AI audit can become substantial. Every new audit, vendor pitch, protocol, acronym, or competitive claim creates another round of questions about whether the organization is falling behind.

The problem is not llms.txt, MCP, markdown, or any particular technology. In fact, they do different things. Some help machines discover information, some provide alternative ways to represent it, and others define how systems exchange or access it. Lumping them together, technically, would be inaccurate, but strategically, they create the same organizational temptation: treating the latest delivery mechanism as the solution rather than examining the underlying knowledge. The mistake is treating each one as though it represents a new strategy.

After watching variations of this cycle for decades, I believe we are once again focusing too much attention on the format and not enough on the information those formats are supposed to communicate. Instead of immediately asking, “Do we need to implement this?”, organizations should first ask a more fundamental question:

“Do we have the knowledge required to support it?”

That distinction becomes increasingly important as AI creates more ways for machines to consume organizational information. If the underlying knowledge is incomplete, fragmented, inconsistent, or trapped inside individual departments, adding another machine-readable format does not solve the problem. It simply creates another place to publish the same limitations.

The organizations best positioned to adapt will not necessarily be those that implement every new protocol first. They will be those that organize and govern their knowledge well enough that supporting the next useful format becomes a publishing decision rather than another reconstruction project.

Decision Coverage Creates The Next Question

In the previous article in this series, I introduced Decision Coverage as a way to measure how completely an organization has exposed the evidence AI needs to evaluate, compare, qualify, and confidently recommend its products or services.

The idea emerged from a problem I believe many organizations are beginning to encounter. They may have an enormous amount of product information yet lack the evidence AI needs to support an actual customer decision. Specifications can describe what a product is, but they do not necessarily explain who it is appropriate for, when it should be recommended, how it compares with alternatives, or which trade-offs matter to different customers.

This becomes especially apparent when we deconstruct complex prompts. A request for the “best” product is rarely a single question. It is typically a combination of stated requirements, inferred preferences, constraints, comparisons, and eligibility criteria that collectively determine which options make the cut.

Consider a customer asking for the best family-friendly beachfront resort in Cancun. “Best” is not an attribute a hotel can simply add to a page. The recommendation may depend on beachfront access, family suitability, room configuration, amenities, price, availability, reviews, and other criteria inferred from the request. The AI must evaluate those conditions collectively before deciding which properties qualify for consideration.

Decision Coverage approaches the same problem from the organization’s side. Once we understand the variables influencing the decision, we can determine whether the organization has authoritative evidence to support them. If a critical criterion cannot be substantiated, the problem may not be that the brand ranked poorly. It may never have provided enough evidence to make the cut.

This gives us a more defensible way to diagnose a lack of AI visibility. Rather than observing that a competitor was recommended and immediately responding with more “me too parity content,” more links, or another complex technical implementation, we should deconstruct the decision, identify the criteria influencing qualification, and determine where our supporting evidence is incomplete.

In other words, we can begin moving from simply observing what happened toward developing evidence for why it happened. Once we know what evidence should exist, however, Decision Coverage raises another question: Where should that knowledge reside, and how do we ensure every system receives the same complete answer?

That is where the obsession with these new individual formats begins to create problems.

A New Format Cannot Fix Missing Knowledge

The easiest response to a Decision Coverage gap is to put the missing information into whatever format is receiving attention at the moment. Daily LinkedIn is flooded with recommendations to expand the schema, create a markdown version, or build an MCP endpoint, and yes, deploy llms.txt.

That may solve an immediate publishing problem, but it does not necessarily solve the underlying knowledge problem. If a customer decision depends upon five meaningful criteria and the organization can substantiate only four, publishing those same four pieces of evidence through another protocol does not suddenly establish the fifth. We have simply made the same evidence gap available in another format.

This distinction sounds obvious, yet much of today’s discussion of AI implementation reverses the order, focusing on citations rather than the sources or methods of integration. An expanded schema can describe relationships between entities, but it cannot determine what those relationships should be. MCP can make multiple organizational resources accessible to AI systems, but it cannot determine whether those resources contain the knowledge required to answer a customer’s question. An llms.txt file can point machines toward information, but it cannot compensate for information the organization never created.

All of these formats are mechanisms for communicating and transporting knowledge. Their value ultimately depends on the completeness and quality of what organizations put into them. I have seen over 100 agentic readiness audits all flagging the presence of an llms.txt file, but none of them critique the depth or quality of the file for those that had them.

This is also why the current discussion around data integrity is so important. In his recent Search Engine Journal article, Alex Moss argued that technical SEO increasingly needs to focus on maximizing data integrity as AI systems depend on accurate entities, explicit relationships, machine-readable formats, actions, and reliable perception signals. He also made an important point that aligns closely with my argument here: Rather than trying to predict which emerging protocol will ultimately win, organizations should strengthen the underlying layers on which those protocols depend.

Data integrity, however, also creates a preceding organizational question. Before we can ensure that information remains accurate, synchronized, and trustworthy, we need to determine what knowledge should exist, how those pieces relate to one another, who owns them, and which source should be considered authoritative.

Data integrity helps ensure that information remains trustworthy once it exists. Knowledge architecture helps ensure that the right knowledge exists, is connected appropriately, and can be governed as an organizational asset. Both become increasingly important as AI systems rely on our information to make decisions rather than merely return documents.

Build The Base Once, Publish Everywhere

During a recent webinar, I tried to simplify this increasingly complex AI landscape into a single principle: Build the canonical base once. Publish everywhere.

The idea is intentionally simple because organizations do not need another acronym or protocol to manage. They need to stop rebuilding the same knowledge for every new destination.

At the foundation are the facts, relationships, policies, expertise, customer decision criteria, and supporting evidence the organization can authoritatively provide. Those elements need to be captured in a canonical knowledge source where they can be connected, governed, updated, and reused independently of any particular publishing format. AI-focused organizations like Milestone have built this natively into their content management system as the canonical source of truth, capable of outputting to any current and emerging markup formats.

Decision Coverage helps us determine whether that knowledge is sufficiently complete to support the customer decisions that matter. Knowledge architecture provides a way to organize and maintain knowledge. The various formats then become delivery mechanisms for making the appropriate portions of that knowledge available to the systems that need them.

Today, those delivery mechanisms may include web content, schema markup, Merchant Center feeds, APIs, markdown, MCP, llms.txt, and other emerging formats. Tomorrow, the list will almost certainly be different.

That should not require rebuilding the underlying knowledge.

If every publishing format maintains its own version of the organization’s facts and decision evidence, every update creates synchronization problems and every new protocol creates another implementation project. If those formats draw from a common, governed knowledge source, the architecture changes dramatically. The difficult work happens once at the knowledge layer, while the publication layer adapts as technologies and requirements change.

This is what I refer to as Knowledge Architecture. It is the organizational capability that allows trusted knowledge to be consistently assembled, governed, and delivered wherever it creates value.

Publication Is Not Capability

This distinction also explains some of my frustration with the increasingly loose use of terms such as “AI ready” and “agentic ready.”

Supporting an agent-oriented protocol can certainly make it easier for an agent to interact with an organization’s systems. That is useful infrastructure, but it does not automatically mean the organization possesses the knowledge required for an agent to make a useful decision.

There are really two different problems being conflated. The first is organizational capability: Can the company capture, connect, govern, maintain, and retrieve the knowledge customers and machines need? The second is publication: Can that knowledge be expressed through the format required by a particular search engine, AI platform, agent, application, or protocol?

One of my arguments about these markup formats is that they come from a vendor’s solution that promises a clearly defined deliverable. They are solving a real problem for AI systems: the chaos of a modern marketing-focused website, and that makes it easy to sell. Some of their tools expound on how quickly and easily they can spin out the format, with little to no mention of how they can wrangle organizational knowledge, since no protocol can create it for us.

A protocol cannot reconcile conflicting product information owned by different departments. It cannot extract the expertise living inside a salesperson’s head, determine which customer objections matter, establish how a policy affects a particular product, or create the missing evidence identified through Decision Coverage. Those are organizational knowledge problems that must be resolved before technology can distribute the answers.

Technology can expose organizational capability, but it cannot substitute for it.

This is why organizations do not become AI-ready simply by implementing more protocols. They become AI-ready by organizing their knowledge well enough that each useful protocol becomes another publishing destination rather than another attempt to reconstruct what the organization knows.

Organize Knowledge Around Decisions

For most of the web’s history, the focus was on creating and managing collections of pages; CMS platforms reinforced that structure, and SEO naturally optimized product pages, category pages, articles, FAQs, and landing pages because pages were the primary units through which search engines retrieved information and customers consumed it.

AI is weakening that relationship.

A single customer question may now cause an AI system to retrieve information from multiple pages, product feeds, structured data, reviews, external sources, databases, and other knowledge repositories before synthesizing a response. The targeted webpage remains important, but it is no longer necessarily the unit around which the decision is constructed.

The more durable organizing principle is the customer decision.

What does the customer need to know? Which criteria determine whether a product qualifies? What evidence supports those criteria? Which alternatives need to be compared? What trade-offs should be understood? Which policies, locations, availability constraints, or other relationships affect the outcome?

These questions connect directly back to the Decision Coverage framework. If we understand the conditions that collectively determine whether a product, service, or organization makes the cut, we can identify the evidence required to support each condition. The canonical knowledge source then provides a governed home for that evidence, while individual formats determine how it is delivered.

This is why chasing output formats gets the sequence backward. We should not begin with an empty protocol and ask what information we can put into it. We should begin with the customer decisions we need to support, ensure the evidence required for those decisions exists, and then determine which delivery mechanisms make that knowledge accessible to the systems influencing the outcome.

This Is Infrastructure, Not Another AI Tactic

This argument should sound familiar to anyone who has followed my previous Search Engine Journal articles because it extends a position I have held for some time. In “SEO Is Not a Tactic. It’s Infrastructure for Growth,” I argued that sustainable search performance depends on capabilities embedded across the organization rather than isolated optimization projects. Search works best when product, content, technology, and business strategy are connected around how customers actually discover, evaluate, and choose solutions.

I later introduced the Search Equity Gap to quantify the business value lost when organizations fail to capture the qualified visibility they should reasonably earn. That article also highlighted the growing impact of zero-click experiences and AI-mediated search, in which visibility can remain even as the economics of customer interactions change.

Those ideas have become increasingly connected as AI has evolved. Brand Sovereignty establishes the need for organizations to become the authoritative source of their own facts and expertise. Click Worthiness helps determine where continued engagement yields sufficient incremental customer and business value to justify investment. Decision Coverage asks whether we have exposed the evidence AI needs to evaluate, compare, qualify, and confidently recommend us.

Knowledge architecture provides the durable foundation underneath those capabilities.

Without trustworthy organizational information, brand sovereignty becomes difficult to establish. Without understanding customer decisions, it becomes difficult to prioritize click worthiness. Without complete decision evidence, Decision Coverage remains incomplete. Without an architecture capable of governing and reusing that knowledge, every new AI format sends the organization back into another implementation cycle.

This is why the next AI protocol will not save an SEO strategy that lacks the underlying knowledge capability. The protocol is downstream of the problem.

The Next Protocol Won’t Be The Last

I do not know whether MCP, llms.txt, Agents.md, UCP, or any of today’s other emerging approaches will become foundational standards. Some undoubtedly will become more important. Others will evolve, merge into something else, or disappear as quickly as previous technologies that once seemed essential. That uncertainty is precisely why organizations should resist building their AI strategy around individual formats. The next protocol will not be the last one.

Organizations that build their strategy around today’s hyped formats will eventually need to rebuild around tomorrow’s. Organizations that build a governed knowledge source around their business expertise and customer decisions will be in a very different position. When the next useful format appears, they will not need to rediscover, recreate, and reconcile the knowledge it requires. They will need to determine whether the format provides a valuable new way to publish what they already know.

That is a much more resilient model for AI readiness and, more importantly, a much better use of organizational resources.

The goal is not to support every possible format. It is to ensure that the knowledge required to make important customer decisions is complete, authoritative, governed, and available for delivery through the formats that matter. The protocols will continue to change. The delivery mechanisms will continue to multiply, and consultants will undoubtedly continue finding new items to add to AI readiness audits. The strategic response should remain remarkably stable.

Build the base once. Publish everywhere.

More Resources:

Featured Image: Rawpixel.com/Shutterstock