Strukturierte Daten, die echte Rich Results bringen

Einleitung

Die meisten Schema-Projekte, die wir übernehmen, sind im Rich Results Test grün und bringen trotzdem nichts. Der Grund ist selten ein Syntaxfehler. Meistens steckt der Aufwand in Typen, die Google längst nicht mehr ausspielt, während die eine Auszeichnung fehlt, die über Jahre trägt: eine widerspruchsfreie Beschreibung des Unternehmens selbst.

Unten steht beides getrennt. Was strukturierte Daten laut Googles eigener Dokumentation leisten, welche Typen 2026 noch etwas auslösen, JSON-LD zum Übernehmen, und der Ablauf, den wir bei jedem Projekt in derselben Reihenfolge gehen.

Was strukturierte Daten tun und was nicht

Google beschreibt strukturierte Daten als standardisiertes Format, mit dem Sie Informationen über eine Seite bereitstellen und deren Inhalt klassifizieren. Der Suchmaschine fällt damit leichter, was sie sonst aus Fließtext erschließen muss: Wer schreibt hier, um welches Unternehmen geht es, welche Adresse gilt, wann ist geöffnet.

Was daraus folgt, ist enger begrenzt, als viele Anbieter behaupten. Strukturierte Daten machen eine Seite für Rich Results zulässig. Sie garantieren keine. Google formuliert das in den allgemeinen Richtlinien unmissverständlich: Auch bei korrektem Markup nach dem Rich Results Test gibt es keine Zusage, dass ein Feature erscheint, weil der Algorithmus je nach Suchverlauf, Standort und Gerät entscheidet, welche Darstellung passt.

Die Frage nach dem Ranking beantwortet Google an einer Stelle, die kaum jemand zitiert. In derselben Richtlinie steht zur manuellen Maßnahme gegen strukturierte Daten: Die Seite verliert die Zulässigkeit für Rich Results, die Position in der Websuche bleibt davon unberührt. Wenn selbst die Strafe das Ranking nicht berührt, tut es die Auszeichnung im Normalfall auch nicht.

Bleibt die Darstellung. Google führt in seiner Einführung vier Fallstudien an, darunter Nestlé mit einer um 82 Prozent höheren Klickrate für Seiten, die als Rich Result erscheinen, und Rotten Tomatoes mit 25 Prozent höherer Klickrate nach der Auszeichnung von 100.000 Seiten. Zwei Einschränkungen gehören dazu: Es sind Zahlen der Websites selbst, veröffentlicht von Google, und sie vergleichen Seiten mit und ohne Markup, nicht dieselbe Seite vor und nach einer sonst unveränderten Umstellung.

Eine Regel steht über allen anderen: Zeichnen Sie nichts aus, was auf der Seite nicht sichtbar ist. Google nennt als Beispiel JSON-LD, das eine Person beschreibt, die im HTML-Text nicht vorkommt. Die Folge ist keine Abwertung, sondern etwas Konkreteres. Bei einer manuellen Maßnahme wird das Markup der Seite komplett ignoriert. Die Seite rankt weiter, ihre strukturierten Daten existieren für Google nicht mehr.

Welche Typen 2026 noch etwas auslösen

Diese Liste wird seit Jahren kürzer, und das Tempo hat zugenommen:

• FAQPage. Google hat am 8. Mai 2026 einen Deprecation-Hinweis gesetzt: Das Feature erscheint seit dem 7. Mai 2026 nicht mehr in der Suche. Am 15. Juni 2026 wurde die Dokumentation entfernt.
• HowTo. Bereits im August 2023 zurückgezogen, angekündigt im Search-Central-Blog.
• Practice problem. Dokumentation am 6. Januar 2026 entfernt, weil das Feature nicht mehr ausgespielt wird.

Daraus folgt eine Planungsregel: Bauen Sie keinen Geschäftsfall auf einen einzelnen Rich-Result-Typ. Google entfernt Features mit wenigen Wochen Vorlauf. Stabil geblieben ist nur die Gruppe, die beschreibt, wer Sie sind und wie Ihre Seiten zusammenhängen.

Für die Kundenprofile, mit denen wir arbeiten, lohnen sich vier Typen fast immer: Organization oder ein passender LocalBusiness-Subtyp, BreadcrumbList, Article beziehungsweise BlogPosting, und im Handel Product mit Offer. Event kommt dazu, wenn ein Hotel echte Veranstaltungen führt. JobPosting, wenn Sie tatsächlich Stellen ausschreiben. Alles andere prüfen wir im Einzelfall und lassen es meistens weg.

Organization: das Markup für ein eindeutiges Unternehmen

