Warum sollten strukturierte Daten zu einer Website hinzugefügt werden?

Der zentrale Nutzen der Einbindung strukturierter Daten in eine Website besteht nicht darin, „dem Seiteninhalt einen Codeabschnitt hinzuzufügen“, sondern darin, die auf der Seite vorhandenen Entitäten, Eigenschaften und Beziehungen in einem von Suchmaschinen zuverlässig erkennbaren semantischen Format eindeutig zu beschreiben. Texte auf einer Seite können von Menschen verstanden werden, doch Suchsysteme können nicht unbedingt präzise erkennen, ob eine Zahlenfolge einen Preis, eine Modellnummer, eine Bewertung oder eine Telefonnummer darstellt. Strukturierte Daten kennzeichnen solche Informationen dagegen als berechenbare und verknüpfbare Entitätseigenschaften.

Bei Websites mit Produktkatalogen, Leistungsbeschreibungen, Artikeln, häufig gestellten Fragen, Unternehmensinformationen oder mehrsprachigen Seiten kann diese Kennzeichnung Mehrdeutigkeiten im maschinellen Verständnis verringern. Suchmaschinen müssen sich nicht mehr allein auf Titel, Fließtext und Links stützen, um das Seitenthema zu erschließen, sondern erhalten klarere Signale: Dies ist eine Produktseite, zu welcher Kategorie das Produkt gehört, wer der Hersteller ist, ob ein gültiger Breadcrumb-Pfad vorhanden ist sowie wer den Artikel verfasst hat und wann er veröffentlicht wurde.

Strukturierte Daten lösen kein Problem der „Indexierung“, sondern ein Problem des „Verständnisses“

Viele Websites führen unzureichende Rankings oder das Ausbleiben von Rich Results einfach auf fehlende Schema-Markierungen zurück. Diese Einschätzung ist nicht korrekt. Strukturierte Daten können weder crawlbare Seiten, originäre Inhalte, interne Links, Seitenleistung und externe Autoritätssignale ersetzen, noch sorgen sie dafür, dass eine ursprünglich minderwertige Seite automatisch in den Suchergebnissen erscheint.

Ihr Einsatzbereich ist konkreter: Wenn eine Suchmaschine eine Seite bereits gecrawlt hat, liefern strukturierte Daten eine standardisierte Beschreibung für die Inhaltsanalyse. Bei einer Website eines B2B-Fertigungsunternehmens können beispielsweise auf einer Produktseite gleichzeitig Spezifikationstabellen, Download-Materialien, Anfrage-Schaltflächen, Anwendungsbranchen und verwandte Modelle erscheinen. Allein anhand natürlicher Sprache kann das System möglicherweise nicht zwischen „Nenndruck“ und „Lagerbestand“ unterscheiden und die hierarchischen Beziehungen zwischen ähnlichen Modellen nur schwer beurteilen. Durch den Einsatz geeigneter Typen wie Product, Organization und BreadcrumbList werden die semantischen Grenzen der Seiteninformationen klarer.

Diese Fähigkeit ist besonders für Websites mit umfangreichen Inhalten, tiefen Website-Hierarchien, komplexen Produktparametern oder mehrsprachigen Versionen geeignet. Sie bedeutet keine direkte Verbesserung des Rankings, kann jedoch die Wahrscheinlichkeit verringern, dass wichtige Informationen falsch interpretiert, übersehen oder verwechselt werden.

Die Darstellung in Suchergebnissen ist nur einer der sichtbaren Vorteile

Der am häufigsten genannte Nutzen strukturierter Daten besteht darin, Seiten für Rich Results zu qualifizieren, beispielsweise für Produktpreise, Lagerstatus, Bewertungsinformationen, Veröffentlichungszeitpunkte von Artikeln, Zusammenfassungen häufig gestellter Fragen oder Breadcrumb-Navigation. „Qualifiziert“ und „zwangsläufig angezeigt“ sind jedoch zwei verschiedene Dinge. Ob und in welchem Stil ein Suchergebnis angezeigt wird, entscheidet weiterhin die Suchmaschine anhand der Suchintention, des Geräts, der Region, der Seitenqualität und weiterer Signale.

Daher sollten Rich Results nicht als einziges Abnahmekriterium betrachtet werden. Selbst wenn eine Markierung nicht in einer erweiterten Darstellung in den Suchergebnissen erscheint, kann sie dennoch das Inhaltsverständnis, die Entitätsverknüpfung und die Seitenklassifizierung unterstützen. Umgekehrt kann eine bestimmte umfangreiche Darstellung, selbst wenn sie kurzfristig erreicht wird, wieder verschwinden, wenn der Seiteninhalt nicht mit den Markierungsdaten übereinstimmt oder die Gesamtqualität der Website unzureichend ist.

