Schema.org: strukturierte Daten richtig einsetzen

Was strukturierte Daten leisten, und was nicht

Ein Sprachmodell oder ein Crawler kann aus Fließtext ableiten, dass „ab 800 Euro monatlich“ ein Preis ist. Das kostet Rechenaufwand und ist fehleranfällig. Steht dieselbe Angabe als Markup im Quelltext, ist sie eindeutig.

Was strukturierte Daten nicht tun: Sie sind kein Rankingfaktor im engeren Sinne. Googles eigene Dokumentation beschreibt sie durchgehend als Voraussetzung dafür, dass eine Seite für eine erweiterte Darstellung in Frage kommt. Von einer besseren Platzierung ist dort an keiner Stelle die Rede. Wer Markup einbaut und danach höhere Positionen erwartet, wird enttäuscht.

Was sie doch tun: Sie ermöglichen erweiterte Darstellungen in den Suchergebnissen, also Rich Snippets wie Sternebewertungen, Preisspannen oder Öffnungszeiten. Sie machen Ihr Unternehmen als Entität eindeutig, also als klar identifizierbares Ding mit Eigenschaften und Beziehungen. Das ist die Grundlage dafür, dass ein Modell Sie überhaupt zuordnen kann und dass Google Sie im Knowledge Graph führt.

Ein Punkt wird dabei oft übersehen. Google hält in der Einführung zu strukturierten Daten ausdrücklich fest, dass es die Eigenschaft sameAs und weitere schema.org-Angaben auch allgemein auswerten kann, unabhängig von einer dokumentierten Suchfunktion. Markup wirkt also nicht nur dort, wo es sichtbar wird.

Die vier Typen, die sich lohnen

Organization beschreibt das Unternehmen: Name, Rechtsform, Adresse, Telefon, Logo und verknüpfte Profile über sameAs. In der Google-Dokumentation zu Organization gibt es dafür keine Pflichtfelder. Google empfiehlt stattdessen, so viele passende Eigenschaften wie möglich anzugeben, und rät dazu, den Block auf der Startseite auszuspielen oder auf einer einzelnen Seite, die das Unternehmen beschreibt. Zwei Details, an denen es in der Praxis oft scheitert: Das Logo muss mindestens 112 mal 112 Pixel groß sein und für das Crawling erreichbar und indexierbar sein.

Für Industrieunternehmen lohnt sich ein Blick auf die Kennungsfelder derselben Dokumentation. legalName nimmt den Firmennamen laut Handelsregister auf, vatID die Umsatzsteuer-Identifikationsnummer, iso6523Code eine offizielle Unternehmenskennung mit vorangestelltem Schema. Google nennt dafür unter anderem die Präfixe 0060 für DUNS, 0088 für die GS1 Global Location Number und 0199 für den Legal Entity Identifier. Das sind Angaben, die eine Firma weltweit eindeutig machen.

Person beschreibt die Menschen dahinter, mindestens die Geschäftsführung und die Autoren von Fachbeiträgen. Sprachmodelle verankern Fachwissen an Personen, nicht an Firmen. Eine Person ohne Markup und ohne verknüpfte Profile bleibt für ein Modell eine Zeichenkette.

Article gehört auf jeden Ratgeberbeitrag. Googles Dokumentation zu Article kennt ebenfalls keine Pflichtfelder, empfiehlt aber headline, datePublished und vor allem author samt author.url. Der Verweis auf eine echte Autorenseite ist der Punkt, der aus einem Namen eine zuordenbare Person macht.

LocalBusiness oder Service, je nachdem, ob der Standort oder die Leistung im Vordergrund steht. LocalBusiness ist der einzige der hier genannten Typen mit echten Pflichtangaben: Name und Adresse. Empfohlen sind zusätzlich Öffnungszeiten über openingHoursSpecification, Telefonnummer mit Landesvorwahl und Koordinaten über geo. Für Breiten- und Längengrad nennt Googles Dokumentation zu LocalBusiness mindestens fünf Nachkommastellen als Anforderung. Für Unternehmen mit Einzugsgebiet ist das die Basis für Local SEO.

Ein vollständiges Beispiel in JSON-LD

