I’m a psychometrician, not an SEO guy. When I got into structured data, I came at it the same way I come at any measurement problem: what are you actually encoding, what does the receiver do with it, and where does the signal get lost? Turns out that frame works pretty well. Structured data is a formalised vocabulary for telling a machine what your content means — not just what it says. And when it’s done right, Google can reward you with rich results: expanded SERP features that are, according to Google’s own case studies, measurably better for clicks than plain blue links.
This is the technical SEO layer where good implementation compounds and bad implementation just quietly does nothing. Let’s be specific about both.
What Structured Data Is and Why Google Wants You to Use It
Structured data is standardised markup you add to a page so that search engines can parse the meaning of your content — not just the words. The vocabulary Google recognises comes primarily from schema.org: a shared dictionary of types (Article, Product, Recipe, FAQ, Person, Organisation, etc.) and their properties.
Google uses structured data as an eligibility signal for rich results: the visual enhancements you see in search — star ratings, FAQ dropdowns, how-to steps, product price/availability, recipe cards. These don’t appear from page content alone. They require explicit markup.
Google’s own documentation cites real uplift numbers from the intro-structured-data page (last updated December 2025):
- Rotten Tomatoes added structured data to 100,000 pages and saw a 25% higher click-through rate on those pages versus pages without it.
- Nestlé measured 82% higher click-through rate on pages showing rich results.
A few caveats before anyone orders the implementation: these are case studies from Google’s own documentation, not a randomised trial. The uplift varies by rich result type, industry, and SERP competition. Rich results are not guaranteed — your markup can be technically valid and still not trigger a feature. More on that gap in the debugging section.
The first precondition, though, is that Google has to be able to crawl and index the page in the first place. Structured data layered on top of a broken crawl setup is decorating a house with no foundation. If you haven’t resolved your indexing setup — covered in Part 3 of this series on crawling and indexing — start there.
JSON-LD, Microdata, RDFa: Pick One (Hint: JSON-LD)
Three formats can deliver structured data to Google: JSON-LD, Microdata, and RDFa. Google explicitly recommends JSON-LD. Their documentation calls it “easiest to implement and maintain at scale,” and the mechanism makes clear why.
JSON-LD is JavaScript Object Notation for Linked Data. It sits in a <script type="application/ld+json"> tag, completely separate from the page’s HTML structure. You’re not wrapping individual content elements with attribute annotations — you’re writing a self-contained block that lives in the <head> or anywhere in the <body>. That separation has two real consequences:
Maintainability. When your page structure changes, your structured data markup doesn’t break because it was never entangled with the HTML. The JSON-LD block is either correct or it isn’t, and it stays put while the presentation layer evolves around it.
Dynamic injection. JSON-LD can be server-rendered or injected via JavaScript after page load. Google can process dynamically injected JSON-LD (it renders pages with a headless Chromium instance), so the data doesn’t have to be in the raw HTML — useful for SPAs and dynamic pages.
Microdata and RDFa work by annotating your HTML elements directly with attribute-based markup. They produce the same output for Google, but they tie your schema to your DOM structure in ways that turn refactors into schema breakage. Unless you’re already deep in a Microdata or RDFa implementation, don’t start one.
Here’s a minimal JSON-LD block for an Article — illustrative, not exhaustive:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Technical SEO and Structured Data",
"author": {
"@type": "Person",
"name": "Blazej Mrozinski"
},
"datePublished": "2026-06-23",
"publisher": {
"@type": "Organization",
"name": "SEO Savages"
}
}
</script>The @context declares the vocabulary (schema.org). The @type tells Google what kind of thing this is. Everything else is properties — and the specific properties required or recommended depend on the rich result type you’re targeting.
The 31 Rich Result Types: What’s Available and What’s Worth Implementing
Google’s search gallery documents 31 rich result types as of the current documentation cycle. Not all of them are relevant to every site, and some require significantly more implementation work than others.
The high-value types for most business sites:
Breadcrumb — almost always worth doing. Displays your site hierarchy in the SERP under the title. Low implementation cost, cleans up the URL display, helps users and Google parse your site structure. Directly tied to how Google understands your internal hierarchy. See the breadcrumbs SEO entry for the SEO mechanics.
FAQ — a <script> block with Question/Answer pairs. When Google serves it as a rich result, users see 2–3 questions expanded directly in the SERP. High click intent — someone who expands a FAQ is often pre-qualified. Note: Google has reduced FAQ rich results for high-authority sites in some verticals; test in your context.
Article — required properties are headline, image, datePublished, author. Standard for blog content, news, and editorial. Establishes content freshness and authorship signals. Google added AI/automation transparency guidance in December 2025 — author clarity is increasingly a trust signal, not a formality.
Product — structured data for e-commerce: name, image, offers (price, availability, currency), ratings. This is where structured data has the most direct commercial payoff because Product rich results display price and availability before a user clicks.
Organization / LocalBusiness — not a rich result itself, but a critical entity signal. Logo, name, contact, sameAs (canonical links to your social profiles and directory listings). This is how Google understands who you are across the web.
HowTo — step-by-step instructions with images. High-effort to implement well (each step needs a name, text, and ideally an image), but can produce visually dominant rich results for informational content.
Recipe, Event, Video, Course, JobPosting — domain-specific. If any of these describes your core content type, they’re worth implementing fully.
Newer types in recent documentation cycles: Profile Page (for author or person pages), Discussion Forum (community content), Education Q&A (question-and-answer educational content). If you’re building author-driven or community content, Profile Page is worth evaluating — it directly addresses the E-E-A-T author signal problem.
The question “which schema types should I implement first” has a boring answer: Breadcrumb (because it’s always applicable and nearly free), then whatever matches your primary content type, then Organization at the site level. Don’t implement a dozen types at once — prioritise, ship, validate, monitor.
Implementing and Validating: From Markup to Live Rich Results
Implementation workflow has two tools, and they are not the same tool.
Rich Results Test (search.google.com/test/rich-results) — Google’s current validation tool for structured data. It tests whether a specific URL’s markup is eligible for Google’s rich results. Use this. It shows you detected items, whether they’re valid, which properties are present, which are missing, and what errors versus warnings you have.
Schema Markup Validator (validator.schema.org) — this is the current home of what used to be called the Structured Data Testing Tool (SDTT). The SDTT was Google’s old validation tool; it was migrated to the schema.org domain and is now maintained as the Schema Markup Validator. If your team still has the old SDTT URL bookmarked, it no longer exists. The Schema Markup Validator tests conformance against the schema.org vocabulary broadly — it does not test for Google’s specific rich result eligibility the way the Rich Results Test does. Both tools are useful; they’re testing different things. Use the Rich Results Test for “will Google show a rich result for this.” Use the Schema Markup Validator for vocabulary correctness when building non-Google structured data.
Common implementation errors caught by validation:
- Missing required properties — each rich result type has required fields. Article without
authoranddatePublishedwon’t be eligible. Product withoutoffers(price/availability) won’t show pricing in the SERP. Check the gallery documentation for the specific type. - Invalid property values —
datePublishedin the wrong format, image URLs that resolve to a 404, price values without apriceCurrency. - Markup/content mismatch — Google’s structured data guidelines are explicit: the markup must match the visible page content. Marking up a Product schema on a page that has no visible product information is a violation, not a shortcut. Google will suppress rich results for markup it determines is misleading.
- Multiple conflicting types — common when a CMS auto-generates schema and a developer adds manual schema on top. Two
Articleblocks with differentdatePublishedvalues confuse the parser. Audit what’s already being emitted before you add anything.
Errors fail validation and prevent rich results. Warnings don’t block eligibility but indicate missing recommended properties — missing a recommended image reduces how richly your result can appear. Fix errors first, then work down the warnings list.
Search Console: Monitoring Indexing, Performance, and Structured Data Health
Search Console is where you find out what Google actually sees when it looks at your site. The Search Console start guide organises monitoring across several report types — the ones that matter for technical SEO:
Coverage / Indexing Report — shows which pages are indexed, which are excluded, and why. The “Discovered — currently not indexed” status means Google found the URL but hasn’t crawled it yet, often due to crawl priority or budget. “Crawled — currently not indexed” is the harder problem: Google crawled it and decided not to index it, which usually indicates a thin content or quality signal issue. Neither is a structured data problem specifically, but both block rich results because rich results require an indexed page.
URL Inspection Tool — test any individual URL. Shows the last crawl date, canonical URL, indexing status, page title as Google sees it, and detected structured data. This is your ground truth when a page isn’t behaving the way you expect. If you’ve updated your structured data and want to know whether Google has picked it up, URL Inspection shows you the cached version Google has.
Rich Results Status Reports — Search Console generates per-type reports for any structured data it detects across your site: a report for Article, a report for FAQ, a report for Product (if applicable). Each shows the count of valid items, items with warnings, and items with errors — broken down by the specific error. This is where you catch systematic implementation problems. If you have 200 Article pages and 40 are failing with “missing required field,” the report tells you what field and which URLs. You don’t find this with spot-checking.
Core Web Vitals — Google’s SERP features include page experience signals, and Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint) are measured and reported in Search Console. Poor CWV doesn’t disqualify you from rich results directly, but page experience is a ranking input, and a slow page is a page that performs less well across the board. The CWV report segments by mobile and desktop; mobile is the one that matters more given mobile-first indexing.
Manual Actions and Security Issues — low-frequency, high-severity. A Manual Action means a human reviewer at Google has taken action against your site for a policy violation. This will suppress rankings and rich results. Security Issues means Google has detected malware or deceptive content. Both require immediate attention and, if resolved, a reconsideration request via Search Console.
If you run WordPress on your own infrastructure, Search Console monitoring integrates with the broader operational picture covered in Self-Hosting WordPress on a Hetzner VPS — specifically around ensuring your server configuration doesn’t block Googlebot from crawling the pages your structured data lives on.
Verification and property setup — Search Console requires domain-level or URL-prefix verification. The domain-level property (requiring a DNS TXT record) gives you data across all protocols and subdomains and is the right choice for most sites. If you haven’t verified yet, the HTML tag and Google Analytics methods also work, but DNS is the most reliable long-term.
Debugging the Gap Between Valid Markup and Rich Results
This is the part nobody explains clearly, and it causes real frustration.
Valid structured data markup does not guarantee rich results. Google’s systems check multiple conditions before showing a feature:
Eligibility — the markup must be for a type that supports a rich result, and the required properties must be present and valid. This is what the Rich Results Test checks.
Content quality — Google’s structured data guidelines include a quality threshold. Pages with thin content, low trust signals, or that appear to be gaming the markup system can have valid markup suppressed. The quality evaluation isn’t just about the markup; it’s about the page.
Relevance — Google decides on a per-query basis whether to show a rich result. Your FAQ schema might be valid and eligible, but if Google determines the FAQ content isn’t relevant to how a searcher is querying, it won’t show. You have less control over this than over the technical implementation.
Feature availability by content type — not every rich result type is served for every query type. HowTo rich results appear for informational how-to queries, not commercial queries about the same product. Match your schema type to the actual search intent of your target queries.
Diagnostic workflow when your markup validates but rich results don’t appear:
- Check the Rich Results Test — confirm the page is actually eligible (not just schema-valid).
- Check Search Console Rich Results reports — confirm Google has processed the markup and there are no server-side errors.
- Use URL Inspection — check the indexed version of the page. If Google’s cached version is old, request re-indexing.
- Check page quality signals — thin word count, duplicate content, poor CWV can suppress features even for technically correct markup.
- Wait. New markup takes time to appear in rich results — typically days to a few weeks depending on your crawl frequency.
One specific failure mode worth naming: structured data on pages that aren’t indexed. It happens more than it should. You implement markup on a staging environment, the pages get indexed from staging before the canonical is set correctly, and your production rich results never appear because Google indexed the wrong version. URL Inspection on the production URL will surface this immediately.
The featured snippets mechanism is worth understanding alongside rich results — they’re different SERP features with different eligibility criteria, but both benefit from clear, well-structured content that matches query intent. Structured data improves your eligibility for rich results; it doesn’t directly produce featured snippets, which are algorithmically extracted from page content.
Frequently Asked Questions
What is the difference between JSON-LD and Microdata for SEO?
Both deliver structured data that Google can process. JSON-LD is a self-contained script block, separate from HTML — easier to implement, maintain, and update without touching the page’s markup. Microdata annotates HTML elements directly with attributes. Google recommends JSON-LD. Unless you’re maintaining an existing Microdata implementation, use JSON-LD.
Does structured data directly improve rankings?
No — structured data is not a direct ranking signal. It makes pages eligible for rich results (expanded SERP features that improve visibility and CTR), which can indirectly affect ranking over time through engagement signals. The most accurate claim: structured data improves SERP appearance for eligible pages. It doesn’t move you up the list; it changes how your entry looks.
Which schema types should I implement first?
Breadcrumb first — it applies to almost every site, costs little to implement, and improves how your URL hierarchy appears in the SERP. Then your primary content type (Article for a blog, Product for e-commerce, LocalBusiness for a service business). Then Organization at the site level for entity clarity. Don’t implement everything simultaneously — implement, validate, monitor, then expand.
How do I check if my structured data is working in Google Search?
Two tools: the Rich Results Test (search.google.com/test/rich-results) for per-URL eligibility, and Search Console’s Rich Results status reports for site-wide monitoring. URL Inspection in Search Console shows you what Google’s indexed version of a page contains, including detected structured data. Use all three — they answer different questions.
Why is my structured data valid but not showing as rich results?
Several reasons, often combined: the page isn’t indexed; content quality doesn’t meet Google’s threshold; the query type doesn’t trigger that result; Google hasn’t re-crawled since you added the markup; or the markup is schema-valid but fails Google’s eligibility checks. Work the flow: Rich Results Test, then Search Console, then URL Inspection, then wait.
Get the Implementation Right the First Time
Structured data done right is a one-time implementation that compounds over time: markup goes in, Search Console validates it, rich results appear, CTR improves, and the only maintenance is keeping it current when your content structure changes. Done wrong, it’s markup that validates locally but never appears in the SERP — or worse, triggers a manual action because the markup doesn’t match the page content.
The monitoring is the part most teams skip. Valid markup at launch doesn’t mean valid markup six months later after template changes, plugin updates, or new page types that weren’t in the original schema plan.
If you’d rather not own the implementation and monitoring loop yourself, our Fractional SEO service covers structured data implementation, validation setup, and ongoing Search Console monitoring as part of the technical SEO scope. One less operational layer you have to maintain.