Technical SEO

Schema Markup for AI Search: What Moved and What Didn't

·2026-08-29·17 min read
Editorial illustration of a webpage being read by a machine. A document panel sits at the centre with labelled JSON-LD tags attached to it, and two divergent measurement lines run away from it - one rising sharply and one staying flat - representing the gap between site-wide gains and the isolated schema cohort.

There is a version of the schema markup argument that has been repeated so often it now reads as settled: add structured data, become legible to AI engines, get cited more. Every guide on the first page of Google for this topic says a variant of it. The AI Overview for the query assembles the same claim from twelve sources.

We believed it too. On 7 May 2026 we deployed a full schema stack across our own site in a single commit - 91 application and library files touched, Article and Organization and Person and BreadcrumbList and FAQPage and ImageObject wired through the templates that render roughly 110 blog posts and 31 case studies. It was the largest single structured-data change we have ever made to a property we control.

Then we measured it properly, which is the part that almost nobody publishes.

This post is that measurement. Ninety days before against ninety days after, pulled from the Search Console API rather than screenshotted from the dashboard, cut into cohorts so that pages whose content changed are separated from pages where only the markup moved. The headline is not the one we expected, and it is not the one we would have chosen for a sales page. On our cleanest cohort, schema did nothing measurable. Site-wide, a great deal moved and almost none of it is honestly attributable to the markup.

The useful finding is underneath both of those, and it changed how we sequence structured data work for clients.

The Short Answer

Deploying a full schema stack did not lift click-through rate on the one cohort where we could isolate it. Twenty-seven case study pages received Article, Organization, Person, BreadcrumbList, FAQPage and ImageObject markup on 7 May 2026 and had no content changes in the measurement window. Their click-through rate moved from 0.416% to 0.389%, a decline of 6.4%, and their average position worsened slightly from 7.10 to 7.40.

Across the whole site over the same period, click-through rate rose from 0.195% to 0.310% on pages present in both windows, a 58.7% increase at essentially flat average position. That is a real and large gain. It is also not evidence for schema, because we published 118 new blog posts, consolidated 17 URLs through redirects, and rewrote a large share of the service pages in the same window.

The changes that plausibly did contribute were the ones that resolved identity rather than the ones that produced rich results: consolidating every author reference to a single Person @id, completing the Organization sameAs chain, and putting BreadcrumbList on every page. The changes that produced nothing detectable were the decorative tier - expanded FAQPage markup most of all.

If you take one operating rule from this: schema is an accuracy control, not a visibility lever. Budget it as the thing that makes an engine describe you correctly, and stop budgeting it as the thing that makes an engine choose you.

What We Actually Shipped, and When

Most schema case studies are unfalsifiable because they never state what changed or when. Here is our deployment log, taken from the commit history rather than from memory.

DateChangeScope
17 Apr 2026Initial site-wide SEO/AEO implementation41 service pages, 76 blog posts
2 May 2026AEO and GEO pillar page with Service schema1 page
7 May 2026Full schema enrichment commit91 app and lib files
7 May 2026Person hub launched, AUTHOR_ADITYA @id rewiredAffects ~110 posts + 31 case studies
8 May 2026Reference and service pillar batch, DefinedTermSet7 new pages
27 May 2026International location pages3 pages
12–23 Jun 2026Partner Center, Dataset and HowTo schema8 routes

The 7 May commit is the one worth isolating. It added, to the case study template alone, Article, two Organization entities, Person, BreadcrumbList, FAQPage, ImageObject and WebPage. Every one of the 31 case studies inherited that template on the same day. Nothing about the visible page changed.

That accident of implementation - a template-level schema change applied to a page set whose content sat still - is the only clean experiment in the whole programme. Everything else is contaminated.

For reference, here is what the site emits today, counted from the source:

Schema typeInstances
Question / Answer pairs441 each
ListItem (breadcrumbs, lists)282
BreadcrumbList104
FAQPage103
Organization101
Service83
Offer23
ImageObject19
Article18
Person8

If markup volume drove AI visibility, a site emitting 441 marked-up question-and-answer pairs should be extremely visible. That is roughly the hypothesis this post tests.

