SEO Schema JSON-LD mit Codex: kopierbares SKILL.md und Prüfworkflow

Kurz gesagt: Schema sollte eine strukturierte Kopie der Seitenfakten sein

Wenn Sie nach einem Codex-SKILL.md-Prompt für SEO Schema JSON-LD suchen, finden Sie weiter unten eine kopierbare Vorlage. Wichtiger als der Code ist die Grundregel: Strukturierte Daten sollen Fakten ausdrücken, die Besucher auf der Seite selbst überprüfen können. Sie sind kein Anlass, ein möglichst umfangreiches JSON-Objekt zu erzeugen.

Codex kann die Seite, ihre Inhaltsdaten und vorhandenes Markup prüfen, bevor ein Typ empfohlen oder JSON-LD geschrieben wird. Diese Reihenfolge ist entscheidend. Eine unscharfe Aufforderung wie „Füge alles mögliche Schema hinzu“ führt leicht zu erfundenen aggregateRating-Werten, Preisen, Autoren oder Veröffentlichungsdaten. Solche Felder können syntaktisch korrekt sein und die Seite trotzdem falsch darstellen.

Google empfiehlt JSON-LD, wenn die Website-Konfiguration es zulässt, weil es meist leichter zu implementieren und zu pflegen ist. Google verlangt zugleich, dass das Markup die jeweilige Seite beschreibt, sichtbare Inhalte abbildet und korrekt bleibt. Ein bestandener Rich Results Test garantiert kein erweitertes Suchergebnis.

Wählen Sie den Haupttyp der Seite vor unterstützenden Objekten

Beginnen Sie mit einer einfachen Frage: Was betrachtet der Besucher hauptsächlich? Die Antwort bestimmt den primären Schema.org-Typ. Breadcrumbs, Organisationsdaten und Videos können das Hauptobjekt nur ergänzen, wenn sie sichtbare Informationen derselben Seite beschreiben.

Schema.org bietet ein deutlich größeres Vokabular als Googles Rich-Result-Funktionen. Für Google Search ist die aktuelle Search-Central-Dokumentation der Zielfunktion maßgeblicher als die bloße Existenz einer Eigenschaft bei Schema.org.

Beginnen Sie mit dem Seitenzweck. Der Typ folgt den sichtbaren Fakten, nicht umgekehrt.

Ein sicherer Codex-Workflow hat vier Prüfpunkte

1. Fakteninventar. Verwenden Sie nur sichtbaren Seitentext, verlässliche CMS-Felder, die auf der Seite gerendert werden, oder ausdrücklich bestätigte Daten. Markieren Sie jedes Feld als bestätigt, fehlend oder menschlich zu prüfen.
2. Typentscheidung. Wählen Sie einen Haupttyp, der zum zentralen Seitenzweck passt. Erklären Sie Alternativen, statt alle denkbaren Typen zu stapeln.
3. Code und Zuordnung. Erzeugen Sie JSON-LD mit einer Quelle für jeden ausgegebenen Wert. Lassen Sie unbekannte Eigenschaften weg, statt Platzhalter zu erfinden.
4. Validierung und Veröffentlichung. Prüfen Sie JSON-Syntax, funktionsspezifische Anforderungen, das gerenderte DOM, URL Inspection und den passenden Search-Console-Bericht.

Der folgende Skill schreibt diese Prüfpunkte fest. Codex auditiert zuerst und ändert erst danach Code. So lässt sich verhindern, dass scheinbar valides Markup vom sichtbaren Seiteninhalt abweicht.

Kopierbarer SEO Schema JSON-LD Codex Skill (SKILL.md)

Speichern Sie den folgenden Block als Skill-Konfiguration. Er enthält keine Computerverzeichnisse, Benutzernamen, Zugriffstoken, Umgebungsvariablenwerte oder privaten Pfade. Codex wird außerdem angewiesen, sensible Informationen aus der Ausgabe zu entfernen.

---
name: seo-schema-jsonld
description: Audit visible page facts, recommend accurate Schema.org JSON-LD, implement it safely, and validate it against Google structured-data requirements.
---

# SEO Schema JSON-LD

Use this skill when a user asks to add, repair, review, or validate Schema.org JSON-LD / structured data for a website page, template, CMS entry, or component.

## Primary rule

Treat structured data as a structured representation of the page's user-visible facts. Never use it to invent, hide, exaggerate, or imply information that the page does not support.

## Privacy and output safety

- Never print absolute local paths, home directories, usernames, credentials, tokens, cookies, API keys, environment-variable values, private URLs, or repository-specific secrets.
- Refer to files with short, project-relative labels when needed, such as `src/pages/article.tsx` or `the page template`.
- Do not copy sensitive values into JSON-LD, examples, logs, commit messages, screenshots, or explanations.
- If input contains secrets or private identifiers, omit them and state that sensitive values were excluded.

## Required workflow

### 1. Inspect before generating

Read the relevant page, template, content data, and any existing structured data. Build a fact inventory using only:

- visible page text and user-visible UI;
- trusted CMS fields that are rendered on that page;
- verified product, organization, author, or breadcrumb data supplied by the user.

