Leitfaden zu Schema.org und JSON-LD für strukturierte Daten

Wählen Sie das Objekt aus, das tatsächlich auf der Seite beschrieben wird, füllen Sie seine Eigenschaften und erhalten Sie den JSON-LD-Code zur Einbindung in HTML. Der Generator hilft, die Syntax zu erstellen, aber vor der Veröffentlichung muss die Übereinstimmung mit dem sichtbaren Inhalt, die Anforderungen des gewählten Datenkonsumenten und die Aktualität der Werte überprüft werden.

Schema.org, JSON-LD und das Rich Result sind verschiedene Dinge

Schema.org

Dies ist ein gemeinsames Vokabular von Typen und Eigenschaften: Article, Product, Organization, Event, name, image, offers und viele andere. Es beschreibt, welche Entitäten und Beziehungen strukturiert dargestellt werden können.

JSON-LD

Dies ist eines der Formate zur Erfassung strukturierter Daten. Der Code wird innerhalb von:

Google empfiehlt JSON-LD, wenn es für die Implementierung geeignet ist, aber Schema.org kann auch mit Microdata oder RDFa geschrieben werden.

Rich Result von Google

Dies ist eine spezielle Darstellung in den Suchergebnissen, die nur eine begrenzte Anzahl von Typen unterstützt und die Einhaltung bestimmter Google-Regeln erfordert. Ein gültiges Schema.org-Markup garantiert kein Rich Result, kein hohes Ranking oder sogar die Verwendung aller übermittelten Eigenschaften. Daher sollte man das Markup nicht nur mit der Frage bewerten, "ob es einen schönen Snippet anzeigt". Es muss in erster Linie die reale Entität der Seite korrekt beschreiben.

So wählen Sie den Markup-Typ

Wählen Sie den Typ nach dem Hauptobjekt der Seite, nicht nach dem gewünschten Aussehen in der Suche.

Auf einer Seite sind mehrere verwandte Objekte zulässig. Ein Artikel kann beispielsweise einen Autor Person, einen Herausgeber Organization, Breadcrumbs BreadcrumbList und ein eingebettetes Video VideoObject haben. Es ist besser, sie über @id zu verknüpfen, anstatt widersprüchliche Kopien zu erstellen.

Wichtige aktuelle Einschränkungen von Google

FAQPage

Google hat die Anzeige von FAQ-Rich-Results erheblich eingeschränkt: Sie sind in der Regel nur für bekannte, vertrauenswürdige Regierungs- und Medizin-Websites verfügbar. Für eine normale kommerzielle oder informative Website kann ein korrektes FAQ-Markup keine nennenswerte Erweiterung in den Suchergebnissen bringen. Das macht den Typ FAQPage in Schema.org nicht ungültig, aber man kann dem Nutzer nicht versprechen, dass "die Fragen bei Google erscheinen".

HowTo

Google hat die Anzeige von HowTo-Rich-Results eingestellt. Der Typ HowTo bleibt im Schema.org-Vokabular und kann von anderen Konsumenten genutzt werden, aber das Hinzufügen nur für das frühere Google-Rich-Result ist nicht mehr sinnvoll.

Andere Typen

Organization, Person und WebSite helfen, Entitäten zu beschreiben, aber nicht jeder erzeugt ein eigenes visuelles Rich Result. Die Unterstützung und das Erscheinungsbild von Suchfunktionen ändern sich, daher sollten Sie vor der Implementierung die aktuelle Galerie von Google Search Central prüfen.

Hauptregel: Das Markup muss mit dem sichtbaren Inhalt übereinstimmen

Fügen Sie in JSON-LD keine Informationen hinzu, die auf der Seite fehlen oder ihr widersprechen. Dies gilt insbesondere für:

• Preis und Verfügbarkeit des Produkts;
• Bewertung und Anzahl der Rezensionen;
• Fragen und Antworten;
• Datum und Ort der Veranstaltung;
• Autor des Materials;
• Adresse und Öffnungszeiten des Unternehmens;
• Bedingungen der Stelle;
• Zutaten und Schritte des Rezepts.