Hier liegt der Teil, der über Google hinaus trägt. In der Organization-Dokumentation schreibt Google, dass einige Eigenschaften im Hintergrund dazu dienen, Ihre Organisation von anderen Organisationen zu unterscheiden, und nennt iso6523Code und naics als Beispiele. Zur url heißt es, sie helfe Google, die Organisation eindeutig zu identifizieren. Zur vatID: ein wichtiges Vertrauenssignal, weil Nutzer das Unternehmen in öffentlichen Registern nachschlagen können.

Pflichtfelder gibt es bei Organization keine. Google empfiehlt, so viele passende Eigenschaften wie möglich anzugeben, mit Schwerpunkt auf realer Präsenz wie Adresse und Telefon sowie digitaler Präsenz wie URL und Logo.

Ein Beispiel für einen Betrieb in Südtirol, mit deutscher und italienischer Firmierung:

{

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

"@type": "Organization",

"@id": "https://www.beispiel-tischlerei.it/#organization",

"name": "Tischlerei Gruber",

"alternateName": "Falegnameria Gruber",

"legalName": "Tischlerei Gruber GmbH",

"url": "https://www.beispiel-tischlerei.it/",

"logo": "https://www.beispiel-tischlerei.it/bilder/logo-512.png",

"description": "Tischlerei für Innenausbau und Möbel nach Maß in Brixen.",

"email": "info@beispiel-tischlerei.it",

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

"vatID": "IT01234567890",

"foundingDate": "1987",

"address": {

"@type": "PostalAddress",

"streetAddress": "Bahnhofstraße 12",

"addressLocality": "Brixen",

"addressRegion": "BZ",

"postalCode": "39042",

"addressCountry": "IT"

},

"sameAs": [

"https://www.linkedin.com/company/beispiel-tischlerei",

"https://www.instagram.com/beispiel\_tischlerei"

]

}

Vier Details, an denen es in der Praxis scheitert:

Ein Knoten, nicht zwanzig. Google empfiehlt, diese Angaben auf die Startseite oder eine Seite über das Unternehmen zu legen, und schreibt ausdrücklich, dass sie nicht auf jeder Seite stehen müssen. Vergeben Sie eine stabile @id und verweisen Sie von anderen Blöcken darauf. Der häufigste Befund in unseren Audits sind zwei Organization-Blöcke pro Seite, einer vom Theme, einer vom SEO-Plugin, mit unterschiedlichen Telefonnummern.

vatID passend zum Land. Google verlangt, dass die Steuernummer zum Land in address passt. Für Italien die Partita IVA mit Präfix IT, für Deutschland die USt-IdNr mit DE, für Österreich ATU, für die Schweiz die UID im Format CHE.

Zweisprachigkeit sauber abbilden. In Südtirol führen viele Betriebe zwei Firmierungen. Die geläufigere gehört in name, die zweite in alternateName. Erfinden Sie keine Übersetzung, die im Handelsregister nicht steht.

sameAs nur mit echten Profilen. Verlinken Sie Profile, die Sie kontrollieren und die live sind. Ein Verweis auf ein gelöschtes Facebook-Profil ist kein Signal, sondern ein Widerspruch.

Das Logo muss mindestens 112 mal 112 Pixel groß und crawlbar sein.

LocalBusiness, Article und BreadcrumbList

Bei LocalBusiness gibt es zwei Pflichtfelder: name und address. Google empfiehlt den spezifischsten Subtyp statt des Oberbegriffs, also Dentist statt LocalBusiness. Bei mehreren Tätigkeiten geben Sie ein Array an, additionalType unterstützt Google nicht.

{

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

"@type": "Dentist",

"@id": "https://www.beispiel-praxis.de/#praxis",

"name": "Zahnarztpraxis Dr. Berger",

"url": "https://www.beispiel-praxis.de/",

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

"priceRange": "$$",

"address": {

"@type": "PostalAddress",

"streetAddress": "Leopoldstraße 42",

"addressLocality": "München",

"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"

}

]

}

Die Koordinaten brauchen laut Google mindestens fünf Nachkommastellen. priceRange muss unter 100 Zeichen bleiben, sonst zeigt Google gar keine Preisangabe.

Und jetzt die Falle, die uns am häufigsten begegnet. aggregateRating und review empfiehlt Google bei LocalBusiness ausdrücklich nur für Seiten, die Bewertungen über andere Unternehmen sammeln. Die vier Sterne aus den eigenen Kundenstimmen als AggregateRating auszuzeichnen ist der kürzeste Weg zu einer manuellen Maßnahme. Wir tun das nicht, bei keinem Kunden, auch wenn die Bewertungen echt sind.

Für Blogartikel reichen zwei Objekte nebeneinander. Article kennt ebenfalls keine Pflichtfelder:

[

{

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

"@type": "BlogPosting",

"@id": "https://www.beispiel.de/blog/strukturierte-daten#article",

"headline": "Strukturierte Daten, die echte Rich Results bringen",

"image": ["https://www.beispiel.de/bilder/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.beispiel.de/author/jonas-tribus"

},

"publisher": { "@id": "https://www.beispiel.de/#organization" }

},

{

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

"@type": "BreadcrumbList",

"itemListElement": [

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

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

{ "@type": "ListItem", "position": 3, "name": "Strukturierte Daten" }

]

}

]

Zwei Punkte dazu: In author.name gehört ausschließlich der Name. Google listet Jobtitel, Anreden und Zusätze wie „veröffentlicht von" ausdrücklich als Fehler und verweist für die Funktion auf jobTitle. Und das letzte Element der Breadcrumb bekommt kein item, weil es die aktuelle Seite ist.

Strukturierte Daten und KI-Antworten

Seit Mai 2026 gibt es dazu eine offizielle Antwort, und sie fällt nüchterner aus, als der Markt sie gern hätte. In seinem Leitfaden zur Optimierung für generative KI-Funktionen listet Google unter „Mythbusting" den Punkt „Overfocusing on structured data" und schreibt: Strukturierte Daten sind für die generative KI-Suche nicht erforderlich, und es gibt kein spezielles Schema.org-Markup, das Sie hinzufügen müssten. Als Teil der SEO-Arbeit bleibe der Einsatz sinnvoll, weil er die Zulässigkeit für Rich Results herstellt. Im selben Abschnitt steht, dass Google llms.txt und vergleichbare Dateien ignoriert.

Wer Ihnen ein „Schema-Paket für AI Overviews" verkauft, widerspricht damit der Dokumentation des Anbieters, um dessen Funktion es geht.

Der Entitätsnutzen bleibt trotzdem real, nur an anderer Stelle. Er entsteht dort, wo Google ihn selbst benennt: bei der Unterscheidung. Wenn in Brixen ein Hotel, eine Tischlerei und eine Kanzlei denselben Familiennamen tragen, entscheidet die Kombination aus Adresse, Umsatzsteuernummer, URL und verifizierten Profilen darüber, welcher Eintrag gemeint ist. Diese Angaben sind auch dann korrekt, wenn niemand ein Rich Result ausspielt.

Leiten Sie aus Schema.org-Markup keinen garantierten Vorteil in ChatGPT, Perplexity oder Gemini ab: Die hier zitierten Anbieter-Dokumentationen geben dafür keine Zusage. Wie sich Sichtbarkeit in KI-Antworten dagegen tatsächlich beeinflussen lässt, steht in unserem Vergleich von SEO, AEO und GEO und in der Leistungsbeschreibung zur Sichtbarkeit in KI-Antworten.

Messen lässt sich das in der Search Console, im Bericht zur Leistung in generativen KI-Funktionen.

Der Ablauf, den wir bei jedem Projekt gehen

1. Inventur über fünf Seitentypen. Startseite, eine Leistungsseite, eine Standortseite, ein Artikel, die Kontaktseite. Rich Results Test plus Blick in den Quelltext. Wir suchen zuerst nach Dubletten, nicht nach Fehlern.
2. Faktenabgleich. Firmenname, Adresse, Telefonnummer und Umsatzsteuernummer müssen mit dem Impressum und dem Google-Unternehmensprofil übereinstimmen. Im DACH-Raum ist das Impressum die belastbarste Quelle, weil es rechtlich gepflegt wird. Bei Umlauten und Straßenschreibweisen gilt eine Variante für alle Systeme.
3. Ein Organization-Knoten. Auf der Startseite, mit stabiler @id. Alles andere referenziert ihn, statt ihn zu wiederholen.
4. Serverseitig ausliefern. Google verarbeitet auch per JavaScript eingefügtes JSON-LD, aber jede zusätzliche Abhängigkeit ist eine Fehlerquelle beim nächsten Deployment.
5. Zwei Validierungen, zwei Fragen. Der Rich Results Test beantwortet, ob eine Seite für ein Google-Feature zulässig ist. Der Schema Markup Validator auf validator.schema.org beantwortet, ob das Vokabular gültig ist, auch für Typen, die Google nicht verwendet. Danach die URL-Prüfung in der Search Console, weil nur sie zeigt, was Google nach dem Rendern sieht.
6. Warten und beobachten. Google weist darauf hin, dass es nach der Veröffentlichung mehrere Tage dauern kann, bis eine Seite gefunden und gecrawlt ist. Wer am nächsten Morgen Ergebnisse erwartet, misst Rauschen.

Was wir bewusst weglassen: Bewertungen über uns selbst, weiteren Aufwand für FAQPage, und jede Angabe, die auf der Seite nicht steht. Die technischen Voraussetzungen dahinter, von der Auslieferung bis zur Crawlbarkeit, gehören zu den technischen Grundlagen einer Website. Wie sich Ladezeit und Stabilität dazu verhalten, steht in unserem Text zu Core Web Vitals in der Praxis.