Structured data for businesses: Schema.org made simple

What it does for you

Structured data helps search engines and AI systems to classify content correctly. It can lead to enhanced displays in search, but does not have to. The main benefit is clarity.

Sensible types for businesses

Organization / LocalBusiness / ProfessionalService: name, address, contact details, founding, services.
WebSite: the name and address of the website.
Service: individual services with a description.
BreadcrumbList: breadcrumb navigation.
Article: guides and blog posts with author and date.
FAQPage: questions and answers.

Limits

Google now shows FAQ results in search only to a limited extent, and some other displays have been discontinued. The information is still useful, because it gives machines clear facts. The data must match the visible content.

Example: a business in JSON-LD

This is what minimal markup for a local business looks like. It sits in the source code of the home page, in a script block of the type application/ld+json:

{ "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Beispiel Tischlerei", "url": "https://beispiel.de", "telephone": "+49 711 000000", "address": { "@type": "PostalAddress", "streetAddress": "Musterstraße 1", "postalCode": "70173", "addressLocality": "Stuttgart", "addressCountry": "DE" } }

Name, address and telephone number must match your legal notice and Google profile exactly, otherwise you create the very contradiction that the data is meant to avoid.

Typical mistakes

Data that cannot be seen on the page: reviews or prices in the markup that the visitor cannot find anywhere breach the guidelines and can lead to action being taken against your site.
The wrong type: a guide article is an Article, not a Product. Choose the most specific type that fits.
Outdated details: after a move or a price change, the markup stays in the source code and contradicts the visible page.
Syntax errors: a missing comma or an unclosed bracket makes the whole block unreadable.
Duplicate markup: if a plugin and a manually inserted block supply the same details, conflicts arise.

Where to start: a decision guide

First Organization or LocalBusiness on the home page, because this is where your core data sits.
Then BreadcrumbList on all inner pages; it is technically simple and unambiguous.
After that Article for guide pages and Service for services.
Last of all questions and answers, but only if the questions are visibly on the page.

Maintenance and how the pieces fit together

On systems such as WordPress, SEO plugins generate many of these details automatically. Even so, check what actually ends up in the source code, because default settings rarely suit a business without adjustment. On sites you build yourself, the markup can be built into a template so that new pages receive it automatically. Whichever route you take, the same applies: markup describes the page; it does not replace good content. How the individual building blocks work together is shown on the page about on-page SEO.

An example of an error message and what it means

The Rich Results Test distinguishes between errors and warnings. An error usually means that a required field is missing or incorrectly constructed, such as a date in the wrong format. A warning points to recommended but not mandatory fields, for example an image on an article. Fix the errors first. With warnings, you decide whether the detail makes sense for your page, and only enter it if it is true.

Who maintains the data

Decide who also updates the markup when the address, telephone number or services change. Without clear responsibility, the visible page and the markup drift apart after a few months. An entry in your checklist for a relaunch or a move is usually enough to make sure this is not forgotten. After major changes, test several pages by spot check.

Checking

Errors can be found with Google’s Rich Results Test or the Schema Markup Validator. This website also uses structured data; see Technical SEO.