Zum Inhalt springen
Aback Tools Logo

Strukturierte Daten einer Website Prüfen: JSON-LD-Validierungs-Guide

Strukturierte Daten einer Website prüfen: JSON-LD-Blöcke finden, Syntax und Pflichteigenschaften validieren, häufige Schemafehler beheben, Rich-Result-Eignung testen und Validierung in CI/CD automatisieren.

DH
Tutorials & How-Tos12 Min. Lesezeit2,700 Wörter

Strukturierte Daten sagen Suchmaschinen, was Ihr Inhalt bedeutet – nicht nur, was die Worte sagen, sondern ob eine Seite ein Produkt, ein Artikel, ein Rezept oder eine FAQ ist. Richtig umgesetzt, hebt Google Ihren Inhalt als Rich Results hervor: Sternbewertungen, FAQ-Akkordeons, Breadcrumb-Pfade und How-to-Karussells. Falsch umgesetzt, wird das Markup stillschweigend ignoriert. Dieser Leitfaden deckt jede Methode ab, um strukturierte Daten auf einer beliebigen Website zu prüfen – von der Quelltext-Inspektion bis zur automatisierten CI-Validierung.

40+Schema-Typenvon Google Rich Results unterstützt
100%Browser-lokale Prüfungkeine URL oder Anmeldung nötig
<1sValidierungsgeschwindigkeitsofortiges JSON-LD-Feedback

Was sind strukturierte Daten?

Strukturierte Daten sind maschinenlesbare Metadaten, die in eine Webseite eingebettet sind und Suchmaschinen helfen, den Inhalt über den sichtbaren Text hinaus zu verstehen. Das dominante Format ist JSON-LD – ein JavaScript-Object-Notation-Script-Tag im `<head>` einer Seite, das Vokabular von schema.org verwendet, um Entitäten wie Artikel, Produkte, Veranstaltungen, Rezepte und Organisationen zu beschreiben.

Wenn eine Suchmaschine eine Seite crawlt, extrahiert sie diese Schema-Blöcke und nutzt sie zur Erzeugung von Rich Results: erweiterte Suchtreffer, die Sternbewertungen, Preisspannen, Veranstaltungsdaten, FAQ-Akkordeons und Breadcrumb-Navigation direkt in der SERP zeigen. Rich Results erzielen konstant höhere Klickraten als Standard-Treffer mit blauem Link, weil sie auf einen Blick mehr Information vermitteln.

Die drei Formate strukturierter Daten

  • JSON-LD: ein eigenständiges `<script type="application/ld+json">`-Tag mit einem JSON-Objekt. Google empfiehlt dieses Format – am leichtesten hinzuzufügen, zu validieren und zu pflegen, ohne den Seiten-HTML anzufassen.
  • Microdata: Schema-Attribute (`itemscope`, `itemtype`, `itemprop`), die direkt an HTML-Elemente gehängt werden. Eng an die Seitenstruktur gekoppelt – schwerer zu validieren und zu aktualisieren.
  • RDFa: Linked-Data-Attribute (`typeof`, `property`) an HTML-Elementen. Auf manchen CMS-Plattformen verbreitet, für neue Implementierungen aber seltener als JSON-LD.

Note

Google unterstützt alle drei Formate, empfiehlt aber JSON-LD für die meisten Anwendungsfälle. Dieser Leitfaden konzentriert sich auf JSON-LD, weil es das dominante Format moderner Implementierungen ist und die meisten Tools darauf ausgelegt sind.

So prüfen Sie strukturierte Daten

Es gibt vier praktische Methoden, um strukturierte Daten auf einer Seite zu prüfen, jede für andere Situationen geeignet. Die schnellsten Methoden brauchen gar keine Tools; die gründlichsten benötigen einen Validator und Googles eigene Testumgebung.

Methode 1: Seitenquelltext anzeigen

Klicken Sie mit der rechten Maustaste auf eine beliebige Seite im Browser und wählen Sie Seitenquelltext anzeigen (Strg+U / Cmd+U). Drücken Sie Strg+F für die Suche und suchen Sie nach `application/ld+json`. Jeder Treffer ist ein Block strukturierter Daten. So wissen Sie sofort, ob strukturierte Daten auf der Seite existieren, und können das JSON zur Validierung kopieren. Bei Seiten, die Inhalte per JavaScript rendern, zeigt der Quelltext nur das initiale HTML – nutzen Sie die DevTools für die gerenderte Ausgabe.