Eine angemessenere Beurteilung lautet: Enthält die Seite Informationen, die sowohl für Nutzer als auch für Suchsysteme real, wertvoll und überprüfbar sind? Lassen sich diese Informationen sinnvoll durch Standardtypen ausdrücken? Stimmen die Markierungen strikt mit den sichtbaren Inhalten überein?

Welche Seiten sollten vorrangig behandelt werden?

Nicht jede Seite muss mehrere Datentypen stapeln. Strukturierte Daten sollten der geschäftlichen Semantik der Seite selbst dienen, statt den Markierungsumfang nur zur Abdeckung weiterer Schema-Typen auszuweiten. Bei der technischen Bewertung kann üblicherweise mit Seiten begonnen werden, deren Informationen stabil sind, deren Vorlagen stark wiederverwendet werden und die einen größeren Einfluss auf das Suchverständnis haben.

• Unternehmens- und Markenseiten: Organization kann zur Darstellung des Unternehmensnamens, der offiziellen Website, von Kontaktdaten, Kennzeichnungen und verknüpften Startseiteninformationen verwendet werden. Entscheidend ist, dass Markenname, Domain und öffentliche Kontaktinformationen konsistent bleiben.
• Produkt- und Kategorieseiten: Felder wie Product, Offer, Brand und SKU eignen sich für Seiten mit eindeutigen Waren- oder Modellinformationen. Angaben wie Preis, Währung und Verfügbarkeitsstatus sollten nur aufgenommen werden, wenn sie auf der Seite tatsächlich öffentlich angezeigt werden und zeitnah aktualisiert werden können.
• Artikel- und Inhaltsseiten: Article oder BlogPosting können grundlegende Informationen wie Titel, Autor, Veröffentlichungsdatum, Aktualisierungsdatum und Hauptbild beschreiben. Bei fortlaufend aktualisierten technischen Unterlagen sollten Datumsfelder den tatsächlichen Bearbeitungsstatus widerspiegeln und nicht mechanisch aktualisiert werden.
• Navigationspfade: BreadcrumbList ist besonders für Websites mit tiefen Verzeichnisstrukturen nützlich. Es kann Suchsystemen helfen, die Position der aktuellen Seite innerhalb der Website zu verstehen, und zugleich die Lesbarkeit der Pfadinformationen in den Suchergebnissen verbessern.
• Frage-und-Antwort-Inhalte: FAQPage eignet sich nur für Fragen und Antworten, die tatsächlich auf der Seite vorhanden und für Nutzer direkt sichtbar sind. Marketingslogans als Fragen und Antworten zu tarnen oder identische Fragen und Antworten auf der gesamten Website zu kopieren, hat in der Regel keinen Wert.

JSON-LD ist in der Regel einfacher zu pflegen, doch die technische Wahl darf nicht von der Website-Architektur losgelöst werden

Derzeit ist JSON-LD eine häufig verwendete Implementierungsform. Es wird in der Regel im script-Tag einer Seite platziert, beeinträchtigt nicht das visuelle Layout des Frontends und kann bequem einheitlich durch CMS, Vorlagensysteme oder serverseitige Programme erzeugt werden. Bei Websites mit einer großen Anzahl von Produkten können Name, Modell, Bild, Marke und Spezifikationen aus der Produktdatenbank, dem PIM-System oder CMS-Feldern abgerufen werden, um Auslassungen durch manuelle Vervielfältigung zu reduzieren.

Automatisch generierte Daten sind jedoch nicht von Natur aus zuverlässig. Häufige Probleme bei dynamischen Websites sind: Daten der sichtbaren Seite und JSON-LD-Daten stammen aus unterschiedlichen Schnittstellen, wodurch Preise, Lagerbestände oder Titel nicht synchronisiert sind; nach einer Änderung der mehrsprachigen Routing-Struktur verweist die URL in der Markierung weiterhin auf die Standardsprache; Paginierungs- und Filterseiten übernehmen fälschlicherweise die Entität der Produktseite; asynchrones Frontend-Rendering führt dazu, dass Suchmaschinen beim Crawlen nicht auf vollständige Felder zugreifen können. Diese Probleme verschwinden nicht automatisch, nur weil der Code „keinen Fehler meldet“.

