The previous article in this series asked a smaller, more embarrassing question than “should we invest in a knowledge graph.” It asked whether the right people were even in the same room, and whether that room could sit with an unanswered question long enough to be useful — instead of grabbing the nearest concrete task just to make the discomfort go away.
Assume that part’s done. The team exists. Nobody reached for a technology just to end the meeting early. Now what actually needs to happen in it?
Run the prompts, find what’s broken
Here’s where I’d start, and I’d start here before touching schema, before touching any AI-visibility vendor pitch, before anyone drafts a business case: this isn’t a content audit. It’s a GEO audit. Take the real prompts a customer would type into ChatGPT, Perplexity, Gemini — the comparative, “best X for Y” questions, not brand lookups — and run them. See where you show up and where you don’t.
Then, for every place you don’t, resist the instinct to write more. Ask a sharper question instead: if we genuinely believe we’re the best at this, is there anything public a model could point to that proves it? Most of the time, the honest answer is no — not because nobody wrote about the topic, but because “we’re the best at this” exists only as a claim on your own site, unverified and unsupported elsewhere. That’s not a content gap. Publishing ten more blog posts won’t close it. It’s an eligibility gap — nothing exists that would let a model say it on your behalf, no matter how true it is.
The content gap versus the eligibility gap is the whole diagnostic. It replaces “we should probably think about AI visibility” with something specific and uncomfortable: of the prompts we should be winning, how many are we even eligible to win, given what’s actually publicly verifiable about us.
A case in point
I know a retailer — I won’t name them, but you’ve probably shopped somewhere just like this — that does most of the things people tell you to do. They have schema markup on their product pages. They’re on a platform that automatically ships an agents.md file, so on paper they check the “AI-ready” box. And they’ve built a genuinely excellent product selector tool — the kind of interactive experience that helps a shopper narrow down exactly the right piece for their space and their taste.
And yet when you ask an AI assistant a real product question about what they sell, it can’t answer. Not because the company hasn’t done the technical homework. Because the actual answer — the thing that would let a customer’s question get resolved — lives inside that selector tool. It’s interactive, it’s session-based, and it requires the customer to already be standing in the store, so to speak, before it will tell them anything.
That’s the chicken-and-egg problem in miniature. The tool is great if you’ve already arrived. It does nothing to help you arrive. And no amount of schema markup fixes that, because schema was never the thing standing in the way. The fact was never absent — it just never left the building.
There’s a sharper version of the problem underneath that one, though. The selector tool isn’t just holding facts hostage — it’s holding logic hostage. It can weigh several criteria at once, ask a follow-up question, narrow a decision the way a good salesperson on the floor would. That’s genuinely hard to build and genuinely valuable. But it only works for an audience with hands and eyes — something that can click, drag a slider, read a comparison rendered on screen. Google doesn’t have fingers. Neither does an AI assistant, at least not yet. Whatever reasoning the selector performs when a human uses it simply doesn’t exist for a model, because a model can’t operate it. They built real decision-making capability and then made it available exclusively to the one audience that can hold a mouse.
That’s the eligibility gap from the section above, in its most literal form: it’s not that the retailer lacks content, and it’s not even only that a fact is gated. It’s that the reasoning across multiple criteria — the thing that would let an assistant confidently recommend a specific product instead of hedging — is trapped inside an interface no model can operate, with nothing equivalent expressed anywhere a model can read.
That’s the pattern I’d bet is repeating across a huge number of companies who’d tell you, honestly, that they’ve “done the AI work.” They’ve done the checklist. They haven’t asked whether the thing a customer actually needs to know — or the logic that would help decide it — is reachable without already being inside their walls, operating a tool built for hands.
The same trap, from the other side
I got off a call ten minutes before writing this. A dev team wanted to know which standard to chase. My answer was none of them — not yet, because the infrastructure underneath isn’t ready. The pushback was immediate: well, how would we ever build any of them, then? EntityMap seems to have traction, so maybe we just build that.
That’s the build-side version of the exact same trap the retailer above is stuck in on the demand side. The retailer already did the visible work — schema, an agents.md file, a well-built tool — and still can’t answer a customer’s question, because none of it was ever organized around what a customer would actually ask. My dev team wanted to skip straight to the same mistake in the other direction: pick the standard with the most buzz this month and build toward it, before anyone had inventoried what data they actually have or how it’s scattered across the systems that hold it.
“EntityMap has traction” is not evidence EntityMap will still have traction in eighteen months. It’s the RDFa story with a different acronym in the starring role, and I’ve lived that story once already.
What I told them instead: bake one batch of dough before you argue about which cutter shapes it. Build a repository — a single normalized source of truth — that can be pressed into EntityMap, or into whatever else is standing when the dust settles, or into nothing more exotic than clean HTML if it comes to that. Arguing over cutters before the dough exists is the part everyone wants to skip past, because it isn’t as fun as picking a shape and cutting. But the dough is the actual hard part, and it’s the only part of this that’s worth anything regardless of which cutter wins. Picking a manifest and building straight to it isn’t a shortcut. It’s a bet dressed up as a decision.
The dev team’s next idea told me where the real problem actually lives, though. Their instinct, once “which standard” was off the table, was to write a skill that crawls every page after the fact and extracts an entity map from what’s already there — the same move as generating an image XML sitemap by crawling images nobody ever tagged with intent. It sounds efficient. It’s actually a bet that human-authored prose — written for narrative, tone, persuasion, the stuff that moves a person toward a decision — can be reliably parsed backward into clean, validator-passing facts. It usually can’t, not without someone reviewing the output by hand, because the content was never built to survive that round-trip.
That’s the real gap, and it isn’t a delivery-mechanism problem at all. Nobody ever designed the authoring layer to produce a human layer and a machine-verifiable layer from the same source at the moment of creation. A crawler bolted on afterward is trying to manufacture that second layer retroactively instead of admitting it was never built. So before anyone writes a spec for how the entity map gets delivered, the actual decision the organization has to make is harder and less technical: are we willing to change how content gets authored in the first place, not just add an export step at the end? That’s a real project — new authoring workflow, new review step, new ownership — and it’s worth naming as the thing being decided, rather than letting “let’s write a crawler skill” quietly stand in for having decided it.
There’s a second audit worth running regardless of which way that decision goes, and it’s separate from “what’s broken in the prompts” — it’s simply “could we produce a conforming file today, even from content authored the old way.” Take EntityMap as an illustration, not a recommendation. On paper it looks simple — a root object, at least one entity, a chunk per entity, roughly a dozen required fields. The part worth designing around before you start, rather than discovering it during a failed validator run, is how granular the requirements actually get. Every chunk has to carry a publisher string that matches your root record exactly, character for character — which sounds trivial until you find out it’s retyped in twelve different places instead of pulled from one source. And not every fact gets treated the same: some claims need nothing more than the fact itself, others — the more interpretive ones, like “this product improves X” — need a confidence score attached, or the whole file fails validation.
None of that is hard on its own. But “do we have a publisher name that lives in one place instead of twelve” and “do we know which of our facts are solid versus interpretive” are yes-or-no questions a dev team can answer in an afternoon — and the answers tell you whether you’re six weeks out or six months out, regardless of whether EntityMap specifically is still the spec that matters by the time you’d ship. That’s the audit my dev team actually needed to run before arguing about which standard to chase: not “which one has traction” but “what would it take to produce a conforming file from what we already have, and how far off are we.”
From a gap to a decision
Once you’ve run the prompts and sorted the misses — content gap here, eligibility gap there, reasoning trapped inside a tool over there — you’re finally at the point where Warren’s four questions apply cleanly, because now they’re scoped to something specific instead of “AI” in the abstract.
A content gap is a content problem, and the fix is obvious even if it’s tedious. An eligibility gap is a different animal — it’s a proof problem, not a writing problem, and no amount of additional publishing closes it if there’s still nothing publicly verifiable behind the claim. Reasoning trapped inside an interactive tool, like the selector above, is a product decision about what logic is worth exposing as flat, citable content outside the tool — and that’s a conversation that belongs with product and engineering, not with the marketing team alone. Naming which kind of gap you’re looking at is what turns “we should do something about AI” into a project someone can actually own.
And underneath all three sits the build-readiness audit from the dev-team section — because knowing exactly where you’re ineligible doesn’t help if nobody’s checked whether the data even exists in a shape that could close the gap. That’s the piece most teams skip: they diagnose the gap correctly and then discover, three sprints into building something, that the publisher field was never consistent to begin with.
From there, the instinct I’d resist is building a shiny parallel machine-readable version of everything before doing the boring version of the fix: make the fact visible, in the primary HTML response, above whatever JavaScript boundary is currently hiding it. I wrote a few weeks back about the emerging research on this, and the one finding that held up under scrutiny wasn’t about schema markup at all — it was that making previously hidden facts visible as plain text moved outcomes, while schema alone mostly didn’t. That’s not a reason to skip structured data. It’s a reason to stop treating it as the whole answer.
That’s also, conveniently, the version of the fix that doesn’t require betting on which standard wins. It’s robust whether the next two years belong to Markdown, or agentic browsing, or something nobody’s named yet, because you’re not optimizing for a format. You’re making sure the fact — and the reasoning behind it — is reachable at all.
Rerun the prompts
The last step is the one people skip because it isn’t glamorous: rerun the same prompts after you’ve closed the gaps. Not because you shipped something, but because you want to know whether you actually became eligible. A flat result after a quarter of engineering time is your signal to stop and rethink. A shifted one is the business case for the next round — and it’s a business case built entirely out of things you measured, not things you believed.
I’ve been burned before by believing a standard mattered before anyone proved it did. Warren’s question was whether the investment is worth making. The piece before this one asked whether the room could even ask that question honestly. This one is smaller and more mechanical: do you know where you’re ineligible, and could you fix it if you decided to today? Most organizations don’t know the first part and haven’t checked the second — not because either answer is hard to find, but because nobody’s run the prompts yet, and nobody’s checked the data against a real spec’s requirements.
Human-authored content and machine-verifiable facts are two distinct outputs, and right now almost every organization has the machinery to produce only one. Deciding to build the other deliberately at the point content is created, not bolt it on afterward, is the mindset shift behind all of this. It’s so much easier to argue about which cutter to use than to admit nobody’s made the dough.
That’s where I’d start. Not with a standard. With a gap.
