Vorhanden heißt nicht brauchbar: die häufigsten Fehler in strukturierten Daten und was sie kosten

Die meisten Ratgeber zu strukturierten Daten beantworten die Frage, wie man sie anlegt. Das ist der einfache Teil. Die schwierigere Frage stellt sich danach: Das Markup ist da, es ist formal gültig, jedes Prüfwerkzeug meldet grün, und trotzdem beschreibt kein Modell die Marke richtig.

Dieser Text ist deshalb kein Einstiegs-Ratgeber, sondern eine Fehlerkunde. Jeder Abschnitt beschreibt einen Befund, den wir in echten Prüfungen tatsächlich gefunden haben, was er kostet und wie er sich beheben lässt. Die Zahlen stammen aus Läufen unseres eigenen Prüfwerkzeugs gegen laufende Websites. Fremde Seiten nennen wir nicht beim Namen, unsere eigenen schon, und unsere eigenen kommen dabei nicht gut weg.

Zuerst eine Klarstellung, die selten jemand macht

Strukturierte Daten sind keine Voraussetzung dafür, in KI-Antworten aufzutauchen. Google sagt das ausdrücklich: Für AI Overviews sind keine besonderen strukturierten Daten nötig. Wer verspricht, ohne Schema sei eine Marke unsichtbar, verkauft eine Behauptung, die sich mit einem Satz aus der Google-Dokumentation kippen lässt.

Was strukturierte Daten leisten, ist etwas anderes und Genaueres. Sie entscheiden nicht darüber, ob ein Modell eine Marke findet, sondern ob es sie richtig beschreibt. Ohne sie liest ein Modell Fließtext und schätzt: Was ist hier das Produkt, was der Preis, wer der Anbieter, ist das eine Filiale oder eine Konzernzentrale? Meistens rät es passabel. Manchmal rät es falsch, und dann wiederholt sich der Fehler, weil eine falsche Antwort genauso zitierfähig ist wie eine richtige.

Der ehrliche Nutzen ist also: weniger Interpretationsspielraum. Das klingt bescheidener als „sonst seid ihr unsichtbar" und ist der einzige Anspruch, den man auch in sechs Monaten noch halten kann.

Der Unterschied zwischen vorhanden und brauchbar

Fast alle Prüfwerkzeuge beantworten eine Ja-Nein-Frage: Ist Markup da? Diese Frage stellt man einmal. Danach ist sie nutzlos, weil die Antwort ab dann immer ja lautet.

Wir bewerten stattdessen die Tiefe, und zwar entlang von fünf tragenden Bausteinen:

1. Der Absender. Wer bietet das an? Ein Organization-Knoten.

2. Die Website. Was ist das für ein Auftritt? Ein WebSite-Knoten.

3. Die Seite. Worum geht es auf genau dieser Unterseite? Ein WebPage-Knoten.

4. Der Pfad. Wo steht diese Seite im Aufbau? Eine BreadcrumbList.

5. Der Gegenstand. Was wird hier eigentlich beschrieben? Ein Product, Service, Article, FAQPage.

Warum diese fünf und nicht mehr: Sie sind die Minimalmenge, aus der sich ein Zusammenhang bilden lässt. Ein Modell kann daraus ableiten, dass dieser Anbieter auf dieser Seite dieses Angebot macht, und wo das im Gesamtauftritt steht. Fehlt einer der fünf, bricht eine Beziehung weg.

Der Unterschied ist größer, als er klingt. Wir haben eine Zeit lang jede Seite bei 100 Punkten starten lassen und nur Fehler abgezogen. Ergebnis: Ein Autohaus-Portal mit einem einzigen nackten Organization-Knoten bekam denselben Wert wie ein vollständig verknüpfter Graph. Beide 88. Das war keine Bewertung, das war eine Fehlerliste mit einer Zahl davor.

Seitdem ist die Tiefe der Grundwert und Befunde ziehen davon ab. Eine Seite mit einem Knoten kann damit nicht mehr gut abschneiden, egal wie fehlerfrei dieser eine Knoten ist. Das ist der wichtigste Satz dieses Textes: Ein einzelner korrekter Knoten ist nicht wenig gutes Markup, sondern fast kein Markup.

