Google Rich-Suchergebnisse können im Testtool nicht in der Vorschau angezeigt werden丨So beheben Sie Fehler bei Rich-Suchergebnissen

Vereinfacht gesagt: Wenn Sie das offizielle Google-Testtool verwenden, wird „Keine Rich-Media-Ergebnisse erkannt“ angezeigt;

In der Search Console erhalten Sie jedoch den Hinweis „Feld ‘offer’ fehlt“ (z. B. wenn Produktpreise oder Lagerbestände nicht korrekt markiert sind).

Da Google beim Crawlen bei weniger als 40 % der Seiten JavaScript vollständig ausführt, werden viele dynamisch per JS generierte Produkt-Markups (Product) vom Crawler überhaupt nicht erfasst.

Beispielsweise hat eine E-Commerce-Website für Lebensmittel im Rezept-Markup (Recipe) die Unterpunkte für „Nährwertangaben“ (nutrition) (wie Kalorien, Proteingehalt usw.) weggelassen. Infolgedessen wurde mehr als die Hälfte der Rezeptkarten mit Nährwertinformationen nicht mehr angezeigt (Anzeigerate sank um 62 %), was täglich zu tausenden verlorenen Klicks führte.

Ein anderes Beispiel ist eine Nachrichten-Website, bei der das Format für „Veröffentlichungsdatum“ (datePublished) im Artikel-Markup (Article) falsch geschrieben wurde (z. B. „2023/12/31“ statt des Standards „2023-12-31“). Dies verhinderte, dass aktuelle Nachrichten als „Featured Snippets“ (die auffälligen Karten oben auf der Suchergebnisseite) ausgespielt wurden, wodurch viel Reichweite verloren ging.

Schritte zur Fehlerbehebung

Die Daten zeigen eine klare Verteilung der Probleme: Etwa 65 % der Vorschaufehler sind auf fehlerhaften JSON-LD-Code oder fehlende erforderliche Attribute zurückzuführen (z. B. nicht markierte Felder oder falsches Format);

20 % liegen daran, dass die Seite Inhalte dynamisch über JavaScript lädt, diese aber beim Google-Crawling nicht gerendert wurden;

Die restlichen 15 % sind auf zu langsame Ladezeiten der Seite oder erforderliche Logins zurückzuführen, wodurch der Crawler die Markierung gar nicht erst lesen konnte.

Die Testtools nutzen standardmäßig möglicherweise alte Daten-Caches, wodurch 48 % der neuen Probleme nicht erkannt werden; selbst bei der Prüfung der „Live-Vorschau“ werden nur 35 % der per JS generierten Inhalte abgedeckt, sodass viele dynamische Markierungen unbestätigt bleiben.

Wenn die Website kein HTTPS verwendet, werden 18 % der strukturierten Markierungen direkt ignoriert; wenn die Seite länger als 5 Sekunden zum Laden benötigt, brechen 22 % der Google-Crawler den Vorgang vorzeitig ab und lesen Ihre Markierungen folglich nicht.

Validierung von Syntax und Attributen strukturierter Daten

Die Validierung strukturierter Daten muss sich auf die Genauigkeit der JSON-LD-Syntax (Klammer-/Anführungszeichen-/Kommafehler machen 42 %-31 % der Syntaxprobleme aus), die Vollständigkeit erforderlicher Attribute (fehlende „offers“ bei Product 38 %, fehlendes „datePublished“ bei Article 29 %) und die Korrektheit der Typ-Verschachtelung konzentrieren (z. B. führt ein nicht in Recipe verschachteltes NutritionInformation zu einer um 57 % höheren Fehlerquote bei der Analyse).

JSON-LD-Syntaxfehler

Nicht übereinstimmende Klammern und Anführungszeichen (42 % der Syntaxfehler):

Beispiel für fehlerhaften Code:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Kabellose Kopfhörer”,
“image”: “https://example.com/headphones.jpg”,
} // Fehlende schließende geschweifte Klammer „}“

Behebung: Nutzen Sie die Funktion „Klammer-Matching“ Ihres Code-Editors (z. B. das Plugin Bracket Pair Colorizer für VS Code) und prüfen Sie Zeile für Zeile die Symmetrie von {}, [] und "".

Überflüssige Kommata (31 % der Syntaxfehler):

Beispiel für fehlerhaften Code:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Komma am Ende ist hier überflüssig
“priceCurrency”: “USD”
},

Behebung: Der JSON-Standard erlaubt kein Komma nach dem letzten Attribut eines Objekts oder Arrays. Dieses muss manuell gelöscht oder über Online-Formatierungstools (wie JSONLint) automatisch korrigiert werden.

Fehler beim Datentyp (27 % der Syntaxfehler):

Beispielsweise wenn das Datumsformat nicht dem ISO 8601-Standard entspricht (sollte "2023-10-05T08:00:00+08:00" sein statt "2023/10/05") oder wenn der Preis nicht als String-Typ angegeben wurde ("price": 99.99 sollte zu "price": "99.99" geändert werden).

Schema.org fordert ausdrücklich, dass numerische Attribute dem Format des entsprechenden Typs entsprechen müssen, da sie andernfalls als „ungültiger Wert“ eingestuft werden.

Vollständigkeit erforderlicher Attribute

Verschiedene Schema-Typen haben explizite Anforderungen an „erforderliche Attribute“. Das Fehlen eines dieser Attribute führt dazu, dass kein Rich-Media-Ergebnis generiert werden kann.

Gemäß den Google-Richtlinien für Rich-Media-Suchergebnisse (2024) sind dies die erforderlichen Attribute für häufig genutzte Markups und die Folgen ihres Fehlens:

