Structured data that actually produces rich results

Introduction

Most schema projects we take over pass the Rich Results Test and still deliver nothing. The reason is rarely a syntax error. Usually the effort went into types Google stopped serving, while the one piece of markup that pays off over years is missing: a consistent description of the company itself.

Below: what the documentation actually says, which types still produce something in 2026, JSON-LD you can adapt, and the sequence we work through on every project.

What structured data does and does not do

Google describes structured data as a standardised format for providing information about a page and classifying its content. It removes guesswork a search engine would otherwise apply to running text: who wrote this, which company it concerns, which address applies, when the business is open.

What follows from that is narrower than most vendors claim. Structured data makes a page eligible for rich results. It does not guarantee one. Google's general guidelines say that even with markup passing the Rich Results Test, there is no promise a feature appears, because the algorithm picks the presentation it considers best for that user.

The ranking question is answered in a sentence almost nobody quotes. The same guidelines say that a structured data manual action means the page loses eligibility for rich result appearance and that this does not affect how the page ranks in Google web search. If the penalty leaves rankings alone, the markup normally does too.

That leaves presentation, where the effect is real. Google's introduction cites four case studies, among them Nestlé measuring an 82 percent higher click-through rate for pages shown as rich results, and Rotten Tomatoes measuring 25 percent higher after marking up 100,000 pages. Both figures come from the sites themselves, published by Google, and compare pages with markup against pages without rather than the same page before and after an otherwise unchanged switch.

One rule sits above the rest: do not mark up anything that is not visible on the page. Google's example is JSON-LD describing a performer who does not appear in the HTML body. The consequence is not a demotion but something more specific. Under a manual action the page's markup is ignored entirely. The page still ranks, and its structured data no longer exists as far as Google is concerned.

Which types still produce something in 2026

This list has been shrinking for years, and the pace has picked up:

• FAQPage. Google added a deprecation notice on 8 May 2026: the feature stopped appearing in search on 7 May 2026. The documentation was removed on 15 June 2026.
• HowTo. Withdrawn back in August 2023, announced on the Search Central blog.
• Practice problem. Documentation removed on 6 January 2026 because the feature is no longer served.

The planning rule that follows: do not build a business case on a single rich result type. Google removes features with a few weeks' notice. What has stayed stable is the group that describes who you are and how your pages relate to each other.

For the client profiles we work with, four types earn their keep almost every time: Organization or a fitting LocalBusiness subtype, BreadcrumbList, Article or BlogPosting, and Product with Offer in retail. Event when a hotel runs real events, JobPosting when you genuinely advertise roles. The rest we assess case by case and usually leave out.

Organization: the markup that makes a company unambiguous

This is the part that carries beyond Google. In the Organization documentation, Google writes that some properties are used behind the scenes to disambiguate your organization from other organizations, naming iso6523Code and naics as examples. Of url it says the property helps Google uniquely identify your organization. Of vatID: an important trust signal, because users can look your business up in public VAT registries.

There are no required properties. Google recommends adding as many relevant ones as possible, weighted toward real-world presence (address, telephone) and online presence (URL, logo).

Here is an example for a company in South Tyrol, which trades under both a German and an Italian name:

{

"@context": "https://schema.org",

"@type": "Organization",

"@id": "https://www.example-joinery.it/#organization",

"name": "Tischlerei Gruber",

"alternateName": "Falegnameria Gruber",

"legalName": "Tischlerei Gruber GmbH",

"url": "https://www.example-joinery.it/",

"logo": "https://www.example-joinery.it/images/logo-512.png",

"description": "Joinery for interior fit-out and bespoke furniture in Brixen.",

"email": "info@example-joinery.it",

"telephone": "+39-0472-123456",

"vatID": "IT01234567890",

"foundingDate": "1987",

"address": {

"@type": "PostalAddress",

"streetAddress": "Bahnhofstrasse 12",

"addressLocality": "Brixen",

"addressRegion": "BZ",

"postalCode": "39042",

"addressCountry": "IT"

},

"sameAs": [

"https://www.linkedin.com/company/example-joinery",

"https://www.instagram.com/example\_joinery"

]

}

Four details that trip projects up in practice:

One node, not twenty. Google recommends placing these details on the home page or a single page about the organization, and states explicitly that you do not need them on every page. Assign a stable @id and reference it from other blocks. The most common finding in our audits is two Organization blocks per page, one from the theme and one from the SEO plugin, carrying different phone numbers.

A vatID that matches the country. Google requires the tax ID to match the country given in address. Italy uses the Partita IVA with an IT prefix, Germany the USt-IdNr with DE, Austria ATU, Switzerland the UID in CHE format.

Bilingual names handled properly. Many businesses in South Tyrol trade under two names. The more common one goes in name, the second in alternateName. Do not invent a translation that does not appear in the commercial register.

sameAs with real profiles only. Link profiles you control and that are live. A pointer to a deleted Facebook page is not a signal, it is a contradiction.

The logo must be at least 112 by 112 pixels and crawlable.

LocalBusiness, Article and BreadcrumbList