Die Befunde am Absender

Kein Organization-Knoten

Der häufigste Fall überhaupt. Die Seite beschreibt Produkte, Leistungen, Artikel, aber nirgends steht, wer das anbietet.

Für ein Modell entsteht dann Inhalt ohne Herkunft. Es kann sagen, was auf der Seite steht, aber die Aussage keiner Marke zuordnen. Genau das ist der Moment, in dem in einer Antwort der Wettbewerber genannt wird, weil dessen Name sauber an seinen Fakten hängt.

Beheben: Ein Organization-Knoten mit name, url, logo und einer stabilen @id, auf die andere Knoten verweisen können.

Zwei Organisationen mit verschiedenen Namen

Ein Fehler, der fast nur bei größeren Auftritten vorkommt, dafür mit Wucht. Auf derselben Seite stehen zwei Organization-Knoten, einer trägt den Markennamen, der andere den Namen der Holding oder des Dienstleisters, der die Seite gebaut hat.

Für eine Maschine ist damit offen, wie das Unternehmen heißt. Sie muss sich entscheiden und entscheidet nicht immer für den Namen, unter dem Kunden suchen.

Beheben: Ein Name pro Seite. Gehört die Holding wirklich erwähnt, dann als parentOrganization, nicht als zweiter gleichrangiger Knoten.

Organization ohne sameAs

sameAs verweist auf ein Profil, das anderswo existiert: LinkedIn, Wikidata, ein Branchenregister, ein Handelsregistereintrag.

Ohne diesen Verweis bleibt der Markenname für ein Modell ein Wort ohne Anker. Es kann ihn nicht mit dem verknüpfen, was es sonst über das Unternehmen gelesen hat, und behandelt zwei Erwähnungen derselben Firma möglicherweise als zwei verschiedene Firmen.

Das ist der stärkste einzelne Hebel in diesem ganzen Text, und gleichzeitig der, der am häufigsten fehlt. Auch bei uns, siehe unten.

Beheben: Nur echte, erreichbare Profile eintragen. Ein falscher Verweis ist schlechter als keiner.

Das Logo, das keins ist

Ein leiser Fehler, den fast niemand bemerkt. Unter logo steht die Adresse des Social-Media-Vorschaubilds, also der 1200 mal 630 Pixel breiten Karte mit Text darauf.

Suchmaschinen erwarten dort die Bildmarke: quadratisch, ohne Text, als Rasterbild. Eine breite Karte wird verworfen oder falsch beschnitten.

Das ist uns selbst zweimal passiert. Wir haben es im Organization-Knoten behoben und dabei übersehen, dass dieselbe Angabe im Artikel-Markup ein zweites Mal steht. Dort zeigte sie noch wochenlang auf die Social-Karte.

Beheben: Eine eigene, stabile URL für die quadratische Bildmarke, und dann im ganzen Auftritt nur diese eine.

Die Befunde an der Seite

Der WebPage-Knoten gehört zu einer anderen Seite

Das Markup nennt eine URL, die geprüfte Seite ist eine andere. Fast immer ein Vorlagen-Fehler: Ein Muster wurde kopiert und die Adresse nicht mitgezogen.

Die Folge ist, dass eine Maschine den Inhalt dieser Seite den Fakten einer anderen zuordnet. Das ist schlimmer als fehlendes Markup, weil es aktiv in die Irre führt.

Beheben: Die URL aus dem Seitenkontext erzeugen, nie hart eintragen.

Alle Breadcrumb-Stufen zeigen auf dasselbe Ziel

Die Brotkrumen sehen im Quelltext vollständig aus, drei Stufen, saubere Bezeichnungen. Nur zeigen alle drei item-Angaben auf dieselbe URL.

Das beschreibt keinen Pfad. Ein Modell kann daraus nicht ableiten, dass eine Seite in einer Kategorie liegt und die Kategorie im Gesamtauftritt.

Das letzte Breadcrumb-Label ist der Seitentitel

