Structured Data for AI Search: What the Evidence Shows

Structured data was supposed to be how machines read your site. Then three new protocols shipped in ten months. Not one adopted it.

Nobody is asking you for it

Start with what the engines say. Short, and unanimous.

Google's own guide is not hedged: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search."

Bing's grounding guidance names four things: facts stated directly, consistent entity naming, one topic per URL, key information near the top. Not markup.

OpenAI has published nothing across its commerce documentation. Microsoft has published something.

A Bing post from May 2025 pairs schema.org Product markup with IndexNow, and says it helps engines surface content "in search results, shopping experiences, and AI-driven assistants."

Read what that is. A recommendation, with no result behind it.

Google co-founded schema.org in 2011, with Bing and Yahoo.

Fifteen years on, it will not claim the vocabulary does anything for the product it now sells.

No engine has ever published a controlled result showing that adding structured data changed an AI answer.

Has anyone shown you one? Has anyone quoted you one? Not one. In no direction. Ever.

Every one had opportunity and incentive. None took it.

Read that absence for what it is made of. It does not mean markup is worthless. It means the AI story attached to it has no published result behind it. None, from anyone.

Count the doors

Between September 2025 and June 2026, three machine-readable protocols were published. Three publishers: Google, OpenAI with Stripe, and Chrome, which is Google again. Two older pipelines already ran.

Every one is a decision about what a program should read. How many have you read? Which is your budget aimed at?

OpenAI's commerce feed has its own field names. It will also ingest a Google-compatible feed "without renaming its columns to OpenAI field names." So the Merchant Center field list travels. The markup does not.

We searched every page of that documentation for schema.org, JSON-LD, microdata and structured data. Zero occurrences.

Then the advice. Google's AI optimization guide names three ways an agent reads you: "analyzing visual renderings (like screenshots), inspecting the DOM structure, and interpreting the accessibility tree." Structured data is not one of them.

The page it links to, web.dev's "Build agent-friendly websites," never mentions structured data. Its advice: real buttons, labeled form fields, click targets over eight square pixels. Good advice. None of it markup.

Chrome's agent-ready toolkit is the other advice document. Same silence.

When the AI guide turns to products, it names Merchant Center feeds and Business Profiles. Then one line about the commerce protocols: "Protocols like Universal Commerce Protocol (UCP) are emerging that will allow Search agents to do more." Emerging. Not markup.

Google is pointing merchants at UCP. Not at Product markup.

Which settles the hedge Chapter 2 left here, and narrows it. What the protocols read is the feed and the endpoint. Your markup sits upstream of that, and only there.

So implement UCP or ACP? Only if you sell online, and the Merchant Center feed comes first. You probably owe one anyway.

Queue UCP rather than leading. Google published a six-step merchant path, and step one ends at a waitlist. Your integration "must be approved by Google" before you go live on AI Mode or Gemini.

The manifest is half a day. The gate after it is not yours to open. Neither protocol is a marketing task.

One thing does travel from your markup into that world. Merchant Center will build a feed from your Product and Offer markup. OpenAI takes that format.

So your markup is already most of an agentic commerce feed. Not because anybody reads it as markup. Because it is a clean source of the fields a feed wants: price, currency, availability, condition, GTIN.

One row breaks the pattern, and we put it there ourselves. NLWeb is Microsoft, May 2025: a protocol for agent access to a site. Its documentation: "The response returned uses Schema.org."

So a major engine did build a schema-consuming protocol.

Once, and four months before the window this chapter counts.

Not one release since went back to it. Including Microsoft.

One objection to our own table, and it is fair. Schema.org is a vocabulary, while the three recent protocols are transport layers. So in one sense a vocabulary is not what they declined.

Except a transport layer still names its fields. UCP wrote its own profile. ACP wrote its own field names. WebMCP took JSON Schema.

Three chances. Three vocabularies.

None of them this one.

Which is why the claim this chapter defends is the narrow one. No machine-readable protocol published since September 2025 has adopted schema.org as its vocabulary.

Take that version. It survives.

