{"id":10297,"date":"2026-08-26T12:40:00","date_gmt":"2026-08-26T10:40:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10297"},"modified":"2026-10-26T13:10:16","modified_gmt":"2026-10-26T12:10:16","slug":"website-inhalte-fur-suchmaschinen-beschreiben-json-ld-richtig-einbauen-und-prufen","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/tutorials-de-digital-marketing-de\/website-inhalte-fur-suchmaschinen-beschreiben-json-ld-richtig-einbauen-und-prufen\/","title":{"rendered":"Website-Inhalte f\u00fcr Suchmaschinen beschreiben: JSON-LD richtig einbauen und pr\u00fcfen"},"content":{"rendered":"

JSON-LD beschreibt Seiteninhalte in einer maschinenlesbaren Form. Ein Rich Result ist ein Suchergebnis mit zus\u00e4tzlichen Angaben, beispielsweise einem Produktpreis oder einer Bewertung. Ein syntaktisch g\u00fcltiger Block ist jedoch noch kein Nachweis f\u00fcr ein passendes Google-Rich-Result. Vier Pr\u00fcfungen geh\u00f6ren zusammen: g\u00fcltiges JSON, richtig verwendetes Vokabular, Anforderungen der jeweiligen Suchfunktion und \u00dcbereinstimmung mit der sichtbaren Seite.<\/p>\n

Fehler bleiben im normalen Seitenbild oft unsichtbar, lassen sich aber durchaus mit Pr\u00fcfwerkzeugen erkennen. Umgekehrt beweist ein fehlendes Rich Result keinen Fehler. Selbst korrekte und geeignete Auszeichnung garantiert keine bestimmte Darstellung oder Platzierung.<\/p>\n

\"Getrennte
G\u00fcltige Syntax, richtige Bedeutung und Eignung f\u00fcr eine Suchfunktion sind unterschiedliche Pr\u00fcfungen.<\/figcaption><\/figure>\n

1. Format, Vokabular und Suchfunktion trennen<\/h2>\n

@context<\/code> legt fest, wie kurze Begriffe interpretiert werden. F\u00fcr gew\u00f6hnliche Schema.org-Auszeichnung ist \"@context\": \"https:\/\/schema.org\"<\/code> eine klare Standardform. JSON-LD erlaubt aber auch Kontextobjekte und vollst\u00e4ndig ausgeschriebene Kennungen. Damit sind mehrere technisch g\u00fcltige Darstellungen m\u00f6glich.<\/p>\n

Typnamen behalten die Schreibweise des Vokabulars: Article<\/code> bezeichnet den Schema.org-Artikeltyp, article<\/code> nicht. Ein JSON-Parser pr\u00fcft lediglich den formalen Aufbau, etwa Kommas und Anf\u00fchrungszeichen; die Erkennung eines bekannten Typs ben\u00f6tigt eine zus\u00e4tzliche Vokabularpr\u00fcfung. Mehrere zusammengeh\u00f6rige Objekte k\u00f6nnen in @graph<\/code> oder in getrennten Skriptbl\u00f6cken stehen.<\/p>\n

Schema.org beschreibt mehr Eigenschaften als einzelne Google-Suchfunktionen nutzen. Deshalb sind eine erfolgreiche JSON-Pr\u00fcfung, eine Schema.org-Pr\u00fcfung und die Eignung f\u00fcr eine Google-Darstellung verschiedene Ergebnisse. Die aktuelle Dokumentation der gew\u00fcnschten Suchfunktion bestimmt deren Pflicht- und Empfehlungsfelder.<\/p>\n

2. Werte passend zur Bedeutung ausgeben<\/h2>\n\n
Beispiel<\/th>Einordnung und Verbesserung<\/th><\/tr><\/thead>
\"image\": \"\/img\/a.jpg\"<\/code><\/td>Relative Kennungen sind in JSON-LD grunds\u00e4tzlich aufl\u00f6sbar, abh\u00e4ngig von Kontext und Basisadresse. Eine vollst\u00e4ndige HTTPS-Adresse vermeidet Mehrdeutigkeiten beim Kopieren und Auswerten. Das Bild muss au\u00dferdem erreichbar und inhaltlich passend sein.<\/td><\/tr>\n
\"datePublished\": \"26.08.2026\"<\/code><\/td>F\u00fcr das Artikeldatum ist ein ISO-8601-Wert wie 2026-08-26T10:00:00+02:00<\/code> geeignet. Die lokale Anzeigeform geh\u00f6rt nicht unver\u00e4ndert in dieses Feld.<\/td><\/tr>\n
\"price\": \"49,90 EUR\"<\/code><\/td>Preis und W\u00e4hrung bleiben getrennt: beispielsweise \"price\": \"49.90\"<\/code> und \"priceCurrency\": \"EUR\"<\/code>. Ein Fehler kann die Nutzung der Angebotsdaten beeintr\u00e4chtigen; daraus folgt keine allgemeine Regel, dass stets s\u00e4mtliche Angebotsfelder verschwinden.<\/td><\/tr>\n
\"@type\": \"article\"<\/code><\/td>Die korrekte Schreibweise lautet Article<\/code>. Ein Vokabularpr\u00fcfer oder ein unterst\u00fctzter Rich-Results-Test kann unbekannte Typen sichtbar machen.<\/td><\/tr>\n<\/tbody><\/table>\n

Vorlagen sollten Ver\u00f6ffentlichungszeitpunkt, aktuellen Preis und Bildadresse aus den fachlichen Ausgangswerten erzeugen. Eine bereits lokalisierte Preiszeichenfolge ist keine geeignete Rechengrundlage. Dezimalstellen richten sich nach W\u00e4hrung und Preismodell; zwei Stellen passen zum gezeigten EUR-Beispiel, nicht pauschal zu jeder W\u00e4hrung.<\/p>\n\n\n\n

\"Im
Im Angelkasten hat jedes Teil sein eigenes Fach, nur ein Haken liegt bei den Posen. Genauso geh\u00f6rt jeder Wert in das Feld, das zu seiner Bedeutung passt.<\/figcaption><\/figure>\n\n\n

3. Article: hilfreiche Angaben ohne erfundene Pflichtfelder<\/h2>\n

Die aktuelle Google-Dokumentation nennt f\u00fcr Article keine verpflichtenden Eigenschaften. headline<\/code> geh\u00f6rt zu den empfohlenen Angaben. Ein sinnvoller Datensatz beschreibt dennoch den tats\u00e4chlichen Titel, Autor, Ver\u00f6ffentlichungs- und \u00c4nderungszeitpunkt sowie repr\u00e4sentative Bilder.<\/p>\n

Das folgende Beispiel ist ausschlie\u00dflich eine Vorlage f\u00fcr eine passende Artikelseite. Domain, Bilder, Autorprofil und Zeitpunkte sind Beispieldaten und m\u00fcssen den tats\u00e4chlichen sichtbaren Angaben entsprechen. Die Produktvorlage im sp\u00e4teren Abschnitt geh\u00f6rt auf eine Produktseite; beide Beispiele sind keine zus\u00e4tzliche Auszeichnung dieses Tutorials.<\/p>\n

HTML<\/span>