For every candidate property, label it `confirmed`, `missing`, or `needs human confirmation`. Do not infer missing values from brand names, URLs, conventions, or unrelated pages.

### 2. Choose the narrowest suitable type

Identify the page's primary purpose first. Recommend one primary Schema.org type that truthfully describes it. Add supporting objects only when they also describe user-visible information on the same page.

Explain the recommended primary type, supporting types, why each applies, and types deliberately rejected.

For Google rich-result eligibility, consult the current Google Search Central documentation for the target feature. Schema.org support alone does not establish Google feature support.

### 3. Apply strict data guardrails

Never generate these values unless they are confirmed and visible or otherwise explicitly verified by the user:

- `aggregateRating`, `review`, or review counts;
- price, currency, availability, offer dates, shipping, or return policy;
- author, publisher, logo, address, phone, social profile, or `sameAs`;
- publication dates, modification dates, images, video duration, or interaction counts;
- FAQ questions and answers that are not visibly present;
- event, job, medical, financial, legal, or local-business claims.

Never add misleading `FAQPage`, fake reviews, hidden content, keyword lists, or unrelated types. Prefer fewer complete and accurate properties over many uncertain ones.

### 4. Produce the implementation

Return these sections in order:

1. `Fact inventory` - property, value or status, and visible source.
2. `Schema decision` - primary type, supporting types, assumptions, and exclusions.
3. `JSON-LD` - valid JSON inside one `application/ld+json` script block. Use placeholders only in a clearly labeled illustrative example; never present placeholders as production-ready values.
4. `Implementation note` - the safe insertion point for the site's framework or CMS, without exposing private paths.
5. `Validation checklist` - syntax, rendered-page check, Google Rich Results Test when applicable, Schema Markup Validator, URL Inspection after deployment, and Search Console monitoring.
6. `Open questions` - every field that needs a human decision.

If editing code is requested, make the smallest scoped change. Preserve existing valid markup, avoid duplicate entities, and explain any conflict before replacing it.

## JSON-LD quality checks

Before finalizing, verify all of the following:

- JSON parses and uses `https://schema.org` as `@context`.
- The main type matches the page's main user-visible purpose.
- Every emitted value has a page-level source or explicit user confirmation.
- Required fields for the intended Google feature are present and accurate.
- URLs are canonical, publicly reachable URLs when the property requires a URL.
- Dates use ISO 8601 where required.
- Multiple entities are connected deliberately, not duplicated accidentally.
- The markup remains available to crawlers in the rendered response.
- The result contains no secrets, local paths, private identifiers, or fabricated claims.

## Limitations to state plainly

Valid structured data can help search engines understand a page and make it eligible for certain search appearances. It does not guarantee rich results, rankings, traffic, citations, or inclusion in AI answers.

Verwenden Sie den Skill mit einem Freigabepunkt

Sagen Sie nicht nur „Füge Schema zu dieser Seite hinzu“. Geben Sie Codex die Seite und klare Abnahmekriterien. Dieser Prompt ist ein sinnvoller Ausgangspunkt:

Use the SEO Schema JSON-LD skill to review this article page.

Goal: add accurate Article and BreadcrumbList JSON-LD if the visible content supports them.
First return the fact inventory and schema decision. Do not edit code until I approve the decision.
Do not create ratings, reviews, author details, dates, images, or organization fields that are absent from the page.
After approval, make the smallest implementation change and provide the validation checklist.

Bei großen Templates sollte der Prüfschritt „Fakteninventar und Typentscheidung zuerst“ bestehen bleiben. Er kostet eine kurze Prüfung, verhindert aber, dass sich eine falsche Annahme auf Tausende URLs ausbreitet.

In 30 Minuten vom Audit zur Veröffentlichung

Prüfen Sie nach der Veröffentlichung mit URL Inspection, ob Google die Seite abrufen und verarbeiten kann. Nutzen Sie anschließend den passenden Search-Console-Erweiterungsbericht, um Template-, Deployment- oder Datenquellenfehler im größeren Maßstab zu erkennen. Das erste Werkzeug prüft eine URL, das zweite systemische Fehler.

Jede Ebene findet andere Fehler. Syntaktisch valides Markup kann dennoch an Fakten oder Deployment scheitern.

Ein bewusst minimales Beispiel für eine Artikelseite

Der folgende Code ist nur ein Beispiel, kein produktionsfertiges Objekt. Er zeigt die Form von BlogPosting und BreadcrumbList. Verwenden Sie für Titel, Beschreibung, URL, Autor, Datum und Bild ausschließlich bestätigte Seitenwerte. Fehlt ein Fakt, fügen Sie ihn nicht nur der Vollständigkeit wegen hinzu.

Das Beispiel enthält bewusst keine Bewertung, keinen Autor, kein Veröffentlichungsdatum, kein Bild und keinen Herausgeber. Das sind keine optionalen SEO-Dekorationen, sondern Aussagen, die eine verlässliche Quelle brauchen.

Fünf Wege, wie technisch valides Markup trotzdem scheitert

JSON-Parsing ist keine Wahrheitsprüfung