Three studies, none of them ours

One controlled study isolates JSON-LD as a variable, from March 2026. The authors are WordLift, and their product is schema markup. Read the section heading. They wrote it.

Their setup: a research pipeline over a closed corpus, answers scored one to five by a model judge. Not a production engine, and they say so.

Accuracy moved from 3.62 to 3.89 on that five-point scale. Effect size: 0.18. Completeness did not survive correction for multiple comparisons.

In the discussion they gloss it. Schema.org markup "remains valuable for search engines with dedicated parsers (Google, Bing), but it provides no measurable benefit in RAG-based systems that treat pages as flat text."

Keep both halves, then notice a schema vendor published the second one. When did yours send it to you?

Now the number the field quotes: +29.6%. That figure belongs to their "enhanced entity page," which adds natural-language summaries, breadcrumbs, linked entity navigation, agent instructions and a neural search reference on top of the markup. Six components, one number.

Here the authors do something unusual. They report an ablation nobody performed.

On removing the JSON-LD from the winning page they write only this: "we expect it would not" change performance, "since the same information is already expressed in natural language."

The people selling markup expect their winning condition to work without the markup. Read that twice.

Then the mechanism. Their pipeline ingests each page as one text field, truncated at roughly 20,000 characters before embedding. One field. One cut.

In their corpus, 88% of the JSON-LD pages ran past that limit. The block starts at median character 18,510.

Which gives you the cheapest move in this chapter. Put your JSON-LD block in the head, not the bottom.

Most plugins inject it wherever is convenient, and in our experience that is often the footer.

Start at 18,000 against a 20,000-character budget and a flat-text reader sees almost none of it. Start at 900 and it sees all of it.

No parser changes, no vendor, one template edit. Step 7 gives you the command that finds it.

One caveat: this is inference, not a published finding.

It holds only where the extractor keeps the script block and document order. Plenty drop script contents entirely. Chapter 3's ChatGPT measurement is that case.

Where the block is dropped, head placement buys you nothing. It costs you nothing either. Which is why we print it anyway.

Structured data has a dedicated parser in the systems that predate language models. No documented parser in any retrieval system anybody has published details of.

The same paper is plain. Google and Bing "have evolved specialized crawl-time parsers" that pull the block out as a separate signal. There, "the structured data is never flattened into a single text embedding."

One caveat on the parser side, and it cuts against us. Bing reads structured data, and Microsoft says so itself. It is "one of the clues that Bing uses."

Bing also grounds Copilot. And Google's own guide says AI Overviews and AI Mode retrieve from the Search index. Which is the index that parser feeds.

So two live paths exist where a parsed block sits upstream of an AI answer.

Neither vendor says what the parsed block does once it is there. Nobody outside has measured it either.

Two more studies, neither of them ours

Ahrefs published the before-and-after in May 2026. They sell SEO tooling, nothing in structured data. Worth copying: 1,885 pages that added JSON-LD between August 2025 and March 2026, against 4,000 matched controls. Thirty days either side.

Three surfaces. Google AI Overviews came back at minus 4.6%: statistically significant. AI Mode at plus 2.4%. ChatGPT at plus 2.2%. Their sentence: "adding schema produced no major uplift in citations on any platform."

They are careful about the negative one, and so are we. They call it "small enough that we can't definitively pin it on schema." Now their limitations. That is the interesting part.

The sample was pages already heavily cited, over a hundred citations before treatment. So it does not test a page nobody has found. All schema types were pooled.

And they looked only at markup in the page HTML. Not markup injected by JavaScript. They add that crawlers "appear to treat the two differently."

Thirty days is a short window. They cannot separate schema from anything else changing. But take it for what it is. Disinterested party, large sample, matched control.

Then a third leg, after WordLift and Ahrefs. Fischman, February 2026, published by a vendor selling GEO services.

The design: 730 AI citations from ChatGPT and Gemini across 75 commercial queries, 1,006 unique pages, with domain authority as a covariate.

Observational, not experimental. Nobody added markup to anything. Every page in it already was what it was.