How We Measured It

Two matched 90-day windows either side of the deployment date, with the deployment day itself excluded:

  • Pre: 6 February 2026 to 6 May 2026
  • Post: 8 May 2026 to 6 August 2026

All figures come from the Search Console API on the sc-domain:nicodigital.com property. We used three deliberate constraints.

We restricted every cohort to pages present in both windows. New pages inflate a before-and-after comparison enormously, and we published a lot of them. Of 144 pages that cleared the threshold in both windows, only those are counted.

We required at least 100 impressions in each window per page. Below that, click-through rate is noise dressed as a percentage.

We led on click-through rate at comparable average position, not clicks. Clicks move with demand, seasonality and ranking. Click-through at a stable position is the closest signal Search Console offers to something a markup change could plausibly cause.

Three limitations you should hold against everything below. First, Search Console measures Google organic, not AI answers - we treat it as a proxy and address the gap in a later section. Second, our clean cohort is 27 pages, which is small. Third, this is one site in one market, and our results agreeing with another team's null result is suggestive rather than conclusive.

Finding 1: The Cleanest Cohort Showed No Lift

The 27 case studies that received the full schema stack and no content edits:

MetricPre (6 Feb – 6 May)Post (8 May – 6 Aug)Change
Impressions16,84692,791+451%
Clicks70361+416%
Click-through rate0.416%0.389%−6.4%
Average position7.107.40−0.30 (worse)

Clicks went up more than fivefold, and that number means nothing here. Impressions rose by a similar multiple because the site's overall authority rose, so the page set was being shown far more often. The ratio is what a markup change should move, and the ratio went slightly down.

We ran the four case studies whose content did change in the same window as an informal contrast. Those moved click-through +5.2% and improved position by 0.19. Four pages is too few to conclude anything, but the direction is the one you would expect if content is doing the work and markup is not.

A −6.4% swing on 27 pages is not evidence that schema hurts. Read honestly, it is a null result: the effect, if any, is smaller than the noise in a cohort this size. That matches Otterly.ai's published GEO experiment, which found no measurable influence of schema markup on AI search citation behaviour, and it matches the more cautious framing Search Engine Land has taken on the topic.

Two independent null results do not make a law. They do make the confident version of the claim harder to justify.

Finding 2: The Site-Wide Lift Was Real and Not Attributable

Here is every page present in both windows, and the three sub-cohorts inside it.

CohortPagesCTR preCTR postCTR changePosition change
All pages in both windows1440.195%0.310%+58.7%−0.10 (better)
Blog posts580.172%0.313%+81.9%−1.91 (better)
Service and pillar pages550.159%0.252%+58.8%+1.58 (worse)
Case studies (schema only)270.416%0.389%−6.4%+0.30 (worse)

Site totals over the same period went from 2,361 clicks to 4,896, and from 669,814 impressions to 965,025.

It would be very easy to publish the first row and call it a schema case study. It would also be wrong. In the same 90 days we shipped 118 new blog posts, consolidated 17 legacy URLs through redirects, stripped pricing sections from 52 service pages, and rewrote several pillar pages end to end. The schema change is one of at least five simultaneous interventions, and it is the cheapest one.

The service-page row is the one that gives schema its best case: click-through rose 58.8% while average position got 1.58 places worse. Rising click-through at a declining position is the classic signature of a result presentation improvement. But those same pages received full content rewrites and expanded FAQ sections in the same commits, so presentation improved for reasons that have nothing to do with JSON-LD.

We cannot separate them. Neither can anyone else who ships schema alongside content and then publishes the aggregate.

Click-through change after the schema deployment90 days before vs 90 days after 7 May 2026. Only the bottom cohort had content held constant.0%Blog posts58 pages, content changed+81.9%Service & pillar55 pages, content changed+58.8%All pages144 pages, mixed+58.7%Case studies27 pages, SCHEMA ONLY-6.4%The three cohorts that rose also received new content. The one that did not, did not rise.

Finding 3: Entity Resolution Is Where the Value Actually Sits

