Die JSON-LD-Fehler, die Sie 2026 unbemerkt Rich Results kosten

Die meisten Websites, die heute JSON-LD einsetzen, würden einen einfachen Grundtest nicht bestehen: die eigenen strukturierten Daten in einen Validator einfügen und sehen, was dabei herauskommt. Nicht die Frage „Ist es optimiert?" Nur: Lässt es sich überhaupt parsen? Verweist es auf eine Entität oder auf drei widersprüchliche? Ist es Markup für einen Rich Result, den Google überhaupt noch vergibt?

Schema ist zur Checkbox verkommen — ein Plugin wird installiert, eine Vorlage aus einem Blogpost kopiert, und alle gehen davon aus, dass es funktioniert, weil sich auf der Seite sichtbar nichts verändert hat. Fehler in strukturierten Daten sind von Natur aus unsichtbar. Es gibt kein kaputtes Layout, das auffällt. Es gibt nur einen Knowledge Graph, der nie ganz versteht, wer man ist, und Rich Results, die nie erscheinen — und niemand debuggt das, weil nichts falsch aussieht.

Was JSON-LD 2026 tatsächlich leistet

Unter dem Begriff „Schema Markup" werden zwei völlig unterschiedliche Aufgaben zusammengeworfen — und genau diese Vermischung ist der Ausgangspunkt für viel verschwendete Arbeit.

Die erste Aufgabe sind Rich Results: die visuellen Erweiterungen in den SERPs — Sternebewertungen, Preisspannen, Veranstaltungsdaten, Stellenanzeigen, Breadcrumbs, Video-Thumbnails. Nur eine kleine Auswahl an @types qualifiziert sich dafür, und Google ändert diese Auswahl oft ohne große Vorwarnung.

Die zweite Aufgabe ist Entitätsklarheit: Google mitzuteilen, wer man ist, wozu man gehört und wie die eigenen Seiten miteinander zusammenhängen. Organization, WebSite, Person und WebPage übernehmen größtenteils diese Aufgabe. Sie erzeugen selten von sich aus ein sichtbares Snippet, liefern aber die Grundlage für Knowledge Panel, Sitelinks-Suchfeld und die Unterscheidung von Marken.

Die meisten Schema-Fehler, die es zu beheben lohnt, fallen in eine von drei Kategorien — und keine davon ist subtil, sobald man weiß, wo man hinschauen muss.

Fehler 1: Kaputtes JSON durch fehlerhaftes Escaping in Templates

Das ist der häufigste Fehler und zugleich der am wenigsten sichtbare. Er entsteht an der Schnittstelle zwischen dem CMS und dem <script type="application/ld+json">-Tag.

Ein Bewertungszitat mit einem verirrten doppelten Anführungszeichen darin. Eine Produktbeschreibung, die aus einem Datenblatt kopiert wurde und mitten im Text einen rohen Zeilenumbruch enthält. Wird so etwas per naiver String-Verkettung statt sauberer Serialisierung in ein JSON-LD-Template eingefügt, kommt so etwas dabei heraus:

{
  "@type": "Product",
  "name": "Editor's Choice Desk Lamp",
  "description": "The reviewer called it "the best lamp under $50""
}

Dieses nicht escapte Anführungszeichen bricht den JSON-Parser genau an dieser Stelle. Googles Rich-Results-Test markiert das als ungültig — aber dieser Test wird meist nur einmal ausgeführt, beim Launch, für eine handverlesene URL. Niemand testet ihn erneut gegen die 400 Produktseiten, die sechs Monate später mit den Zeichensetzungsgewohnheiten eines neuen Texters live gehen.

Die Lösung ist nicht kompliziert: Den JSON-String niemals von Hand zusammenbauen. Das Objekt in der eigenen Template-Sprache erstellen und korrekt serialisieren (JSON.stringify in JS, json_encode in PHP, das jeweilige Äquivalent, je nachdem, was die Seiten rendert), damit das Escaping von Code übernommen wird, der weiß, was JSON ist — nicht von einem Template-Autor, der es nicht weiß. Anschließend das gerenderte HTML validieren — die tatsächliche Antwort, die ein Crawler sieht — nicht den Template-Quellcode. Ein Template kann perfekt aussehen und trotzdem kaputtes JSON ausliefern, sobald ein String ein Sonderzeichen enthält.

Fehler 2: Doppelte Organization-Entitäten ohne gemeinsame @id

Das taucht fast immer dann auf, wenn eine Website ein Redesign, eine CMS-Migration oder gleichzeitig mehrere SEO-Plugins durchlaufen hat.

Das Theme gibt im Footer einen Organization-Block aus. Ein Plugin gibt auf jeder Seite einen weiteren aus, mit leicht abweichendem logo und abweichender sameAs-Liste. Ein Entwickler hat vor zwei Jahren von Hand einen dritten auf der Startseite ergänzt, für einen Schema-Markup-Test, der nie aufgeräumt wurde. Keiner von ihnen teilt sich eine @id.

Für Google lesen sich drei Organization-Objekte ohne gemeinsamen Identifier nicht wie „ein Unternehmen, dreimal beschrieben". Sie lesen sich mehrdeutig — möglicherweise drei verschiedene Entitäten, möglicherweise doppelte Signale, die sich gegenseitig aufheben. Genau diese Mehrdeutigkeit soll Entity-Markup eigentlich verhindern.