Methode 2: DevTools-Elements-Panel

Öffnen Sie die Chrome-DevTools (F12), gehen Sie zum Elements-Tab und suchen Sie im Elementbaum nach `ld+json`. Das zeigt die strukturierten Daten so, wie der Browser sie aktuell rendert – einschließlich der per JavaScript nach dem Laden injizierten Blöcke. Das ist der richtige Ansatz für React, Next.js oder jedes Framework, das strukturierte Daten clientseitig oder per serverseitigem Rendering hinzufügt.

Methode 3: Strukturierte-Daten-Validator (am schnellsten in der Entwicklung)

Kopieren Sie einen JSON-LD-Block und fügen Sie ihn in den Validator für strukturierte Daten ein. Er validiert die JSON-Syntax, prüft `@context`- und `@type`-Deklarationen und markiert fehlende Pflichteigenschaften des deklarierten Schema-Typs – alles in Ihrem Browser, ohne URL-Einreichung oder Warten auf einen Crawl. Das ist die schnellste Schleife in der Entwicklung, weil Sie in Sekunden korrigieren und neu validieren können.

Methode 4: Googles Rich Results Test

Reichen Sie die URL Ihrer Live-Seite bei Googles Rich Results Test unter `search.google.com/test/rich-results` ein. Google ruft die Seite ab, extrahiert alle strukturierten Daten und meldet, für welche Rich-Result-Typen die Seite in Frage kommt. Das ist der verbindliche Test für die Rich-Result-Eignung – er benötigt aber eine Live-URL und dauert 5-30 Sekunden pro Test. Verwenden Sie ihn, wenn die lokale Validierung sauber ist.

Validator für Strukturierte Daten

Validieren Sie jeden JSON-LD-Block strukturierter Daten auf Syntax, Pflichteigenschaften und schema.org-Konformität – browser-lokal, ohne URL.

Open tool

JSON-LD-Markup validieren

Die JSON-LD-Validierung hat zwei getrennte Ebenen: die Syntaxvalidierung (ist das JSON strukturell gültig?) und die Schemavalidierung (entspricht der Inhalt den Pflicht- und Empfehlungseigenschaften des schema.org-Typs?). Beide Ebenen müssen bestehen, bevor ein Block strukturierter Daten nützlich ist.

1

Seite auf JSON-LD-Blöcke inspizieren

Klicken Sie mit der rechten Maustaste auf die Seite und wählen Sie Seitenquelltext anzeigen. Suchen Sie nach `application/ld+json`. Kopieren Sie das gesamte JSON-Objekt aus dem Script-Tag – von der öffnenden bis zur schließenden Klammer. Gibt es mehrere Blöcke, kopieren Sie jeden einzeln zur Validierung.

2

Syntax mit dem JSON-LD-Validator prüfen

Fügen Sie den kopierten Block in den JSON-LD-Validator ein. Er prüft, dass das JSON wohlgeformt ist, dass `@context` auf `https://schema.org` gesetzt ist und dass `@type` einen erkannten schema.org-Typ referenziert. Syntaxfehler werden mit Zeilennummern gemeldet; Unbekannter-Typ-Warnungen identifizieren Schema-Typen, die kaum Rich Results erzeugen.

3

Pflichteigenschaften des deklarierten Typs prüfen

Jeder Schema-Typ hat Pflicht- und Empfehlungseigenschaften. Ein `Product`-Schema verlangt `name` und entweder `offers` oder `review` für die Rich-Result-Eignung. Ein `Article` verlangt `headline`, `author` und `datePublished`. Der Validator für strukturierte Daten prüft den deklarierten `@type` und markiert jede fehlende oder falsch formatierte Pflichteigenschaft.

4

Rich-Result-Eignung mit Googles Tool testen

Sobald die lokale Validierung sauber ist, reichen Sie die Seiten-URL bei Googles Rich Results Test ein. Prüfen Sie die Liste der erkannten Schema-Typen und bestätigen Sie, dass jeder als berechtigt statt mit Fehlern markiert erscheint. Behandeln Sie „Empfohlen“-Warnungen für Eigenschaften, die die Qualität der Rich Results verbessern, ohne sie zu blockieren.

beispiel-artikel-schema.json
json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Check Structured Data on a Website",
  "author": {
    "@type": "Person",
    "name": "Devvrat Hans",
    "url": "https://abacktools.com"
  },
  "datePublished": "2026-06-11",
  "dateModified": "2026-06-11",
  "publisher": {
    "@type": "Organization",
    "name": "Aback Tools",
    "url": "https://abacktools.com"
  }
}