The answer was null: odds ratio 0.678, p of 0.296.

Read what they found instead, worth more than the null. Rank position dominated, cutting citation odds by roughly 24% for every place you fall. Position, not markup.

Hold that loosely too. An observational rank coefficient cannot separate rank from whatever produced the rank. Nobody can.

What would your own thirty days look like? Chapter 11 builds that.

The reconciliation Chapter 3 asked for, and where your money is

Chapter 3 left this chapter a bill. A 2026 measurement found ChatGPT converting fetched pages into a stored copy, with the JSON-LD taken out. A chapter was owed on whether markup mattered.

Here is the second fact. Where the block is not removed, it is arithmetic. The markup is there, and the window closes first.

Removed, or late.

Either way it does not reach the model.

Then searchVIU, where a value existing only in markup was found by none of five systems. Perplexity was one, and Chapter 3 hedged that it might be the exception.

On this evidence it is not. One test, so hold it loosely.

Which surface is your money in?

One question, asked of every commercial page you own. Does the money arrive through a surface with a parser, or one without?

Parsers sit in Google results, Bing results and Merchant Center. Anything rendering a rich result.

Nothing else has one.

Now your numbers, not this chapter's. What share of revenue lands through classic search?

If most of it still does, your markup is doing a job. Add the two free properties later in this chapter and nothing that costs money. Then let Artifact 7.5 tell you what to remove.

If you are watching that share fall, markup does not follow the traffic. Chapters 4, 5 and 6 were the answer to that. This chapter is its boundary.

So the answer splits by what you sell. Which one are you?

Five readers who get a different answer

First, the local business, or anyone running locations. Keep your LocalBusiness markup and stop thinking about it.

It renders a panel, and that panel appears in classic results and in Maps. Both parsed, both where local revenue lands. Your hours, address, phone and geo are read there.

Locations change the arithmetic, not the verdict. Every location page runs one template. So your audit is one page and your fix is one deploy.

Which inverts the rest of this chapter. Here the surface consuming your markup is the surface paying you.

Second, the reader this book is mostly written for. You sell B2B software.

Look down the current 25. Products, locations and recipes are not yours. Most of the rest describe content you do not publish.

What is realistically left is Organization, WebSite and Breadcrumbs, which you already ship, plus Article on the blog, and Video or JobPosting if you host either yourself.

Strip the conditionals and your estate is a logo, a site name and a breadcrumb trail. All real, all small, all already deployed.

So your annual schema spend is nothing, and your project is one afternoon of Artifact 7.5. Then never again until Google adds a feature you can earn.

Third, and the only reader here told to extend markup you already ship. You sell products online.

Your Product and Offer markup is a feed. Merchant Center builds one from it. OpenAI accepts that format. The pipeline is binary.

So step 4 is most of your audit. Diff your markup against the Merchant Center product data specification. Fill the gaps.

Then know what you are buying. Google routes merchants at feeds and protocols, not at markup. So the chain runs markup to feed to answer, with a hop in the middle you do not control.

Documented at every link.

Measured at none.

One more free thing while you are in there. Bing pairs structured data with IndexNow. Their line is worth having: IndexNow tells engines "that something has changed, while structured data tells them what has changed."

If your prices move, submitting on change is one endpoint and costs nothing.

Fourth, the site that ships nothing. New build, or a theme that emits no markup.

You have no estate to audit, so the question inverts. What is the floor?

Organization on the home page. WebSite on the home page too, because a site name preference is live in every language. BreadcrumbList from the template. Product and Offer if you sell things.

That is the whole floor. Nothing else goes on until a feature exists you can earn.

Fifth, the reader who does not own the generator. Wix, Squarespace, a plugin you cannot fork.

Most of this chapter's repair is a template edit and you do not have one. So your version is shorter.

Run the audit to learn what you ship, stop paying anyone to extend it, and take whatever free moves your platform allows.

If you also sell products, the third verdict still stands. The feed fields are worth filling even on a platform you cannot template-edit. The app or the crawl carries them.

What markup actually buys