Ein JSON-Validator erkennt, ob die Syntax verarbeitet werden kann. Er weiß nicht, ob die Seite die angegebenen Bewertungen, Preise oder Autoren enthält oder ob Product tatsächlich ein Produkt statt einer Dienstleistung beschreibt. Das Fakteninventar erkennt viele dieser Fehler früh.

Mehr Objekte bedeuten kein besseres Markup

Eine Rezeptseite mit sichtbarem Video kann berechtigt Recipe, VideoObject und Breadcrumbs enthalten. Ihr Hauptzweck sollte trotzdem klar bleiben. Article, Product, FAQPage und HowTo auf einer allgemeinen Inhaltsseite erhöhen meist nur Wartungsaufwand und Inkonsistenzrisiko.

Sichtbarkeit und Aktualität brauchen denselben Verantwortlichen

Googles allgemeine Richtlinien verlangen, dass strukturierte Daten die Seite abbilden und zeitkritische Angaben aktuell bleiben. Preise, Bestand, Termine, Stellenanzeigen und Bewertungen dürfen keine einmal eingetragenen statischen Werte sein. Verbinden Sie dynamische Fakten mit einer kontrollierten Quelle und testen Sie nach Template-Änderungen erneut.

FAQPage ist keine allgemeine Frage-Antwort-Dekoration

Nur Fragen und Antworten, die Nutzer tatsächlich sehen, gehören in FAQ-Markup. Google-Funktionen können zusätzliche Voraussetzungen haben. Veröffentlichen Sie zuerst echte, vollständige FAQ und prüfen Sie anschließend die aktuelle Funktionsdokumentation. Erfinden Sie keine Fragen nur für eine Ergebnisdarstellung.

Schema umgeht Crawling, Indexierung und Seitenqualität nicht

Eine durch noindex, Zugangskontrollen oder Crawling-Regeln blockierte Seite wird durch JSON-LD nicht suchfähig. Schema ist eine Ebene des technischen SEO, kein Ersatz für Crawlbarkeit, nützliche Inhalte und Seitenerfahrung. Für einen breiteren Check wählen Sie im Auspia-Verzeichnis der SEO-Tools den passenden Audit-Workflow.

Checkliste vor der Veröffentlichung

• [ ] Der Haupttyp der Seite ist benannt und in einem Satz begründbar.
• [ ] Jeder JSON-LD-Wert hat eine sichtbare oder verlässlich gerenderte Quelle.
• [ ] Bewertungen, Rezensionen, Preis, Bestand, Autor, Datum, Bild und Organisationsdaten wurden nicht erfunden.
• [ ] Die Änderung dupliziert keine Entitäten aus CMS, Plugin oder anderer Komponente.
• [ ] JSON ist valide und das Markup steht im gerenderten DOM nach dem Deployment.
• [ ] Erforderliche Eigenschaften der Google-Funktion wurden mit aktueller offizieller Dokumentation geprüft.
• [ ] Rich Results Test, sofern relevant, und Schema Markup Validator wurden verwendet.
• [ ] URL Inspection und Search-Console-Prüfung nach der Veröffentlichung sind geplant.
• [ ] Das Team versteht: Valides Markup schafft Eignung und Klarheit, aber keine Ergebnis- oder Ranking-Garantie.

Häufige Fragen

Kann ein SKILL.md entscheiden, welches Schema meine Website braucht?

Es kann anhand von Seitenfakten empfehlen und Unbekanntes markieren, ersetzt aber keine Bestätigung. Preise, Rezensionen, Organisationsdaten, Autoren und Veröffentlichungsdaten müssen aus einer zuverlässigen Seitenquelle oder vom zuständigen Verantwortlichen kommen.

Gehört JSON-LD in <head> oder <body>?

Google unterstützt JSON-LD sowohl in <head> als auch in <body>. Verwenden Sie die stabile Stelle, die Ihr Framework oder CMS mit dem Seiteninhalt synchron halten kann. Entscheidend ist, dass Google valides, zum Rendering passendes Markup crawlen kann.

Warum hat sich nach bestandenem Rich Results Test nichts geändert?

Ein erfolgreicher Test bestätigt technische Signale, verpflichtet Google aber nicht zur Anzeige eines Rich Results. Darstellung hängt von Suchanfrage, Gerät, Standort, Seite und weiteren Signalen ab. Prüfen Sie Inhaltsübereinstimmung und Indexierbarkeit, statt unbelegte Eigenschaften hinzuzufügen.

Sollte Codex jede gefundene Schema.org-Eigenschaft ausfüllen?

Nein. Google bevorzugt wenige vollständige und genaue empfohlene Eigenschaften gegenüber vielen unvollständigen oder falschen. Diese Grenze gehört in den Skill, nicht nur in einen einmaligen Prompt.

Offizielle Referenzen

• Google Search Central: Introduction to structured data markup
• Google Search Central: General structured data guidelines
• Google Rich Results Test
• Schema.org

Autor: Julian Mercer, technischer SEO-Praktiker mit 14 Jahren Erfahrung bei Auspia. Er schreibt über Crawlbarkeit, Rendering, strukturierte Daten und technische Systeme, die Teams zuverlässig betreiben können.