Tip

Setzen Sie `datePublished` und `dateModified` immer als ISO-8601-Datumsstrings (`YYYY-MM-DD` oder `YYYY-MM-DDTHH:MM:SSZ`). Ein häufiger Fehler ist ein menschenlesbares Format wie „11. Juni 2026“ – das scheitert an der Schemavalidierung und kann verhindern, dass der Artikel in Google Discover und Top Stories erscheint.

Häufige Fehler bei strukturierten Daten

Die meisten Fehler bei strukturierten Daten fallen in vorhersagbare Kategorien. Zu wissen, was jeder Fehlertyp bedeutet – und warum er zählt – erlaubt es, Probleme in der richtigen Reihenfolge zu beheben: zuerst Syntax, dann Pflichteigenschaften, zuletzt empfohlene Erweiterungen.

Fehlende Pflichteigenschaften

Google definiert Pflichteigenschaften für jeden Schema-Typ, der Rich Results unterstützt. Fehlt eine Pflichteigenschaft, ist das gesamte Schema für seine Rich-Result-Funktion untauglich. Häufige Beispiele: `Product` ohne `name` oder `offers`, `Recipe` ohne `name` oder `recipeIngredient`, `Event` ohne `name`, `startDate` oder `location`. Der Product-Schema-Vollständigkeits-Checker prüft Product-Schemas speziell gegen alle Pflicht- und empfohlenen Google-Felder.

Falsche Wertetypen

schema.org-Eigenschaften erwarten bestimmte Wertetypen. `url`-Eigenschaften müssen absolute URLs sein, die mit `https://` beginnen; `ratingValue` muss eine Zahl sein (kein String wie `"4.5"`); `datePublished` muss ein gültiger ISO-8601-Datumsstring sein. Einen String zu übergeben, wo eine Zahl erwartet wird, oder einen relativen Pfad, wo eine absolute URL nötig ist, erzeugt einen Typkonflikt-Fehler, der die korrekte Lesung des Schemas blockiert.

Schema-Typ und Seiteninhalt passen nicht zusammen

Google verlangt, dass strukturierte Daten den sichtbaren Seiteninhalt korrekt widerspiegeln. FAQPage-Markup auf einer Seite, die keine sichtbaren FAQ-Fragen und -Antworten zeigt, oder Product-Markup auf einer Kategorieseite ohne konkrete Produktdetails verstößt gegen Googles Richtlinien zu strukturierten Daten und kann manuelle Maßnahmen gegen die Rich-Result-Eignung auslösen.

FehlertypBeispielAuswirkungBehebung
Fehlende PflichteigenschaftProduct ohne nameBlockiert Rich ResultEigenschaft ergänzen
Falscher WertetypratingValue: "4.5" (String)Schema ignoriertZahl verwenden: 4.5
Relative URL im url-Feldimage: /foto.jpgValidierungsfehlerAbsolute HTTPS-URL verwenden
Ungültiges DatumsformatdatePublished: "Juni 2026"Datum nicht geparstFormat YYYY-MM-DD verwenden
Unbekannter @type@type: "BlogPosting2"Schema nicht erkanntExakten schema.org-Typ verwenden
Fehlendes @contextKeine @context-DeklarationSchema nicht extrahiertschema.org-Kontext ergänzen
Inhalt passt nichtFAQPage auf Nicht-FAQ-SeiteRisiko manueller MaßnahmenSchema an Inhalt anpassen

Warning

Googles Richtlinien zu strukturierten Daten verbieten es, mit strukturierten Daten Inhalte zu markieren, die für den Nutzer nicht sichtbar sind. Versteckte strukturierte Daten – ausführlichere Beschreibungen als der sichtbare Inhalt, gefälschte Bewertungen oder für SEO erfundene Entitätsdaten – gelten als Spam. Stellen Sie stets sicher, dass Ihr JSON-LD das widerspiegelt, was Nutzer auf der Seite tatsächlich sehen.

Prüfung nach Schema-Typ

Verschiedene Schema-Typen haben unterschiedliche Pflichteigenschaften, unterschiedliche Rich-Result-Darstellungen und unterschiedliche am besten geeignete Validierungstools. So gehen Sie mit den am häufigsten verwendeten Typen um.

FAQPage und HowTo

