Schema is not magic: structured data explained for beginners

Someone hears that with schema you get little stars on Google. They paste a code they found on a forum, don't check whether it works, and wait. Weeks go by and nothing changes in the results.

It isn't that Google ignores it on a whim. It is that structured data is not a trick to show up better, it is a way of explaining to Google what is on your page. If you understand it that way, you stop waiting for magic and start using it where it makes sense.

What structured data is

According to Google's introduction to structured data, it is a standard format for providing information about a page and classifying its content. Google's example is a recipe: with structured data you can say what the ingredients, the cooking time and the calories are, instead of letting Google deduce it from the text.

Think of a pantry. Unlabeled jars can be opened and looked into, but it takes time. With labels, you know instantly what is in each one. Structured data is those labels, written for a crawler to read.

Two clarifications Google makes and that are worth having clear:

• Google uses this data to understand the page's content and also to gather information about the world in general, such as the people, books or businesses that appear in the markup.
• What can appear in results thanks to them are rich results: more eye-catching results, with extra data, that can encourage more people to click.

What you gain, with what Google says and without exaggerating

Google cites cases of companies that added structured data and measured improvements. Rotten Tomatoes measured 25% higher click-through on pages with structured data than on those without it, and Nestlé 82% more clicks on pages that showed up as a rich result. These are cases Google tells, from very large sites, with their own conditions. They don't work as a promise for your website.

Google's documentation says it another, more useful way: adding structured data can make your results more attractive, but you have to meet all the required properties of each type to be eligible. Eligible is not the same as guaranteed.

Schema.org, JSON-LD and the naming mess

When someone says "schema" they usually mean two different things:

• Schema.org is the vocabulary: the list of types (article, product, local business, recipe) and properties (name, price, author, date).
• JSON-LD, microdata and RDFa are the formats to write that vocabulary on your page.

Google supports all three, and says they are equally valid if the markup is correct. Even so, it recommends JSON-LD because it is usually the easiest to implement and maintain. It is a block of text inside a script tag, separate from the visible content, and Google can read it even if JavaScript injects it. If your website uses a modern framework, in the edition on Astro and SEO you have other technical SEO things that shouldn't be taken for granted.

There is a nuance that gets overlooked: to know what is mandatory and what isn't, Google Search's documentation rules, not schema.org's. Schema.org has many more properties than Google uses.

An invented example, to see the shape it has. Imagine a fictitious plumbing business, "Example Plumbing", with this listing:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "name": "Example Plumbing",
  "telephone": "+34 000 000 000",
  "url": "https://www.ejemplo.com/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Sample Street 1",
    "addressLocality": "Valencia",
    "addressCountry": "ES"
  }
}
</script>

If you have a local business, in the edition on Google Business Profile you have how to fix your listing, and its data should match your website's. Notice that every piece of data in the block must also appear visibly on the page. That brings us to the part that causes the most errors.

The rules that do matter

Google's general structured data guidelines separate the technical ones from the quality ones. The most useful to start:

• Don't mark up content the reader doesn't see. If the JSON-LD talks about an author or a price, the page has to show that author or that price.
• Don't mark up irrelevant or misleading content, such as fake reviews or information unrelated to the page.
• The data must truly represent the content: Google gives the example of a carpentry website that tags instructions as recipes.
• Keep the information up to date. Google won't show a rich result for dated content that is no longer valid.
• Put the markup on the page it describes, not on another one.
• The images you indicate in the markup must be relevant to the page and be crawlable and indexable.

Skipping the quality rules has consequences. Google explains that a problem with structured data can end in a manual action: the page loses eligibility for rich results. That doesn't affect its position in normal web search, but it takes away exactly what you were after.

The rule that links to the previous edition

The guidelines also say not to block pages with structured data from Googlebot with robots.txt, noindex or any other access control. It makes sense: if Google can't get into the page, it can't read its markup. It is the same principle we explained in the robots.txt and sitemap.xml edition: crawling comes before anything else.

What structured data doesn't do

It is worth keeping the list of expectations at hand, because almost all disappointments slip in here:

• They don't guarantee a rich result. They make you eligible if you meet the required properties and the guidelines.
• They don't fix a bad page. They describe what is there, and if what is there is weak, they keep describing it.
• They don't replace visible content. The markup describes what the reader sees, it doesn't replace it.
• They aren't done once and forgotten. A template that changes or a failure serving the page can break the markup without anyone noticing.

How to implement them without being a programmer

If you use a content management system like WordPress, Wix or Shopify, you may not be able to touch the HTML. Google suggests looking in your CMS's SEO settings or installing a plugin that lets you specify structured data. Search for something like "wordpress structured data plugin" and then check what it generates, because not everything that gets added is correct.

A reasonable order for beginners:

1. Start with a type that fits your site and that Google documents. Google has a list of search features with structured data, each with its guide.
2. Do the implementation following that guide. Meet all the required properties. Google prefers a few complete and correct properties to many malformed ones.
3. Validate during development with the Rich Results Test, which can also show a preview of the feature in search, and with schema.org's Schema Markup Validator (below I explain when to use each one).
4. After publishing, review the rich result status reports in Search Console, because markup can break because of templates or failures serving pages. If you get lost in Search Console, this edition on where to look when indexed pages drop is a good starting point.
5. Use URL inspection to confirm that Google has found the markup.

Two tools to check it, and when to use each

There are two validators and they don't do the same thing. It is worth using both, in this order:

• The Schema Markup Validator is schema.org's tool. You paste a URL or a piece of code and it tells you whether the markup is well written according to schema.org's vocabulary. Use it to detect syntax errors and misplaced properties, whatever the data type. It doesn't know what Google requires to show a rich result.
• The Google Rich Results Test checks a public page and tells you which rich results it can generate with the structured data it contains. Use it to know whether your markup meets what Google asks for that feature, and to see a preview. If the type you have marked up isn't in the list of features Google supports, this tool won't tell you anything useful, even if the markup is correct on schema.org.

The practical rule: the schema.org validator answers "is it well written?" and Google's test answers "can Google use it for anything?". Markup can pass the first and fail the second.

How to know whether it has helped

Measure with a before and after, as Google proposes. Choose a few pages without structured data, with several months of data in Search Console, that don't depend on the time of year or on current events. Add the markup, confirm it is valid, and compare the performance report by URL for a few months.

It is a slow process, and Google acknowledges it is somewhat tricky, because a page's visits vary for many reasons. That is why it isn't wise to draw conclusions after two weeks.

Checklist for today

1. Choose an important page (a product, a service or an article).
2. Look in Google's guide at which type of structured data corresponds to it and which properties are required.
3. Check that everything you are going to mark up is visible on the page.
4. Write or generate the JSON-LD and test it first in the schema.org validator and then in Google's Rich Results Test.
5. Verify that the page isn't blocked in robots.txt or with noindex (we saw it in the robots.txt edition).
6. Publish and review the rich result status report in Search Console.
7. Note the date and that URL's performance to compare in a few months.

The idea to keep

Structured data explains, it doesn't promise. It tells Google what is on your page, and if you follow the rules, it can give you a more eye-catching result. If you mark up things that aren't seen or invent what doesn't exist, the only thing you achieve is losing eligibility.

Choose just one page today and do it well. There will be time to scale.

If you prefer that I mark it up for you, you can see what my technical SEO service includes.