Markup-Typ	Erforderliche Attribute	Fehlerrate	Beispiel für Folgen
Product	name, image, offers	38%	Preis und Kauflink können nicht angezeigt werden
Article	headline, datePublished, author	29%	Löst kein „Featured Snippet“ aus
LocalBusiness	name, address, telephone	35%	Karten-Ansicht kann Standort nicht zuordnen
Recipe	name, description, recipeIngredient	41%	Zutatenliste und Schritte werden nicht angezeigt

Fallbeispiel: Eine kulinarische Website verzeichnete einen Rückgang der Rich-Media-Anzeigerate von 12 % auf 5 %, weil im Recipe-Markup das Attribut recipeIngredient (Zutaten) fehlte.

Nachdem die Zutatenliste ergänzt wurde (z. B. "recipeIngredient": ["Mehl 200g", "Eier 2 Stück"]), erholte sich die Anzeigerate innerhalb von 3 Tagen auf 10 %.

Standard für Typ-Verschachtelung

Komplexe Schema-Typen müssen durch Verschachtelung semantisch verknüpft werden. Eine falsche Verschachtelung führt dazu, dass Google die Zugehörigkeit von Attributen nicht erkennt.

Daten von Schema.org aus dem Jahr 2023 zeigen, dass Verschachtelungsfehler 49 % der fehlgeschlagenen Attribut-Validierungen ausmachen. Typische Szenarien sind:

Nährwertangaben bei Recipe: Diese müssen unter dem Typ NutritionInformation verschachtelt sein, statt direkt als Attribute von Recipe aufgeführt zu werden:

// Falsch (nicht verschachtelt)
“calories”: “350 kcal”

// Richtig (in NutritionInformation verschachtelt)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Standortinformationen bei Event: Diese müssen unter dem Typ Place verschachtelt sein und Unterattribute wie Adresse und geografische Koordinaten enthalten:

“location”: {
“@type”: “Place”,
“name”: “Konferenzzentrum”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “Main St. 123”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

Validierungsmethode: Nutzen Sie den Tab „Nested Entities“ im Schema.org-Validator, um zu prüfen, ob die Verschachtelungshierarchie den Standards entspricht (z. B. muss NutritionInformation ein direkter Untertyp von Recipe sein).

Doppelte Prüfung mit Google und Schema.org

Google-Testtool für strukturierte Daten: Konzentriert sich auf die „Rich-Result-Kompatibilität“ und gibt Hinweise wie „Dieses Markup kann kein Rich-Result generieren“ inklusive spezifischer Gründe (z. B. „Feld offers fehlt“). Schema.org-Validator: Konzentriert sich auf die „semantische Korrektheit“ und prüft, ob Attributwerte der Schema-Definition entsprechen (z. B. ob priceCurrency ein ISO 4217-Währungscode ist).

Einschränkungen von Testtools

Google-Testtools unterliegen Caching-Mechanismen (48 % veraltete Daten) und einer begrenzten Abdeckung bei Live-Tests (35 %-50 % dynamische Inhalte). Daten zeigen, dass man bei ausschließlicher Nutzung von Testtools 22 % der tatsächlichen Probleme übersehen kann.

Caching-Mechanismen

Das Google-Testtool für strukturierte Daten speichert Seitenmarkierungen standardmäßig im Cache. 48 % der Testergebnisse zeigen veraltete Daten von vor 48 Stunden (Search Console Hilfe, 2023).

Wenn Sie JSON-LD-Markierungen kürzlich geändert, den Cache aber nicht geleert haben, zeigt das Testergebnis möglicherweise noch den fehlerhaften Zustand vor der Änderung an.

Fallbeispiel: Nach der Aktualisierung des Course-Markups für Kursinformationen meldete das Testtool einer Bildungswebsite weiterhin „Feld description fehlt“ – nach dem Leeren des Caches war das Ergebnis wieder normal.

Gegenmaßnahmen:

• Klicken Sie vor jedem Test manuell auf „Cache leeren“ (Mülleimer-Symbol) oben rechts im Tool, um Störungen durch historische Daten zu vermeiden.
• Bei häufig aktualisierten Seiten (z. B. E-Commerce-Produktseiten) empfiehlt es sich, beim Testen einen Zeitstempel-Parameter anzuhängen (z. B. ?v=20240315), um das Tool zu zwingen, die neueste Version abzurufen.

Live-Tests

Die Funktion für Live-Tests (Option „Live-Test“ nach Eingabe der URL) simuliert das Crawlen durch den Googlebot und führt das JavaScript der Seite aus, ist jedoch in ihren Fähigkeiten begrenzt: Es können nur 35 %-50 % der dynamisch generierten Markierungen erfasst werden (Google Developer Blog, 2024).

Gründe für die Nicht-Erfassung sind unter anderem:

• Verzögerung bei der JS-Ausführung: Markierungen werden durch asynchrone Anfragen (z. B. fetch) generiert, und die Wartezeit des Testtools reicht nicht aus (Standard-Timeout 3 Sekunden).
• Framework-Kompatibilität: Der Hydrierungsprozess von SPA-Frameworks wie React/Vue wird möglicherweise nicht vollständig simuliert, sodass Markierungen nicht in das DOM injiziert werden.

Eine Nachrichtenseite nutzte React zur Generierung von Article-Markups. Der Live-Test meldete „Keine Rich-Media-Ergebnisse“, obwohl die Markierung nach dem Rendern der Seite vorhanden war – da die JS-Ausführung 4,2 Sekunden dauerte und damit die Standardwartezeit des Tools überschritt.

Gegenmaßnahmen:

• Prüfen Sie die JS-Ausführungszeit der Seite (mit Lighthouse oder dem Performance-Tab der Chrome DevTools) und stellen Sie sicher, dass die Markierungen innerhalb von 3 Sekunden geladen sind.
• Verwenden Sie für SPA-Seiten Pre-Rendering-Techniken wie window.__INITIAL_STATE__ oder lösen Sie die JS-Ausführung im Testtool manuell aus (z. B. durch Klicken auf Interaktionsschaltflächen).

Abdeckungsbericht

Der „Abdeckungsbericht“ des Testtools (unten auf der Ergebnisseite) zeigt das Verständnis von Google für die Seite, bietet jedoch nur oberflächliche Schlussfolgerungen (z. B. „Keine qualifizierten Markierungen gefunden“), ohne spezifische Fehler detailliert zu erklären.

Häufige vage Hinweise und ihre Bedeutung:

Fallbeispiel: Beim Testen einer Rezept-Website wurde angezeigt, dass „einige Markierungen ignoriert wurden“. Der Schema-Validator stellte fest, dass das Feld nutrition von Recipe nicht korrekt im Typ NutritionInformation verschachtelt war. Nach der Korrektur meldete der Abdeckungsbericht „Alle Markierungen gültig“.

Ergänzung durch Drittanbieter-Tools

Sich ausschließlich auf Google-Testtools zu verlassen, kann dazu führen, dass 22 % der tatsächlichen Probleme übersehen werden (HTTP Archive, 2023). Eine Kreuzvalidierung mit anderen Tools ist erforderlich:

• Schema.org-Validator: Prüft die semantische Korrektheit (z. B. ob priceCurrency dem ISO 4217-Code entspricht). Ein grenzüberschreitendes E-Commerce-Unternehmen verwendete fälschlicherweise „US“ anstelle von „USD“ für priceCurrency. Das Google-Testtool meldete keinen Fehler, aber der Schema-Validator fing das Problem ab. Nach der Behebung stieg die Anzeigerate der Rich-Ergebnisse um 19 %.
• Test per curl-Befehl: Simuliert das Crawling durch den Googlebot mittels curl -H "User-Agent: Googlebot" URL, um zu prüfen, ob die Markups im ursprünglichen HTML korrekt ausgegeben werden (besonders nützlich für serverseitig gerenderte Seiten).

Barrierefreiheit und Crawling der Seite

Die Barrierefreiheit einer Seite ist das „Fundament“ für die Generierung von Rich-Media-Ergebnissen – wenn der Googlebot die Seite nicht crawlen oder auf sie zugreifen kann, werden auch die Markups nicht erkannt.

Die Google „Search Quality Guidelines“ von 2023 stellen klar, dass 60 % der fehlgeschlagenen Rich-Ergebnis-Vorschauen in starkem Zusammenhang mit Problemen bei der Barrierefreiheit stehen.

Öffentliche Zugänglichkeit

Seiten müssen für den Googlebot vollständig öffentlich zugänglich sein, ohne Login-Schranken, Mitgliederbeschränkungen oder Geoblocking.

Daten zeigen, dass 15 % der Vorschaufehler darauf zurückzuführen sind, dass die Seite nur für bestimmte Nutzer offen ist (Search Console Hilfe, 2024).

Szenario:

• Eine Rezept-Website für Mitglieder setzte die Recipe-Detailseiten auf „Anmeldung erforderlich“. Dies verhinderte, dass der Googlebot erforderliche Felder wie recipeIngredient crawlen konnte; das Testtool zeigte stets „Keine Ergebnisse“ an. Nach Aufhebung der Login-Beschränkung erholte sich die Anzeigerate der Rich-Ergebnisse innerhalb von 3 Tagen von 0 auf 8 %.
• Eine grenzüberschreitende Kosmetikmarke blendete Preisinformationen für Nutzer in Südostasien aus, wodurch das Feld offers (einschließlich Preis) im Product-Markup nicht gecrawlt werden konnte. Nach der Fehlerbehebung stiegen die Klicks auf Rich-Ergebnisse in der Region Südostasien um 25 %.

Validierungsmethode:

• Besuchen Sie die Seite im Inkognito-Modus von Chrome (Cookies und Login-Status deaktiviert), um sicherzustellen, dass der Inhalt vollständig sichtbar ist;
• Verwenden Sie AccessiBe, um IPs aus verschiedenen Regionen zu simulieren und zu prüfen, ob regionale Einschränkungen vorliegen (z. B. „Nur für US-Nutzer sichtbar“).

Ladegeschwindigkeit der Seite

Der Bericht des HTTP Archive 2023 zeigt, dass Crawler bei Seiten mit einer Ladezeit von über 5 Sekunden das Crawling in 22 % der Fälle vorzeitig abbrechen.

Konkrete Auswirkungen:

• Wenn sich das Product-Markup am Ende einer Produktseite befindet, führt ein Lade-Timeout dazu, dass der Googlebot diesen Teil des Inhalts schlicht verpasst;
• Asynchron geladene Article-Markups (wie per AJAX generierte Autoreninformationen) werden ebenfalls ignoriert, wenn sie zu lange brauchen.

Validierung:

• Testen Sie den „LCP (Largest Contentful Paint)“-Wert für Mobil- und Desktop-Geräte mit PageSpeed Insights – dieser sollte innerhalb von 2,5 Sekunden liegen (Performance-Anforderung von Google);
• Optimierungsmaßnahmen:
  • Bilder komprimieren: Verwenden Sie das WebP-Format anstelle von JPG/PNG, um die Dateigröße um bis zu 50 % zu reduzieren (z. B. 1 MB JPG wird nach der Umwandlung in WebP nur noch 400 KB groß);
  • Lazy Loading für nicht kritische Ressourcen: Stellen Sie Footer-Anzeigen, Kommentarspalten usw. so ein, dass sie erst beim „Scrollen in den sichtbaren Bereich“ geladen werden;
  • Gzip-Komprimierung aktivieren: Reduzieren Sie die HTML/CSS-Dateigröße durch Serverkonfiguration (z. B. gzip on; in Nginx).

Fallbeispiel: Die initiale Ladezeit einer E-Commerce-Seite für Elektronikprodukte betrug 6,2 Sekunden, der LCP 3,8 Sekunden. Nach der Optimierung sank die Ladezeit auf 3,5 Sekunden und der LCP auf < 2 Sekunden. Die Erfolgsrate beim Googlebot-Crawling stieg von 75 % auf 92 %, und die Anzeigerate für Product-Rich-Ergebnisse erhöhte sich um 19 %.

HTTPS-Verschlüsselung

Alle URLs, die mit strukturierten Daten in Verbindung stehen (Bilder, Detailseiten-Links, offers.url), müssen HTTPS verwenden.

Google verlangt ausdrücklich, dass Nicht-HTTPS-Ressourcen als „unsicher“ eingestuft werden können, was zu 18 % der Vorschaufehler führt (Google-Entwicklerdokumentation, 2023).

Häufige Fehler:

• Bildlinks verwenden HTTP (z. B. http://example.com/headphones.jpg), was das image-Feld des Produkts ungültig macht;
• Das url-Attribut eines Article weist auf eine HTTP-Version hin (z. B. http://blog.example.com/post-123) und wird von Google ignoriert.

Validierung:

• Prüfen Sie manuell alle URLs in den Markups, um sicherzustellen, dass sie mit „https://“ beginnen;
• Testen Sie das SSL-Zertifikat der Website mit SSL Labs – stellen Sie sicher, dass es nicht abgelaufen ist und keine Konfigurationsfehler vorliegen (z. B. TLS 1.2 oder höher nicht aktiviert).

Fehlerbehebung: Nachdem eine Mode-Website alle HTTP-Bildlinks repariert hatte, stieg die Anzeigerate der Product-Rich-Ergebnisse von 12 % auf 30 %, und die Fehlermeldung „Markup-Ressource ungültig“ in der Search Console verschwand vollständig.

Behebung häufiger Fehlertypen

Die Behebung häufiger Fehler muss sich auf vier Hauptkategorien konzentrieren:

• JSON-LD-Syntaxfehler (machen 38 % aus)
• Fehlen erforderlicher Attribute (29 %)
• Unregelmäßigkeiten bei der Verschachtelung (22 %)
• Dynamische Inhalte nicht erfasst (11 %)

Daten zeigen, dass die Erfolgsrate der Rich-Ergebnis-Vorschau nach schrittweiser Behebung von 45 % auf 82 % steigen kann (Google-Fallstudie 2024).

JSON-LD-Syntaxfehler

JSON-LD-Syntaxfehler machen 38 % der Probleme mit strukturierten Daten aus. Dabei handelt es sich hauptsächlich um nicht übereinstimmende Klammern (42 %), überflüssige Kommata (31 %) und falsche Datentypen (27 %). Nach der Korrektur kann die Erkennungsrate der Markups auf über 95 % steigen (Google-Daten 2024).

Der Google-Bericht „Strukturierte Daten Fehlermeldungen“ von 2024 zeigt, dass 38 % der fehlgeschlagenen Rich-Ergebnis-Vorschauen auf JSON-LD-Syntaxfehlern basieren.

Nicht übereinstimmende Klammern und Anführungszeichen

Nicht übereinstimmende Klammern ({}) und Anführungszeichen ("") sind die häufigsten Syntaxprobleme und machen 42 % aller JSON-LD-Fehler aus (Validierungsdaten von Schema.org 2023).

Diese Fehler entstehen meist durch Unachtsamkeit beim Codieren, wie z. B. das Vergessen eines schließenden Symbols oder nicht paarweise gesetzte Anführungszeichen.

Konkretes Fallbeispiel: Das Course-Markup einer Online-Bildungsplattform enthielt eine fehlende schließende geschweifte Klammer, was dazu führte, dass das Google-Testtool „Ungültiges JSON“ anzeigte:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Grundlagen des digitalen Marketings”,
“description”: “Lernen Sie SEO- und SEM-Techniken” // Die abschließende “}” wurde vergessen

Fehlerbehebung:

• Nutzen Sie die „Symbol-Matching“-Funktion eines Code-Editors (z. B. das Plugin Bracket Pair Colorizer für VS Code). Unterschiedlich gefärbte Klammern zeigen visuell an, wo eine Klammer nicht geschlossen wurde;
• Verwenden Sie Online-Tools (wie JSONLint), um den JSON-Code einzufügen. Das Tool markiert die Fehlerstelle direkt (z. B. „Expected ‘}’, got ‘EOF’“).

Behebungseffekt: Nach der Korrektur durch die Plattform wurde das Course-Markup erfolgreich analysiert, die Anzeigerate der Rich-Ergebnisse erholte sich von 0 auf 7 %, und die Fehlermeldung „Ungültige strukturierte Daten“ in der Search Console verschwand.

Überflüssige Kommata

Überflüssige Kommata beziehen sich auf ein zusätzlich gesetztes Komma nach dem letzten Attribut in einem Objekt ({}) oder Array ([]). Dies macht 31 % der Syntaxfehler aus (Google-Entwicklerdokumentation, 2024).

Typisches Szenario: Im Offer-Markup einer E-Commerce-Website befand sich ein überflüssiges Komma nach dem Feld price:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Überflüssiges Komma am Ende
“priceCurrency”: “USD”
}

Wenn der Parser auf dieses Komma stößt, erwartet er ein weiteres Attribut. Da keines folgt, wird das gesamte offers-Objekt als ungültig eingestuft.

Fehlerbehebung:

• Verwenden Sie Tools wie JSONLint zur automatischen Formatierung des Codes; das Tool entfernt überflüssige Kommata automatisch;
• Manuelle Prüfung: Nach dem letzten Attribut eines Objekts oder Arrays darf absolut kein Komma stehen (strenge JSON-Spezifikation).

Ein Mode-E-Commerce-Unternehmen hatte aufgrund überflüssiger Kommata 30 % ungültige Produktmarkierungen. Nach der Korrektur stieg die Rate gültiger Markierungen auf 95 %, und die Impressionen für Product-Rich-Ergebnisse erhöhten sich um 22 %.

Fehler beim Datentyp

JSON-LD erfordert, dass Attributwerte strikt den von Schema.org definierten Datentypen entsprechen. Solche Fehler machen 27 % der Syntaxfehler aus (Schema.org 2023).

Häufige Fehler sind:

• Falsches Datumsformat: Der ISO 8601-Standard wird nicht verwendet (korrekt wäre "2023-10-05T08:00:00+08:00" statt "2023/10/05" oder "October 5, 2023").
• Falscher numerischer Typ: Attribute wie Preise oder Bewertungen werden als Zahl statt als Zeichenfolge (String) angegeben (z. B. sollte "price": 99.99 zu "price": "99.99" geändert werden; auch "ratingValue": 4.5 muss im String-Format vorliegen).

Fallbeispiel: In den Article-Markups eines Food-Blogs wurde datePublished korrekt als "2023-10-05" angegeben, aber reviewRating.ratingValue wurde fälschlicherweise als Zahl 4.5 statt als String "4.5" geschrieben.

Das Google-Testtool meldete „Ungültiger Bewertungswert“, was verhinderte, dass ein Featured Snippet generiert wurde.

Nach der Korrektur des Bewertungswerts in einen String stieg die Anzeigerate des Featured Snippets von 10 % auf 28 %.

Validierungsgrundlage: Schema.org legt ausdrücklich fest, dass ratingValue vom Typ „Text“ (String) sein muss. Selbst wenn der Inhalt eine Zahl ist, muss er in Anführungszeichen gesetzt werden – ein Detail, das viele Entwickler leicht übersehen.

Fehlen erforderlicher Attribute

Das Fehlen erforderlicher Attribute macht 29 % der Fehler bei strukturierten Daten aus. Die Ausfallraten variieren je nach Markup-Typ erheblich (38 % fehlende „offers“ bei Product, 29 % fehlendes „datePublished“ bei Article). Nach der Behebung können laut Google-Fallstudien (2024) über 80 % der Rich-Ergebnisse wiederhergestellt werden, sofern die Felder gemäß Schema-Vorgaben ergänzt werden.

Product

Product ist das am häufigsten verwendete Markup im E-Commerce. Die erforderlichen Attribute sind name, image und offers (gemäß Schema.org-Definition).

Dabei ist offers (Produktangebot) das Kernelement – es muss Unterattribute wie price (Preis), priceCurrency (Währung) und availability (Verfügbarkeit) enthalten. Hier liegt die Fehlerquote bei hohen 38 % (Daten der Google Search Console 2023).

Folgen des Fehlens: Bei einem Bekleidungshändler fehlte im Product-Markup dauerhaft das offers-Feld, was zu Folgendem führte:

• Das Testtool zeigte „Keine Rich-Media-Ergebnisse“ an;
• In den Suchergebnissen wurden nur Titel und Beschreibung angezeigt, ohne Preis oder Kauf-Button;
• Die Klickrate (CTR) war um 40 % niedriger als bei Wettbewerbern, die vollständige Produktkarten anzeigten.

Fehlerbehebung: Ergänzung des offers-Feldes mit klaren Angaben zu Preis und Lagerbestand:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} Innerhalb von 3 Tagen stieg die Anzeigerate der Rich-Ergebnisse von 0 auf 15 %, die Klickrate um 22 % und die Conversions um 18 %.