FAQPage ist einer der wirkungsvollsten Schema-Typen für den organischen CTR – ein gültiges FAQPage-Schema wird direkt in den Google-Suchergebnissen als ausklappbares Akkordeon gerendert und zeigt Fragen und Antworten ohne Klick. Nutzen Sie den FAQ-Schema-Generator, um aus einfachen Frage-Antwort-Paaren sauberes FAQPage-Markup zu erzeugen, und validieren Sie die Ausgabe mit dem JSON-LD-Validator. Für Schritt-für-Schritt-Anleitungen baut der HowTo-Schema-Generator gültiges HowTo-Markup mit korrekt strukturierten `HowToStep`-Blöcken.

BreadcrumbList-Markup erzeugt die Breadcrumb-Leiste unter dem Seitentitel in den Google-Suchergebnissen – und ersetzt die rohe URL durch eine lesbare Hierarchie. Jedes `ListItem` benötigt einen `name` und eine `item`-URL. Nutzen Sie den Breadcrumb-Schema-Generator, um BreadcrumbList-JSON-LD aus einem URL-Pfad oder manuellen Einträgen zu erzeugen, direkt einsetzbar in Ihr Seitentemplate.

Organization und Article

Das Organization-Schema etabliert die Identität Ihrer Website für Googles Wissensgraph – Name, Logo, Kontaktdaten und Social-Profile. Der Organization-Schema-Validator prüft, dass alle empfohlenen Felder vorhanden und korrekt formatiert sind. Für redaktionelle Inhalte erhöht das Article-Schema mit `author`, `datePublished` und `publisher` die Eignung für Google News, Top Stories und Discover, was Nachrichten- und Blogseiten erheblichen Traffic bringen kann.

Rezensionen und Gesamtbewertungen

Sternbewertungen in Suchergebnissen stammen aus `AggregateRating`, verschachtelt in einem `Product`-, `LocalBusiness`- oder `Recipe`-Schema. `ratingValue` muss eine Zahl sein, `reviewCount` eine positive Ganzzahl, und sowohl `bestRating` als auch `worstRating` müssen angegeben sein, um Mehrdeutigkeit zu vermeiden. Der Rezensions-Snippet-Eignungs-Checker validiert Bewertungs-Markup gegen Googles spezifische Anforderungen an Rich Results für Rezensionen.


Schema-TypRich ResultWichtigste PflichtfelderAback-Tools-Checker
FAQPageFAQ-Akkordeon in der SERPmainEntity mit F&AFAQ-Schema-Generator
HowToSchritt-Karussell in der SERPname, step, textHowTo-Schema-Generator
BreadcrumbListBreadcrumb-Pfad in der SERPitemListElement, name, itemBreadcrumb-Schema-Generator
ProductProduktpanel mit Preis/Bewertungname, offers oder reviewProduct-Schema-Vollständigkeits-Checker
ArticleTop Stories, Discoverheadline, author, datePublishedJSON-LD-Validator
OrganizationWissenspanelname, url, logoOrganization-Schema-Validator
LocalBusinessLokales Paket, Kartenname, address, telephoneValidator für strukturierte Daten

Strukturierte Daten in CI/CD

Manuelle Prüfungen strukturierter Daten genügen für einzelne Seiten, doch große Websites mit Templates, die strukturierte Daten programmatisch erzeugen, brauchen automatisierte Validierung. Eine Prüfung strukturierter Daten in Ihre CI/CD-Pipeline einzubauen, fängt Regressionen ab, bevor sie in Produktion gehen und die Rich-Result-Eignung blockieren.

Extraktion und Validierung in Build-Pipelines

Der zuverlässigste Ansatz ist, JSON-LD aus dem gebauten HTML-Output zu extrahieren und programmatisch zu validieren. Nach einem Build parsen Sie die erzeugten HTML-Dateien, extrahieren jeden `<script type="application/ld+json">`-Block und führen jeden durch eine schema.org-Validierungsbibliothek wie `schema-dts` (TypeScript), `jsonld` (Node.js) oder Googles Structured Data Linter. Lassen Sie den Build fehlschlagen, wenn eine Pflichteigenschaft fehlt oder das JSON fehlerhaft ist.

terminal
bash
# Extract all JSON-LD blocks from built HTML using grep
grep -rl 'application/ld+json' ./out/ | while read file; do
  # Parse and validate each block
  node scripts/validate-schema.js "$file"
done