If the decorative markup did nothing measurable, why keep any of it? Because a subset of structured data is doing a job that click-through rate was never going to capture.

Before 7 May, our author entity was referenced inconsistently - some pages pointed at an /about-us/#aditya-kathotia fragment, others at an author archive URL. Two identifiers for one human. We consolidated everything onto a single Person @id resolving to a dedicated Person hub, with a complete sameAs chain out to LinkedIn, X and Crunchbase, and referenced that one entity from every Article schema on the site.

That change cannot lift click-through rate. What it does is settle a question the engine would otherwise have to guess at. The mechanics of why this matters are the subject of our entity SEO and knowledge graph playbook, and they are the reason we now sequence structured data work in this order:

  1. Organization with a complete sameAs chain. Who is this company, and which other profiles on the web are the same company.
  2. Person with one stable @id per author. Who wrote this, and is that the same person who wrote the other forty things.
  3. BreadcrumbList on every page. Where does this sit in the site's structure.
  4. Article with an honest dateModified. How current is this, and does the date reflect a real edit.

Those four are invisible. None produce a rich result. All four answer a question an AI engine must resolve before it can name you as a source rather than paraphrase you anonymously.

Everything below that line - FAQPage, HowTo, ItemList, Product - is second tier. Useful when the page genuinely has that structure. Actively counterproductive when the structure gets invented to justify the markup.

Finding 4: The Review Snippet Anomaly We Cannot Explain

The Search Console search-appearance report produced a result we still have not resolved, and we are including it because leaving it out would make this post cleaner and less true.

Appearance typePre impressionsPost impressions
REVIEW_SNIPPET367,3211,752
TRANSLATED_RESULT8,5429,708

Review snippet appearances fell by 99.5%. In the pre window they accounted for 55% of all site impressions, spread across case studies, service pages and blog posts.

Here is the problem: we do not emit review markup anywhere. We grepped the entire application. Every occurrence of AggregateRating in our codebase is either body copy inside a client-facing checklist or a code comment instructing future editors not to add it without verified review data. There is no AggregateRating in any JSON-LD block we ship, and there was none in the pre window either.

So we have a 365,000-impression appearance category collapsing on a site that never produced the markup that category describes. Plausible explanations include a Google-side eligibility change, a reporting reclassification, or attribution from a source we have not identified. We have not confirmed any of them.

We are not claiming we caused this. We are including it because it is the single best argument in this entire post for measurement discipline: if we had found this collapse alongside a traffic decline instead of a doubling, the temptation to write "our schema change broke our rich results" would have been enormous, and it would have been fiction.

Total clicks more than doubled across the same window in which 55% of impressions lost their rich-result appearance. Whatever review snippets were contributing, the site did fine without them.

Finding 5: FAQPage Did Less Than the Content It Marked Up

We expanded FAQ coverage aggressively - from 4 entries to 12 on several pillars, and to 8 entries across 24 service pages, with FAQPage JSON-LD synced to every visible block. The site now emits 441 marked-up question-and-answer pairs.

The honest read on that investment: the FAQs earned their place as content, and the markup around them contributed nothing we can detect.

This should not be surprising. Google restricted FAQ rich results to government and health sites in 2023, which removed the visible payoff for commercial pages. What remains is the argument that marked-up Q&A is easier for an engine to extract - and that argument is really an argument about the writing, not the JSON-LD. A page that answers a question in a clean self-contained paragraph is extractable whether or not you wrap it in schema. We tested which shapes of content actually get quoted in our study of the content formats LLMs cite, and the pattern that predicted citation was passage structure, not markup.

The failure mode to avoid is the one we have seen on client sites repeatedly: FAQ sections written backwards, generated to fill a schema block rather than because a buyer asks that question. That adds thin duplicative content to a page in exchange for a rich result that no longer renders. It is a straightforwardly bad trade.

What This Means for AI Answers Specifically

Everything above measures Google organic. AI answers are a different surface, and Search Console does not report them, so the honest position is that this dataset constrains the schema-for-AI claim without settling it.

