Wann strukturierte Daten wirklich Sinn ergeben – und wann sie nur gut gemeint sind
FAQ-Schema, Sterne-Bewertungen, Organisationsdaten: Strukturierte Daten gelten oft als Selbstläufer für bessere Sichtbarkeit. Ein genauerer Blick zeigt, wo sie wirklich helfen können, und wo ihre Wirkung verpufft.
Im Beitrag über den Content-Pillar-Baukasten haben wir die 10 Bausteine vorgestellt, aus denen sich eine starke Content Pillar Page zusammensetzt – ausgerichtet auf E-E-A-T. Was jeder dieser Bausteine an strukturierten Daten benötigt, ist die letzte, oft missverstandene Ebene obendrauf.
Google selbst schreibt in den Guidelines zur KI-Optimierung, dass strukturierte Daten nicht nötig sind, damit eine Suchmaschine Inhalte versteht. Trotzdem sollen sie weiterhin für ihren ursprünglichen Zweck eingesetzt werden: nämlich zusätzliche, explizite Informationen zu liefern, die aus Fliesstext allein nicht eindeutig hervorgehen.
Strukturierte Daten sind dann sinnvoll, wenn sie gute Inhalte sinnvoll ergänzen. Sie sind aber kein Trick, um bei Google besser sichtbar zu werden. Wer sie als einen solchen behandelt, wird früher oder später abgestraft. Ein Beispiel dafür sind FAQ-Schema: Viele Websites haben solche Angaben gezielt eingebaut, um in den Suchresultaten auffälliger dargestellt zu werden. Google schränkte deshalb 2023 die Darstellung in den Rich-Results stark ein – und entfernte sie im Mai 2026 ganz.
Strukturierte Daten sind also keine Abkürzung zu besseren Rankings. Sie helfen Suchmaschinen lediglich dabei, bereits vorhandene Inhalte einer Website besser zu verstehen. Genau deshalb lohnt sich ein genauerer Blick, welche strukturierten Daten heute noch etwas bringen – und welche nur noch gut gemeint sind.
Strukturierte Daten im Überblick
Manche Daten gehören nicht auf jede einzelne Content Pillar Page, sondern genau einmal ins Fundament der Website – und werden von dort aus referenziert. Andere sind pro Seite sinnvoll, wenn das jeweilige Thema es hergibt. Und ein Typ gehört bewusst weder auf die eine noch die andere Ebene. Ein Überblick:
| Typ | Ebene | Einsatz |
|---|---|---|
Organization / LocalBusiness | website-weit | Der Entitäts-Anker: möglichst spezifischer Subtyp statt generisch (für ein Treuhandbüro z. B. AccountingService), plus Name, Adresse, Telefon, Logo, sameAs, areaServed. Zentral definiert, über eine @id von jeder Seite referenziert – nicht auf jeder Seite neu und leicht unterschiedlich ausformuliert. |
Person | website-weit | Für jedes Teammitglied, mit jobTitle und worksFor. Eine Person, eine @id, über alle Content Pillar Pages hinweg konsistent. |
WebSite | website-weit | Grundeinordnung der Domain, meist ohnehin durch das SEO-Setup abgedeckt. |
Service | pro Content Pillar Page | Das jeweilige Angebot als eigene, benannte Entität, mit serviceType und provider-Verweis auf die zentrale Organization. |
FAQPage | pro Content Pillar Page | Seit 7. Mai 2026 vollständig aus der Google-Suche entfernt, keine Ausnahmen mehr – aber geringer Aufwand als expliziter Daten-Layer für andere Systeme. |
HowTo | Eher nicht priorisieren | Dieselbe Deprecation wie FAQ, aber ohne Zusatznutzen als Daten-Layer – ein Prozess steht ohnehin meist schon als klar nummerierter Text im HTML. |
BreadcrumbList | pro Content Pillar Page | Niedriger Aufwand, klare Einordnung der Seite in die Website-Hierarchie. |
Review / AggregateRating | bewusst weglassen | Self-serving auf der eigenen Content Pillar Page nicht zulässig, unabhängig von der Quelle. Ausführliche Erklärung weiter unten. |
Article / BlogPosting | separat, auf Ratgeber-Artikeln | datePublished, dateModified, author – gehören auf die verlinkten Wissensartikel, nicht auf die Content Pillar Page selbst. |
Hinweise zu FAQPage und HowTo
Google hat FAQ-Rich-Results 2023 zunächst auf eine kleine Zahl autoritativer Gesundheits- und Behördenseiten eingeschränkt und diese Ausnahme per 7. Mai 2026 ebenfalls gestrichen. Seither zeigt Google für niemanden mehr FAQ-Rich-Results an, auch nicht mehr im Rich-Results-Test (die Unterstützung dafür fiel im Juni 2026 weg).
Der optische Effekt in der Google-Suche ist also vollständig weg. Trotzdem kann FAQPage weiterhin gesetzt werden. Denn der Aufwand bleibt klein und die Struktur als Daten-Layer für andere Systeme, die nicht zwingend dieselbe Rich-Result-Logik fahren wie Google, kann wertvoll bleiben.
Dabei muss jedoch der genaue Zweck von FAQPage beachtet werden. Das FAQPage-Schema sollte nur für Seiten eingesetzt werden, die eigentlich FAQ-Seiten sind. Beispielsweise könnten das häufig gestellte Fragen für Gäste eines Hotels sein. Dieser Schema-Typ sollte nicht für FAQ-Abschnitte auf einer längeren Seite verwendet werden. Aktuell wird in der Web-Community gerade darüber diskutiert, ob ein FAQSection-Schema für FAQ-Abschnitte Sinn ergeben würde.
Bei HowTo empfehlen wir, keine Schema-Daten mehr hinzufügen. Wenn ein Ablauf oder ein Prozess beschrieben wird und dieser bereits semantisch als Liste im HTML aufgeführt ist, dann bringt die Schema-Hülle dort kaum zusätzliche Klarheit.
Hinweise zu Organization/LocalBusiness
Auch beim Schema-Typ Organization/LocalBusiness lohnt sich Präzision: Google empfiehlt ausdrücklich, den spezifischsten passenden Subtyp zu verwenden, statt der generischen Bezeichnung. Für unser Beispiel «Muster Treuhand AG» also AccountingService statt LocalBusiness.
Zusätzlich kann diese Ebene durch mehrere Properties ergänzt werden, die direkt E-E-A-T stützen, aber häufig vergessen gehen:
foundingDate(Erfahrung)award(gewonnene Awards/Preise)hasCredential(Fachausweise, Zertifizierungen)memberOf(Branchenverband)vatID(ein von Google explizit als Vertrauenssignal benanntes Feld)
Diese Properties sind kein Pflichtprogramm, aber jedes davon kann die Entität für Systeme wie Google und LLMs, die nach überprüfbaren Fakten statt nach Behauptungen suchen, etwas greifbarer machen.
Die Sonderfälle «Review» und «AggregateRating»
Die Schema-Typen Review und AggregateRating werden häufig missverstanden. Für Testimonials sollten wir nicht einfach Schema-Daten hinzufügen.
Die Regel dahinter: Es kommt nicht auf die Quelle einer Bewertung an, sondern darauf, wer wen bewertet.
Bewertet sich ein Unternehmen auf der eigenen Content Pillar Page selbst, ist das für Google nicht für die Stern-Darstellung zugelassen. Laut Googles eigener Dokumentation ausdrücklich auch dann nicht, wenn die Bewertungen über ein eingebettetes Drittanbieter-Widget eingebunden werden, etwa ein Google- oder Facebook-Reviews-Widget.
Die zwei Ausnahmen:
- Bewertet wird ein Produkt, ein Rezept, ein Kurs, eine Software oder ein vergleichbares Werk statt des Unternehmens selbst.
- Eine unabhängige Drittseite bewertet ein anderes Unternehmen.
Für den klassischen Testimonial-Block trifft keine der beiden Ausnahmen zu. Die Zitate selbst bleiben auf der Webseite, einfach als sauberes HTML statt ergänzt mit Schema.
Diese Trennung zwischen Website-weiten und seitenspezifischen Daten – und das bewusste Weglassen dort, wo es nichts bringt – ist Teil des Content-Pillar-Baukastens: Strukturierte Daten sind dabei nie der erste Schritt, sondern die letzte, gezielt eingesetzte Ebene über einer bereits stimmigen inhaltlichen Struktur.
Sind bei dir die richtigen strukturierten Daten im Einsatz?
Zwischen sinnvoll und nur gut gemeint liegt oft nur ein technischer Blick unter die Haube. Im Marken- und Sichtbarkeitscheck prüfen wir dein technisches Fundament – inklusive konkreter Handlungsempfehlungen.
