The Next AI Protocol Won’t Save Your SEO Strategy via @sejournal, @billhunt
All Paid Media PPC News Social MediaAdvertising Video Advertising Columns Ask A PPC ExpertNEW PPC Pulse Webinar ChatGPT Ads Or GEO: What To Buy, What To Earn Audit where ChatGPT places your brand, then get the rule for when Ads win, when GEO wins, and when running both beats either one. Digital Marketing All Digital Marketing Analytics & Data Ecommerce Lead Generation Content Marketing Social Platforms Google YouTube Reddit LinkedIn TikTokNEW WordPress Other CMS Platforms SEJ Pro SEJ Pro: compare AI search notes in private Ask the SEJ experts you already read what AI, agents, and algorithm changes mean for your traffic. Private, human to human. $97/mo. SEJ Live Webinars Rundowns PodcastNEW Ebooks All Resources Webinar Turn AI Visibility Data Into an AEO Plan Live Ahrefs workshop: interpret your AI visibility reports, prioritize fixes, and win more citations. Free. Every AI audit adds another acronym to your roadmap. Knowledge architecture is the capability that makes the next one a publishing decision. Bill Hunt September 2, 2026 ⋅ 14 min read Bill Hunt President at Bisan Digital Bio Follow 1.0K READS 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. 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. 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. 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.
Source: Search Engine Journal
This article has been carefully curated and reformatted for educational and informational purposes. Full credit goes to the original publisher.
📚 Visit more helpful articles on Joab Peters Blog
No comments