Das Markup ist kein Ort für versteckte Werbetexte oder zusätzliche Keywords. Der Nutzer und die Suchmaschine sollten konsistente Informationen erhalten.

Pflichtfelder hängen davon ab, wer das Markup liest

Schema.org definiert ein Vokabular, aber keine einheitliche universelle Liste von "Pflichtfeldern" für alle Systeme. Ein bestimmter Konsument, wie Google Search, legt eigene obligatorische und empfohlene Eigenschaften für eine bestimmte Suchfunktion fest. Daher sind drei verschiedene Validierungsergebnisse möglich:

1. Das JSON ist syntaktisch korrekt.
2. Die Typen und Eigenschaften existieren in Schema.org.
3. Das Markup entspricht den Anforderungen des spezifischen Google-Rich-Results.

Das Bestehen der ersten oder zweiten Stufe garantiert nicht die dritte.

So füllen Sie URLs, Daten und Identifikatoren aus

Verwenden Sie absolute URLs

Bevorzugt:

Anstelle von:

Die Links müssen für den Suchroboter zugänglich sein, keine Authentifizierung erfordern und auf eine stabile Ressource verweisen.

Geben Sie Daten im ISO-8601-Format an

Datum:

Datum und Uhrzeit mit Zeitzone:

Für Veranstaltungen ist es besonders wichtig, die Zeitzone nicht zu verlieren. Andernfalls könnte die Zeit falsch interpretiert werden.

Erstellen Sie eine stabile @id

@id ist der Identifikator der Entität, oft als URL mit Fragment:

Dieselbe Organisation auf verschiedenen Seiten sollte auf eine stabile Identifikator verweisen, nicht wie viele unabhängige Unternehmen aussehen.

So beschreiben Sie mehrere Entitäten mit @graph

Für verwandte Objekte ist es praktisch, einen einzigen Block zu verwenden:

So sind die Objekte explizit verknüpft und es ist nicht nötig, alle Informationen über die Organisation in jedem Artikel zu wiederholen.

Wo JSON-LD eingefügt wird

Der Block <script type="application/ld+json"> kann im <head> oder <body> der HTML-Seite platziert werden. Wichtiger ist, dass:

• der Code im endgültigen HTML vorhanden oder nach korrektem Rendering zugänglich ist;
• er sich spezifisch auf die aktuelle Seite bezieht;
• das CMS ihn ohne Beschädigung von Anführungszeichen und Sonderzeichen escaped;
• eine Vorlage nicht dieselben Daten auf verschiedene Seiten einfügt;
• dynamische Preise, Verfügbarkeit und Daten zusammen mit dem sichtbaren Inhalt aktualisiert werden.

Nach der Implementierung überprüfen Sie nicht nur den Code aus dem Generator, sondern auch die veröffentlichte URL: Die Vorlage, ein Plugin oder JavaScript können das endgültige Markup verändern.

Zwei verschiedene Validierungsebenen

Schema Markup Validator

Prüft die Syntax und die Verwendung des Schema.org-Vokabulars. Geeignet, um gefundene Typen, Eigenschaften und allgemeine Probleme des Markups zu erkennen.

Google Rich Results Test

Zeigt, ob Google auf der Seite einen unterstützten Rich-Result-Typ erkennt und ob dessen spezielle Anforderungen erfüllt sind. Das Tool bestätigt nicht, dass das Rich Result in der Suche erscheint. Nach der Veröffentlichung ist es auch sinnvoll, die URL über die URL-Inspektion in der Google Search Console zu prüfen, um die von Google verarbeitete Version der Seite und die erkannten Elemente zu sehen.

Fehler und Warnung sind keine universellen Kategorien

Ein Validator kann das Fehlen einer Eigenschaft als Warnung betrachten, während sie für einen bestimmten Konsumenten obligatorisch ist. Und umgekehrt erlaubt Schema.org eine Eigenschaft, die Google für die gewünschte Funktion nicht verwendet. Bewerten Sie die Meldung anhand von vier Fragen:

1. Ist die JSON-Syntax fehlerhaft?
2. Existieren der Typ und die Eigenschaft in Schema.org?
3. Ist die Eigenschaft korrekt verschachtelt und hat sie einen gültigen Wert?
4. Wird sie von der gewählten Suchfunktion oder einer anderen Integration benötigt?

Häufige Fehler

• Ungeeigneter Typ: Die Kategorieseite für Produkte wird als einzelnes Product ausgezeichnet, obwohl es kein einzelnes Produkt und kein einheitliches Angebot gibt. Oder ein gewöhnlicher Artikel erhält FAQPage, nur weil es am Ende einen kleinen Fragenblock gibt.
• Markup stimmt nicht mit der Seite überein: Im Code werden ein alter Preis, eine nicht vorhandene Bewertung, versteckte Fragen oder ein anderer Autor angegeben.
• Konfliktierende Entitäten: Mehrere Plugins erzeugen verschiedene Organization-Blöcke mit unterschiedlichen Namen, Logos und URLs. Die Objekte sind nicht über eine gemeinsame @id verknüpft.
• Falsche Verschachtelung: Zum Beispiel wird price direkt in Product geschrieben, obwohl das Angebot normalerweise über ein Offer-Objekt in der Eigenschaft offers beschrieben wird.
• Falscher Werttyp: Das Datum wird als beliebiger Text geschrieben, der Preis enthält die Währung in derselben Zeichenfolge, der boolesche Wert wird als Phrase übergeben und das Feld, das eine URL erwartet, enthält einen relativen Pfad.
• Unzugängliche Bilder und Seiten: Die URL liefert einen Fehler, ist durch Authentifizierung oder robots.txt blockiert, verweist auf einen instabilen temporären Link oder auf ein Bild, das der Crawler nicht abrufen kann.
• Veraltete dynamische Daten: Die Veranstaltung ist bereits beendet, die Stelle ist geschlossen, das Produkt ist nicht verfügbar, aber das Markup übermittelt weiterhin den alten Status.
• JSON-Fehler: Einfache oder typografische Anführungszeichen; überflüssiges Komma nach der letzten Eigenschaft; nicht geschlossene Klammer; Kommentare innerhalb des JSONs; nicht verarbeitete Zeilenumbrüche innerhalb eines Zeichenfolgenwerts; doppelter Schlüssel in einem Objekt.

Workflow für die Implementierung

1. Bestimmen Sie das Hauptobjekt und den Zweck des Markups.
2. Prüfen Sie die aktuellen Anforderungen von Schema.org und des benötigten Datenkonsumenten.
3. Wählen Sie den genauesten Typ.
4. Füllen Sie nur die zuverlässigen Eigenschaften aus, die auf der Seite vorhanden sind.
5. Generieren Sie das JSON-LD.
6. Validieren Sie den Code im Schema Markup Validator.
7. Wenn ein unterstütztes Google-Rich-Result benötigt wird, prüfen Sie im Rich Results Test.
8. Fügen Sie den Code in eine Testversion der Seite ein.
9. Überprüfen Sie erneut die veröffentlichte URL, nicht nur das isolierte Fragment.
10. Konfigurieren Sie die Aktualisierung dynamischer Werte und erneute Prüfungen nach Vorlagenänderungen.

Kurze Checkliste vor der Veröffentlichung

• der Typ des realen Objekts der Seite wurde ausgewählt;
• die Daten stimmen mit dem sichtbaren Inhalt überein;
• es gibt keine erfundenen Bewertungen, Rezensionen oder Eigenschaften;
• die URLs sind absolut, zugänglich und kanonisch konsistent;
• die Daten sind im klaren Format und mit Zeitzone angegeben, wenn nötig;
• Preis und Währung befinden sich in separaten Feldern;
• gleiche Entitäten sind über eine stabile @id verknüpft;
• es gibt kein widersprüchliches Markup von einem anderen Modul;
• der Code hat die entsprechenden Validierungen bestanden;
• die veröffentlichte URL enthält dasselbe korrekte JSON-LD;
• dynamische Daten werden aktualisiert.