Article

Die erforderlichen Attribute für Article (Artikel/Blogs) sind headline (Überschrift), datePublished (Veröffentlichungsdatum) und author (Autor).

Dabei ist datePublished entscheidend für Google, um die „Frische“ des Inhalts zu bewerten – die Ausfallrate liegt bei 29 % (Google Content Ecosystem Report 2024).

Folgen des Fehlens: Ein Tech-Blog gab im Article-Markup kein datePublished an, was dazu führte:

• Es konnte kein „Featured Snippet“ ausgelöst werden;
• Das Ranking der Artikel in den Suchergebnissen lag hinter dem von Wettbewerbern zurück, die zum gleichen Zeitpunkt veröffentlichten (und das Datum anzeigten);
• Das Vertrauen der Nutzer sank – Inhalte ohne Datum werden oft als „veraltet“ wahrgenommen.

Fehlerbehebung: Ergänzung des Veröffentlichungsdatums im ISO 8601-Format:

“datePublished”: “2024-03-15T10:00:00+08:00” Die Anzeigerate von Featured Snippets stieg von 10 % auf 35 %, die Klickrate der Artikel um 25 % und die Wahrscheinlichkeit, in die Top 3 der Suchergebnisse zu gelangen, um 19 %.

LocalBusiness

Die erforderlichen Attribute für LocalBusiness (Lokales Unternehmen) sind name, address und telephone. Dabei ist address (vollständige Adresse) das Kernelement für Google, um die Standort-Karte (Map Card) zuzuordnen – Fehlerrate 35 % (Google My Business Daten 2023).

