All guides

Structured data: what it does and what it does not

Development6 min read

Structured data is a block of JSON in your page that states, unambiguously, what the page is about. That this string is a product name, that number is a price, that date is when the event starts.

Google publishes measured results from sites that added it. Rotten Tomatoes saw a 25% higher click-through rate on pages with structured data. Nestlé measured an 82% higher click-through rate on pages appearing as rich results against pages that did not. Food Network converted 80% of their pages and recorded a 35% increase in visits. Rakuten found users spent 1.5 times longer on pages with it.

Those are Google’s own case studies on Google’s own documentation, so read them as directionally useful rather than independent. The mechanism behind them is straightforward enough to trust.

What it actually buys you

Structured data does not improve your ranking. Google has been consistent on this and it is the most common misconception in the field.

What it does is change how your result looks once you already rank. Star ratings, prices, stock status, FAQ dropdowns, event dates, recipe cook times, breadcrumb trails. A result that occupies more vertical space and carries real information will out-click a plain blue link sitting in the same position, which is the whole mechanism.

So it moves click-through rate, never position. Position five with rich results can out-earn position three without.

There is a second use now. Assistants and AI search systems parse structured data to extract facts, because it is the one part of your page that states things without ambiguity. Prose says “we open at nine most days”. Structured data says "opens": "09:00". We covered the rest of that in getting cited by AI search.

Use JSON-LD

Three formats are supported. Google recommends JSON-LD and describes it as the easiest to implement and maintain at scale, and less prone to error than the alternatives.

The reason is separation. Microdata and RDFa weave attributes through your HTML, so any markup change risks breaking the data and any data change means touching the template. JSON-LD sits in a single <script type="application/ld+json"> block in the head, independent of your layout. Move a div and nothing breaks.

Generate it from the same source as the visible content rather than maintaining it separately, because two copies of a price will disagree eventually, and a disagreement is worse than an absence since mismatched markup is the specific thing Google penalises.

Which types are worth doing

Most sites need fewer than they think.

Organization on the home page, covering name, logo, URL and social profiles, feeds Google’s knowledge panel. LocalBusiness instead if you have a physical location, with address and opening hours. Article on anything editorial, with a real published date and an author. BreadcrumbList on anything nested, which produces the path display in search results and is cheap to add. Product with price and availability if you sell things. FAQPage where you genuinely answer questions, though eligibility for FAQ rich results has narrowed considerably and it is worth checking current guidance before investing.

That covers the great majority of sites. Marking up every entity you can find produces bloat and no additional benefit.

Where it goes wrong

Marking up content that is not on the page is the violation Google acts on. Review stars in structured data with no reviews visible, FAQ markup for questions nobody can see, a price in the JSON that differs from the price on screen. This gets manual actions, and manual actions are much harder to recover from than a ranking dip.

Stale data is the quieter failure. An event that finished in March still marked as upcoming, or availability that says in stock for a product discontinued last year. If the data is generated from your database this cannot happen, and if somebody pasted it into a template by hand it eventually will.

Then there is validation. Test with Google’s Rich Results Test rather than a generic schema validator, because they answer different questions. A generic validator confirms your JSON-LD is well formed, while the Rich Results Test tells you whether Google will actually use it, which is the thing you care about.

Adding it

If your site renders on the server, this is a small job. Build the object from the data you already have, serialise it, drop it in the head. Our own approach to that is part of why we build content sites the way described in why Astro is a great framework for simple content sites, where the page is assembled at build time and the structured data comes from the same source as the visible text.

Multiple blocks on one page are fine and often correct, and an article page reasonably carries Organization, BreadcrumbList and Article all at once, describing three different things.

After deployment, watch Search Console. The Enhancements reports show which types Google detected, how many pages are valid, and which have errors. That report is the feedback loop, and it takes a few weeks to populate, so add the markup and check back rather than judging it the next morning.

Worth an afternoon

Run three of your important pages through the Rich Results Test and see what Google currently detects. Most sites we look at have nothing, or have Organization markup from a theme with a logo URL that 404s.

Fixing that is an afternoon of work with a measurable result in Search Console within a month. It sits alongside the development work we do on most builds. Get in touch if you would like it checked.

References