# Or use a dedicated CLI tool
npx schema-validator ./out/**/*.html --strict

SERP-Feature-Monitoring

Überwachen Sie nach dem Deployment die Rich-Result-Performance in der Google Search Console unter dem Abschnitt „Verbesserungen“. Jeder implementierte Schema-Typ erhält seinen eigenen Bericht mit gültigen Elementen, Warnungen und Fehlern, während Googlebot Ihre Seiten crawlt. Ein plötzlicher Fehleranstieg zeigt meist eine Template-Änderung, die das Schema einer ganzen Seitenkategorie zerbrochen hat. Der SERP-Features-Checker liefert eine ergänzende Sicht – welche SERP-Features eine bestimmte URL aktuell auslöst.

Tip

Fordern Sie nach der Behebung eines Fehlers strukturierter Daten die Neuindexierung betroffener URLs in der Google Search Console über das URL-Prüfung-Tool an. Klicken Sie auf „Indexierung beantragen“, um Googlebot zu bitten, früher als im normalen Crawl-Zyklus neu zu crawlen und die strukturierten Daten erneut zu extrahieren – bei Seiten niedrigerer Priorität kann der Zyklus Tage oder Wochen dauern.

Best Practices

Die Befolgung dieser Praktiken stellt sicher, dass Ihre strukturierten Daten korrekt, wartbar und konform mit Googles Richtlinien sind – maximale Rich-Result-Eignung ohne Risiko manueller Maßnahmen oder stiller Schemafehler.

Strukturierte Daten mit sichtbarem Inhalt synchron halten

Die häufigste Quelle manueller Maßnahmen gegen strukturierte Daten ist eine Diskrepanz zwischen Schema und Nutzeranzeige. Zeigt Ihr `Product`-Schema einen Preis von 29 $, die Seite aber 49 $, wertet Google das als irreführendes Markup. Nutzen Sie Ihr CMS oder Templatesystem, um strukturierte Daten aus derselben Datenquelle zu erzeugen, die den sichtbaren Seiteninhalt befüllt – hardcoden Sie niemals Werte im Schema, die andernorts dynamisch angezeigt werden.

Spezifische Typen statt generische verwenden

Schema.org hat eine tiefe Typenhierarchie. Eine Seite über ein Softwareprodukt sollte `SoftwareApplication` verwenden, nicht das generische `Product`. Ein lokales Restaurant sollte `Restaurant` (Subtyp von `FoodEstablishment`) nutzen, nicht das generische `LocalBusiness`. Spezifischere Typen geben Suchmaschinen mehr Signal zum Inhalt und können reichhaltigere Darstellungsformate in den Suchergebnissen freischalten.

Strukturierte Daten dürfen nicht verwendet werden, um Nutzer zu täuschen oder irreführende Informationen bereitzustellen. Die strukturierten Daten einer Seite müssen den Inhalt der Seite korrekt wiedergeben.

- Google Search Central Dokumentation
  • Vor dem Deploy validieren: Führen Sie den Validator für strukturierte Daten für jeden Schema-Block vor dem Livegang aus – finden Sie Fehler, bevor Googlebot sie findet.
  • Eine Entität pro Block: Verschachteln Sie verwandte Entitäten (z. B. `author` in `Article`), statt für jede Unterentität separate Top-Level-Blöcke zu erzeugen.
  • Überall absolute URLs: Die Felder `url`, `image`, `logo` und `sameAs` verlangen durchgehend vollständige `https://`-URLs – relative Pfade sind in strukturierten Daten ungültig.
  • sameAs für Organisationen: Verknüpfen Sie Ihr Organization-Schema mit Wikipedia, Wikidata, LinkedIn und anderen autoritativen Quellen, um die Wissensgraph-Zuordnung zu stärken.
  • Google Search Console überwachen: Prüfen Sie wöchentlich die Verbesserungsberichte – sie zeigen, welche Seiten gültige, mit Warnungen behaftete oder fehlerhafte strukturierte Daten haben, während Googlebot sie crawlt.

Note

Strukturierte Daten liest mehr als nur Google. Microsoft Bing, Pinterest Rich Pins und Slack-Linkvorschauen nutzen alle schema.org-strukturierte Daten für ihre eigenen angereicherten Darstellungen. Eine gut implementierte Schema-Strategie nützt jeder Plattform, die Ihre Seiten konsumiert – nicht nur der Google-Suche.