Three studies, no engine result. All of which would be a reason to stop, except structured data does pay. Just not where it is sold.

One qualifier on that Merchant Center row. If you already push a feed from a PIM, this buys you nothing.

The markup path is for merchants whose product page is the only place the data lives. What it saves is a pipeline, not a listing.

Rich results are the older case. How short is that list now?

HowTo went in September 2023. The sitelinks search box in 2024. Practice problems in 2025. FAQ stopped appearing on 7 May 2026. The documentation came down 15 June.

Notice how that one was announced. No blog post: a changelog entry, and the old URL redirects to it. Which is why the advice outlived the feature.

Now plot the four. One loss a year, four years running. Nothing added for a generative surface.

So name the survivors. Step 2 of your audit needs something to check against.

The features still rendering are the commercial and the calendar ones. Product and merchant listings. Review snippets. Job postings. Events. Recipes. Videos. Breadcrumbs.

Notice what all but one share. What do they describe? A thing with a price, a date or a duration.

Breadcrumbs is the exception. It renders a path rather than a fact.

Which is the rule underneath the gallery. Google renders markup carrying a fact a search result can display, and stops when it does not. FAQPage carried an answer. Answers are what the generative surfaces now do themselves.

So read the current 25 as a ceiling that drops.

Publishers get one more item, too small for Table 7.3. Google states plainly that there is "no markup requirement to be eligible for Google News features like Top stories." What Article buys is better title text, images and dates. Real, and smaller than a feed.

One publisher decision matters more: the paywall. Running a subscription wall? Then set isAccessibleForFree to false and add a hasPart block naming the walled section by CSS selector. Two properties, one decision.

That shows Google the full text without being treated as cloaking.

It changes how a surface treats your content, not how it renders it.

Which puts it in row one, not row three. Search Console carries a Subscribed content report. You can see whether it worked.

Traced to source

Chapter 5 traced five writing prescriptions. Chapter 6 traced five entity claims. Same method, third time.

The first row is worth walking. A Bing product manager spoke at a conference in Munich, March 2025.

An attendee, David Mihm, wrote a LinkedIn post summarizing it: schema markup helps Microsoft's language models understand your content. The product manager replied. His entire reply: "Thanks, please to help all of you."

Two trade publications called it confirmation. There is no Microsoft document behind it.

The nearest thing is that May 2025 Bing post, co-authored by the same product manager. It shows nothing.

And the claim moved in transmission. Mihm's sentence became the field's line that schema is how you talk to AI. One is a remark about comprehension. The other, a claim about a channel.

How many claims in your last schema proposal would survive the walk?

The threads Chapter 6 left here

Two properties exist to say this is the same entity as that one, and Chapter 6 left them here. Start with sameAs, the one every entity retainer bills for.

Google's Organization documentation lists twenty-three properties. Seven are identifiers: DUNS, GLN, ISO 6523, LEI, NAICS, tax ID, VAT ID. Five are numbers somebody issued you. One wraps a number you already have. One you pick from a table.

Google's own gloss for sameAs: "The URL of a page on another website with additional information about your organization, if applicable." Additional information. Nobody issues it, and nobody checks it.

The page never uses the word entity, except inside "Legal Entity Identifier." Knowledge Graph does not appear at all, and no property is marked required.

No threshold to reach.

Nothing to buy.

Now the better thing Chapter 6 handed over. It found Google using the word disambiguate in one place. Its Organization documentation.

What it could not do was price the two codes it names. This chapter can.

Some properties, it says, are used "behind the scenes to disambiguate your organization from other organizations (like iso6523 and naics)."

That is the page's only claim about a function you can act on. Two other properties carry non-rendering language: url "helps Google uniquely identify your organization," and vatID is "an important trust signal for users," who can look you up in a public VAT registry. Neither is something you choose.

Google's own split is two-way. Some properties work behind the scenes, and others "can influence visual elements in Search results."

What the rest do it never says. And it names nothing an entity retainer has ever billed for.

Neither is a registration either. NAICS is an industry code you pick yourself from a public table. ISO 6523 wraps a number somebody already gave you.