Die Lösung ist eine einzige kanonische @id, einmal vergeben und überall referenziert:

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": ["https://www.linkedin.com/company/example"]
}

Jede andere Seite referenziert dann diese @id, statt das Objekt erneut vollständig auszugeben — als publisher einer WebSite, als author oder publisher eines Article, als isPartOf einer WebPage. Eine Entität, ein Satz Fakten, durchgängig referenziert. Das ist Graph-Modellierung, keine Dekoration — und es ist der Unterschied zwischen einem Google, das die eigenen Signale zusammenführt, und einem Google, das sich nicht sicher ist, welcher Version man vertrauen soll.

Fehler 3: Schema-Typen, die nichts mehr bringen

Google hat FAQ-Rich-Results im August 2023 auf eine kleine Gruppe von Regierungs- und Gesundheitsseiten eingeschränkt und das Feature später ganz aus der Suche entfernt — auch diese Ausnahmeregelung existiert nicht mehr. FAQPage-Markup wird trotzdem weiterhin als Standard-Best-Practice in Template-Bibliotheken und CMS-Plugins hineinkopiert, und jede Menge B2B- und E-Commerce-Websites liefern es weiterhin aus, ohne dafür irgendetwas zu bekommen — und setzen sich in manchen Fällen sogar einem echten Risiko aus: Wenn der ausgezeichnete FAQ-Text nicht mit dem sichtbaren Seiteninhalt übereinstimmt, ist das ein Verstoß gegen die Richtlinien für strukturierte Daten, nicht nur verschwendetes Markup. HowTo-Rich-Results sind auf die gleiche Weise verschwunden — 2023 zunächst auf Mobilgeräten entfernt, dann auch auf dem Desktop, ohne dass der Typ irgendwo noch ein sichtbares Ergebnis erzielt.

Worauf man wirklich achten sollte, ist nicht nur „dieser Typ ist veraltet". Es geht um Markup, das vor drei Jahren aus einer Vorlage kopiert und nie wieder daraufhin überprüft wurde, was der Typ aktuell überhaupt noch bewirkt. Das Vokabular von Schema.org ist stabil; Googles Bereitschaft, einen bestimmten Typ als Rich Result darzustellen, ist es nicht — und das ändert sich nach einem Zeitplan, über den niemand eine Benachrichtigung verschickt.

Was noch immer Rich Results bringt

Die Liste, die sich 2026 verlässlich auszahlt: Product mit echtem Preis, Verfügbarkeit und AggregateRating aus echten Bewertungen des jeweiligen Produkts (Googles Richtlinie für Bewertungs-Snippets verbietet ausdrücklich Bewertungen in eigener Sache — ein Unternehmen, das sein eigenes Produkt bewertet —, die Bewertungen müssen also von echten Kunden stammen, nicht erfunden sein); BreadcrumbList; VideoObject; JobPosting; Event; Recipe; sowie SoftwareApplication mit einer gültigen applicationCategory. Daneben erledigen Organization und WebSite mit einer sauberen, deduplizierten @id-Struktur weiterhin ihre stillere Aufgabe: Entitätsklarheit und Eignung für das Sitelinks-Suchfeld — auch ganz ohne eigenes sichtbares Snippet.

Ein minimaler Audit, den man vierteljährlich durchführen sollte

• Die gerenderte HTML-Antwort validieren, nicht die Template-Datei — Escaping-Fehler zeigen sich erst nach dem Rendern.
• Die Codebasis nach jeder Stelle durchsuchen, an der Organization oder WebSite ausgegeben wird. Gibt es mehr als eine Stelle, alles hinter einer gemeinsamen @id konsolidieren.
• Jeden ausgelieferten @type gegen Googles aktuelle Dokumentation zu strukturierten Daten prüfen — nicht gegen den Blogpost, aus dem er ursprünglich kopiert wurde.
• Die Enhancements-Berichte in der Search Console monatlich prüfen — ein Anstieg bei „Invalid JSON-LD"- oder „Missing field"-Fehlern liegt meist an einem Deploy, nicht an einer Google-Richtlinienänderung.
• Sicherstellen, dass jede im Markup ausgezeichnete Aussage (eine Bewertungspunktzahl, eine FAQ-Antwort, ein Preis) in derselben Form auch sichtbar auf der Seite steht. Markup ohne sichtbare Entsprechung im Content ist ein Richtlinienverstoß, der nur darauf wartet, entdeckt zu werden.

Fazit

Strukturierte Daten sind Infrastruktur, keine Dekoration — und sie versagen so, wie Infrastruktur versagt: lautlos, bis ein Audit oder eine manuelle Maßnahme das Problem sichtbar macht. Die Websites, die 2026 Rich Results bekommen, sind nicht die mit dem meisten Schema. Es sind die, deren JSON tatsächlich fehlerfrei geparst wird, deren Entitäten auf eine einzige @id auflösen und deren Markup dem entspricht, was ein Mensch auf der Seite sieht.

Wenn Sie das ordentlich geprüft haben möchten — den gerenderten Output, nicht den Template-Quellcode —, führt unser SEO-Team die Validierung strukturierter Daten standardmäßig bei jedem technischen Audit durch, zusammen mit der Arbeit an Crawlbarkeit und Core Web Vitals, die sich meist direkt daneben findet.