Does Schema Markup Improve Rankings? A 14-Page Test

By Ugur Saritepe · October 28, 2026

Schema markup did not move rankings in any way we could measure. We moved 14 list pages on game-scout.app to a template with BlogPosting markup and real dates, and only one of them was a clean test. That page grew faster than the median page of its age, and 4 of the 14 untouched pages beside it grew faster still.

The question

game-scout.app is my other site, a catalogue of curated PlayStation lists. In late August we built a second template for those lists, called v2. On the page it looks the same. Underneath it adds a BlogPosting node next to the existing ItemList markup, and it stamps the real last-edit date from git into both the markup's dateModified and the sitemap. Before, the date was typed by hand, and one list still says it was updated on 4 August though it was last edited on 12 September.

Seven weeks later, while planning a template test on a different list, I asked the assistant I work with:

can we check a little bit v2 migration. Does it make any difference on pages migrated so far ?

It answered in about a minute: no measurable effect yet, two pages worse than similar lists and one better. I re-ran it a few hours later to write this up. The answer held, but not for the reasons first given.

Fourteen migrated pages, one clean test

59 of the site's 128 lists are on v2. 45 were built on it, so they have no before. 14 were moved from the old template, and six of those moved on 11 and 12 October, too recently to read. That leaves eight. Then I read the eight commits:

page                    moved    what else changed in the same commit
hunting                 08-31    title and meta description rewritten
horror, zombie,         09-01    copy rewritten in a new voice
survival, vampire,
games-like-last-of-us
open-world              09-03    editorial changes; 22 impressions before
post-apocalyptic        09-13    nothing: 4 lines added, 1 removed

Seven of the eight changed the markup and something a reader sees at the same time. A title rewrite or a copy rewrite is a bigger change than a new JSON-LD node, so any movement on those pages cannot be credited to the schema. The session's table labelled hunting "migration only". The commit says otherwise. One page, the post-apocalyptic list, is a pure migration. Even that one changed three things together: the new markup node, the dates inside the markup, and the sitemap's date. The v2 design doc itself says the sitemap date is "the only mechanism in this spec with a documented effect on crawl".

Why a plain before and after flatters the change

These lists were one to two months old when they moved, and young pages on this site grow on their own as Google tests them in more searches. On top of that, the whole site had a surge in early September:

sc-domain:game-scout.app, page contains /best/, 2026-09-01 to 09-21 vs 2026-08-10 to 08-30

all list pages   impressions 62,753 -> 95,232   (x1.52)
hunting          impressions  2,115 ->  3,298   (x1.56)   position 8.9 -> 9.2

Hunting grew 56% after its migration, which sounds like a win until you see every list grew 52% in the same three weeks. So each migrated page needs a comparison group: pages that did not change, over the same days, that were the same age.

The control group decided the verdict

The first read in the session compared hunting against similar lists that grew 2.14 times, and last-of-us against 2.08 times, and called both worse. The transcript does not say how those groups were chosen. So I wrote a rule down before I compared anything: lists never migrated, created within 14 days of the page by git, with at least 100 impressions in the before window.

page               page    controls   median   controls that grew faster
hunting            x1.56      13       x1.50         5 of 13
last-of-us         x1.41      25       x1.24        10 of 25
zombie             x1.01      13       x1.22         7 of 13
post-apocalyptic   x2.12      14       x1.24         4 of 14

Under that rule, the two pages first read as worse sit at or above the middle of their groups. Same pages, same Search Console, same windows. Only the comparison changed, and the verdict flipped. That is what a small effect looks like: the noise between untouched pages is bigger than anything the change did, so whichever group you pick writes the conclusion.

The one clean page

sc-domain:game-scout.app, page contains /best/best-, 2026-09-14 to 10-04 vs 2026-08-23 to 09-12

post-apocalyptic   impressions 362 -> 768 (x2.12)   clicks 5 -> 11   position 10.3 -> 9.2
14 same-age lists  median x1.24, range x0.34 to x5.81

The post-apocalyptic list more than doubled while the site as a whole dipped 6%. That is the best result in the set, and it still sits inside the spread of pages we did not migrate: the parkour and dinosaur lists each grew 5.8 times in the same three weeks with no edit of their own. Three caveats on this pull. It was capped at 60 rows, so a few controls with falling traffic may be missing, which would make the median lower, not higher. The controls were not clean either: 7 of the 14 had their own edits in the window, mostly retitles on 28 August. And one page cannot separate the markup from the fresh sitemap date.

What the ranked pages say

I read the pages ranking for this question on 2026-10-18. Most of them state Google's line that schema is not a ranking factor, and two Reddit threads in the top five repeat it. Google's introduction to structured data describes it as a way to become eligible for rich results, and says nothing about rank. The one real test in the top ten, a study on 29 local-business sites, used a control group and found no effect on rank or Maps. None of them shows one site's own pages against untouched pages of the same age, or what happens to the answer when the comparison changes.

This matches what we saw when the page update came before an impressions drop and when pages lost rankings with nothing changed: on this site, the movement of pages nobody edited is large enough to hide most single changes.

What we have not done

We have not run the test we planned on 3 October, a template change on the co-op RPG list alone. Our co-op RPG list still says it was updated on 4 August, and we have not fixed it. The six lists moved on 11 and 12 October each had their copy rewritten in the same commit, and we have not read them; they are readable around 1 November and will carry the same confound as the first seven.

How to test a schema change on your own site

1. Change only the markup, in its own commit. Good: the diff touches JSON-LD and nothing a reader sees. Bad: a new title ships in the same deploy. Seven of our eight readable pages failed this.
2. Pick pages with a real before. At least 100 impressions in the 21 days before the change, or the ratio is noise.
3. Write the control rule down first.Same age, same section of the site, no edits of their own in either window. Write it before you pull, because we got two verdicts from two groups, and check the controls' commits too: ours had retitles in them.
4. Compare the page to the spread, not to one number. Count how many untouched pages grew faster. If it is more than a handful, you have not found an effect.

If the markup itself might be broken, the free triage report lists the structured data types it finds and flags invalid JSON-LD. The rest of these measured reads are in the AI-assistant SEO series.

FAQ

Does schema markup improve rankings?

Not in any way we could measure on our own site. We moved 14 list pages on game-scout.app to a template that adds BlogPosting markup and real modified dates. Only one of the 14 changed nothing else in the same commit. Its impressions grew 2.12 times in the 21 days after, against a median of 1.24 times for 14 pages of the same age, but 4 of those 14 untouched pages grew faster. One page inside that spread is not evidence either way. Google's own introduction to structured data talks about rich results, not ranking.

How do I test whether a schema change helped my rankings?

Change only the markup, in its own commit, on pages old enough to have a stable before. Then compare each changed page against untouched pages of the same age over the same 21 days, using a control rule you write down before you look. A young page grows on its own, so a plain before and after flatters any change made to it.

Why did a different comparison give a different answer?

Because the control group decides the verdict when the effect is small. An assistant read two of our migrated pages as falling behind similar pages that grew about 2.1 times. With controls limited to pages created within 14 days of each one, the same two pages sat at or above the median. Nothing about the pages changed between the two reads; only the comparison did.

Is structured data still worth adding?

For what Google says it does, yes: rich result eligibility and helping Google understand the page. Ours also fixed a real problem, a date that said August on pages edited in September. Add it for those reasons and expect no ranking change you can see.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works