Häufig gestellte Fragen

Garantiert Schema.org ein Rich Snippet?

Nein. Ein korrektes Markup macht die Seite verarbeitbar, aber die Suchmaschine entscheidet selbstständig, ob sie es verwendet und wie sie das Ergebnis anzeigt.

Muss ich auf jeder Seite Schema.org hinzufügen?

Nur dort, wo es eine Entität und nützliche, zuverlässige Eigenschaften zu deren Beschreibung gibt. Das massenhafte Einfügen desselben Blocks ohne Bezug zum Inhalt erzeugt Fehler und Widersprüche.

Kann ich Eigenschaften belassen, die der Nutzer nicht sieht?

Technische Verknüpfungen und Identifikatoren müssen nicht als separater Text angezeigt werden, aber die tatsächlichen Informationen über das Produkt, die Bewertung, Fragen, das Ereignis und andere Objekte müssen mit dem für den Nutzer zugänglichen Inhalt und den Regeln des Konsumenten übereinstimmen.

Wo platziere ich den Code – in head oder body?

JSON-LD kann an beiden Stellen stehen. Wichtig ist das korrekte endgültige HTML, die Zugänglichkeit des Markups für den Prozessor und die Übereinstimmung mit der aktuellen Seite.

Warum zeigt der Schema Markup Validator keinen Fehler, aber Google schon?

Das erste Tool prüft das Schema.org-Vokabular und die Struktur des Markups, während Google zusätzlich die Anforderungen der spezifischen Suchfunktion anwendet.

Lohnt es sich, aktuell FAQPage auszuzeichnen?

Man kann es tun, wenn die Seite tatsächlich ein FAQ ist und der Typ für andere Datenkonsumenten nützlich ist. Für die meisten Websites sollte man jedoch nicht auf das FAQ-Rich-Result von Google hoffen.

Ist HowTo für Google notwendig?

Google zeigt keine HowTo-Rich-Results mehr an. Der Typ kann weiterhin als semantische Beschreibung für andere Systeme nützlich sein, aber den früheren Suchmaschineneffekt von Google sollte man nicht erwarten.

Verwandte Tools

Diffchecker; Textverarbeitung; Base64.

Offizielle Materialien

• Schema.org-Vokabular
• Google Search Central — Einführung in strukturierte Daten
• Google — Allgemeine Richtlinien für strukturierte Daten
• Google — Galerie der Funktionen für strukturierte Daten
• Schema Markup Validator
• Google Rich Results Test

Allgemeine redaktionelle Empfehlungen für den Bereich

1. Nicht denselben kommerziellen Block innerhalb jedes nützlichen Textes duplizieren

Der aktuelle Block über "vollständiges SEO-Audit, Tools für das Sichtbarkeitswachstum in KI und Automatisierung" kann als separater visueller CTA nach dem Hauptmaterial belassen werden. Er sollte nicht in die Artikelstruktur zwischen nützlichen Abschnitten eingebettet werden: Das unterbricht den Lesefluss und sieht auf allen neun Seiten gleich aus. Besser ist es, einen kurzen, kontextbezogenen Link zu verwenden, der zum Tool passt. Zum Beispiel:

• nach dem UTM-Generator — zu Berichten nach Kanälen und Konversionen;
• nach dem Kombinator — zur Prüfung von Häufigkeit, Clustering und Zuweisung von Suchanfragen zu Seiten;
• nach Schema — zum Audit strukturierter Daten;
• nach Diffchecker — zur Überwachung von Seitenänderungen;
• nach der Duplikatentfernung — zum Import von Semantik oder URLs in das Projekt.

2. Keine identischen Abschnitte "Vorteile" und "Für wen geeignet" als Vorlage erstellen