Both free.

Both ten minutes.

So the ruling on all seven. Copy across every registered identifier your finance system holds. Then fill in naics and iso6523Code, the two Google gives a function and no rendering. The property carries the Code suffix even though Google's prose drops it. Do not obtain a number you do not have.

One limit, held to the same standard this chapter holds everybody else to. The documentation locates the disambiguation "in search results" and stops there.

No feature named. No measurement. Nothing you can look at.

We print it because it costs nothing. Not because anybody has shown it does anything.

That is Chapter 6's finding, cashed.

Then @id, which Chapter 6 also left open. Google documents it in several places, and every one is plumbing.

Joining a Product to its shipping and return policy nodes, so you write the policy once. Linking loyalty tiers. Linking a recipe and a video "on the page," so the video can appear inside a Recipe rich result.

Some of it does cross a page boundary. Merchant listing uses @id to point an Offer at your global return policy, your global shipping policy and your member tiers. Each by absolute URL.

Three cross-page uses. Two point at a policy page you already publish. The third at a members page.

So the honest reading: @id stops you repeating yourself, inside a page and across three named pages you already run. One feed spec you are not in requires it to be globally unique. Nothing documents it as a way to build a site-wide graph.

Which leaves the residue of both. Organization markup helps Google understand your administrative details and render your logo. Two codes help it tell you apart from somebody else. Real, modest, checkable. Not entity construction. Does your invoice say otherwise?

The one rule, and the thing that voids it

One rule sits underneath all of this, from Google's own quality guidelines. Every fact worth marking up has to be visible text on your page.

Two exceptions, both already in this chapter. Identifiers nobody renders, and a paywall block Google documents as the way to show it what a reader cannot see.

Everything else obeys.

That is not a style preference. It costs you rich result eligibility. Google's structured data policies carry a manual action for markup that does not match visible content. A real penalty.

The rule also makes markup work where nothing parses it. If the price sits in your JSON-LD and in your paragraph, the flat-text pipeline finds the paragraph. If only in the JSON-LD, nothing finds it.

So the policy rule and the machine-readability rule are the same rule. Which almost never happens.

Price the cost side first

Nobody prices the cost side, so price it before you defend it.

Three lines, all pullable this week.

The schema line on your last three invoices, agency or plugin subscription. Then engineering hours per template change, times the templates you touched last year.

Then the one nobody books: every price, availability and date exists twice, and somebody keeps the copies in step. Second syntax, second system. Usually a plugin.

Google requires the copies to agree. Merchant Center puts it hardest: structured data "must match the values that are shown to the customer." And the duplicates guidance doubles the surface. Put the same structured data "on all page duplicates, not just on the canonical page."

Which is a template-generator property, not a page one. If your markup is server-side it is already handled. If it arrives through a tag manager it is not.

So the failure mode is not that your markup is wrong. It is subtler. When did your markup last describe this month's price?

Vendors overstate the consequence. A structured data manual action costs you rich result eligibility and nothing else. Anyone telling you schema errors will tank your rankings is contradicting the documentation, in the sentence that describes the penalty.

The thing Merchant Center will not take

One more cost nobody checks. Google Search processes markup injected by JavaScript. Merchant Center does not: the markup "can't be generated with JavaScript after the page has loaded."

So the one binary pipeline here rejects it. Anthropic's web fetch tool cannot see it either. It "currently does not support websites dynamically rendered with JavaScript."

Another free move, then. If the block only appears after render, move it into your server-side template. Step 7 finds out in one command.

What a crawler can execute belongs to Chapter 10.

The installed base is mostly the smallest types

One verdict before the numbers, for anyone on an inherited microdata estate. Do not migrate it.

Microdata is still parsed, and migration is a template rewrite bought with the money this chapter tells you to stop spending. Convert on the next template touch, or never.

JSON-LD is on 41% of pages, up from 34% two years earlier.

That is the 2024 Web Almanac.

Now the four commonest on mobile. WebSite: 12.73%. Organization: 7.16%. BreadcrumbList: 5.66%.