Der häufigste Fehler beim Einbau ist nicht ein falsches Feld, sondern eine fehlende Verbindung. Organisation und Person stehen als zwei getrennte Blöcke im Quelltext, ohne dass eine Maschine erkennt, dass die eine für die andere arbeitet. Die Lösung sind feste Kennungen über @id und ein gemeinsamer @graph. Das folgende Beispiel arbeitet mit Platzhaltern und lässt sich eins zu eins übernehmen.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.de/#organisation",
      "name": "Muster GmbH",
      "legalName": "Muster Maschinenbau GmbH",
      "url": "https://example.de/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.de/bilder/logo.png",
        "width": 512,
        "height": 512
      },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Musterstrasse 1",
        "postalCode": "26123",
        "addressLocality": "Oldenburg",
        "addressCountry": "DE"
      },
      "contactPoint": {
        "@type": "ContactPoint",
        "telephone": "+49-441-0000000",
        "contactType": "customer support"
      },
      "vatID": "DE000000000",
      "sameAs": [
        "https://www.linkedin.com/company/muster-gmbh",
        "https://www.wikidata.org/wiki/Q0000000"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://example.de/#geschaeftsfuehrung",
      "name": "Vorname Nachname",
      "jobTitle": "Geschäftsführung",
      "url": "https://example.de/team/vorname-nachname",
      "worksFor": { "@id": "https://example.de/#organisation" },
      "sameAs": [
        "https://www.linkedin.com/in/vorname-nachname"
      ]
    }
  ]
}
</script>

Entscheidend sind die drei Zeilen mit @id und worksFor. Die Person verweist über die Kennung auf die Organisation, statt sie ein zweites Mal zu beschreiben. Wenn Sie auf einer Unterseite ein weiteres Objekt auszeichnen, etwa einen Article oder einen Service, verweisen Sie mit derselben Kennung auf dieselbe Organisation. So bleibt es aus Sicht der Maschine ein Unternehmen und nicht fünf.

sameAs: die Eigenschaft, die am meisten unterschätzt wird

Die Eigenschaft sameAs verknüpft Ihre Entität mit anderen Auftritten derselben Firma oder Person. schema.org definiert sie als die Adresse einer Referenzseite, die die Identität des Objekts eindeutig angibt, und nennt als Beispiele die Wikipedia-Seite, einen Wikidata-Eintrag und die offizielle Website. Google beschreibt in der Organization-Dokumentation denselben Zweck etwas weiter: eine Seite auf einer anderen Website mit zusätzlichen Informationen, etwa ein Profil in einem sozialen Netzwerk oder auf einem Bewertungsportal. Mehrere Adressen sind ausdrücklich erlaubt.

Warum das zählt: Suchmaschinen und Modelle müssen entscheiden, ob die „Muster GmbH“ auf Ihrer Website dieselbe ist wie die auf LinkedIn und die in einem Fachartikel. Ohne sameAs müssen sie das aus dem Kontext erraten. Mit sameAs ist es festgelegt. Und weil Google diese Eigenschaft laut eigener Einführung auch außerhalb dokumentierter Suchfunktionen auswertet, ist sie einer der wenigen Hebel, die unabhängig von einer bestimmten Darstellung wirken.

Praktisch heißt das: Zwei Zeilen Markup können mehr bewirken als eine zusätzliche Unterseite. Sinnvoll sind der LinkedIn-Firmeneintrag, ein Wikidata-Eintrag, sofern vorhanden, das Unternehmensprofil bei Google und Einträge in Branchenverzeichnissen, die Ihre Kunden tatsächlich nutzen. Bei Personen sind das LinkedIn und Autorenprofile auf Fachplattformen.

Eine Warnung dazu: Falsche oder tote sameAs-Angaben schaden mehr, als sie nützen. Prüfen Sie jede verlinkte Adresse, bevor sie live geht, und prüfen Sie sie erneut, wenn ein Profil umzieht oder gelöscht wird.

Was mit FAQPage passiert ist

Bis vor Kurzem galt FAQPage als der Typ mit dem besten Verhältnis von Aufwand zu Nutzen. Das stimmt so nicht mehr. Google hat die Funktion abgekündigt und im Änderungsprotokoll von Search Central zwei Schritte dokumentiert: Am 8. Mai 2026 kam der Hinweis in die Dokumentation, dass die aufklappbaren Fragen ab dem 7. Mai 2026 nicht mehr in der Google-Suche erscheinen. Am 15. Juni 2026 wurde die Dokumentation zu FAQPage komplett entfernt, mit der Begründung, dass die Darstellung in den Suchergebnissen nicht mehr gezeigt wird.

Was heißt das für Ihre Website? Vorhandenes FAQ-Markup müssen Sie nicht ausbauen. Es ist gültiges schema.org-Vokabular, es verstößt gegen nichts, und andere Systeme können es weiterhin lesen. Neu investieren würde ich die Zeit dort aber nicht mehr. Wer heute anfängt, baut zuerst Organization, Person und Article.