Ein kleiner, aber verräterischer Befund: Die letzte Stufe trägt statt eines kurzen Pfadnamens den vollständigen, für Suchmaschinen optimierten Seitentitel. Wir schlagen ab 60 Zeichen an. Gemessen haben wir Labels mit über 100 Zeichen, auf unserer eigenen Magazin-Seite.

Es ist kein Beinbruch, aber es zeigt, dass die Brotkrumen automatisch aus dem Titel-Feld befüllt wurden statt aus der Navigationsstruktur.

Die Befunde am Angebot

Alle Produkt-URLs zeigen auf die Startseite

Ein Muster, das wir bei einem großen Händler-Portal gefunden haben und das uns überhaupt erst dazu gebracht hat, eine eigene Regel dafür zu bauen: Dutzende Angebotsknoten, jeder korrekt benannt, jeder mit Bild, und jeder mit einer url, die auf die Startseite zeigt.

Formal ist das gültig. Praktisch ist es wertlos: Kein einziges Angebot lässt sich einer Seite zuordnen. Fragt jemand nach einem konkreten Artikel, kann ein Modell ihn nennen, aber nicht sagen, wo er zu finden ist. Auf einer Unterseite ist die Angabe schlicht falsch.

Beheben: Jeder Angebotsknoten bekommt die URL seiner eigenen Seite.

Kein Angebot trägt eine Beschreibung

Namen sind billig, Beschreibungen sind die Substanz. Trägt kein einziger Angebotsknoten eine description, kann ein Modell das Produkt zwar nennen, aber nicht sagen, was es ist oder für wen es taugt. Damit fällt es aus genau den Antworten heraus, die vor der Kaufentscheidung stehen.

Kein Preis, keine Verfügbarkeit

Preis und Verfügbarkeit sind die beiden Felder, nach denen bei Kaufabsicht tatsächlich gefragt wird. Fehlen sie, bleibt „Was kostet das?" und „Gibt es das noch?" unbeantwortet, obwohl beides auf der Seite steht.

Hier lauert allerdings die Falle, die uns selbst fast reingelegt hätte.

Die Shopify-Falle: der Preis hängt nicht am Produkt

Als wir die Preis-Regel gebaut hatten, lief sie sauber durch alle Tests. Dann haben wir sie gegen einen echten Shop laufen lassen und sie meldete fehlende Preise, obwohl der Shop vollständige Preise ausliefert.

Der Grund: Shopify zeichnet Artikel mit Varianten nicht als Product aus, sondern als ProductGroup. Am Gruppenknoten selbst steht kein offers. Preis, Währung und Verfügbarkeit hängen ausschließlich an den einzelnen Varianten unter hasVariant. In dem geprüften Shop waren das elf Varianten, jede mit vollständigem Angebot.

Wer nur die oberste Ebene liest, meldet also jedem Shopify-Shop fehlende Preise, und Shopify ist kein Randfall.

Dasselbe Muster noch einmal, eine Branche weiter: Autohäuser zeichnen Fahrzeuge als Car aus. Das ist ein Untertyp von Product, heißt aber eben nicht Product. Unsere Regel kannte den Namen nicht und wäre an der gesamten Branche vorbeigelaufen.

Wie tiefe Produktdaten im Positiven aussehen, also nicht als Fehlerliste, sondern als Beispiel, steht im Artikel „Perfekte Produktdaten für AI". Wer zuerst wissen will, warum viele Crawler den Seiteninhalt gar nicht erst sehen, findet den Hintergrund unter „Warum die meisten AI-Crawler euren JavaScript-Inhalt nicht lesen".

Die Lehre daraus ist allgemeiner als der Einzelfall: Eine Prüfregel, die nur gegen selbstgebaute Testdaten läuft, prüft die eigene Vorstellung von Markup, nicht das Markup, das es tatsächlich gibt. Wir lassen neue Regeln inzwischen grundsätzlich gegen laufende Seiten mehrerer Branchen laufen, bevor wir sie einschalten. Beide Fehler oben sind genau so gefunden worden, keiner davon in den Tests.