LocalBusiness: 3.97%.

WebSite powered the sitelinks search box, retired in November 2024. It is also how you state a site name preference, live in every language on both devices. Organization renders a logo. BreadcrumbList renders a trail. LocalBusiness renders a panel.

Each buys one small rendering. Each is real. Then Product, the binary row, at 0.77%. So the web deployed the markup with the smallest payoff. At sixteen times the rate of the largest.

Both shares are measured over all pages, which flatters WebSite. Product only makes sense on a merchant site.

Most companies never chose to deploy schema. A plugin did, or an agency did, four years ago.

So your question is not what to add. What do you keep?

Artifact 7.5 answers that. Keep what earns a report or a documented function. Keep whatever Merchant Center consumes. Delete the rest.

Quote Google's line at whoever objects. Unused structured data "has no visible effects in Google Search."

It is not hurting your rankings. It costs you every time somebody changes a template. One caution before you start deleting. Markup is a template property, not a page property. So audit one page per template, and change it once.

If the estate is genuinely large, the verdict changes shape. Forty templates, a vendor contract, tag-manager deployment.

There, deletion is not the deliverable. Freezing is.

Stop paying for expansion this quarter. Run Artifact 7.5 once, across templates not pages. Delete only on the next scheduled template touch. A deploy you were making anyway is free. One you scheduled for this is not.

A different answer from the one a ten-template company gets. The difference is the cost of the deploy. Not the value of the markup.

The objections this chapter has to answer

One thing to fix before any of them. This chapter is not telling you to cancel markup, only the AI story attached to it, and Artifact 7.5 keeps whatever earns a rich result or a feed.

The first objection, in two halves.

"Absence of evidence is not evidence of absence. Web Data Commons pulls schema.org out of Common Crawl and publishes it as tens of billions of triples, so my markup demonstrably sits in a public dataset model builders use. Nobody has shown it does nothing at the training stage, and you cannot see that stage. And engines have every reason not to tell you. Publishing what moves an answer is publishing a ranking factor."

Both halves are fair. Silence is consistent with markup working, and equally consistent with markup doing nothing.

It cannot be evidence for one. What it settles is who pays for the uncertainty, and right now that is you.

Then weigh what the silence is not made of. The vendor with the most to gain published a study whose section heading says its product does not help.

Not proof.

The strongest thing a schema seller has printed against itself.

The second, and it is the one every CFO raises.

"The markup is deployed. It costs me nothing incremental. Google co-founded schema.org, and if some future protocol adopts it I am ready for free. Your spine is a snapshot of June 2026."

The snapshot point is correct. This chapter counted the doors on one day.

The option breaks on carrying cost, which you priced earlier. Two copies that must agree, forever, against a gallery losing a feature a year.

You are carrying a call option whose underlying keeps shrinking.

A third, built out of our own third leg. "Rank dominates citation odds, and rich results move click-through. So markup buys rank, and rank buys citation."

It breaks at the middle link. Eligibility is not rank, and nobody has published a rich-result-to-rank effect, so the chain has a first step and a last step and nothing in between.

A fourth, and the only one that names a mechanism rather than a result.

"Your truncation evidence is one pipeline's implementation choice. In a grounding step that passes a hundred thousand tokens of raw HTML to a model, my JSON-LD is inside the window. It is also the most token-efficient description of my facts that exists."

A real mechanism, and we cannot rule it out. Nobody has published a grounding step in enough detail to test it.

Two things constrain it. First the visible-text rule, which Google requires anyway. If every marked-up fact is also in your prose, the model has it regardless.

Then searchVIU, from earlier in this chapter. Truncation does not explain that miss. The JSON-LD price sat earlier in the document than the visible price the same systems did return.

One page, one test, and the only one anybody has run on this question.

A fifth, and it is built from this chapter's own sources. It arrives with a preamble worth granting first: the vocabulary really is everywhere. Pinterest documents Rich Pins on schema.org, and every enterprise retrieval stack with an off-the-shelf extractor reads it, because it is the only vocabulary there is.