Key takeaways

  • Prüfen Sie auf strukturierte Daten, indem Sie im Seitenquelltext nach `application/ld+json` suchen – jedes Script-Tag dieses Typs ist ein Block strukturierter Daten.
  • Nutzen Sie den Validator für strukturierte Daten in der Entwicklung für sofortige, browser-lokale JSON-LD-Validierung ohne URL-Einreichung.
  • Googles Rich Results Test ist das verbindliche Tool für die Rich-Result-Eignung – führen Sie ihn aus, wenn die lokale Validierung sauber ist, nicht an ihrer Stelle.
  • Die häufigsten Fehler sind fehlende Pflichteigenschaften, falsche Wertetypen (Strings, wo Zahlen erwartet werden) und relative URLs, wo absolute HTTPS-URLs nötig sind.
  • Erzeugen Sie korrektes Schema-Markup für FAQPage, HowTo, BreadcrumbList und Product mit den dedizierten Aback-Tools-Generatoren und -Validatoren.
  • Strukturierte Daten müssen dem sichtbaren Seiteninhalt entsprechen – Diskrepanzen zwischen Schema- und angezeigten Werten riskieren manuelle Maßnahmen gegen die Rich-Result-Eignung.
  • Überwachen Sie nach dem Deployment den Abschnitt Verbesserungen in der Google Search Console, um gültige Elemente, Warnungen und Fehler zu verfolgen, während Googlebot Ihre Seiten crawlt.

Häufige Fragen

The fastest way is to right-click the page, select View Page Source, and search for "application/ld+json". Each script tag with that type contains a structured data block. Alternatively, open Chrome DevTools, go to the Network tab, reload the page, find the HTML document response, and search for "schema.org" in the response body. For a visual summary, use a browser extension like Schema Markup Validator or submit the URL to Google's Rich Results Test.

Google's Rich Results Test (search.google.com/test/rich-results) is the authoritative tool for checking rich result eligibility - it shows exactly which features your markup qualifies for. For faster, privacy-first validation without submitting a URL, the Aback Tools Structured Data Validator checks your JSON-LD block entirely in the browser with line-level error reporting. Use both: the Aback Tools validator during development and Google's tool before deployment.

JSON-LD (JavaScript Object Notation for Linked Data) is the W3C standard format for embedding structured data in web pages. You place a `<script type="application/ld+json">` tag in the `<head>` of your HTML document containing a JSON object that describes the page content using schema.org vocabulary. Google, Bing, and other search engines read this script tag to understand the page and generate rich results - star ratings, FAQ accordions, recipe cards, and breadcrumb trails in search results.

The most frequent errors are missing required properties (a `Product` schema without `name` or `offers`, an `Article` without `headline`), incorrect value types (a number where a URL is expected), invalid enum values (a `priceValidUntil` date in the wrong format), missing `@context` or `@type` declarations, and mismatched types (using `FAQPage` markup on a page that is not an FAQ page). Google also flags "soft errors" - missing recommended properties that do not block rich results but reduce their quality.

Structured data does not directly improve rankings - Google has stated it is not a ranking signal. Its value is in rich result eligibility: pages with correct structured data can appear as FAQ accordions, product panels with ratings and price, event listings, recipe cards, and How-to carousels in Google Search. These rich features increase click-through rate significantly, which has an indirect positive effect on organic performance. Structured data is also used by Google's AI Overviews for sourcing cited information.

Copy the JSON-LD block from your template or build output and paste it into the Aback Tools Structured Data Validator - it validates the schema without needing a live URL. For full rich-result eligibility testing, Google's Rich Results Test accepts either a URL or raw HTML - paste the entire `<head>` section of your page into the code input and it will extract and validate the structured data without the page being publicly accessible.

Yes. A page can have multiple `<script type="application/ld+json">` tags, each containing a separate schema type. A blog post page might include an Article schema, a BreadcrumbList schema, and an FAQPage schema simultaneously. Google reads all of them independently and applies whichever rich result features each schema qualifies for. The schemas must not contradict each other - the page name, URL, and author should be consistent across all blocks on the same page.

All three are formats for embedding structured data in HTML, but they differ in approach. JSON-LD places the schema in a standalone script tag, separate from the visible HTML - making it easy to add, maintain, and validate without touching the page content. Microdata and RDFa annotate existing HTML elements with schema attributes, tightly coupling the markup to the page structure. Google supports all three formats, but officially recommends JSON-LD for most use cases because it is the easiest to implement and maintain.

ShareXLinkedIn