Die Befunde am Ort

Dieser Teil kam zuletzt dazu, weil er in den meisten Schema-Ratgebern fehlt und in echten Anfragen ständig vorkommt.

Ortsmerkmale ohne LocalBusiness-Knoten

Wir werten den sichtbaren Seitentext auf Merkmale eines ortsgebundenen Geschäfts aus: Öffnungszeiten, Wochentage mit Uhrzeiten, Anschriften, Telefonnummern, Begriffe wie Filiale oder Standort. Erst zwei unabhängige Merkmalsarten zählen, weil eine Telefonnummer im Impressum jede Seite hat.

Treffen mehrere zu und es gibt trotzdem keinen LocalBusiness-Knoten, ist das ein Befund. Öffnungszeiten und Anschrift stehen dann nur als Fließtext da. Ein Modell kann sie lesen, aber nicht sicher zuordnen, und beantwortet „Wer hat samstags offen?" im Zweifel gar nicht.

LocalBusiness ohne Öffnungszeiten

„Wer hat samstags offen?" ist die häufigste Frage an ein lokales Geschäft überhaupt. Ohne openingHoursSpecification bleibt sie unbeantwortet, selbst wenn die Zeiten gut sichtbar auf der Seite stehen.

Anschrift ja, LocalBusiness nein

Ein feiner, aber folgenreicher Unterschied. Der Organization-Knoten trägt eine Adresse, ist aber nicht als ortsgebundenes Geschäft ausgezeichnet.

Für eine Maschine ist das die Firmenanschrift, kein Ort, den man besuchen kann. In einer Antwort auf „in meiner Nähe" taucht das Unternehmen damit nicht auf, obwohl die Adresse im Markup steht. Der Typ entscheidet, nicht das Feld.

Wichtig dabei: Diese Daten gehören dem Unternehmen, nicht dem Werkzeug, mit dem es sie prüft. Öffnungszeiten und Standorte pflegt man dort, wo sie ohnehin gepflegt werden. Ein Prüfwerkzeug soll melden, dass sie fehlen, und sich ansonsten heraushalten.

Der Befund, der aktiv schadet

Alle bisherigen Befunde beschreiben etwas, das fehlt. Dieser eine beschreibt etwas, das da ist und Schaden anrichtet.

Bewertungen über sich selbst

Ein Review- oder AggregateRating-Knoten, dessen Autor das Unternehmen selbst ist. Meist entsteht das gutgläubig: Die Kundenstimmen auf der eigenen Seite werden ausgezeichnet, damit Sterne in den Suchergebnissen erscheinen.

Google stuft Bewertungen über das eigene Unternehmen auf der eigenen Seite als selbstbezogen ein und schließt die Seite von Bewertungs-Rich-Results aus. Das Ergebnis ist also nicht null Wirkung, sondern negative: Man verliert eine Darstellungsform, die man sonst hätte haben können.

Der Grenzfall ist wichtig: Stammen die Sterne von einem Bewertungsportal, ist das völlig in Ordnung. Dann muss aber das Portal im Markup stehen, als author oder publisher der Bewertung. Steht dort nichts, ist die Bewertung von außen nicht von einer Selbstbewertung zu unterscheiden.

Beheben: Entweder die fremde Quelle benennen oder das Bewertungs-Markup entfernen.

Die Befunde am Artikel

Blogs und Magazine erben ihr Artikel-Markup fast immer aus dem Redaktionssystem. Zwei Felder bleiben dabei regelmäßig leer.

Artikel ohne Autor

Ohne author fehlt dem Text der Absender, an dem ein Modell Fachlichkeit festmacht. Ein Artikel ohne Autor ist eine Behauptung ohne jemanden dahinter.

Der Autor muss keine Person sein. Ein Unternehmen als Organization ist eine legitime und für Firmenblogs oft ehrlichere Angabe. Was nicht zählt, ist ein leeres Autorobjekt: ein author vom Typ Person ohne name ist kein Autor, sondern eine leere Hülle, die formal gültig ist.

Artikel ohne Datum