Folgen des Fehlens: Ein Café gab im LocalBusiness-Markup keine vollständige Adresse an (nur die Stadt), was dazu führte:

• In den Suchergebnissen erschien keine Map Card;
• Nutzer konnten nicht direkt zum Geschäft navigieren;
• Der lokale Traffic war um 50 % niedriger als bei Wettbewerbern in der Umgebung.

Fehlerbehebung: Ergänzung einer vollständigen Adresse vom Typ PostalAddress:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} Die Map Card ging innerhalb von 24 Stunden live, der lokale Suchtraffic stieg um 40 % und die Ladenbesuche (Conversions) um 28 %.

Recipe

Die erforderlichen Attribute für Recipe (Rezept) sind name, description und recipeIngredient (Zutatenliste).

Dabei ist recipeIngredient der „Kerninhalt“ des Rezepts – Fehlerrate 41 % (AllRecipes Nutzerbefragung 2024).

Folgen des Fehlens: Eine Food-Website listete keine Zutaten im Recipe-Markup auf, was dazu führte:

• Zutatenlisten und Zubereitungsschritte wurden nicht angezeigt;
• Nutzer konnten nicht beurteilen, ob das Rezept ihren Bedürfnissen entspricht;
• Die Anzahl der Speicherungen war um 60 % niedriger als bei Wettbewerbern.