LocalBusiness has two required properties: name and address. Google recommends the most specific subtype rather than the umbrella term, so Dentist instead of LocalBusiness. For multiple activities, supply an array; Google does not support additionalType.

{

"@context": "https://schema.org",

"@type": "Dentist",

"@id": "https://www.example-practice.de/#practice",

"name": "Zahnarztpraxis Dr. Berger",

"url": "https://www.example-practice.de/",

"telephone": "+49-89-1234567",

"priceRange": "$$",

"address": {

"@type": "PostalAddress",

"streetAddress": "Leopoldstrasse 42",

"addressLocality": "Munich",

"addressRegion": "BY",

"postalCode": "80802",

"addressCountry": "DE"

},

"geo": {

"@type": "GeoCoordinates",

"latitude": 48.16241,

"longitude": 11.58675

},

"openingHoursSpecification": [

{

"@type": "OpeningHoursSpecification",

"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],

"opens": "08:00",

"closes": "18:00"

},

{

"@type": "OpeningHoursSpecification",

"dayOfWeek": "Friday",

"opens": "08:00",

"closes": "13:00"

}

]

}

Google requires at least five decimal places on the coordinates. priceRange has to stay under 100 characters, otherwise Google shows no price range at all.

Now the trap we run into most often. For LocalBusiness, Google recommends aggregateRating and review only for sites that capture reviews about other businesses. Marking up the four stars from your own testimonials as an AggregateRating is the shortest route to a manual action. We do not do it for any client, even when the reviews are genuine.

For blog articles, two objects side by side are enough. Article has no required properties either:

[

{

"@context": "https://schema.org",

"@type": "BlogPosting",

"@id": "https://www.example.com/blog/structured-data#article",

"headline": "Structured data that actually produces rich results",

"image": ["https://www.example.com/images/schema-16x9.jpg"],

"datePublished": "2026-07-29T09:00:00+02:00",

"dateModified": "2026-07-29T09:00:00+02:00",

"author": {

"@type": "Person",

"name": "Jonas Tribus",

"jobTitle": "CTO",

"url": "https://www.example.com/author/jonas-tribus"

},

"publisher": { "@id": "https://www.example.com/#organization" }

},

{

"@context": "https://schema.org",

"@type": "BreadcrumbList",

"itemListElement": [

{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },

{ "@type": "ListItem", "position": 2, "name": "SEO", "item": "https://www.example.com/blog/seo" },

{ "@type": "ListItem", "position": 3, "name": "Structured data" }

]

}

]

Two notes. author.name takes the name and nothing else. Google explicitly lists job titles, honorifics and introductory words such as "posted by" as errors, and points to jobTitle for the role. And the final breadcrumb item carries no item, because it is the current page.

Structured data and AI answers

Since May 2026 there has been an official answer, and it is drier than the market would like. Google's guide to optimising for generative AI features lists "Overfocusing on structured data" under mythbusting: structured data is not required for generative AI search, and there is no special schema.org markup to add. It stays worth using as part of overall SEO because it establishes rich result eligibility. The same section states that Google Search ignores llms.txt.

Anyone selling you a "schema package for AI Overviews" is contradicting the documentation of the vendor whose feature is being sold.

The entity value is still real, just somewhere else: in disambiguation, which is where Google itself locates it. If a hotel, a joinery and a law firm in the same town share a family name, it is the combination of address, VAT number, URL and verified profiles that decides which one is meant. Those facts remain correct whether or not anyone serves a rich result.

Do not infer a guaranteed advantage in ChatGPT, Perplexity or Gemini from Schema.org markup: the vendor documentation cited here makes no such promise. For what does move visibility in AI answers, see our comparison of the difference between SEO, AEO and GEO and the service description for visibility in AI answers. The effect is measurable in Search Console, in the generative AI performance report.

The sequence we work through on every project

1. Inventory across five page types. Home page, one service page, one location page, one article, the contact page. Rich Results Test plus a look at the source. Duplicates before errors.
2. Fact reconciliation. Company name, address, phone number and VAT number have to match the legal notice and the Google Business Profile. In German-speaking markets the Impressum is the most reliable source, because it is maintained for legal reasons. Where umlauts or street spellings vary, one variant applies everywhere.
3. One Organization node. On the home page, with a stable @id. Everything else references it instead of repeating it.
4. Server-side rendering. Google does process JSON-LD injected via JavaScript, but every extra dependency is a way for the next deployment to break it.
5. Two validations, two questions. The Rich Results Test answers whether a page is eligible for a Google feature. The Schema Markup Validator at validator.schema.org answers whether the vocabulary is valid, including types Google ignores. Then URL Inspection, because only that shows what Google sees after rendering.
6. Wait, then watch. Google notes it can take several days after publishing for a page to be found and crawled. Anyone expecting results the next morning is measuring noise.

What we deliberately leave out: reviews about ourselves, any further effort on FAQPage, and any claim that does not appear on the page. The groundwork underneath, from delivery to crawlability, belongs to the technical foundations of a website. How load time and stability relate to it is covered in Core Web Vitals in practice.