Eligibility, not ranking
Valid markup makes a page eligible for a rich result. Google is deliberate with that word: including every required property qualifies the page for an enhanced display, it does not promise one, and structured data is not a ranking factor in itself.
The gap between eligible and shown is wider than most people expect, and it is not arbitrary. Whether an enhancement appears depends on the query, the device, the country, whether the feature exists in that language, and Google's own judgement about whether it helps in that context. The same page can show stars on one search and not the next.
JSON-LD is the format to use
All three syntaxes — JSON-LD, Microdata and RDFa — are equally acceptable to Google, and JSON-LD is the one it recommends. The recommendation is practical rather than technical.
JSON-LD lives in a single script tag rather than being threaded through the markup as attributes on the elements it describes. That means it survives a template refactor, it can be read in one place by whoever inherits it, and a mistake in it does not disturb the visible page. Microdata couples the description to the presentation, so every redesign risks silently dropping properties.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Robots.txt and sitemaps",
"datePublished": "2026-06-14",
"author": { "@type": "Organization", "name": "DigestSEO" }
}
</script>- One block per entity is clearer than one giant block trying to describe everything on the page.
- Generate it from the same data that renders the page, so the two cannot drift apart.
- It can be injected by JavaScript, but the page still has to render successfully for the markup to be seen.
The markup has to match the page
Describing content a visitor cannot see is a guidelines violation, not a shortcut. Google names both failure modes explicitly: pages built as empty shells to carry markup, and properties asserting facts the page never displays. Either can cost the rich result outright, and a manual action removes it across the site rather than the page.
The most common version of this is not deliberate. A template emits an aggregate rating whose reviews were removed, or a price that a currency switcher changes on the client, or an event date that has passed. Nobody set out to mislead; the markup simply outlived the content it described. That is why generating it from the rendered data matters more than getting it right once.
| Symptom | Usual cause |
|---|---|
| Enhancement never appeared | A required property is missing, so the page is not eligible |
| Enhancement appeared, then stopped | Content changed and the markup no longer matches it |
| Valid markup, still no enhancement | Eligible but not chosen — query, locale or device |
| Enhancement lost across the whole site | A manual action, which is reported in Search Console |
Connecting entities instead of repeating them
Most sites end up describing the same organisation on every page, in slightly different words each time. The vocabulary has a better answer than repetition: give an entity an @id, define it once, and reference that identifier everywhere else.
This matters beyond tidiness. An engine reconciling three subtly different descriptions of your company has to decide whether they are one organisation or three; an explicit identifier removes the guess. The same applies to an author who writes across a site, or a product referenced from both a listing and a review.
sameAs is the other half of that. It points at the profiles and entries that already describe the entity elsewhere — a Wikipedia article, an official social account, a company register. It is not a ranking play; it is corroboration, which is what an engine needs to connect your claim about yourself to something it can check.
Choosing which types to add
The useful filter is short: does a search feature exist for this type, and can the page genuinely earn it? Marking up a type with no rich result attached adds maintenance and changes nothing in the results — the markup is valid, correct, and inert.
Claiming a type the page does not warrant is worse than not marking it up, because it can violate feature guidelines without creating a useful search appearance. A guide article is not a Product. Google stopped showing FAQ rich results on May 7, 2026 and removed the FAQ rich-result documentation in June. This is a reminder that Search features can be withdrawn. Mark up what the page actually is, and check the supported-feature gallery before maintaining markup for a Search feature.
- Identify what the page actually is, in the vocabulary's terms.
- Check whether a search feature exists for that type, and what it requires.
- Emit every required property from the data that renders the page.
- Validate the syntax, then confirm eligibility in the enhancement report.
- Re-check after template changes — that is when markup and content drift apart.