Schema Markup: strukturierte Daten ohne Spam

Ein gültiger JSON-LD-Block kann den Rich Results Test bestehen und trotzdem kein Rich Result erzeugen. Das ist kein Testfehler. Strukturierte Daten beschreiben Inhalte in maschinenlesbarer Form; sie ersetzen den Inhalt nicht, garantieren keine Suchfunktion und sind kein Ranking-Schalter.

Der übliche Fehler ist, mit „Welchen Schema-Typ sollte diese Website hinzufügen?“ zu beginnen. Eine bessere Ausgangsfrage lautet: Welche Entität beschreibt diese Seite in erster Linie, welche Fakten können Besucher tatsächlich sehen, und welche Darstellung unterstützt Google derzeit für diesen Inhalt?

Strukturierte Daten, Schema.org und Schema Markup

Strukturierte Daten sind Informationen, die in einem maschinenlesbaren Format organisiert sind. Schema.org liefert ein Vokabular aus Entitätstypen und Eigenschaften. Schema Markup ist die Umsetzung dieses Vokabulars auf einer Seite mit JSON-LD, Microdata oder RDFa.

Google Search unterstützt alle drei Formate für viele Funktionen und empfiehlt meist JSON-LD, weil es vom Darstellungs-HTML getrennt und leichter zu pflegen ist. Das Format kann falsche Daten nicht retten. Ein perfekt geformtes JSON-LD-Product, das einen Preis angibt, der auf der Seite fehlt, verstößt dennoch gegen die Konsistenzerwartung.

Verbessert Schema das Ranking?

Schema sollte nicht als direkter Rankingfaktor verkauft werden. Strukturierte Daten können Systemen helfen, eine Seite zu verstehen, und sie für bestimmte Rich Results qualifizieren. Eine auffälligere Darstellung kann die Klickrate in manchen Situationen beeinflussen, doch Google garantiert die Anzeige auch bei korrektem Markup nicht.

Die Ergebnisse hängen außerdem ab von:

• Ob die Seite gecrawlt und indexiert werden kann.
• Ob der Inhalt die Search-Richtlinien und die funktionsspezifischen Richtlinien erfüllt.
• Ob die Daten korrekt, vollständig, aktuell und sichtbar sind.
• Suchanfrage, Gerät, Standort und Googles Darstellungsentscheidung.
• Ob die Funktion in der aktuellen Dokumentation weiterhin unterstützt wird.

Die Verfügbarkeit von Rich Results ändert sich. Prüfen Sie die offizielle Search Gallery, statt sich auf einen alten Artikel oder die Typenliste eines Plugins zu verlassen.

Einen Typ aus dem Hauptinhalt der Seite wählen

Zeichnen Sie nicht jede Seite mit jedem entfernt verwandten Typ aus. Bestimmen Sie die Haupt-Entität:

• Einen redaktionellen Artikel: Article, BlogPosting oder einen passenden Untertyp.
• Eine kaufbare Produktseite: Product mit echtem Angebot, Preis und Verfügbarkeit.
• Einen physischen Geschäftsstandort: LocalBusiness oder einen genauen Untertyp.
• Ein Rezept: Recipe.
• Eine Seite rund um ein Video: VideoObject.
• Ein Organisationsprofil: Organization.
• Einen hierarchischen Pfad: BreadcrumbList.

Eine Kategorie, die Produkte auflistet, ist nicht automatisch ein Product. Ein Laptop-Kaufratgeber sollte sich nicht als Produkt ausweisen, nur weil er mehrere Modelle bespricht. Der Typ muss darstellen, was die Seite tatsächlich bietet.

Mit Quelldaten beginnen, nicht mit einem JSON-String

Wartbares Schema wird aus denselben Quellen erzeugt, die auch die sichtbare Seite rendern:

Zeigt ein Template den Datenbankpreis, während das JSON-LD eine im CMS von Hand eingetragene Zahl speichert, laufen beide bei der ersten Aktion auseinander. Strukturierte Daten sollten eine weitere Darstellung derselben Wahrheit sein und kein zweites Inhaltsarchiv.

