Structured data isn't a ranking technique in the sense that adding it directly boosts your position; it's a standardized language (Schema.org, jointly maintained by Google, Bing, Yahoo and Yandex) for telling a search engine, unambiguously, what each element on your page is: that a number is a price and not a year, that a piece of text is an author's name and not a title, that a date is the publication date and not the last-edited date. That clarity is what lets Google build so-called rich results: rating stars, prices, expandable FAQs or breadcrumbs directly in the search results page.
Why JSON-LD and not microdata or RDFa
Schema.org can be implemented with three different syntaxes: microdata and RDFa, which are woven directly into the visible HTML's attributes, and JSON-LD, declared as an independent script block, separate from the HTML the user sees. Google explicitly recommends JSON-LD for a practical reason, not just an aesthetic one: since it doesn't depend on visible HTML attributes, it can be added, updated or removed without touching markup that already works, and it can be generated dynamically from database data without risking breaking the page's design.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Nordic oak chair",
"image": "https://www.yourdomain.com/img/nordic-chair.jpg",
"offers": {
"@type": "Offer",
"priceCurrency": "EUR",
"price": "189.00",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "83"
}
}
</script>The structured data types with the biggest visible impact
Not every Schema.org type produces a visible rich result in Google; many are purely semantic and help content understanding without changing how the result looks. Among those with direct visual impact: Product (price, availability and star rating), Recipe (prep time, calories and rating, with a featured image in a carousel), FAQPage (expandable questions directly under the result, taking up far more visual space than a normal result), HowTo (numbered steps), Article or BlogPosting (date, author and featured image in Google Discover) and LocalBusiness (hours, address and phone in the local knowledge panel).
Implementation mistakes that make Google ignore the markup
The most common and most serious is marking up data that isn't visible to the user on the page: for example, declaring a 4.8-star rating in the JSON-LD when that rating doesn't appear anywhere in the visible content. This directly violates Google's structured data guidelines and can trigger a manual action that disables all rich results for the domain, not just the affected type.
The second common mistake is badly nested property hierarchy: for example, putting price directly on Product instead of inside its offers property, which is where the Schema.org spec requires it to live. This kind of structural mistake doesn't always trigger an explicit validation error, but it does make Google silently discard the corresponding rich result, without explaining why.
The third mistake is duplicating the same data type with different values on the same page, for example an FAQPage block generated by a plugin and another added manually with different questions: Google picks only one (usually whichever it processes first) or discards both if it detects the contradiction.
How to validate markup before publishing it
There are two levels of validation with different purposes. A syntax validator checks that the JSON-LD is valid JSON and respects the property structure Schema.org requires, but says nothing about whether Google will actually generate a rich result from that data: for that you need Google's Rich Results Test, which besides validating syntax confirms which rich result types are eligible under the currently active guidelines (which change more often than the Schema.org spec itself).
// Basic JSON syntax check before publishing,
// from any console with Node.js available
JSON.parse(document.querySelector('script[type="application/ld+json"]').textContent)Structured data and AI-generated content in conversational search
With the rise of AI-generated summaries in search results (AI Overviews) and conversational answer engines that cite sources, Schema.org markup has gained a second purpose beyond traditional rich results: it remains the most direct way to communicate verifiable facts (price, availability, author, date) to systems that synthesize content from multiple sources, precisely because it removes the ambiguity that exists when extracting those same facts purely from natural-language text.
Maintenance: outdated structured data is worse than none
More a management than an implementation mistake: marking a product as InStock in the JSON-LD when it's actually sold out, or leaving a fixed star rating in the markup while real reviews keep accumulating and shifting the average. These mismatches between structured data and the reality of the content are exactly the kind of signal Google's quality guidelines flag as misleading markup, regardless of whether it was a sync failure and not an intent to manipulate.
Frequently asked questions
Does structured data directly improve rankings?
Not directly: it isn't a ranking factor in itself. What it does is enable result formats (rich results) that usually improve click-through rate, which can indirectly benefit the page's performance over time.
Can I use several Schema.org types on the same page?
Yes, and it's common: for example, combining Product with BreadcrumbList and Organization on the same product page, as long as each type is declared in its own JSON-LD block or in a well-formed array, without mixing properties from different types in the same object.
What happens if Google detects structured data that doesn't match the visible content?
At best, it silently ignores that data block and doesn't show the rich result. In more serious or systematic cases, it can apply a manual action for "structured data not matching guidelines," visible in Search Console, which disables rich results for the entire domain until it's fixed.
Do I need to use the exact property names from the Schema.org documentation?
Yes, they're case-sensitive and don't accept synonyms: aggregateRating doesn't work if written as AggregateRating or rating_average. The official schema.org documentation is the normative reference, not Google's guidelines (which document which subset of properties each rich result uses, but don't invent their own syntax).
Do I need to update the markup every time the price or stock changes?
Yes, if the markup is generated manually and statically. The robust solution is to generate the JSON-LD dynamically from the same data that feeds the price and stock shown on the page, so both stay automatically in sync without depending on a parallel manual update.