Wenn die Website JavaScript-Rendering verwendet, sollten zentrale Entitätsinformationen möglichst bereits im initialen HTML oder in stabilen serverseitig gerenderten Ergebnissen verfügbar sein. Es kann nicht davon ausgegangen werden, dass alle Crawler vor der Datenanalyse auf komplexe Interaktionen, Schnittstellenanfragen oder durch Nutzerverhalten ausgelöste Vorgänge warten. Bei Shopsystemen oder Website-Baukastensystemen, die auf Komponenten von Drittanbietern angewiesen sind, muss zudem geprüft werden, ob sie die Ausgabe eigenständiger Markierungen nach Seitentyp unterstützen, um zu vermeiden, dass websiteweit ein festes und verzerrtes Schema eingebunden wird.

Der häufigste Fehler besteht darin, dass Markierungsinhalte über die Fakten der Seite hinausgehen

Strukturierte Daten sind ihrem Wesen nach eine Erklärung. Stimmen diese Erklärungen nicht mit den tatsächlich sichtbaren Informationen für Nutzer überein, beeinträchtigt dies ihre Glaubwürdigkeit und kann auch die Berechtigung für erweiterte Suchergebnisse einschränken. Typische Risiken sind: die Angabe eines fiktiven Preises für Industrieprodukte ohne öffentlich ausgewiesenen Verkaufspreis; das Hinzufügen von AggregateRating auf Seiten ohne ein echtes Bewertungssystem; die Angabe von Händlerinformationen als Herstellerinformationen; die Kennzeichnung gemeinsamer Parameter mehrerer Modelle als exakte Spezifikationen eines einzelnen Produkts; oder die weitere Ausgabe des Status „auf Lager“ für nicht mehr verfügbare Seiten.

Exportorientierte Websites stoßen außerdem leicht auf Inkonsistenzen bei Einheiten, Währungen und Sprachversionen. Beispielsweise zeigt eine englische Seite USD an, während die strukturierten Daten Renminbi beibehalten; oder dasselbe Modell hat auf Seiten verschiedener Märkte unterschiedliche Lieferbedingungen, verwendet jedoch exakt dieselben Offer-Informationen. Solche Probleme beeinträchtigen nicht nur die Datenqualität, sondern erschweren es Suchsystemen auch, die Beziehungen zwischen den Seiten zu beurteilen.

Ein weiterer Irrtum besteht darin, strukturierte Daten als einmalige Entwicklungsaufgabe zu betrachten. Wenn sich Produktpreise, Lagerbestände, Aktualisierungszeiten von Artikeln, Unternehmensadressen oder die Website-Navigation ändern, sollten auch die Markierungen entsprechend aktualisiert werden. Wenn das Geschäftssystem keine stabile Datenquelle bereitstellen kann, ist es besser, nur Felder mit geringen Änderungen wie Name, Marke und Modell beizubehalten, als dynamische Eigenschaften einzutragen, die nicht gepflegt werden können.

Bei der Validierung darf nicht nur geprüft werden, ob die Syntax korrekt ist

Nach der Implementierung können von Suchmaschinen bereitgestellte Testtools für Rich Results oder Validierungstools für strukturierte Daten verwendet werden, um Syntax, Pflichtfelder und erkennbare Typen zu prüfen. Eine erfolgreiche Validierung bedeutet jedoch nur, dass das Codeformat im Wesentlichen gültig ist; sie beweist weder, dass die Seite zwangsläufig für eine Darstellung qualifiziert ist, noch dass die Semantik vollständig korrekt ist.

Eine wertvollere Prüfung sollte drei Ebenen abdecken: Ob die Markierungen tatsächlich im Quellcode der Seite oder im gerenderten DOM vorhanden sind; ob die Markierungsfelder mit den sichtbaren Seiteninhalten, den Canonical-Links und den tatsächlichen Datenquellen übereinstimmen; und ob in den Website-Verwaltungstools relevante Berichte zu erweiterten Ergebnissen, Warnungen oder Bearbeitungshinweise erscheinen. Bei vorlagenbasierten Websites sollten außerdem unterschiedliche Sprachen, verschiedene Produktstatus, Filterseiten, paginierte Seiten und mobile Rendering-Ergebnisse stichprobenartig geprüft werden, statt nur eine Beispielseite zu validieren.

Die eigentliche Antwort auf „données structurées site internet pourquoi“ besteht nicht darin, ein bestimmtes Erscheinungsbild in den Suchergebnissen anzustreben, sondern darin, dass eine Website ihre eigenen Inhalte Suchsystemen klarer und konsistenter vermittelt. Nur wenn Entitätsinformationen real sind, der Seitentyp passt, die Datenquelle pflegbar ist und dies mit solidem technischem SEO und Content-Aufbau kombiniert wird, können strukturierte Daten zu einer wirksamen Grundlage für eine bessere Verständlichkeit und Suchsichtbarkeit der Website werden.