Structured Data: What Search Engines Actually Use It For

It buys eligibility, and eligibility is not a promise

The mental model that causes the most disappointment is the one where markup is a lever: add schema, get a boost. It is not that. Structured data is a translation layer. Your page says, in prose meant for a person, that this article was written by Camille Laurent on 18 August and updated in September. The markup says the same thing in a form a parser can read without guessing. Nothing new enters the page; the machine simply stops having to infer.

What that translation buys is a specific, bounded thing: eligibility for a rich result. Google's own guidelines put it in a highlighted note — it does not guarantee that your structured data will show up in search results, even if your page is marked up correctly. Whether the feature is drawn depends on the query, the device, the layout of that particular results page and on whether Google currently trusts your site enough to render it. Correct markup moves you from ineligible to eligible. Nothing about it moves you up a position.

The clearest confirmation that markup and ranking are separate systems comes from the penalty side. Google describes a structured data manual action as something that makes a page lose eligibility for appearance as a rich result, and states that it does not affect how the page ranks in web search. Two independent dials. If markup could push rankings up, abusing it would push rankings down — and the documented penalty does no such thing.

JSON-LD won, and the reason is maintenance

There are three syntaxes for putting schema.org into a page. Microdata and RDFa are attribute-based: you sprinkle itemscope, itemprop and typeof onto the HTML elements that already contain the values, so the markup lives inside the markup. JSON-LD is a self-contained block, a script tag of type application/ld+json holding an ordinary JSON object, usually dropped in the head or at the end of the body. All three are parsed. Google recommends JSON-LD for structured data if your site's setup allows it, and calls it the easiest solution for website owners to implement and maintain at scale.

The reason is not elegance, it is coupling. Attribute-based markup is welded to the DOM: change the template, move the price into a different component, let a designer swap a span for a div, and the itemprop goes with it or quietly disappears. JSON-LD is decoupled from the presentation entirely, which means it survives redesigns, can be assembled server-side from the same data that renders the page, and can be diffed in a pull request as one readable object rather than as fifteen attributes scattered across a template. That decoupling is also its danger, and the next-but-one section is about exactly that.

Which types still produce something you can see

This is where most published advice has gone bad, so check the date on anything you read, including this. Google maintains a gallery of the structured data types it supports, and that gallery is the only authority worth trusting on the question. Today it lists Article, Breadcrumb, Product, Event, Recipe, Video, Job posting, Local business, Organization, Review snippet, Q&A, Dataset, Software app, Vacation rental, Discussion forum, Profile page and a handful of others. Two names that used to be on every SEO checklist are not on it.

HowTo is gone. Google withdrew HowTo rich results during 2023, from mobile first and then from desktop, and removed the documentation. FAQPage lasted longer but is gone too: from August 2023 it was narrowed to well-known, authoritative government and health sites, and on 7 May 2026 it stopped appearing altogether. The FAQPage documentation was removed on 15 June 2026, and the reporting around it — the search appearance filter, the rich result report, Rich Results Test support — followed. If a checklist tells you to add FAQ schema for the extra real estate in the result, that checklist is at least a year out of date and probably three.

That does not make the markup worthless, and it does not mean you should rip it out. Google's guidance on retired features is that you do not need to remove them, because other search engines and services may still be using them. Schema.org is a shared vocabulary, not a Google product; assistants, aggregators, other engines and an increasing number of language-model retrieval pipelines parse the same JSON. The honest framing is that FAQPage and HowTo have moved from a visible, measurable payoff to a speculative one — which is a real change in how much engineering time they deserve.

Required versus recommended, for the three that still pay

Article is the surprising one: it has no required properties at all. Google's guidance is to add the properties that apply to your content, and lists author, datePublished, dateModified, headline and image as recommended. That is not permission to skip them. A recommended property is one whose absence does not invalidate the object but does reduce what any consumer can do with it — an Article with no author is an Article that cannot support an author byline anywhere downstream. Supply the ones you can supply accurately, and Google's own advice is to prefer fewer complete and accurate recommended properties over every possible property filled in badly.

BreadcrumbList is the strictest of the three and the cheapest to get right. It requires itemListElement, an ordered array of ListItem objects, and each ListItem requires position and name. The item property — the URL that breadcrumb points to — is required on every entry except the last, where Google falls back to the current page's URL. The list must contain at least two ListItems to be shown; a one-item breadcrumb is not a trail. This is the type with the highest ratio of visible effect to implementation effort, because it swaps an ugly URL in the result for a readable path, and because on a site with a disciplined URL structure the trail can be generated from the path itself.

Product sits in the middle. For a product snippet the required properties are name plus at least one of review, aggregateRating or offers — you only need one of the three. In practice offers is the one that earns its keep, because a price and an availability state inside the result answer the two questions a shopper has before clicking. Note the warning the Rich Results Test may raise if you supply offers with no rating at all: it is a warning, not an error, and inventing a rating to silence it is exactly the behaviour the next section is about.