Ein minimales BlogPosting-Beispiel

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/image-seo#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/image-seo"
  },
  "headline": "Image SEO and alt text",
  "image": [
    "https://example.com/images/image-seo-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/alex#person",
    "name": "Alex Nguyen",
    "url": "https://example.com/authors/alex"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

Das zeigt nur die Struktur. Prüfen Sie bei der Umsetzung die erforderlichen und empfohlenen Eigenschaften in der aktuellen Article-Dokumentation. Kopieren Sie niemals Beispieldaten, URLs oder Autoren in die Produktion.

@id verbindet stabile Entitäten

Eine @id muss keine eigene Seite sein, die ein Besucher öffnet. Sie ist ein stabiler Bezeichner im Graph, meist eine absolute URL mit Fragment:

• https://example.com/#organization
• https://example.com/#website
• https://example.com/authors/alex#person
• https://example.com/products/a#product

Verweisen der publisher eines Artikels und die websiteweite Organization auf dieselbe @id, können Systeme sie als eine Entität behandeln statt als unverbundene Objekte mit gleichem Namen.

Bezeichner müssen über Renderings hinweg stabil bleiben. Erzeugen Sie nicht bei jeder Anfrage eine zufällige UUID. Verwenden Sie auch keine @id für verschiedene Entitäten wie die Organisation und ihre Website.

Mehrere Elemente auf einer Seite

Eine Seite kann mehrere gültige Elemente strukturierter Daten enthalten:

• WebPage beschreibt die Seite.
• BlogPosting beschreibt den Artikel.
• BreadcrumbList beschreibt seinen Pfad.
• Organization oder Person wird als publisher oder author referenziert.
• VideoObject beschreibt ein eingebettetes Hauptvideo.

Objekte können getrennt oder in @graph verbunden sein. Korrekte Beziehungen und Widerspruchsfreiheit zählen mehr als das Layout. Ist ein Video nur eine nicht verwandte Werbung, verfälscht das Hinzufügen von VideoObject zur Verfolgung einer Video-Funktion die Seite.

Ein großes Organization-Objekt muss nicht in jedem Knoten wiederholt werden. Definieren Sie eine kanonische Entität und referenzieren Sie ihre @id, damit der Graph übersichtlich bleibt.

Pflicht- und empfohlene Eigenschaften

Die Dokumentation einer Funktion trennt Pflicht- von empfohlenen Eigenschaften. Fehlen Pflichtdaten, ist ein Element nicht berechtigt. Empfohlene Felder können die Vollständigkeit verbessern, aber nur, wenn echte Daten existieren.

Ein guter Grundsatz lautet weniger, genaue, vollständige Eigenschaften. Fügen Sie nicht hinzu:

• aggregateRating ohne echte Bewertungen.
• Ein erfundenes priceValidUntil, um eine Warnung zu beseitigen.
• „Admin“ als Autor, wenn weder Profil noch redaktionelle Verantwortung existiert.
• Ein generisches Logo als Bild für nicht verwandte Inhalte.
• sameAs-Links zu Profilen, die die Entität nicht besitzt.

Eine Warnung ist kein Auftrag, Informationen zu erfinden. Sie zeigt, dass eine empfohlene Eigenschaft fehlt; das Produktteam muss entscheiden, ob eine verlässliche Quelle existiert.

Ausgezeichnete Inhalte müssen sichtbar und konsistent sein

Google verlangt, dass strukturierte Daten den Hauptinhalt repräsentieren, und verbietet Markup für Informationen, die für Leser verborgen sind. Riskante Beispiele:

• JSON-LD nennt 99 $, während die Seite „Kontakt aufnehmen“ zeigt.
• Schema meldet InStock, obwohl der Kauf deaktiviert ist.
• Markup deklariert fünf Fünf-Sterne-Bewertungen, die nicht angezeigt werden.
• FAQ-Antworten existieren nur im JSON-LD.
• Eine abgelaufene Stelle behält ein zukünftiges validThrough.

„Sichtbar“ heißt nicht, dass jede technische Eigenschaft zu rohem Seitentext werden muss. URLs, Bezeichner und Graph-Beziehungen dürfen Metadaten bleiben. Aussagen für Nutzer wie Preis, Bewertung, Veranstaltungsdetails, Fragen und Autor müssen der Erfahrung entsprechen.

Product-Schema offenbart Datenprobleme schnell

Preis und Lagerbestand ändern sich häufig. Product-Markup sollte in derselben Anfrage oder Pipeline wie die Oberfläche erzeugt werden. Vereinheitlichen Sie:

• Währung mit dem passenden ISO-Code.
• Numerische Preise ohne Währungssymbole in Datenfeldern.
• Availability mit der korrekten schema.org-URL.
• Angebote, die der richtigen Variante zugeordnet sind.
• Konsistente Canonicals der Varianten und Produkt-IDs.
• Ratings, die nur aus berechtigten Bewertungen dieses Produkts aggregiert werden.

Lesen Sie bei Produkten mit Varianten die aktuelle Dokumentation zu Produktvarianten, statt Farbe, Preis und SKU beliebig in einem Objekt zu kombinieren. Verkauft eine Seite den Artikel nicht oder hat sie kein echtes Angebot, erstellen Sie kein falsches Angebot, damit Fehler verschwinden.

LocalBusiness kann keine Standorte herstellen

Jeder Standort braucht einen echten Namen, eine Adresse, ein Telefon, Öffnungszeiten, ein Einzugsgebiet und eine URL. Seine Landingpage muss entsprechenden Wert bieten. 200 nahezu identische Stadtseiten anzulegen und LocalBusiness hinzuzufügen, schafft keine 200 Büros.

Schema-Angaben sollten mit Kontaktseiten, Unternehmensprofilen und verwalteten internen Daten übereinstimmen. Ändern sich Feiertagszeiten, aktualisieren Sie Oberfläche und JSON-LD aus derselben Quelle.

Bewertungen und Ratings sind Spam-Risikozonen

Nicht auszeichnen:

• Vom Unternehmen über sich selbst verfasste Bewertungen.
• Von einem anderen Produkt kopierte Ratings.
• Gesamtwerte ohne Quellbewertungen.
• Unternehmensweite Testimonials als Rating für jede Leistung.
• Versteckte Daten, die nur in Skripten vorkommen.

Verstöße gegen die Qualitätsrichtlinien können die Berechtigung für Rich Results entziehen und zu einer manuellen Maßnahme wegen strukturierter Daten führen. Das löscht nicht zwingend das gesamte Web-Ranking, doch das Risiko ist eine Reihe dekorativer Sterne nicht wert.

FAQ-Schema ist nicht für jeden Artikel Standard

Sichtbare FAQ können für Leser nützlich bleiben, doch Markup sollte nicht aktiviert werden, nur weil ein Plugin ein Kontrollkästchen bietet. Berechtigung und Verfügbarkeit können sich mit Zeit, Branche und Richtlinien ändern. Vor einem breiten Rollout:

1. Bestätigen Sie, dass der Typ in der Search Gallery bleibt und für die Website gilt.
2. Lesen Sie die vollständigen funktionsspezifischen Richtlinien.
3. Stellen Sie sicher, dass jede Frage und Antwort auf der Seite erscheint.
4. Vermeiden Sie identische FAQ auf Tausenden URLs.
5. Messen Sie Ergebnisse, statt „valid“ als Erfolg zu werten.

Schema sollte die redaktionelle Struktur nicht diktieren. Schreiben Sie eine FAQ, wenn Leser sie brauchen, und prüfen Sie dann, ob unterstütztes Markup passt.

In drei Ebenen testen

Ebene 1: JSON und Schema-Syntax

Ein Parser muss das JSON-LD lesen können: Kommas, Klammern, Escaping und Datentypen müssen stimmen. Ein nicht maskiertes Anführungszeichen in einem Produktnamen kann den ganzen Block ungültig machen.

Ebene 2: Rich Results Test

Dieses Tool prüft von Google unterstützte Typen und meldet Fehler und Warnungen. Beheben Sie Fehler; bewerten Sie Warnungen anhand tatsächlich verfügbarer Daten. „Valid“ bedeutet technisch berechtigt zum Testzeitpunkt, nicht garantiert angezeigt.

Ebene 3: Produktionsseite und Search Console

Prüfen Sie die bereitgestellte URL mit der URL-Prüfung, sehen Sie das tatsächliche HTML an und überwachen Sie die Rich-Result-Berichte. Ein Staging-Test kann nicht jeden Fehler bei Cache, Sprachversion, Feature-Flag, Einwilligung oder Live-Produktdaten aufdecken.

Führen Sie den SEO Checker aus, um Seitensignale stichprobenartig zu prüfen, und ein kostenloses SEO-Audit, um auffällige Metadaten- oder Canonical-Muster zu finden, bevor Sie dem Schema die Schuld geben.

Unvollständige und feindliche Daten testen

Ein Template sieht mit einem vollständigen Beispielprodukt oft perfekt aus und scheitert an den Rändern:

• Kein Bild.
• Preis null oder nicht veröffentlicht.
• Zwei Währungen.
• Namen mit Anführungszeichen und Zeilenumbrüchen.
• Fehlender Autor.
• Änderungsdatum vor dem Veröffentlichungsdatum nach einer Migration.
• Bewertungsanzahl null.
• Eingestelltes Produkt.
• Eine englische Seite, die unbeabsichtigt vietnamesische Organisationsdaten erhält.

Erstellen Sie Fixtures für diese Fälle. Prüfen Sie, dass das JSON parst, absolute URLs die richtige Sprachversion nutzen, Pflichteigenschaften nur bei Berechtigung erscheinen und ein Objekt entfällt, wenn wesentliche Daten fehlen.

Häufige Umsetzungsfehler

Zwei Plugins erzeugen dieselbe Entität

Das Theme gibt Article aus, ein SEO-Plugin BlogPosting und ein Bewertungs-Plugin ein weiteres Product mit anderer ID. Das Ergebnis enthält widersprüchliche Autoren, Bilder oder Bewertungen. Inventarisieren Sie jedes application/ld+json-Skript und weisen Sie jeder Entität einen Verantwortlichen zu.

Schema enthält Staging-URLs

Umgebungsvariablen oder Caches können @id, Bild und Canonical-URLs auf eine Testdomain zeigen lassen. Durchsuchen Sie das Produktions-HTML nach allen unerwarteten Hostnamen.

Sprachversionen werden vermischt

Eine englische Seite kann eine englische Überschrift, aber vietnamesische Breadcrumbs und Organisationsnamen haben. Legen Sie fest, welche Felder gemeinsam und welche lokalisiert sind; prüfen Sie inLanguage, wenn es verwendet wird.

JavaScript fügt Markup zu spät ein

Google kann JavaScript rendern, doch die Abhängigkeit von einer fehlschlagenden oder blockierten Client-Anfrage macht Daten weniger stabil. Besitzt der Server die Fakten bereits, ist JSON-LD im ursprünglichen HTML meist einfacher und verlässlicher.

Schema wird genutzt, um schwache Inhalte zu kaschieren

Detailliertes Markup kann eine leere Produktseite oder einen kopierten Artikel nicht ausgleichen. Strukturierte Daten beschreiben Wert; sie schaffen keinen Wert, der auf der Seite fehlt.

Nach dem Deployment überwachen

Behandeln Sie Schema wie einen Release-Vertrag:

• Generatoren per Unit-Test mit Fixtures prüfen.
• Haupttemplates validieren oder per Snapshot sichern.
• Staging und Produktion crawlen, um Elemente und Fehler zu zählen.
• Warnen, wenn die Markup-Abdeckung plötzlich sinkt.
• Berichte zu Verbesserungen und manuelle Maßnahmen beobachten.
• Release-Daten für Vergleiche von CTR, Impressionen und Fehlern festhalten.

Ändert Google die Unterstützung für einen Rich-Result-Typ, besteht kein Grund zur Panik und zum Entfernen jeder nützlichen schema.org-Aussage. Unterscheiden Sie Entitäts-Markup, das Inhalte klärt, von Markup, das nur für eine Suchfunktion gepflegt wird. Vergleichen Sie Wartungsaufwand und tatsächlichen Nutzen.

Checkliste vor der Veröffentlichung

• Repräsentiert der Typ den Hauptinhalt?
• Wird die Funktion in der aktuellen Google-Dokumentation unterstützt?
• Sind Pflichteigenschaften vollständig und aus echten Daten bezogen?
• Sind wichtige Aussagen für Besucher sichtbar?
• Sind URLs, Bilder und @id-Werte absolut, crawlbar und auf der richtigen Domain?
• Bezeichnen Canonical und mainEntityOfPage dieselbe strategische URL?
• Aktualisieren sich Datum, Preis, Verfügbarkeit und Rating automatisch?
• Erzeugt ein anderes Plugin ein doppeltes Objekt?
• Besteht der Rich Results Test?
• Können fehlende Daten das JSON ungültig machen?
• Wurden Produktion und Search Console geprüft?

Fazit

Gutes Schema Markup ist eine ehrliche, strukturierte Beschreibung sichtbarer Inhalte. Es beginnt beim Datenmodell und bei der Verantwortung für die Quellen, nicht bei einem kopierten JSON-LD-Schnipsel. Wählen Sie einen passenden Typ, nutzen Sie stabile Bezeichner, liefern Sie echte, vollständige Eigenschaften, testen Sie Randfälle und überwachen Sie nach dem Release.

Erfinden Sie keine Ratings, um Warnungen zu entfernen, zeichnen Sie keine versteckten Aussagen aus und versprechen Sie Rich Results nicht als Gewissheit. Werden Oberfläche und strukturierte Daten aus derselben Wahrheit erzeugt, wird Schema zu wartbarer Technik statt zu einer fragilen Dekorationsschicht.

Quellen: Einführung in strukturierte Daten von Google Search Central, allgemeine Richtlinien für strukturierte Daten und Schema.org-Dokumentation.