Ihr Inhalt wird fast immer zu Wiederholungen: "schnell", "bequem", "kostenlos", "für Vermarkter und Fachleute". Es ist sinnvoller, konkrete Szenarien, Einschränkungen, Beispiele und FAQs zu belassen. Kurze Merkmale wie "kostenlos", "im Browser", "ohne Registrierung" werden bereits neben dem Tool gezeigt.

3. Versprechen mit der tatsächlichen Implementierung abstimmen

Vor der Veröffentlichung sollten die Entwickler bestätigen:

• wird die Verarbeitung vollständig im Browser durchgeführt oder werden Daten an den Server gesendet;
• welche Grenzen gibt es für Textumfang und Zeilenanzahl;
• werden die Originaldaten oder Ergebnisse gespeichert;
• welcher Algorithmus und welche Bibliothek für die Spracherkennung verwendet werden;
• wie genau Diffchecker Wörter und Zeilen vergleicht;
• ob die Duplikatentfernung zwischen Groß- und Kleinschreibung sowie Leerzeichen unterscheidet und in welcher Reihenfolge die Aktionen angewendet werden;
• ob der Passwortgenerator eine kryptografisch sichere Zufallsquelle verwendet;
• welche Kodierung der Base64-Konverter verwendet;
• ob er Base64url oder nur Standard-Base64 unterstützt.

Nach der Bestätigung können diese Details in einem kurzen Block "Verarbeitung und Datenschutz" auf jeder Seite aufgeführt werden. Man darf keine lokale Verarbeitung und Speicherfreiheit versprechen, nur weil das Tool visuell im Browser funktioniert.

4. Einschränkungen neben der Funktion anzeigen, nicht unten verstecken

Besonders wichtige Warnungen:

• UTM-Parameter werden nicht auf internen Links platziert;
• Diffchecker prüft nicht die Bedeutung oder faktische Richtigkeit;
• der Kombinator bestätigt keine Nachfrage und erstellt nicht automatisch die Seitenstruktur;
• Base64 verschlüsselt keine Daten;
• eine gesamte URL sollte nicht ohne Prüfung in Kleinbuchstaben umgewandelt werden;
• ein Passwort kann nicht ohne Überprüfung des Generators als kryptografisch sicher angesehen werden;
• ein gültiges Schema.org garantiert kein Rich Result.

5. Interne Links gemäß der nächsten Aktion des Benutzers hinzufügen

Anstelle einer allgemeinen Liste aller Tools am Ende der Seite zwei oder drei wirklich verwandte Links platzieren. Der Linkname sollte die Fortsetzung des Szenarios erklären: "Die erhaltene Liste bereinigen", "Zwei Versionen vergleichen", "Doppelte Kombinationen entfernen", "Die Sprache des Textes prüfen".

6. FAQ nicht nur wegen der Aussicht auf ein Rich Snippet auszeichnen

Das FAQ in diesen Texten ist für den Nutzer nützlich und kann auf der Seite bleiben. Die Entscheidung, FAQPage hinzuzufügen, sollte jedoch separat getroffen werden, unter Berücksichtigung der Schema.org-Regeln und der aktuellen Suchmaschinenbeschränkungen. Für normale Websites zeigt Google derzeit in der Regel keine FAQ-Rich-Results an.

7. Empfohlene Reihenfolge für die Implementierung

1. Diffchecker, Spracherkennung und UTM — derzeit haben sie am wenigsten nützliches Material.
2. Duplikatentfernung — dringend den Rat korrigieren, alle URLs in Kleinbuchstaben umzuwandeln.
3. Base64 — "entschlüsseln" durch "dekodieren" ersetzen und Base64url hinzufügen.
4. Passwortgenerator — die Empfehlungen zur Länge aktualisieren und die Implementierung der Zufallsgenerierung überprüfen.
5. Schema.org — den aktuellen, übermäßig langen und sich wiederholenden Text durch eine kompaktere, aber technisch präzise Anleitung ersetzen.
6. Kombinator und Textverarbeitung — die starken Teile belassen, Einschränkungen und eine praktische Vorgehensweise hinzufügen.