Granted, and none of those is a surface citing you. Then the objection proper.

"Merchant Center builds a feed from my Product markup. Google's AI guide says feeds are how products get into AI responses. OpenAI takes that feed format. You documented every link. That is markup reaching an AI answer."

Every link is documented, and we printed all three. So concede it: for a merchant, a path exists.

Two things bound it. The hop in the middle is a feed, which is why the instruction here is fill the feed fields rather than expand your schema. And nobody has published what the feed changes in an answer either.

A sixth, from the reader this chapter is hardest on. "I signed a schema SOW three weeks ago. What do I do on Monday?"

Redirect it. The same team does the work either way. Do not cancel it.

Ask for Artifact 7.5 plus a Merchant Center feed check, not a site-wide expansion. Smaller scope, same budget, and it returns a number you can read.

Then ask for the origin document behind every claim in the proposal. If those come back as blog posts, you have learned how your retainer was priced.

A seventh, and it is the sharpest thing anyone can say about this chapter. "You refused every claim backed only by a vendor's documentation, then told me to add two properties on exactly that basis."

Correct, and Table 7.3 concedes it in the row itself. The answer is price rather than evidence: ten minutes and zero dollars is a different decision from a retainer.

So that row sits at the bottom of this chapter's confidence order. We put it there ourselves.

Which leaves the one we raise against ourselves. You say the field cannot show a result, so where is ours?

We do not have one, and nobody does. The rule here is about burden rather than evidence: the party proposing the spend produces it, which is why Artifact 7.5 runs on instruments Google hands you free.

Now the disclosure. We sell GEO services, and have billed for schema work.

We are telling you to shrink it to one afternoon. Then notice where the canceled budget goes. Into Part III, where the off-site work lives. A bigger engagement than a schema retainer.

Which is a reason to ask us the question, not a reason to disbelieve the chapter. Ask it.

What is left

A survey published in July 2026 read 45 GEO studies from November 2023 onward. Its conclusion is the right place to stop. No reviewed technique "shows a stable, longitudinal, cross-platform causal effect on organic discoverability."

Not structured data. Not anything else. So keep the markup that buys you a rich result. Keep the markup building your feed.

Make every marked-up fact visible. It is a policy requirement. And the only form a flat-text system can read.

And stop paying for the rest of it. This chapter closes Part II.

Everything since Chapter 4 has been about the part you control completely, and none of it decides whether an engine has heard of you.

Four chapters converge on one instruction. Every fact a machine needs has to be visible prose. Inside a span that survives being cut out of your page.

Chapter 4 got there through chunking. Chapter 5 through vocabulary. Chapter 6 through naming. This chapter got there through a policy rule Google wrote for a different reason. That is the closest thing to a finding this part has.

Not one of the four can tell you what a production engine did with any of it.

One conflict stays open, and pretending otherwise would be dishonest.

In the two studies that put rank and AI-specific work in the same frame, the AI-specific work does not clear its bar and rank does. Neither was built to compare them, which is itself the finding.

Chapter 4 had an escape from that. It said C-SEO Bench measures what happens after retrieval, not whether you get retrieved.

The third leg closes that escape. Fischman is observational, on live engines. Rank dominates at the retrieval end too.

We have half an answer, and it is the one from earlier: an observational rank coefficient cannot separate rank from whatever produced the rank.

That weakens the argument. It does not dispose of it. Nothing in these four chapters does.

Three debts leave this chapter unpaid, named so you can hold us to them.

Markup injected by JavaScript has an address, and it is Chapter 10.

Head placement needs a test somebody can run: the same page, published twice, block in the head and block in the footer, then ask the engines. We have not run it.

And the Bing parser path to Copilot has no address at all. Nobody outside Microsoft can settle it. So it stays open for the life of this book.

Now the thing Part II could not answer. Every audit assumes a system that has already retrieved your page. Chapter 8 owes you the step before that. Why a model names some brands and not others.

Chapter 8 is about the part you do not own. That is the debt this part hands over.