What we can bring alongside it is our own measurement of that surface. We ran 62 buyer questions across ChatGPT, Gemini and Perplexity for 13 weeks - just over 7,200 recorded answers across 14 brands. Three findings from that study bear directly on schema:

The surface is too unstable for single-variable attribution. A single check disagreed with itself 39% of the time. Any schema test run against AI answers with fewer than several hundred sampled responses is measuring randomness.

63% of citations pointed at domains the brand does not own. Directories, Reddit threads, review sites and press. You cannot mark up a page you do not control, which caps how much of the citation surface schema can influence at roughly a third of it.

What got cited was not what ranked. Which is also why click-through rate in Search Console is an imperfect proxy for the thing we actually care about.

Separately, our GA4 study of AI search traffic found that AI-referred visitors landed on case studies at 2.6 times the site average - the same page type that showed no schema effect here. Documented proof was doing that work, not the Organization block describing it.

The synthesis we now operate on: schema makes an engine's description of you accurate. Proof, entity consistency and passage structure make an engine choose you. If you want the full architecture rather than the markup layer alone, that is what answer engine optimisation covers, and the distinctions between the three disciplines are laid out in our SEO vs AEO vs GEO breakdown. Engine-specific mechanics differ enough to matter, which we cover for ranking on ChatGPT and ranking on Perplexity.

The Schema Stack We Run Now

Revised after this analysis. Priority order, highest leverage first.

Tier 1 - Identity (do these first, always)

  • Organization on the site root with name, url, logo, and a sameAs array covering every profile you control.
  • Person for each author with one stable @id, referenced identically from every Article. One identifier per human, no exceptions.
  • BreadcrumbList on every page. Cheapest schema you will ever ship and it never stops being useful.
  • Article with a dateModified that reflects a real edit. Fake freshness dates are a trust liability.

Tier 2 - Structure (only where the page genuinely has it)

  • FAQPage where real questions get real answers, synced to a visible block.
  • Service with provider, areaServed and audience on commercial pages.
  • ImageObject with dimensions on hero assets.
  • HowTo only for genuine step sequences.

Tier 3 - Situational

  • Dataset for original research you want cited.
  • DefinedTermSet for glossaries, with per-term anchors. Ours runs on the digital marketing glossary.
  • ItemList for genuinely ranked lists.

Do not ship

  • AggregateRating or Review on your own business without verifiable third-party review data.
  • Offer or AggregateOffer with prices you do not actually publish on the page.
  • FAQPage around questions invented to justify the markup.
The schema stack, in priority orderTier 1 is invisible in the SERP and does the most work for AI answers.TIER 1 · IDENTITYShip these first, on every site, always. No rich results. Highest leverage.Organization + sameAsPerson, one @idBreadcrumbListArticle + real dateModifiedTIER 2 · STRUCTUREOnly where the page genuinely has this structure. Never invent it to fill the markup.FAQPageServiceImageObjectHowToTIER 3 · SITUATIONALDatasetDefinedTermSetItemListDO NOT SHIPAggregateRating without verified reviews · Offer with unpublished prices · invented FAQ questions

We removed pricing and offer markup from 52 service pages for exactly the accuracy reason above, and total clicks more than doubled in the following quarter. Accuracy cost us nothing.

How to Run This Test on Your Own Site

The reason so little honest data exists on this question is that the test is easy to run and easy to run badly. This is the procedure.

  1. Freeze content on a cohort. Pick a page group - a template-level change is ideal - and commit to changing nothing else on those pages for 90 days.
  2. Record the deployment date precisely. Not the sprint, the date. You will need it to cut the windows.
  3. Verify the markup actually renders. Check the deployed HTML, not the source. Validate a sample in the Rich Results Test.
  4. Wait 60 days minimum. Anything shorter reads crawl lag as a null result.
  5. Pull matched windows from the API. Equal day counts either side, deployment day excluded.
  6. Filter to pages present in both windows with at least 100 impressions in each.
  7. Subtract every page whose content, title or internal links changed. This is the step almost everyone skips, and skipping it is what turns a content result into a schema case study.
  8. Compare click-through rate at comparable average position. Not clicks. Never clicks alone.
  9. Report the cohort size. Ours was 27 pages and we have said so four times in this post for a reason.
  10. Check search-appearance types separately for rich-result changes you did not intend.
  11. Sample AI answers directly if AI visibility is the actual goal - Search Console will not tell you.
  12. Write down what else shipped in the window before you attribute anything.