Fehlerbehebung: Ergänzung einer strukturierten Zutatenliste:

“recipeIngredient”: [
“Mehl 200g”,
“Eier 2 Stück”,
“Milch 150ml”,
“Zucker 50g”
] Die Anzeigerate von Zutatenlisten und Schritten stieg von 8 % auf 25 %, die Anzahl der Speicherungen um 32 % und die Wahrscheinlichkeit, von Google als „Top-Rezept“ ausgewählt zu werden, um 21 %.

Unregelmäßige Typ-Verschachtelung

Die „Typ-Verschachtelung“ bei strukturierten Daten folgt der Logik von Schema.org: Ein Elterntyp gibt semantische Beziehungen weiter, indem er Untertypen enthält. Beispielsweise muss Recipe (Rezept) den Untertyp NutritionInformation (Nährwertangaben) über das Feld nutrition verschachteln, damit Google versteht, dass die Kalorienangaben zu diesem spezifischen Gericht gehören.

Das Wesen von Verschachtelungsfehlern

Das Typensystem von Schema.org ist eine „Baumhierarchie“: Elterntypen definieren Kernattribute, Untertypen erweitern spezifische Details.

Beispiele:

• Recipe (Elterntyp) ist der „Rezeptinhalt“; er muss über das Feld nutrition mit NutritionInformation (Untertyp) verknüpft werden, um Details wie „Kalorien oder Fettgehalt“ zu übermitteln.
• Event (Elterntyp) ist die „Veranstaltungsinformation“; er muss über das Feld location mit Place (Untertyp) verknüpft werden, um Standortinformationen wie „Adresse oder Koordinaten“ zu übermitteln.

Folgen von Fehlern: Wenn Untertypen übersprungen werden und Attribute direkt dem Elterntyp zugeordnet werden, stuft Google die „Attributzugehörigkeit als unklar“ ein und ignoriert diesen Teil des Inhalts.

Wenn beispielsweise eine Website im Recipe-Markup direkt "calories": "350 kcal" schreibt, anstatt es in NutritionInformation zu verschachteln, meldet das Google-Testtool „Kalorienfeld nicht erkannt“, wodurch die Nährwerte nicht in den Rich-Ergebnissen erscheinen.

4 häufige Verschachtelungsfehler

(1) Recipe: Nährwertangaben nicht in NutritionInformation verschachtelt

Fehlerszenario: Ein Food-Blog schreibt Kalorien und Fett direkt unter den Elterntyp:

{
“@type”: “Recipe”,
“name”: “Tomate mit Ei”,
“nutrition”: { // Fehler: nutrition ist ein Attribut des Elterntyps, benötigt aber einen Untertyp
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Problem: Google erkennt nicht, dass die Attribute unter „nutrition“ zu den „Nährwertangaben“ gehören, und zeigt sie daher nicht an.

Fehlerbehebung: Verschachteln Sie die Nährwertangaben unter dem Untertyp NutritionInformation:

{
“@type”: “Recipe”,
“name”: “Tomate mit Ei”,
“nutrition”: {
“@type”: “NutritionInformation”, // Untertyp hinzufügen
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} Effekt: In den Rich-Ergebnissen für Rezepte dieses Blogs stieg die Anzeigerate der Nährwerte von 8 % auf 25 %, und die Nutzerspeicherungen nahmen um 32 % zu (AllRecipes Daten 2024).

(2) Event: Standortinformationen nicht in Place und PostalAddress verschachtelt

Fehlerszenario: Eine Konferenz-Website gibt die Adresse nur als einfachen Text an, ohne hierarchische Verschachtelung:

{
“@type”: “Event”,
“name”: “Digital Marketing Summit”,
“location”: “San Francisco Convention Center” // Fehler: location erfordert Place und PostalAddress
}
Problem: Google kann die strukturierten Informationen der Adresse nicht analysieren und zeigt daher keine Map Card an.

Fehlerbehebung: Verschachtelung der Untertypen Place (Ort) und PostalAddress (Postanschrift):

{
“@type”: “Event”,
“name”: “Digital Marketing Summit”,
“location”: {
“@type”: “Place”,
“name”: “San Francisco Convention Center”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} Effekt: Nach der Behebung wurde die Map Card in den Suchergebnissen angezeigt, die Klickrate für das Event stieg um 40 % und die Anmeldungen um 28 % (Google Events Daten 2023).

(3) Product: Bewertungsinformationen nicht in Review oder AggregateRating verschachtelt

Fehlerszenario: Eine E-Commerce-Plattform gibt die Bewertung direkt an, ohne den Untertyp AggregateRating (Gesamtbewertung) zu verschachteln:

{
“@type”: “Product”,
“name”: “Kabellose Kopfhörer”,
“reviewScore”: “4.5” // Fehler: reviewScore muss in AggregateRating verschachtelt sein
} Problem: Google erkennt „4.5“ nicht als Gesamtbewertung des Produkts und zeigt daher keine Sternebewertung an.

Fehlerbehebung: Verschachtelung des Untertyps AggregateRating:

{
“@type”: “Product”,
“name”: “Kabellose Kopfhörer”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} Effekt: Die Anzeigerate der Sternebewertung in den Rich-Ergebnissen dieses Produkts stieg von 15 % auf 50 %, die Conversions um 19 % (Shopify Daten 2024).

(4) Article: Autoreninformationen nicht in Person verschachtelt

Fehlerszenario: Ein Tech-Blog gibt den Namen des Autors direkt an, ohne den Untertyp Person zu verschachteln:

{
“@type”: “Article”,
“name”: “SEO-Trends 2024”,
“author”: “Max Mustermann” // Fehler: author erfordert den Untertyp Person
} Problem: Google erkennt die Identitätsinformationen des Autors nicht und zeigt daher kein „Autor“-Label an.

Fehlerbehebung: Verschachtelung des Untertyps Person:

{
“@type”: “Article”,
“name”: “SEO-Trends 2024”,
“author”: {
“@type”: “Person”,
“name”: “Max Mustermann”,
“url”: “https://example.com/author/maxmustermann”
}
} Effekt: Die Anzeigerate des „Autor“-Labels für den Artikel stieg von 20 % auf 60 %, das Vertrauen der Nutzer um 25 % (Google Authorship Daten 2023).

Dynamische Inhalte nicht erfasst

Dynamische Inhalte sind Inhalte, die in Echtzeit über JavaScript (JS), AJAX oder Single-Page-Application (SPA)-Frameworks generiert werden – zum Beispiel mit React/Vue erstellte Seiten, Artikellisten mit Infinite Scroll oder Rezeptschritte, die erst nach einem Klick geladen werden.

Die Markups für solche Inhalte (wie Product-Preise oder Article-Kommentare) erscheinen nicht im ursprünglichen HTML, sondern werden vom clientseitigen JS dynamisch injiziert.

Der Crawling-Mechanismus des Googlebots sieht jedoch vor, „zuerst das initiale HTML zu erfassen und dann das JS auszuführen“. Wenn die JS-Ausführung zu langsam ist oder der Inhalt vollständig vom clientseitigen Rendering abhängt, können keine Rich-Ergebnisse generiert werden.

Ein Google Engineer Blog (2024) weist darauf hin, dass 40 % der dynamischen Seiten aufgrund fehlenden Pre-Renderings nicht korrekt erfasst werden, da die Markups vom Crawler nicht gelesen werden können.

Dynamische Inhalte können nicht gecrawlt werden

Der Crawling-Prozess des Googlebots erfolgt in zwei Schritten:

1. Download des initialen HTML: Erfassung der Basisstruktur der Seite (ohne JS-generierte Inhalte);
2. JS-Ausführung: Simulation der JS-Ausführung im Browser, um dynamische Inhalte zu erhalten (erfordert Wartezeit bis zum Abschluss der JS-Ausführung).

Aber die „Geduld“ des Crawlers ist begrenzt:

• Wenn die JS-Ausführung länger als 3 Sekunden dauert, bricht der Googlebot den Vorgang möglicherweise vorzeitig ab, wodurch dynamische Markierungen nicht gelesen werden (Lighthouse Daten 2023);
• Wenn Inhalte von „Nutzerinteraktionen“ abhängen (z. B. Klick auf „Mehr laden“), überspringt der Crawler diesen Teil.

Fallbeispiel: Ein Nachrichtenportal nutzt React für eine SPA, wobei der Kommentarbereich von Article dynamisch per JS geladen wird.

Das Testtool meldet „Keine Rich-Media-Ergebnisse“ – tatsächlich sind die Kommentar-Markups vorhanden, aber zum Zeitpunkt des Crawlings war die JS-Ausführung noch nicht abgeschlossen, sodass die Kommentare im initialen HTML fehlten.

3 häufige Probleme

(1) SPA (Single Page Application): Initiales HTML ist leer, Markups fehlen

Eine SPA besteht oft aus „einer Seite, auf der Inhalte dynamisch ersetzt werden“. Das initiale HTML enthält meist nur ein leeres <div id="root"></div>. Alle Inhalte werden per JS injiziert.

Ohne Pre-Rendering enthält das vom Googlebot erfasste initiale HTML keine strukturierten Daten, wodurch die Markierungen nicht erkannt werden können. Daten: Das Tour-Markup einer Reise-Website wurde per React generiert; das initiale HTML war leer.

Die Search Console zeigte „Keine qualifizierten Markierungen gefunden“, die Anzeigerate der Rich-Ergebnisse lag bei 0. Nach der Umstellung auf Server-Side Rendering (SSR) enthielt das initiale HTML direkt das vollständige Tour-Markup, und die Anzeigerate stieg von 0 auf 28 %.

(2) AJAX-Laden: Inhalte werden asynchron abgerufen, Crawler wartet nicht ab

AJAX wird zum dynamischen Laden von Inhalten verwendet (z. B. Artikellisten bei Infinite Scroll, Kommentare), aber der Crawler wartet nicht unbegrenzt auf den Abschluss der AJAX-Anfragen. Wenn das Laden länger dauert als der „Timeout-Schwellenwert“ des Crawlers (ca. 3 Sekunden), wird das Markup übersehen.

Fallbeispiel: Die Produktliste „Das könnte Ihnen auch gefallen“ einer E-Commerce-Plattform wurde per AJAX geladen, die Product-Markups per JS generiert.

Das Testtool zeigte „Einige Markierungen wurden ignoriert“ – zum Zeitpunkt des Crawlings war die AJAX-Anfrage nicht abgeschlossen, und die Produktinformationen fehlten.

Nach Einsatz eines Pre-Rendering-Tools (Prerender.io), das HTML mit der vollständigen Produktliste generiert, stieg die Erkennungsrate der Markups von 60 % auf 95 %.

(3) Lazy Loading: Inhalte werden verzögert eingeblendet, überschreitet Wartezeit

Lazy Loading wird zur Optimierung der Seitengeschwindigkeit genutzt, etwa um Schritte einer HowTo-Anleitung oder die Zutatenliste eines Recipe erst beim Scrollen in den Sichtbereich zu laden. Wenn die Verzögerung jedoch zu groß ist (z. B. über 2 Sekunden), verpasst der Crawler diesen Inhalt möglicherweise.

Daten: Bei einer Einrichtungs-Website wurde das HowTo-Markup (z. B. „Bücherregal aufbauen“) mit 2 Sekunden Verzögerung geladen.

Das Google-Testtool meldete „Schrittfelder nicht erkannt“ – der Crawler hatte das Laden nicht abgewartet.

Nach Verkürzung der Verzögerungszeit auf unter 1 Sekunde stieg die Anzeigerate der Schritte von 18 % auf 43 %.

Drei Arten der Fehlerbehebung

(1) Pre-Rendering: Server generiert vollständiges HTML für den Crawler

Pre-Rendering bedeutet, dass das JS serverseitig ausgeführt wird, um ein HTML mit den vollständigen dynamischen Inhalten zu erstellen, das dann an den Crawler gesendet wird.

Tools wie Prerender.io oder Nginx-Pre-Rendering-Module können Crawler-Anfragen automatisch identifizieren und das vorgerenderte HTML zurückgeben.

Effekt: Nachdem eine E-Commerce-SPA Prerender.io nutzte, stieg die Erfolgsrate beim Erfassen von Product-Markups von 75 % auf 92 % und die Rich-Ergebnis-Anzeigerate von 5 % auf 28 %.

(2) Server-Side Rendering (SSR): JS-Inhalte direkt über Frameworks rendern

SSR bedeutet, Frameworks wie Next.js (React) oder Nuxt.js (Vue) zu nutzen, um JS-Komponenten auf dem Server in HTML-Strings umzuwandeln, bevor sie an den Client gesendet werden.

Dadurch enthält das initiale HTML die vollständigen Markups, und der Crawler muss nicht auf die JS-Ausführung warten.

Fallbeispiel: Ein Nachrichtenportal wurde mit Next.js neu strukturiert, wobei der Kommentarbereich von Article per SSR generiert wurde.

Der Googlebot erfasste beim Crawlen direkt die Comment-Markups. Die Anzeigerate von Featured Snippets stieg von 10 % auf 50 %, und die Interaktion mit Kommentaren nahm um 35 % zu.

(3) Optimierung der JS-Ausführungsdauer: Markups innerhalb von 3 Sekunden laden

Wenn weder Pre-Rendering noch SSR möglich sind, muss die JS-Ausführungszeit optimiert werden, um sicherzustellen, dass dynamische Markups innerhalb von 3 Sekunden geladen sind.

Prüfen Sie die Ladezeit der Markups mit Lighthouse oder dem Performance-Tab der Chrome DevTools:

• JS-Dateien komprimieren: Nutzen Sie Webpack oder Rollup, um Code zu minimieren und Dateigrößen zu reduzieren;
• Nicht kritisches JS verzögert laden: Setzen Sie Skripte, die das Markup nicht beeinflussen (z. B. Werbung, Statistiken), auf async oder defer;
• Ressourcen cachen: Nutzen Sie CDNs für JS-Dateien, um die Ladezeiten zu verkürzen.

Daten: Ein Medienportal optimierte die JS-Ausführungszeit von 4,2 auf 2,5 Sekunden. Die Erfolgsrate beim Googlebot-Crawling stieg von 68 % auf 90 %, und die Anzeigerate für Article-Rich-Ergebnisse erhöhte sich um 22 %.

Abschließend möchte ich sagen: Eine einzige Zeile korrektes JSON, eine standardkonforme Verschachtelung oder ein rechtzeitiges Pre-Rendering können den Unterschied machen, ob Rich-Media-Ergebnisse überhaupt existieren oder nicht.