Damit Ihre Website in den Suchergebnissen als Rich Result angezeigt wird, muss zunächst die Genauigkeit des Schema-Markups geprüft werden. Dieser Artikel erläutert technischen Prüfern Testmethoden, häufige Fehler und wichtige Optimierungspunkte.

Nutzer, die nach „comprobar schema“ suchen, möchten in der Regel nicht die grundlegende Definition von Schema kennenlernen. Sie möchten vielmehr bestätigen, ob die vorhandenen Markups einer Seite analysiert werden können, den Google-Richtlinien entsprechen und weshalb keine Rich Results erscheinen.
Technische Prüfer interessieren sich stärker für überprüfbare Nachweise: ob der Code gültig ist, ob Seiteninhalt und Markup übereinstimmen, ob Schlüsselfelder vollständig sind, ob die Suchmaschine die Seite bereits gecrawlt hat und was der tatsächliche Grund für ausbleibende Rich Results ist.
Daher reicht es bei der Prüfung von Schema nicht aus, lediglich darauf zu achten, ob ein Tool „bestanden“ anzeigt. Eine präzisere Beurteilung sollte sechs Aspekte umfassen: Syntax, Entitätstyp, Vollständigkeit der Eigenschaften, sichtbare Seiteninhalte, Indexierungsstatus und Berechtigung auf Suchplattformen.
Wichtig ist: Korrekte strukturierte Daten bedeuten nicht zwangsläufig, dass Rich Results angezeigt werden. Schema liefert maschinenlesbare semantische Signale; ob diese letztlich dargestellt werden, hängt weiterhin von der Qualitätsbewertung der Suchmaschine, dem Seitenthema und dem Wettbewerbsumfeld ab.
Der erste Schritt bei comprobar schema besteht nicht darin, einen Validator zu öffnen, sondern den Seitentyp und das Geschäftsziel zu bestimmen. Für Produktdetailseiten, Artikelseiten, Serviceseiten, FAQ-Seiten, Unternehmensprofilseiten und Breadcrumb-Seiten eignen sich unterschiedliche Markups.
So sollten bei Produktseiten von B2B-Fertigungsunternehmen üblicherweise zuerst Product, Offer, Brand und BreadcrumbList geprüft werden. Für Wissensinhaltsseiten eignen sich eher Strukturen wie Article, FAQPage, HowTo oder WebPage, statt Produktvorlagen schematisch zu kopieren.
Wenn der Seiteninhalt lediglich Serviceleistungen beschreibt, jedoch Product-Felder für nicht vorhandene Preise, Lagerbestände oder Bewertungen hinzugefügt werden, melden manche Prüftools möglicherweise keinen Fehler. Dennoch besteht eine Diskrepanz zwischen Inhalt und Markup, wodurch die Berechtigung zur Anzeige verloren gehen kann.
Bei mehrsprachigen eigenständigen Websites sollte zudem sichergestellt werden, dass Name, Beschreibung, Preiswährung, Bilder und Links der Seiten in verschiedenen Sprachen jeweils der aktuellen Sprachversion entsprechen. Englische Seiten dürfen keine chinesischen Felder übernehmen, und Seiten verschiedener Regionen sollten keine ungültigen Offer-Adressen wiederverwenden.
Für die grundlegende Validierung kann der Schema Markup Validator verwendet werden. Dabei wird insbesondere geprüft, ob die Syntax von JSON-LD, Microdata oder RDFa analysiert werden kann und ob Fehler bei Typbeziehungen, Pflichtfeldern und Eigenschaftenwertformaten vorliegen.
Wenn Google Rich Results das Ziel sind, sollte zusätzlich der Rich Results Test verwendet werden. Dieses Tool erkennt, ob eine Seite den von Google unterstützten Rich-Result-Typen entspricht, und unterteilt Probleme in Fehler, Warnungen und nicht erkannte Elemente.
Fehler verhindern in der Regel die Berechtigung für eine bestimmte Art von Rich Results, beispielsweise wenn bei Product die Felder name oder offers fehlen. Warnungen verhindern die Anzeige nicht unbedingt, deuten aber häufig auf unvollständige Informationen hin, etwa fehlende optionale Erweiterungsfelder wie aggregateRating, review oder shippingDetails.
In der Live-Umgebung sollten außerdem die Berichte zu Verbesserungen in der Google Search Console einbezogen werden. Validatoren können nur belegen, dass der Code der aktuellen URL lesbar ist; nur die Search Console hilft dabei zu bestätigen, ob Google die Seite bereits gecrawlt hat, wie viele gültige Elemente erkannt wurden und auf welchen Seiten weiterhin Fehler auftreten.
Beim Testen sollten sowohl die produktive URL als auch das gerenderte DOM geprüft werden. Bei Websites, die JSON-LD dynamisch per JavaScript ausgeben, ist es nicht zwangsläufig ein Problem, wenn das Markup im Quellcode nicht vorhanden ist. Es muss jedoch bestätigt werden, dass Crawler nach dem Rendern zuverlässig vollständige Daten erhalten.
Die erste Kategorie betrifft Abweichungen zwischen Markup-Inhalten und sichtbaren Seiteninhalten. Felder wie Preise, Rabatte, Lagerbestand, Bewertungen, Autoren und Veröffentlichungsdatum müssen auf der tatsächlich vom Nutzer aufgerufenen Seite auffindbar sein und dürfen nicht für Anzeigezwecke erfunden werden.
Die zweite Kategorie sind doppelte oder widersprüchliche Entitäten. Wenn auf derselben Seite mehrere Product-Objekte ausgegeben werden oder Plugins, Themes und manuell eingefügter Code Organization oder BreadcrumbList mehrfach erzeugen, kann die Suchmaschine möglicherweise nicht erkennen, welche Entität das Hauptobjekt ist.
Die dritte Kategorie ist die Verwendung falscher Feldformate. URLs sollten zugängliche absolute Adressen verwenden, Datumsangaben sollten im ISO-Format vorliegen, Preise sollten als erkennbare Zahlen angegeben werden, Währungen sollten ISO-4217-Codes verwenden und Bildlinks müssen von Suchmaschinen gecrawlt werden können.
Die vierte Kategorie betrifft unlogische Verschachtelungsbeziehungen. Beispielsweise sollte ein Offer zum entsprechenden Product gehören, ein Review auf das tatsächlich bewertete Objekt verweisen und author sowie publisher eines Article eine identifizierbare Identität besitzen. Vollständige Felder bei fehlerhaften Beziehungen verringern ebenfalls die Vertrauenswürdigkeit der Daten.
Die fünfte Kategorie ist die fehlende kontinuierliche Pflege nach der Bereitstellung. Nach der Einstellung eines Produkts, Preisanpassungen, Seitenmigrationen oder mehrsprachigen Überarbeitungen enthält Schema häufig weiterhin alte Daten. Technische Teams sollten die Prüfung strukturierter Daten in den Veröffentlichungsprozess integrieren, statt sie als einmaliges Projekt zu behandeln.
Wenn der Rich Results Test die Eignung bestätigt, in den Suchergebnissen aber keine Rich Results angezeigt werden, sollte zunächst geprüft werden, ob die Seite indexiert wurde. Mit dem Tool zur URL-Prüfung in der Search Console lassen sich die kanonische URL, Crawling-Zeitpunkt, Indexierungsstatus und Rendering-Ergebnis bestätigen.
Anschließend sollte geklärt werden, ob Google die Anzeige dieses Typs im jeweiligen Land, in der jeweiligen Sprache und im jeweiligen Suchkontext unterstützt. Nicht jeder Schema-Typ führt zu sichtbaren Rich Results; einige Markups dienen hauptsächlich dem Verständnis von Entitäten, der Verknüpfung mit dem Knowledge Graph oder der Unterstützung bei der Inhaltsklassifizierung.
Auch die Qualität der Seite selbst muss bewertet werden. Bei zu dünnen Inhalten, nicht überprüfbaren Informationen, schlechter Seitenerfahrung, nicht kaufbaren Produkten oder unzuverlässigen Bewertungsquellen können die erwarteten Anzeigen trotz korrektem Markup ausbleiben oder sogar ignoriert werden.
Rich Results sind eine erweiterte Form von Suchergebnissen und kein Ersatz für Rankings. Eine verlässlichere Strategie besteht darin, Schema gemeinsam mit crawlbarer Architektur, Inhaltsqualität, Internationalisierungskonfiguration, Seitengeschwindigkeit und kontinuierlicher SEO-Optimierung zu bewerten.
Bei neuen Seiten können zunächst in der Entwicklungsumgebung die Hauptentität der Seite und die Feldquellen definiert werden. Anschließend kann das Frontend oder CMS JSON-LD automatisch generieren. Die Felder sollten aus realen Daten zu Produkten, Artikeln oder Unternehmensinformationen stammen; manuelles Kopieren und Einfügen ist nicht empfehlenswert.
Vor der Veröffentlichung können vier Abnahmekriterien festgelegt werden: keine blockierenden Fehler im Validator, Übereinstimmung zwischen sichtbarem Seiteninhalt und Markup, Zugänglichkeit wichtiger URLs sowie stabile Stichprobenergebnisse bei gleichartigen Seiten. So lässt sich vermeiden, dass einzelne Seitentests erfolgreich sind, während Vorlagenfehler in großer Anzahl auftreten.
Nach der Veröffentlichung sollten die Berichte zu Verbesserungen in der Search Console monatlich geprüft werden. Nach Template-Upgrades, Plugin-Änderungen, Website-Migrationen und umfangreichen Produktaktualisierungen sollten erneute Stichproben durchgeführt werden. Seiten mit hohem Traffic, zentrale Kategorieseiten und mehrsprachige Landingpages sollten vorrangig überwacht werden.
Auch Content-Assets können in eine einheitliche Verwaltung einbezogen werden. Wenn ein Unternehmen Forschungsinhalte wie Hindernisse bei der Umsetzung und Optimierungsansätze der Budgetbewertung mittels Balanced Scorecard in Aluminiumverarbeitungsunternehmen veröffentlicht, kann Article-Markup eingesetzt werden, um Titel, Autor, Veröffentlichungszeitpunkt, Hauptbild und Textentitäten zu ergänzen und die Grundlage für ein korrektes Verständnis der Inhalte zu verbessern.
Der Kern von comprobar schema besteht nicht darin, dass alle Anzeigen im Validierungstool grün sind, sondern darin, sicherzustellen, dass die Suchmaschine echte, vollständige, konfliktfreie und zum Seitenzweck passende strukturierte Informationen erhält.
Bei der technischen Bewertung sollte zunächst der richtige Schema-Typ ausgewählt, anschließend durch Validatoren, Rich-Result-Tests und die Search Console gegenseitig bestätigt und zuletzt die Wirkung anhand von Indexierung, Inhaltsqualität und Geschäftsdaten beurteilt werden. Nur so können Rich Results zu einem Ergebnis nachhaltiger Optimierung werden, statt eine zufällig auftretende Funktion zu sein.
Verwandte Artikel
Verwandte Produkte