Ohne datePublished kann ein Modell nicht einschätzen, ob eine Aussage noch gilt. Gerade in einem Feld, in dem sich Grundlagen halbjährlich ändern, ist das teuer.

Und jetzt der Fehler, den wir bei uns selbst gefunden haben

Neben datePublished gibt es dateModified, das Änderungsdatum. Es ist die einzige Angabe, aus der ein Modell Aktualität ableitet.

In unserem eigenen Magazin war dateModified fest auf denselben Wert wie datePublished gesetzt. Jeder Artikel behauptete damit, seit Erscheinen unverändert zu sein, auch die, die wir überarbeitet hatten.

Die naheliegende Reparatur wäre gewesen, den Zeitstempel des letzten Schreibzugriffs aus dem Redaktionssystem zu nehmen. Wir haben nachgesehen, bevor wir es getan haben, und das war gut so: Von 30 Artikeln trugen 19 denselben Zeitstempel und weitere 7 einen zweiten gemeinsamen. Das waren keine Überarbeitungen, das waren Spuren von Sammelläufen über alle Einträge.

Hätten wir diesen Wert ausgeliefert, hätte unser Magazin bei zwei Dritteln aller Artikel eine Aktualisierung behauptet, die nie stattgefunden hat. Also genau die aufgeblasene Frische-Angabe, die wir bei anderen als Befund melden.

Die Lösung war ein eigenes, von Hand gepflegtes Feld, das leer bleiben darf. Ist es leer, entfällt dateModified ganz. Keine Angabe ist richtig. Eine falsche ist es nicht.

Was wir an unserer eigenen Seite gemessen haben

Ein Text über Fehler in strukturierten Daten, der nur fremde Seiten prüft, ist wohlfeil. Deshalb die eigenen Zahlen.

Unsere Startseite kam auf vier Knoten, Tiefe vier von fünf, 68 von 100 Punkten.

Unsere Magazin-Artikel kamen auf zwei Knoten, Tiefe zwei von fünf, 24 von 100 Punkten. Ihnen fehlte der ganze Rahmen: kein Organization-Knoten, kein WebSite-Knoten, kein WebPage-Knoten. Nur der Artikel selbst und die Brotkrumen. Ausgerechnet auf den Seiten, die am ehesten zitiert werden, war unser Markup am dünnsten.

Die Ursache war lehrreicher als der Fehler, und sie ist die häufigste überhaupt: Es war keine Nachlässigkeit, sondern eine Arbeitsteilung. Der gemeinsame Rahmen entsteht an einer zentralen Stelle, die Artikelseite hatte historisch ihren eigenen Weg mit drei getrennten Markup-Blöcken, und die beiden sind sich nie begegnet. Jede Seite für sich lieferte gültiges Markup. Ein Ja-Nein-Prüfwerkzeug meldet auf beiden grün.

Behoben ist es inzwischen: Artikel und FAQ hängen als Themen-Knoten im selben Graphen wie der Rest der Seite. Damit stehen die Artikelseiten bei Tiefe fünf von fünf und 88 Punkten.

Ein Nebeneffekt der Reparatur ist aufschlussreicher als die Punktzahl. Autor und Herausgeber waren vorher eigene Kopien des Firmenknotens statt Verweise darauf. Genau deshalb zeigte das logo an dieser einen Stelle noch auf die Social-Karte, nachdem es an der anderen längst korrigiert war: Wer dieselbe Angabe zweimal pflegt, pflegt sie irgendwann nur noch einmal. Seitdem sind es Verweise auf einen einzigen Knoten, und die Frage kann sich nicht wiederholen.

Was bei uns offen bleibt, ist sameAs. Es gibt bislang kein öffentliches Profil, das wir belegen könnten, und einen erfundenen Verweis setzen wir nicht. Das kostet uns die letzten Punkte und ist die richtige Entscheidung.

Die Reihenfolge, in der man das abarbeitet

Nicht alle Befunde sind gleich viel wert. Die Reihenfolge, die sich in der Praxis bewährt hat:

1. Erst der Zugang, dann das Markup. Wenn robots.txt die falschen Pfade sperrt oder die Sitemap ins Leere zeigt, ist jede weitere Arbeit umsonst. Wir haben bei einem Autohändler eine Sitemap mit über 3.000 Fahrzeug-URLs gefunden, von denen eine Stichprobe von acht ausnahmslos ins Nichts führte, wegen eines doppelten Sprachkürzels im Pfad. Die Fahrzeugseiten selbst waren einwandfrei ausgezeichnet, mit Preis, Verfügbarkeit, Fahrgestellnummer und Händler. Es sah sie nur niemand.

Bemerkenswert daran ist, wie lange so etwas unbemerkt bleibt. Auch unser eigener Prüfer hat es zunächst nicht gemeldet: Er hatte geprüft, ob eine Sitemap existiert und gültiges XML enthält, und beides traf zu. Dass keine der darin genannten Adressen antwortet, war eine Frage, die wir nicht gestellt hatten. Seitdem rufen wir eine über die ganze Liste verteilte Stichprobe tatsächlich ab. Die Verteilung ist dabei nicht nebensächlich: Am Anfang jeder Sitemap stehen Startseite und Hauptrubriken, also genau die Adressen, die auch dann funktionieren, wenn der Rest tot ist.

1. Dann der Absender. Ein Organization-Knoten mit stabiler @id und, wenn irgend möglich, sameAs.

2. Dann der Zusammenhang. WebSite, WebPage, BreadcrumbList. Das ist die Schicht, die aus einzelnen Angaben einen Graphen macht, und die am häufigsten fehlt.

3. Dann die Substanz. Beschreibungen, Preise, Verfügbarkeit, Öffnungszeiten. Die Felder, nach denen tatsächlich gefragt wird.

4. Zuletzt aufräumen. Selbstbewertungen entfernen, Doppel-Organisationen zusammenführen, falsche Logo-Verweise korrigieren.

Wer nur einen Punkt umsetzen kann, nimmt Punkt drei. Der Zusammenhang ist das, was in fast allen geprüften Auftritten fehlt und was kein Standard-Plugin von allein herstellt.

Wie man das prüft

Für die formale Gültigkeit gibt es Googles Rich Results Test und die Search Console. Beide beantworten zuverlässig die Frage, ob das Markup den Regeln entspricht.

Was sie nicht beantworten, ist die Frage aus diesem Text: ob das gültige Markup auch etwas taugt. Ein einzelner Organization-Knoten besteht jeden Validierungstest.

Unser eigener Prüfer setzt genau dort an, kostenlos und ohne Anmeldung: check.klariton.com. Er bewertet die Tiefe, meldet die hier beschriebenen Befunde und erzeugt für Seiten ohne brauchbares Markup einen fertigen Entwurf. Bei diesem Entwurf gilt eine Regel, die uns wichtiger ist als Vollständigkeit: Jeder Wert darin muss nachweislich auf der Seite stehen. Wir prüfen das maschinell nach, statt es dem Modell zu glauben, und verwerfen, was sich nicht belegen lässt. Ein erfundener Preis in einem Vorschlag wäre schlimmer als gar kein Vorschlag.

Prüfen lässt sich das für eine ganze Domain oder für eine einzelne Unterseite. Der Unterschied lohnt sich: Startseiten sind fast immer besser ausgezeichnet als der Rest, und die Seiten, um die es geht, sind der Rest.

Zum Schluss

Strukturierte Daten machen eine Marke nicht sichtbar. Sie machen sie eindeutig. Der Unterschied klingt akademisch und entscheidet darüber, ob ein Modell in einer Antwort eure Zahlen nennt oder eine plausible Schätzung.

Fast alle Befunde in diesem Text haben dieselbe Ursache: Markup ist entstanden, weil ein Plugin es erzeugt hat oder weil jemand einmal eine Vorlage gebaut hat, und danach hat niemand mehr hingesehen. Es ist gültig, es ist da, und es beschreibt nicht, was auf der Seite passiert.

Der erste Schritt ist deshalb kein Projekt, sondern eine Messung.