Structured data is one of the few technical SEO jobs where the work is small, the rules are published, and the outcome is checkable. It is also one of the most commonly botched — usually by marking up things the page does not actually show, or by implementing types that no longer produce anything.
The key point up front: schema markup is not a ranking lever. It is a translation layer. It restates what is already on your page in a vocabulary machines parse without guessing, which can make your listing eligible for a richer presentation and helps engines resolve who and what a page is about. Eligibility is not the same as display — engines decide what to show — and adding markup to a thin page does not make it a good page. Treat it as clarity, and the returns are real: better-looking listings, better click-through, and fewer misreadings of your entities.
What structured data actually is
Schema.org is a shared vocabulary — a set of types (Article, Product, LocalBusiness, Person) and properties (name, author, price, openingHours) that search engines agreed to understand in common. Structured data is that vocabulary embedded in your page.
Three encodings exist: JSON-LD, Microdata, and RDFa. Use JSON-LD. It is Google's stated preference, it sits in a single <script type="application/ld+json"> block in the head or body, and — crucially — it is decoupled from your HTML. Microdata forces you to thread attributes through markup that designers will eventually rearrange; JSON-LD survives a redesign.
That decoupling has a catch, and it is the single most important rule in this article: the markup must describe what a user actually sees on the page. Because JSON-LD is invisible, it is trivially easy to declare a price, a rating, or an author that appears nowhere on screen. Google's structured data guidelines prohibit exactly that, and violations can attract a manual action against the site's rich results. If it is not on the page, it does not go in the markup.
The types worth implementing first
Most sites need a small handful. Ordered by how reliably they earn something:
Organization (or LocalBusiness). One block, usually on the homepage, declaring the entity behind the site: legal name, logo, URL, contact points, and sameAs links to the profiles you control. This is the cheapest markup on the list and the most useful, because it is what an engine consults when deciding which real-world entity your domain corresponds to. LocalBusiness extends it with address, geo coordinates, and openingHoursSpecification — implement that instead if you serve customers at a physical location.
BreadcrumbList. Declares the page's position in your hierarchy and can replace the raw URL in the search listing with a readable path. It is low effort, it rarely breaks, and it reinforces the site structure you already built.
Article / BlogPosting / NewsArticle. For editorial content: headline, images, datePublished, dateModified, and author as a Person or Organization object rather than a bare string. The author field matters more than people assume — a linked, described author entity is far more legible than a name in text.
Product with Offer. For anything sold. Requires the fields a shopper needs: name, image, price, priceCurrency, and availability. Note the distinction between a merchant listing (you sell the item, so full offer data is expected) and a product snippet (you review or list it). Marking up the wrong one produces errors at scale.
Review and AggregateRating. Powerful and heavily policed. Self-serving reviews — a business marking up ratings of itself, on its own site — are not eligible for review rich results. Ratings must be genuinely collected, visible on the page, and about the specific item marked up.
Event, JobPosting, Recipe, VideoObject. Implement these when the content type genuinely matches. Each has its own required-property list, and each is worth checking against current documentation before you build, because required fields change.
The types that no longer do what people think
This is where a lot of stale advice lives, and implementing from an old tutorial wastes real effort:
- FAQPage markup no longer produces FAQ rich results for most sites. Google restricted that display to well-known authoritative government and health sites. The markup is still valid and still describes your content accurately — just do not implement it expecting the expanded accordion in the results page.
- HowTo rich results were similarly deprecated. The same logic applies: valid vocabulary, no visual payoff.
- Speakable remains limited in scope and availability.
None of these are harmful. They are simply not the win they were, and if you are prioritising a fixed number of engineering hours, Organization, BreadcrumbList, and your primary content type earn more.
Writing JSON-LD that survives contact with a real site
A few practices that separate markup which keeps working from markup that quietly rots:
Generate it, don't hand-write it. Markup should be produced by your template from the same data that renders the visible page. Hard-coded JSON-LD drifts the moment a price or a date changes, and drift is what triggers mismatch errors.
Use @id and connect the graph. Give your organisation a stable @id (a URL fragment such as https://example.com/#organization) and reference that @id from your article publisher and product seller properties instead of repeating the whole object. One canonical definition, referenced everywhere, means one place to update.
One @graph per page, not five scripts. Multiple JSON-LD blocks are technically legal, but sites that accumulate them — one from the CMS, one from an SEO plugin, one from an e-commerce extension — end up declaring the same entity three different ways. Consolidate.
Match the canonical. URLs inside your markup should point at the canonical version of the page, agreeing with your rel=canonical, your internal links, and your sitemap. Contradictory signals are the theme running through most indexing problems, as covered in how to use canonical tags correctly.
Absolute URLs everywhere. Relative paths in JSON-LD are a reliable source of silent failure.
Render it server-side where you can. Markup injected by client-side JavaScript can be picked up, but it adds a dependency on rendering. If the markup matters, put it in the initial HTML response.
Validating and monitoring
Three tools, three different jobs — use all three:
- The Rich Results Test checks whether Google can parse your markup and whether the page is eligible for a specific rich result type. This is your pre-launch check. Test a live URL, not a paste, so you catch rendering issues.
- The Schema Markup Validator (validator.schema.org) checks conformance to the schema.org vocabulary generally, without Google's eligibility filter. Useful when you are marking up something no rich result exists for and you still want the syntax right.
- Search Console's enhancement reports are the only one that tells you the truth at scale. A template error affects every page built from it, and you will not find that by spot-checking three URLs. Check these reports after any template deployment, and treat a sudden spike in "invalid items" as a release regression.
A sensible cadence: validate one URL per template before shipping, then watch Search Console for a fortnight afterwards.
Why this is worth more than it used to be
The immediate case for structured data has always been rich results. The broader case has grown: search increasingly involves systems that need to resolve entities — to know that the organisation on this page is the same one on that profile, that this author is a person with a body of work, that this product has a specific price and availability right now.
Prose is ambiguous to a parser. A declared, connected entity graph is not. That is why Organization with proper sameAs links and a consistent @id has become the highest-value block on most sites, well ahead of chasing whichever rich result is currently fashionable. It is the same foundational logic behind everything in our technical SEO guide: make the machine's job unambiguous, and stop spending your crawl and comprehension budget on guesswork.
FAQ
Does schema markup improve rankings?
Not directly. It makes a page's meaning explicit and can make it eligible for richer search listings, which often lifts click-through. Treat it as clarity and presentation, not as a ranking factor.
Which format should I use — JSON-LD, Microdata, or RDFa?
JSON-LD. It is Google's preferred format and it lives in a self-contained script block, so a front-end redesign does not break it. The others require attributes woven through your HTML.
Can I mark up content that isn't visible on the page?
No. Google's guidelines require structured data to represent the page's visible content, and marking up hidden or absent information can trigger a manual action against your rich results. Add the content to the page first, then describe it.
Is FAQ schema still worth adding?
Not for the rich result — that display was restricted to authoritative government and health sites. The markup remains valid and accurately describes your content, so keep it if it already exists, but do not build it expecting expanded listings.
How do I know if my markup is working?
Validate individual URLs with the Rich Results Test before launch, then watch the enhancement reports in Search Console. Only the reports reveal template-wide errors, which are the ones that actually cost you.
Next step
Structured data rewards restraint. Implement Organization or LocalBusiness once and connect it properly, add BreadcrumbList, mark up your primary content type with the fields your page genuinely displays, and skip the deprecated types entirely. Then validate one page per template and let Search Console tell you what broke.
If you want the rest of the foundations in place first, the small-business technical SEO checklist covers what to fix before markup is worth your time. For more practical, vendor-neutral guidance on technical SEO and healthy domains, visit myqsd.com.