Der eigentliche Wert des Frage-Antwort-Formats lag ohnehin nie im Markup, sondern im sichtbaren Text. Eine kurze Frage als Überschrift und eine Antwort, die in den ersten zwei Sätzen fertig ist, bleibt die Passage mit der höchsten Zitierfähigkeit. Das gilt für Google genauso wie für ChatGPT oder Perplexity. Behalten Sie also den Fragenblock, und behandeln Sie das Markup dazu als Beigabe.

In sechs Schritten einbauen und prüfen

Der Einbau ist weniger Arbeit, als viele annehmen. Der Reihe nach:

1. Bestandsaufnahme. Sehen Sie nach, was schon da ist. Viele Baukästen und Plugins schreiben ungefragt Markup in den Quelltext, oft veraltet oder doppelt. Der Test für Rich-Suchergebnisse von Google zeigt es Ihnen für jede einzelne Adresse.
2. Stammdaten festlegen. Firmenname, Rechtsform, Anschrift, Telefonnummer, Logo-Adresse, Umsatzsteuer-Identifikationsnummer, alle Profile. Einmal sauber gesammelt, danach nie wieder abtippen.
3. Organization-Block bauen. Auf die Startseite, mit fester Kennung. Diese Kennung ist ab jetzt der Ankerpunkt für alles Weitere.
4. Person-Blöcke ergänzen. Geschäftsführung und Autoren, jeweils mit worksFor auf die Kennung aus Schritt drei.
5. Seitenspezifisches Markup setzen. Article auf Ratgeberbeiträgen, LocalBusiness auf der Standortseite, Service auf den Leistungsseiten. Nur dort, wo der Inhalt es hergibt.
6. Prüfen und überwachen. Der Test für Rich-Suchergebnisse zeigt, was Google daraus macht. Der Schema-Markup-Validator von schema.org prüft strenger gegen das Vokabular und meldet auch Felder, die Google ignoriert. Für die Dauerüberwachung ist der Bericht zu erweiterten Suchergebnissen in der Google Search Console das richtige Werkzeug, weil er Fehler über die Zeit meldet.

Zum Aufwand, weil das die häufigste Frage im Erstgespräch ist: Für eine Unternehmenswebsite mit 15 bis 30 Seiten liegt der Erstaufwand in meinen Projekten bei einem halben bis einem Arbeitstag, sofern die Stammdaten vorliegen. Der Löwenanteil davon ist das Sammeln der Profile, nicht das Schreiben des Codes. Die laufende Pflege sind etwa 15 Minuten pro Quartal: Adresse, Telefonnummer und die Erreichbarkeit der sameAs-Adressen prüfen.

Bis Änderungen wirken, dauert es. Google muss die Seite neu crawlen, bevor neues Markup überhaupt gesehen wird. Rechnen Sie mit Tagen bis Wochen, abhängig davon, wie oft Ihre Seiten ohnehin abgerufen werden. Ein Blick in die Search Console am Tag nach dem Livegang bringt nichts.

Häufige Fehler

Markup, das nicht zum sichtbaren Inhalt passt. Bewertungen auszuzeichnen, die auf der Seite nicht stehen, ist ein Verstoß gegen die Richtlinien für strukturierte Daten von Google und kann zum Verlust erweiterter Darstellungen führen.

Mehrere Organization-Einträge ohne gemeinsame Kennung. Wenn jede Seite ihre eigene Organisation deklariert, ohne dass klar ist, dass es dieselbe ist, entstehen aus Sicht der Maschine mehrere Unternehmen. Genau dafür ist @id da.

Der Organization-Block auf jeder einzelnen Seite. Das ist gut gemeint, aber nicht das, was Google empfiehlt. Die Dokumentation nennt die Startseite oder eine einzelne Seite, die das Unternehmen beschreibt. Auf Unterseiten genügt der Verweis über die Kennung.

Ein Logo, das die Anforderungen verfehlt. Unter 112 mal 112 Pixel, hinter einem Login, per robots.txt gesperrt oder als SVG ohne indexierbare Adresse: In all diesen Fällen ist das Feld ausgefüllt und trotzdem wertlos.

Veraltete Angaben. Markup wird beim Bau eingebaut und danach vergessen. Wenn sich Adresse, Telefonnummer oder Bewertungszahl ändern, muss auch der Quelltext nachgezogen werden.

Zu viel. Das Vokabular von schema.org umfasst mehrere hundert Typen, und Googles Übersicht der unterstützten Auszeichnungen listet rund drei Dutzend Funktionen. Für eine Unternehmenswebsite sind vier Typen relevant. Der Rest kostet Pflegeaufwand ohne erkennbaren Gegenwert.