What is structured data, and what can you expect from it?
What structured data is, why JSON-LD is the recommended format, which rich results it can unlock, how required and recommended properties differ, and what it does not guarantee.
By Javier Tenjo, Full stack developer
On this page
A search engine reads your page as text. It sees “4.8”, “126 reviews” and “from 45 USD”, but it cannot be certain that the first is an average rating, the second a review count and the third a price. It infers, and sometimes it gets it wrong.
Structured data removes the guesswork. It is a description of the page written for machines, in a vocabulary search engines understand, stating explicitly what each thing is. In return, the page can become eligible to appear on Google with more information than just a title and a description.
What structured data is
It is a set of annotations that accompany the content and classify it: “this page is a product, it is called this, it costs this and it is in stock”; “this is an event, it starts on this day and takes place here”; “this is the company, this is its logo and these are its social profiles”.
The shared vocabulary is schema.org, a project Google, Microsoft, Yahoo and Yandex launched together in 2011 so that each would not need its own. It defines types (Organization, LocalBusiness, Product, Article, Event, BreadcrumbList and hundreds more) and the properties of each one (name, address, price, startDate…).
JSON-LD: the recommended format
There are three ways to write structured data: microdata, RDFa and JSON-LD. The first two are woven into the visible HTML, attribute by attribute. JSON-LD sits apart, in a block of code within the page, and it is the format Google recommends.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "The Corner Bakery",
"url": "https://example.com/",
"image": "https://example.com/img/shopfront.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "12 High Street",
"addressLocality": "York",
"addressCountry": "GB"
},
"openingHours": "Mo-Sa 07:00-19:00"
}
</script>
The practical advantage is maintenance. Because it does not depend on the design, it can be generated from the same data that feeds the page (the catalogue, the blog, the company profile), and a template change will not break it. When several related nodes exist, such as an article, its author and the organisation publishing it, they can be grouped into one block with @graph and linked to each other with @id.
What rich results are
They are the expanded versions of a search result: star ratings, a product’s price and availability, event dates, a recipe’s preparation time, a video’s thumbnail and duration, or the breadcrumb trail in place of the URL.
They take up more space, give information before the click and tend to catch the eye more than a plain result. But not every schema.org type produces one. Google maintains a list of the rich results it supports, each with its own documentation and requirements, and that list changes over time.
Required, recommended and everything else
There are two different bars here, and it pays not to confuse them.
The schema.org bar is very broad. It accepts almost any combination of type and property that exists in the vocabulary. Markup can be perfectly valid for schema.org and achieve nothing visible on Google.
Google’s bar is specific and set per type. For each rich result, its documentation separates:
- Required properties. Without them, the page cannot be eligible for that result. An event, for example, needs at least a name, a start date and a location.
- Recommended properties. They do not prevent the result, but without them it comes out poorer. The same event would be missing its end date, an image or ticket prices.
Properties that are not part of any rich result do no harm either: they help the search engine understand who you are and what you offer, even if they do not change how your result looks.
What it does not guarantee
This is the part that prevents the most disappointment.
- It does not guarantee a rich result. Meeting the requirements makes you eligible; Google decides page by page whether to show it, depending on the search, the content and how much it trusts the site. It can also take weeks to appear.
- It does not lift rankings on its own. Google has said it is not a direct ranking factor. Its effect comes from elsewhere: a fuller result can attract more clicks.
- It must describe what is visible. Marking up reviews that are not on the page, prices that differ from the ones shown or content users cannot find goes against Google’s guidelines and can end in a manual action that removes rich results from the whole site.
- Your own business’s stars will not show. Google does not display ratings for a
LocalBusinessor anOrganizationwhen the reviews are published by the business about itself on its own site. - Some types are now barely shown. Since 2023 the FAQ result (
FAQPage) has been reserved for authoritative government and health sites, and the step-by-stepHowToresult is no longer displayed. The markup is still valid, but do not expect questions to unfold beneath your result.
Common mistakes
- Malformed JSON. A trailing comma at the end of a list or curly quotes pasted from a word processor invalidate the entire block, not just that line.
- Relative URLs in
url,imageorlogo. They must be absolute, with domain and protocol. - Dates in a local format (“day/month/year”) instead of ISO 8601 (
YYYY-MM-DD, with an optional time). - Data that does not match the page. The price changed on the product page and the JSON-LD still carries the old one.
- Duplicate or conflicting markup. Two plugins each generating their own
Organizationwith different details, or a theme and an extension declaring the same product twice. - Types that do not fit. Marking a services page as
Product, or a page without questions asFAQPage.
Structured data works best on a page that already gets the basics right. If the title and description are still generic, start there: it is covered in how to write title tags and meta descriptions. And to see where all this fits in the bigger picture, there is the complete guide to search rankings.
Validating yours
The structured data validator accepts the URL of a published page or the pasted JSON-LD of one that is not live yet. It extracts every block, unrolls any @graph, lists each node with its type and properties, and splits problems into two levels: errors, which block the rich result (JSON that cannot be parsed, a missing @context or @type, absent required properties), and warnings, which only make it poorer (missing recommended ones). It also checks for badly written dates, relative URLs, duplicate @ids and breadcrumb order.
Always start with the errors, validate again, and then fill in the warnings that make sense for your page. For the final word on a specific type, Google’s Rich Results Test is the official reference; the validator helps you get there with the formatting already clean.
Structured data is a way of speaking plainly to the search engine. It works no miracles, but it removes an excuse: if your page does not show stars or a price, let it be Google’s decision and not a stray comma.