If step 7 leaves you with no pages, you did not run a schema test. You ran a content test with schema in it, which is fine, but it should be reported as one.

What We'd Tell Our Past Selves

Sequence identity before decoration. We spent real effort expanding FAQ markup that produced nothing detectable, while the author-entity inconsistency that actually confused machines sat unresolved for months.

Stop treating markup volume as progress. 441 marked-up Q&A pairs is a number we could put in a deck. It is not an outcome.

Ship schema alone, at least once. One template-level change with content frozen would have told us more than the eighteen months of bundled deployments that preceded it. The only clean data in this post exists by accident.

Expect the honest answer to be smaller than the pitch. The AI Overview for this query confidently states that schema boosts citations. Our data, and the published null results from two other teams, do not support the confident version. The modest version - schema makes machines describe you accurately - is defensible, useful, and worth doing.

Frequently Asked Questions

Not directly, and our own data says the effect is smaller than the industry claims. We deployed a full schema stack - Article, Organization, Person, BreadcrumbList, FAQPage and ImageObject - across 91 files on 7 May 2026, then compared the 90 days before with the 90 days after in Search Console. Our cleanest cohort was 27 case study pages that received the entire schema stack and no content changes at all. That cohort's click-through rate fell 6.4 percent and its average position worsened by 0.30. Site-wide click-through did rise 58.7 percent at essentially flat average position, but we published 118 new posts in the same window, so that lift cannot honestly be assigned to markup. What schema reliably does is make your entities unambiguous, which is a prerequisite for being described correctly by an AI engine rather than a lever that lifts you into its answer.

The ones that resolve identity rather than the ones that decorate a result. In priority order we now run Organization with a complete sameAs chain, Person with a single stable @id for every author, BreadcrumbList on every page, and Article with a real dateModified. Those four answer the questions an AI engine actually has to settle before it can name you: who is this, who wrote it, where does it sit, and how current is it. FAQPage, HowTo and ItemList sit in a second tier - useful when the page genuinely contains that structure, close to worthless when they are bolted onto content that does not. The common mistake is investing in the second tier first because it is the tier with visible rich results attached, then wondering why nothing changed in AI answers.

How do you test whether schema markup actually worked?

You need a cohort whose markup changed and whose content did not, measured over matched windows. Pick a page group that received the schema change, then subtract every page in it whose content, title or internal links also moved during the measurement period. Compare an equal number of days before and after the deployment date, and restrict the cohort to pages that had meaningful impressions in both windows so you are not reading noise. Then look at click-through rate at constant average position rather than clicks, because clicks move with demand and position while click-through at a fixed position is the closest thing to a schema-attributable signal in Search Console. Our own test left us with 27 usable pages out of 31 case studies, which is a small sample and we report it as one.

Does FAQPage schema still do anything in 2026?

It does far less than most implementations assume. Google restricted FAQ rich results to authoritative government and health sites in 2023, so the visible SERP payoff is gone for commercial sites. What remains is extraction convenience: a page that already contains genuine question-and-answer structure is easier for an engine to lift a passage from, and the schema makes that structure explicit. The distinction that matters is direction. Marking up questions your content genuinely answers is mild reinforcement. Inventing questions in order to have something to mark up adds thin content to the page and can make it worse. In our own data the pages carrying expanded FAQPage markup did not separate from pages without it once we controlled for the content rewrites that shipped alongside.

Is structured data required to appear in AI Overviews?

No. AI Overviews and the answer engines routinely cite pages with no structured data at all, because the underlying retrieval works on passages and links rather than on JSON-LD. Google has said as much, and the null-result experiments published by other teams point the same way. The useful framing is that schema is not an entry ticket, it is an accuracy control. Without it an engine still might cite you, but it is more likely to misattribute the author, blend your brand with a similarly named company, or quote a stale figure. With it, the facts it repeats about you are more likely to be the facts you published. That is worth doing, and it is a much more modest claim than the one usually made for it.

