Screpys Prüfung strukturierter Daten untersucht JSON-LD aus einer öffentlichen Seite oder eingefügtem Code. Sie findet Fehler beim Parsen, listet deklarierte Entitäten auf und meldet ausgewählte Eigenschaftsprobleme bei fünf unterstützten Schematypen. Nutzen Sie den Bericht, um nötige Korrekturen von weiterführenden Prüfungen zu unterscheiden. Gültige Syntax, unterstützte Prüfungen und die Eignung für ein Rich-Suchergebnis bei Google sind verschiedene Fragen; ein grüner Status beantwortet nicht alle drei.
Seiten-URL oder eingefügtes JSON-LD wählen
Wählen Sie Seiten-URL, um eine veröffentlichte Seite zu untersuchen, etwa eine Produktdetailseite oder eine Kontaktseite des Unternehmens. Geben Sie die öffentliche HTTP- oder HTTPS-Adresse dieser Seite ein, statt grundsätzlich die Startseite zu verwenden: Verschiedene Vorlagen können unterschiedliches Markup enthalten. Der URL-Modus liest das von der Seite zurückgegebene HTML. Eine private oder passwortgeschützte Seite liefert nicht dieselben öffentlichen Belege; ein fehlgeschlagener Abruf beweist keinen Fehler in ihren strukturierten Daten.
Wählen Sie Code einfügen für einen Entwurf, ein extrahiertes Skript oder bereits vorhandenes HTML. Wählen Sie JSON-LD für das JSON selbst, ohne umgebendes <script>-Element. Wählen Sie HTML, wenn Ihre Eingabe Blöcke mit <script type="application/ld+json"> enthält. Die Adresse einer eigenständigen JSON-Datei ist keine HTML-Seite; fügen Sie deren Inhalt im JSON-LD-Modus ein. Eingefügte Daten sind auf 256 KiB begrenzt, gemessen in UTF-8-Bytes. Die mögliche Zeichenanzahl hängt deshalb vom Text ab.
URL-Prüfungen führen kein JavaScript aus. Nach dem Laden eingefügtes Markup kann im abgerufenen Quelltext fehlen. Google kann dynamisch eingefügtes JSON-LD verarbeiten; ein fehlender Block in diesem Bericht beweist daher nicht, dass Google keinen sieht. Untersuchen Sie das relevante gerenderte Markup oder nutzen Sie Googles Funktionstest, wenn diese Unterscheidung wichtig ist. Eingefügter Code prüft Ihre Eingabe, nicht das, was die veröffentlichte Seite tatsächlich ausliefert.
Den Bericht zu strukturierten Daten lesen
Beginnen Sie mit dem Prüfumfang, danach mit den Befunden und der Entitätstabelle. JSON-LD-Blöcke zählt die im HTML erkannten Skripte; eingefügtes JSON-LD gilt als ein Block. Entitäten zählt die übernommenen typisierten Objekte, deren JSON erfolgreich geparst wurde; ein Skript kann mehrere Entitäten enthalten. Syntaxfehler zählt verarbeitete Blöcke, die nicht geparst werden konnten. Das sind unterschiedliche Größen: Drei Blöcke müssen nicht drei Entitäten enthalten. Bei einem Teilbericht beweist die Anzahl erkannter Blöcke nicht, dass jeder Block untersucht wurde.
Jede Zeile trennt Syntax und Prüfumfang. Grün bei gültiger Syntax bedeutet, dass der JSON-Parser den Block angenommen hat. Grün bei unterstützten Prüfungen bedeutet, dass die Entität für die ausgewählten Eigenschaftsprüfungen dieses Tools qualifiziert war. Lesen Sie auch ihre Befunde: Keine dieser Angaben bestätigt die Richtigkeit sämtlicher Eigenschaften. Rot kennzeichnet Parsingfehler oder Fehlerbefunde, Gelb hebt Warnungen und einen teilweisen Prüfumfang hervor, Grau markiert nicht unterstützte oder nicht verfügbare Belege. Beachten Sie neben der Farbe immer den ausgeschriebenen Status.
Die Spalte Pfad hilft beim Auffinden verschachtelter Objekte. $.author verweist beispielsweise auf das Autorenobjekt innerhalb der Wurzel, $.@graph[1] auf das zweite Objekt eines @graph-Arrays. Pfade beziehen sich auf den jeweiligen JSON-LD-Block. Derselbe Pfad kann deshalb in mehreren Skripten vorkommen; der JSON-Download enthält zur Unterscheidung Blocknummern.
Die Spalte Name liest name, nicht jede typspezifische Anzeigeeigenschaft. Ein Article mit gültigem headline kann daher eine leere Namenszelle haben. Prüfen Sie die entsprechende Eigenschaft und den Befund, bevor Sie die leere Zelle als Inhaltsfehler bewerten.
JSON-Syntax vor Eigenschaftswarnungen korrigieren
Ein ungültiger Block liefert keine verlässlichen Entitätsbefunde. Reparieren Sie zuerst das JSON und wiederholen Sie die Prüfung, bevor Sie Warnungen zu fehlenden Eigenschaften auswerten. Häufige Ursachen sind einfache Anführungszeichen bei Namen oder Zeichenketten, ein zusätzliches Komma nach der letzten Eigenschaft, eine fehlende schließende Klammer oder ein nicht maskiertes Anführungszeichen im Text. JSON verwendet doppelte Anführungszeichen und Kommas zwischen Einträgen; RFC 8259 definiert die Grammatik.
Diese fiktive Organization ist ein minimales Syntaxbeispiel für Code einfügen → JSON-LD:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
Das Beispiel liefert die beiden Eigenschaften, nach denen dieses Tool bei Organization sucht. Es ist keine vollständige Vorlage für eine Google-Suchfunktion. Ersetzen Sie die fiktiven Werte durch zutreffende Seiteninformationen und prüfen Sie vor der Veröffentlichung die Anforderungen der jeweiligen Funktion.
Gültiges JSON allein belegt keine verwendbaren strukturierten Daten. Eine einzelne Zeichenkette oder Zahl kann gültiges JSON sein, beschreibt jedoch nicht die erwartete Entität; das Tool meldet, dass die Wurzel ein Objekt oder Array benötigt. Ebenso kann ein geparstes Objekt ohne deklarierten @type keine Entitätszeilen erzeugen. Prüfen Sie die tatsächliche Struktur, bevor Sie nur zur Bereinigung des Berichts Eigenschaften ergänzen.
Welche Schemaeigenschaften werden geprüft?
Die Prüfung strukturierter Daten untersucht ausgewählte Eigenschaften von fünf exakt unterstützten Typen, wenn ihr Kontext erkannt wird. Die Tabelle erklärt Befunde; sie ist weder eine vollständige Liste der Schema.org-Eigenschaften noch der Pflichtfelder von Google.
| Deklarierter Typ | Was dieses Tool untersucht | Wie Sie den Befund nutzen |
|---|---|---|
Organization |
Vorhandensein von name und url |
Prüfen Sie, ob die Werte die tatsächliche Organisation und ihre richtige Website beschreiben. |
LocalBusiness |
Vorhandensein von name und address |
Prüfen Sie die tatsächliche Unternehmensidentität und Adresse; Adressbestandteile werden nicht vollständig validiert. |
Article |
Vorhandensein von headline, author, datePublished und image |
Vergleichen Sie die Werte mit dem Artikel und untersuchen Sie Formate gesondert. |
Product |
Vorhandensein von name; ob offers, review oder aggregateRating angegeben ist |
Verwenden Sie nur zutreffende, passende Produktdaten. Erfinden Sie kein Angebot und keine Bewertung, um eine Warnung zu entfernen. |
BreadcrumbList |
Nicht leeres itemListElement-Array; positive ganzzahlige position und nicht leerer Text in name jedes untersuchten Eintrags |
Korrigieren Sie den genannten Eintrag und prüfen Sie danach den gesamten Navigationspfad und die Ziel-URLs gesondert. |
Die meisten dieser Prüfungen untersuchen lediglich das Vorhandensein. Ein Wert kann vorhanden sein, obwohl seine URL, sein Datum, sein Bild, seine Objektstruktur oder sein sachlicher Inhalt falsch ist. Ein leeres Objekt kann eine solche Prüfung erfüllen; Werte nur aus Leerzeichen werden nicht bei jeder Prüfung abgelehnt. Ein unterstützter Status bestätigt daher nicht, dass eine Adresse, ein Autor oder ein Angebot vollständig ist.
Breadcrumb-Prüfungen untersuchen zusätzlich die ausgewählten Eintragswerte. Sie bestätigen jedoch weder fortlaufende oder eindeutige Positionen noch korrekte item-URLs oder die vollständige ListItem-Semantik. Der Bericht übernimmt höchstens 100 Eigenschaftsbefunde pro Entität. Ein langer Navigationspfad oder eine Entität mit vielen wiederholten Mängeln kann anschließend weitere Prüfung erfordern.
Korrigieren Sie einen Befund im Kontext der Seite. Ist der Artikelautor eine Person, behalten Sie die richtige Autorenstruktur bei, auch wenn die verschachtelte Person außerhalb des Prüfumfangs erscheint. Korrektes Markup nur für grüne Anzeigen zu ändern, kann das eigentliche Problem verdecken statt lösen.
Warum ist gültiges Markup nicht unterstützt oder nur teilweise geprüft?
Nicht unterstützt bedeutet, dass das Tool seine ausgewählten Eigenschaftsprüfungen nicht auf diese Entität angewendet hat. Es bedeutet nicht, dass Schema.org den Typ verbietet. Ein unterstützter Article kann beispielsweise einen verschachtelten Person-Autor enthalten. Article erhält seine ausgewählten Prüfungen, Person erscheint jedoch als nicht unterstützt und macht den Prüfumfang teilweise. Auch Restaurant liegt außerhalb der fünf exakt unterstützten Typen, obwohl es ein spezifischerer Unternehmenstyp ist. Behalten Sie den sachlich passenden Typ bei und verwenden Sie einen umfassenderen Validator für die übrigen Prüfungen.
Der Kontext kann dieselbe Unterscheidung verursachen. Dieses Tool erkennt einen einfachen Kontext http://schema.org oder https://schema.org, mit oder ohne abschließenden Schrägstrich, auch wenn er von einem übergeordneten Objekt übernommen wird. Objekt- oder Array-Kontexte werden nicht aufgelöst. Diese Formen können nach der W3C-Spezifikation für JSON-LD-Kontexte zulässig sein. Deklariert eine Entität mehrere Typen, müssen alle zum unterstützten Satz gehören, damit ihre Eigenschaftsprüfungen ausgeführt werden.
Der Prüfumfang hat außerdem feste Grenzen. Untersucht werden die ersten 50 JSON-LD-Blöcke; übernommen werden höchstens 500 Ergebniszeilen einschließlich Zeilen ungültiger Blöcke. Die Verarbeitung stoppt jenseits von 32 Verschachtelungsebenen oder 10.000 besuchten Werten pro Block. Dadurch können spätere Entitäten ungeprüft bleiben. Im HTML erkannte Microdata oder RDFa machen den Bericht ebenfalls teilweise, weil diese Formate hier nicht validiert werden.
Teilen Sie große eingefügte Eingaben in vollständige JSON-LD-Blöcke für getrennte Prüfungen auf. Schneiden Sie kein Objekt mitten durch und erzeugen Sie dadurch keinen neuen Syntaxfehler. Bewahren Sie die ursprüngliche Quelle auf und kennzeichnen Sie die Teile, die jeder Bericht abdeckt. Diese Prüfungen werden nicht automatisch zu einem vollständigen Seitenaudit zusammengeführt.
Die Seite nach der Markup-Korrektur überprüfen
Vergleichen Sie zuerst das Markup mit dem, was Besucher auf der Seite lesen können. Prüfen Sie Identitäten, Daten, Adressen, Produktdetails und vorhandene Bewertungen anhand der tatsächlichen Inhalte. Googles Richtlinien für strukturierte Daten verlangen relevante, zutreffende Informationen und die Einhaltung der jeweiligen Funktionsanforderungen; ein Parser kann diese Fakten nicht bestätigen. Ergänzen Sie keine erfundenen Angaben, um eine Eigenschaftswarnung zu erfüllen.
Wählen Sie die nächste Prüfung nach der offenen Frage. Der Schema.org Markup Validator bietet eine umfassendere Untersuchung von Schema.org-Markup einschließlich Microdata und RDFa. Auch er hat Grenzen: Andere Kontext-URLs werden nicht abgerufen oder interpretiert. Nutzen Sie Googles Test für Rich-Suchergebnisse, um unterstützte Google-Suchfunktionen und deren gemeldete Fehler oder Warnungen zu prüfen. Ein bestandener Test garantiert nicht, dass Google ein Rich-Suchergebnis anzeigt.
Wenn Sie Unternehmens-Markup vorbereiten, kann der Local-Business-Schema-Generator aus Ihren tatsächlichen Angaben JSON-LD erstellen. Prüfen Sie seine Ausgabe vor der Veröffentlichung. Spezifische Unternehmenstypen und verschachtelte PostalAddress-Objekte können in diesem Prüfwerkzeug weiterhin nicht unterstützt sein; Erstellung und ausgewählte Validierung sind getrennte Aufgaben.
Wiederholen Sie nach der Korrektur die relevante Prüfung auf der veröffentlichten Seite, nicht nur am Entwurf. Bestätigen Sie, dass das ausgelieferte Markup die beabsichtigte Änderung enthält, und vergleichen Sie die verbliebenen Befunde. Mit JSON herunterladen speichern Sie Blocknummern, Entitätspfade, Befunde und Prüfumfang dieses Durchlaufs. Bewahren Sie Eingabe und Umfang zusammen mit dem Export auf, damit andere Prüfer die Belege verstehen können. Ein gespeicherter Bericht dokumentiert eine Prüfung; er überwacht zukünftige Vorlagen- oder Inhaltsänderungen nicht laufend.