The rule that decides everything: mark up what is visible

Google's structured data guidelines contain one instruction that causes more manual actions than every technical mistake combined: do not mark up content that is not visible to readers of the page. It sounds obvious until you notice how easy JSON-LD makes breaking it. The block sits apart from the HTML, is generated by a template, and is never rendered — so nobody on the team ever looks at it side by side with the page. That is precisely why it drifts.

The failure modes are mundane, not malicious. A product template emits aggregateRating from a catalogue field while the page shows no reviews because none have been written yet. A pricing page renders a price server-side after a currency lookup, but the JSON-LD was built from the base price and now disagrees with what the visitor reads. An article block carries a dateModified that the CMS bumps on every republish while the page displays the original date. Each of those is markup describing something the reader cannot verify, and each of them is the same violation as deliberately faking five stars.

The engineering fix is a single principle: never build the JSON-LD from a second source of truth. Assemble it from exactly the same objects that render the visible page, in the same request, so that a value cannot appear in one and not the other. If the price shown comes from a formatted string, derive the markup's price from the number behind that string, not from a separate query. Then add one test per template that asserts every marked-up value appears somewhere in the rendered HTML. That test catches template drift on the day it happens rather than in a Search Console message three months later.

Testing: three tools, three different questions

The schema.org validator answers the vocabulary question: is this valid schema.org, are the types real, are the properties spelled right, do the nested objects fit their expected ranges. It knows nothing about Google. The Rich Results Test answers the eligibility question for Google specifically: given this markup, is the page eligible for a feature Google currently supports, and which required property is missing if not. Search Console's rich result reports answer the third and most important question: what is happening on the live site at scale, across every URL, after the template shipped.

Use them in that order and stop at the third. Google's own advice is to test during development and then monitor validity after deployment, because problems appear post-deployment through templating and serving issues that no pre-flight check can see. A page that passed the Rich Results Test on a developer's laptop can fail in production because a caching layer strips the script tag, because a consent banner delays rendering past the point the crawler gave up, or because one category out of forty has a null in the field that feeds name.

Frequently asked questions

Is structured data a ranking factor?

No. Markup makes a page eligible for rich results; it does not move the page up or down in ordinary web results. The clearest evidence is the penalty: Google describes a structured data manual action as costing a page its eligibility to appear as a rich result while explicitly not affecting how it ranks in web search. Two separate systems. Any indirect benefit comes from a more informative result attracting more clicks, not from the markup being scored.

Should I remove FAQ and HowTo schema now that they produce nothing?

No, and Google says so explicitly for retired features: you do not need to remove them, because other search engines and services may still be using them. Schema.org is a shared vocabulary that Google does not own. What should change is your budget, not your HTML — stop building new FAQ markup expecting a visible payoff in Google, and stop reporting on a feature whose Search Console report no longer exists. If the markup is already generated by a template that costs nothing to maintain, leaving it is the cheaper decision.

My markup is valid and the Rich Results Test passes, but no rich result appears. Why?

Because passing the test proves eligibility, and eligibility is not display. Google states it does not guarantee that structured data will show up even when a page is marked up correctly. The decision depends on the query, the device, the layout of that specific results page and on Google's confidence in the site. There is no lever to pull. The productive response is to confirm the page is indexed at all, confirm the report in Search Console shows the item as valid in production rather than only in the test tool, and then wait — display often begins weeks after the markup was first crawled.

Can I put the JSON-LD in the head, or must it be in the body?

Either works. Google parses the script tag wherever it appears in the document, and there is no ranking or eligibility difference between the two positions. What matters far more is whether the tag survives to the crawler at all. If the block is injected by client-side JavaScript, it depends on rendering completing, which introduces a failure mode that server-rendered markup does not have. Emit it server-side if your stack allows it, and if it must be client-side, verify with the URL inspection tool that the rendered HTML Google sees actually contains it.

What exactly gets a site a structured data manual action?

Markup that describes something the reader cannot see. Google's guidelines say plainly not to mark up content that is not visible to readers of the page, and hidden marked-up content is listed as a reason data will not appear. In practice the offences are ratings for products with no reviews on the page, prices that do not match the price shown, types that do not match the page's actual purpose, and dates the CMS invents. The consequence is loss of rich result eligibility, not a ranking drop — but eligibility is the entire reason you added the markup.

Does a schema markup generator produce something I can ship as-is?

It produces a correct skeleton, which is genuinely the tedious half of the job — the right type, the required properties present, the nesting valid, the JSON well formed. What it cannot do is know your page. Two things remain yours: checking that every value you paste in is a value visible on the rendered page, and wiring the block to your data so it stays true after the next content change. A generator is the right tool for a one-off page or a first template; it is the wrong tool for a catalogue of forty thousand products, which needs generation from the same objects that render the page.