How long does it take to see results from schema markup?

Google typically re-crawls and re-processes structured data within days to a few weeks, but the observable effect lags much further because the effect itself is indirect. In our earlier 90-day citation study the gap between shipping a change and seeing it reflected in AI answers ran to several weeks, and the answers themselves were unstable enough that a single check disagreed with itself 39 percent of the time. Practically, do not evaluate a schema deployment before 60 days, do not evaluate it on a single metric, and do not evaluate it at all if you shipped content changes to the same pages in the same window - you will have no way to separate the two and you will almost certainly credit the markup.

Should you remove schema markup that isn't doing anything?

Remove markup that is inaccurate or that misrepresents the page, and leave markup that is merely quiet. Inaccurate structured data is a genuine liability: it can trigger manual action, and more commonly it teaches an engine a wrong fact about your business that then gets repeated. Markup that is simply not producing a visible rich result is a different case, because entity-resolution markup like Organization, Person and BreadcrumbList does its work invisibly. The audit we run is accuracy first - does every claim in the JSON-LD match what a human sees on the page and what is true - then coverage, then finally the decorative types. We stripped a large amount of pricing and offer markup from our own service pages for accuracy reasons and total clicks still more than doubled over the following quarter.

For classic SEO the goal is eligibility for a specific rich result, so the markup is a means to a visible SERP feature and success is measured in that feature appearing. For AI search there is no feature to win, so the goal shifts to disambiguation: making sure a machine reading your page can tell which organisation, which person and which product you mean, and can link those to the same entities elsewhere on the web. That changes what you prioritise. Classic SEO pushes you toward Product, Review, FAQ and HowTo because those render. AI search pushes you toward Organization, Person, sameAs chains and a single stable @id per entity, none of which render anywhere. Sites that carried the first list into the AI era and expected it to work are the ones reporting no effect.

The Bottom Line

Schema markup is worth implementing and it is not worth the claims made for it.

On the only cohort where we could isolate it - 27 pages, full schema stack, content frozen - it moved click-through rate by −6.4%, which is a null result on a small sample. The 58.7% site-wide gain over the same window belongs to 118 new posts, 17 redirects and a great deal of rewritten content, and assigning it to JSON-LD would have been the easier post to write and a dishonest one.

What survives scrutiny is narrower and more useful. Structured data that resolves identity - one Organization, one Person @id per author, sameAs chains, breadcrumbs everywhere - controls whether a machine describes your business correctly. That is a real job, it is cheap, and nothing else does it. Structured data that decorates a result is running on borrowed time now that the rich results it targeted have mostly been withdrawn from commercial sites.

Ship tier one, be honest about tier two, and put the effort you save into the proof and passage structure that actually determine whether an engine picks you.

If you want this audited on your own site - what you emit, what is inaccurate, and which entity inconsistencies are quietly confusing machines - that is a defined piece of work under our technical SEO services, and it is usually the first thing we look at in an SEO audit. The wider programme it belongs to is AI SEO, which sits alongside the rest of our SEO services. If you would rather start with the measurement question than the markup, talk to us about what your current schema is actually telling machines about you.

Further reading from our own testing: what AI search optimisation did to our traffic, tracking AI citations for 90 days, how to measure brand mentions in ChatGPT and Perplexity, why brands are invisible on ChatGPT but ranking on Google, what llms.txt is and whether you need it, and the classic-SEO companion to this piece on schema markup and rich snippet CTR.

Aditya Kathotia

Aditya Kathotia

Founder & CEO

CEO of Nico Digital and founder of Digital Polo, Aditya Kathotia is a trailblazer in digital marketing. He's powered 500+ brands through transformative strategies, enabling clients worldwide to grow revenue exponentially. Aditya's work has been featured on Entrepreneur, Economic Times, Hubspot, Business.com, Clutch, and more.

Want to explore working together?

Let's talk about how we can grow your digital presence and increase inbound business.

WhatsApp