Mit der Seite und einer unterstützten Funktion beginnen
Beginnen Sie nicht damit, jeden schema.org‑Typ zu ergänzen, der nach Ihrem Geschäftsfeld klingt. schema.org ist ein breiter gemeinsamer Wortschatz, während Google in der Search Gallery die Rich‑Result‑Funktionen dokumentiert, die es unterstützt, und welche Eigenschaften diese benötigen. Eine Produkt-, Veranstaltungs‑ oder Artikelseite sollte zuerst auch ohne Markup nützlich sein.
Nennen Sie für jede Vorlage ihr Hauptthema und die sichtbaren unterstützenden Fakten. Lesen Sie dann die aktuelle Anleitung von Google für die passende Funktion. Produkt, Rezept, Artikel, Breadcrumb, Veranstaltung, Organisation, Local Business und Video sind Beispiele. Ein Vokabulartyp allein erzeugt keine Google‑Funktion; die erforderlichen Eigenschaften dieser Funktion bestimmen die Berechtigung.
Machen Sie das primär sichtbare Element zum primären Markup.
Verwenden Sie die Anleitung von Google für das Verhalten der Funktion und schema.org für das Vokabular.
Machen Sie die sichtbare Seite zur Quelle der Wahrheit
Markup muss den Hauptinhalt der Seite wiedergeben, nicht versteckte, irrelevante oder irreführende Angaben. Wenn es sagt, ein Darsteller trete auf, muss die Seite diesen Darsteller beschreiben. Wenn es eine aggregierte Bewertung markiert, müssen Besucher diese Bewertung sehen. Das verhindert, dass eine Vorlage zu einer irreführenden Zusammenfassung driftet.
Erstellen Sie Seiten‑Text und Markup aus denselben genehmigten Datensätzen. Ein Produktfeed, ein Veranstaltungssystem oder ein CMS kann beides liefern, aber Werte müssen vor der Veröffentlichung überprüft werden. Kopieren Sie keinen Preis, keinen Lagerzustand, kein Datum oder keine Bewertungszahl in ein nur für Markup vorgesehenes Feld, das vergessen werden kann. Aktualisieren oder entfernen Sie Markup, wenn die sichtbaren Informationen sich ändern.
Halten Sie Namen, Daten, Preise, Verfügbarkeit und Bewertungen mit der Seite in Einklang.
Füllen Sie Eigenschaften niemals mit geratenen oder veralteten Werten.
Verwenden Sie JSON‑LD als wartbare Datenschicht
JSON‑LD ist ein JSON‑basiertes Linked‑Data‑Format, das in ein HTML‑Dokument eingefügt wird. Google unterstützt JSON‑LD, Microdata und RDFa und sagt, JSON‑LD sei im Allgemeinen am einfachsten zu implementieren und auf Skalierung zu pflegen. Die Trennung vom sichtbaren Markup macht es oft einfacher, verschachtelte Informationen zu modellieren.
Verwenden Sie für jedes reale Element ein klares Datenobjekt mit einem passenden schema.org‑Typ und genauen unterstützten Eigenschaften. Dokumentieren Sie für jede Vorlage die Funktionsanleitung, das Quellfeld, das Verhalten bei Pflichtfeldern und den Besitzer. Prüfen Sie auch die gerenderte Ausgabe: Ein Plugin oder eine Komponente kann doppeltes oder widersprüchliches Markup hinzufügen.
Wählen Sie das Format, das Ihr Team konsistent pflegen kann.
Erfinden Sie keinen erforderlichen Wert, wenn Quell‑Daten fehlen.
Validieren Sie den Code und die zugängliche Seite
Validierung beantwortet zwei Fragen. Erstens: Ist das Markup vollständig genug für eine unterstützte Funktion? Der Rich Results Test akzeptiert eingefügten Code oder eine öffentlich zugängliche URL und meldet die Rich Results, die aus den strukturierten Daten erzeugt werden können. Testen Sie repräsentative Beispiele für jede Vorlage, nicht nur eine ungewöhnlich vollständige Seite.
Zweitens: Kann Google die veröffentlichte Seite und ihre Ressourcen erreichen? Sperren Sie markierte Seiten nicht mit robots.txt, noindex oder Zugangsbeschränkungen. Prüfen Sie relevante Bild‑URLs. Der Test ist keine Qualitätsgarantie: Probleme mit sichtbarem Inhalt oder Richtlinien können die Anzeige dennoch verhindern.
Testen Sie zuerst den Code, dann eine live öffentliche URL.
Vergleichen Sie gerenderte Seite, Quelltext und Testergebnis, wenn Tools Markup hinzufügen.
Eine mögliche Anzeige ist keine Zusage für eine tatsächliche Anzeige.
Veröffentlichen Sie es wie eine benutzerorientierte Vorlagenänderung
Strukturierte Daten hängen häufig von Vorlagen, Feeds und Veröffentlichungsregeln ab. Ein Redesign, eine Änderung der Inventarintegration, eine Lokalisierungsaktualisierung oder ein entferntes Komponent kann viele Elemente kaputtmachen. Fügen Sie repräsentative Markup‑Checks zur Vorabprüfung hinzu, die Sie auch für kanonische Tags, Titel und Bilder verwenden. Dokumentieren Sie die Vorlage, Beispielseiten, Quellfelder und das Veröffentlichungsdatum.
Wenn eine Vorlage falsches Markup ausgibt, korrigieren Sie die gemeinsame Quelle oder die Vorlage, validieren Sie eine kleine Stichprobe, führen Sie die engste sichere Änderung durch und testen Sie die betroffenen URLs erneut. Wenn die Korrektur unerwartet reagiert, verwenden Sie Ihren normalen Rollback‑Prozess. Ziel ist eine evidenzbasierte Behebung einer verschlechterten Web‑Fähigkeit, kein Ausfallalarm.
Prüfen Sie repräsentative Seitensätze, nicht nur eine einzelne URL.
Dokumentieren Sie die Änderung und die Markup‑Komponente vor einer Folgereparatur.
Pflegen, messen und das Anzeige‑Limit akzeptieren
Nach der Bereitstellung verwenden Sie den relevanten Rich‑Result‑Bericht in der Search Console, um Probleme zu untersuchen und Korrekturen zu bestätigen. Berichte sind Stichproben statt vollständiger Inventare, und Zählwerte beziehen sich auf Elemente, nicht auf Seiten. Untersuchen Sie bei Bedarf eine spezifische URL.
Messen Sie vorsichtig. Google empfiehlt einen Vorher‑Nachher‑Vergleich auf stabilen, ausreichend häufig aufgerufenen Seiten über Monate in der Search Console. Dokumentieren Sie das Veröffentlichungsdatum und andere Seitenänderungen. Korrektes Markup ermöglicht nur die Berechtigung; Google bestimmt die Darstellung in der Suche.
Überprüfen Sie nach CMS‑, Vorlagen‑, Feed‑, Richtlinien‑ oder Modelländerungen erneut.
Vermeiden Sie Vergleiche, bei denen andere wichtige Seitenänderungen unterschiedlich sind.