Strukturierte Daten sind der Teil deiner Seite, den kein Besucher sieht: ein kleiner Block im Quelltext, der einer Maschine sagt, was auf dieser Seite eigentlich steht. Nicht als Fließtext, sondern als Liste benannter Felder — Autor, Datum, Preis, Öffnungszeit, Frage und Antwort. Für Suchmaschinen ist das seit Jahren Routine. Für KI-Antwortsysteme wird es gerade interessant, weil sie aus einer Seite genau das brauchen: eindeutige Fakten, die sie ohne Ratespiel übernehmen können.
Warum Maschinen ein zweites Exemplar deiner Fakten brauchen
Ein Mensch liest „geöffnet Di–Fr, 9 bis 18 Uhr" und versteht sofort, was gemeint ist. Ein Programm muss raten: Ist das die Öffnungszeit des Ladens, der Telefonzentrale oder des Cafés nebenan, das im selben Absatz erwähnt wird? Dieses Raten funktioniert erstaunlich gut und geht trotzdem regelmäßig schief, besonders auf Seiten mit vielen Zahlen.
Strukturierte Daten nehmen dem System das Raten ab. Sie sagen: Dieses Objekt ist eine LocalBusiness, sie heißt so, die Öffnungszeiten sind diese, der Ort ist jener. Der Gewinn ist nicht, dass die Maschine etwas Neues erfährt — es steht ja alles im Text. Der Gewinn ist, dass sie es sicher weiß. Und Systeme, die eine Antwort formulieren und mit einer Quelle belegen müssen, greifen lieber zu dem, was sie sicher wissen.
Die vier Typen, die für kleine Websites reichen
Das Vokabular hinter strukturierten Daten heißt schema.org und umfasst über achthundert Typen. Davon brauchst du vier, alles Weitere ist Feinschliff.
Organization beschreibt, wer hinter der Website steht: Name, Logo, URL, Kontaktweg, Profile in sozialen Netzwerken. Dieser eine Block ist die Grundlage dafür, dass Systeme deine Marke als Ding erkennen, das eine Identität hat, statt als beliebige Domain. Wer ein Ladengeschäft oder ein lokales Gewerbe betreibt, nimmt stattdessen LocalBusiness und ergänzt Adresse und Öffnungszeiten.
Article (oder BlogPosting) beschreibt einen Textbeitrag: Überschrift, Autor, Veröffentlichungs- und Änderungsdatum. Das Änderungsdatum ist der unterschätzte Teil. Antwortsysteme bevorzugen bei zeitkritischen Fragen die aktuellere Quelle, und die einzige verlässliche Angabe dazu ist die, die du selbst maschinenlesbar hinterlegst.
FAQPage beschreibt Frage-Antwort-Paare. Das ist der Typ mit dem direktesten Bezug zu KI-Antworten, weil er die Zuordnung „diese Frage wird hier beantwortet" explizit macht, statt sie aus Überschriften ableiten zu lassen. Ein ehrlicher Hinweis dazu unten.
BreadcrumbList beschreibt, wo die Seite in deiner Struktur hängt. Klingt nach Kleinkram, hilft aber jedem Leser — Mensch wie Maschine — einzuordnen, ob er auf einer Übersichts- oder einer Detailseite steht.
Wer Produkte verkauft, ergänzt Product samt Offer mit Preis und Verfügbarkeit. Das ist der einzige weitere Typ, der sich für die meisten kleinen Websites wirklich lohnt.
Strukturierte Daten für KI einbauen: Schritt für Schritt
Die Arbeit hat fünf Schritte, und die Reihenfolge ist nicht beliebig: Erst schaust du nach, was schon da ist, dann legst du pro Seitentyp fest, was hingehört, und erst danach wird geschrieben, eingebunden und geprüft. Wer mit dem Schreiben anfängt, landet fast immer bei doppeltem Markup, weil Theme oder Plugin längst etwas ausgeben.
Schritt 1: Bestand aufnehmen
Nimm dir drei Seiten vor: die Startseite, einen typischen Artikel und eine Leistungs- oder Produktseite. Für jede öffnest du den Quelltext (Strg+U unter Windows, Cmd+Option+U auf dem Mac) und suchst nach application/ld+json. Jeder Treffer ist ein Block. Notiere, welcher @type darin steht und woher er kommt — Theme, SEO-Plugin, Shop-System, ein Rest vom letzten Relaunch.
Schneller geht es mit dem Rich-Results-Test von Google: URL eingeben, und unter den erkannten Elementen steht jeder Typ, den Google findet. Drei Befunde tauchen dabei fast immer auf:
- Doppelte Typen. Zwei
Organization-Blöcke mit unterschiedlich geschriebenem Namen, weil Theme und Plugin beide ausgeben. Einer muss weg. - Platzhalter. Ein Autor namens „admin", das Logo des Themes, ein Datum aus dem Jahr der Installation.
- Markup, das erst im Browser entsteht. Steht ein Block in den Entwicklerwerkzeugen („Element untersuchen"), aber nicht im Quelltext, wird er per JavaScript nachgeladen, oft über den Tag Manager. Google führt JavaScript aus, die meisten KI-Crawler tun es nicht. Für sie existiert dieses Markup nicht.
Schritt 2: Typen pro Seitentyp festlegen
Nicht jede Seite braucht jeden Typ. Diese Zuordnung passt für die meisten kleinen Websites:
| Seitentyp | Typen | Worauf es ankommt |
|---|---|---|
| Startseite | Organization (oder LocalBusiness) plus WebSite | einmal sauber beschreiben, alle anderen Seiten verweisen darauf |
| Artikel, Ratgeber | Article oder BlogPosting mit Person als Autor, dazu BreadcrumbList | Datum und Autor aus dem System, nicht von Hand |
| Produktseite | Product mit Offer | Preis, Währung und Verfügbarkeit wie auf der Seite |
| Leistungsseite | Service mit Verweis auf die Firma als Anbieter | beschreibt das Angebot, erzeugt keine besondere Darstellung |
| Standort, Kontakt | LocalBusiness mit Adresse und Öffnungszeiten | dieselben Angaben wie im Unternehmensprofil |
| Seite mit Fragen | FAQPage | nur, wenn Fragen und Antworten sichtbar im Text stehen |
Der WebSite-Block auf der Startseite ist klein, aber nicht überflüssig: Google nimmt ihn als Grundlage für den Website-Namen, der in den Treffern über dem Titel steht. Impressum, Datenschutz, Kontaktformular und Suchergebnisseiten brauchen dagegen gar kein Markup.
Für lokale Betriebe kommt eine Regel dazu: Name, Adresse und Telefonnummer im LocalBusiness-Block lauten genauso wie im Google-Unternehmensprofil, nicht ungefähr so. Warum das Profil so viel Gewicht hat, steht in Lokal gefunden werden.
Schritt 3: Das JSON-LD schreiben
Es gibt drei Schreibweisen für strukturierte Daten; nimm JSON-LD. Der Block steht als eigenes <script>-Element im Quelltext, meist im <head>, und ist vom übrigen HTML völlig getrennt. Das ist der praktische Vorteil gegenüber den älteren Formaten Microdata und RDFa, bei denen die Auszeichnung in den Text hineingeflochten wird und beim nächsten Layout-Umbau kaputtgeht.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Strukturierte Daten für KI-Antworten",
"datePublished": "2026-03-14",
"dateModified": "2026-08-01",
"author": { "@type": "Person", "name": "Vorname Nachname" },
"publisher": {
"@type": "Organization",
"name": "Meine Firma",
"url": "https://meine-firma.de"
}
}
</script>
Nach demselben Muster funktionieren die übrigen Typen. Hier ist ein vollständiger LocalBusiness-Block für dasselbe fiktive Küchenstudio, das auch in llms.txt erstellen als Beispiel dient — Name, Adresse und Öffnungszeiten austauschen, fertig:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Küchenstudio Lindner",
"url": "https://kuechenstudio-lindner.de",
"image": "https://kuechenstudio-lindner.de/ausstellung.jpg",
"telephone": "+49 231 5550000",
"address": {
"@type": "PostalAddress",
"streetAddress": "Musterstraße 12",
"addressLocality": "Dortmund",
"postalCode": "44135",
"addressCountry": "DE"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
"opens": "09:00",
"closes": "18:00"
}
],
"sameAs": ["https://www.instagram.com/kuechenstudiolindner"]
}
</script>
Und so sieht ein FAQPage-Block für zwei Fragen aus. Die Bedingung von weiter unten gilt hier mit voller Härte: Beide Fragen und beide Antworten müssen im sichtbaren Text der Seite stehen.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Was kostet eine Einbauküche?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Die meisten Projekte liegen je nach Größe und Geräten zwischen 9.000 und 25.000 Euro. Aufmaß und Planung sind kostenlos."
}
},
{
"@type": "Question",
"name": "Wie lange dauert die Montage?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Eine typische Küche ist in zwei bis drei Arbeitstagen eingebaut. Wasser- und Stromanschlüsse müssen vor dem Einbautag liegen."
}
}
]
}
</script>
Für Shops kommt der Product-Block mit Offer dazu. Preis und Verfügbarkeit ändern sich, deshalb gehören diese Werte aus dem Shop-System in den Block und nicht von Hand hinein — ein Markup-Preis, der vom Seitenpreis abweicht, ist genau der Widerspruch, um den es weiter unten geht:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Arbeitsplatte Eiche massiv, 40 mm",
"image": "https://kuechenstudio-lindner.de/produkte/arbeitsplatte-eiche.jpg",
"description": "Massivholz-Arbeitsplatte aus geölter Eiche, Zuschnitt nach Aufmaß bis 4,10 m Länge.",
"sku": "AP-EI-40",
"brand": { "@type": "Brand", "name": "Küchenstudio Lindner" },
"offers": {
"@type": "Offer",
"url": "https://kuechenstudio-lindner.de/produkte/arbeitsplatte-eiche",
"price": "189.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
}
}
</script>
Mehrere Typen auf einer Seite schreibst du entweder in mehrere <script>-Blöcke oder in einen mit @graph. Beides ist zulässig; mehrere Blöcke sind leichter zu pflegen, ein @graph ist übersichtlicher, sobald du die Objekte miteinander verknüpfst. Wie das aussieht, steht unten im Abschnitt über Entitäten.
Schritt 4: Das Markup einbinden
In WordPress, Shopify und den meisten Baukästen übernimmt das ein Plugin oder das Theme — dann besteht deine Arbeit vor allem darin, zu prüfen, was es ausgibt, statt selbst zu schreiben. Für jeden Weg gilt dieselbe Bedingung aus Schritt 1: Das Markup muss im ausgelieferten HTML stehen, nicht erst im Browser per JavaScript entstehen.
Reines HTML. Den <script>-Block in den <head> der jeweiligen Seite kopieren. Google liest ihn auch im <body>, der <head> ist nur die übliche Stelle. Den Organization-Block setzt du auf die Startseite oder die Über-uns-Seite; das ist die Stelle, die Google dafür empfiehlt.
WordPress. Yoast SEO und Rank Math geben bereits einen verknüpften @graph mit Organisation, Website, Seite, Artikel und Autor aus. Deine Arbeit ist dort die Konfiguration: in den Plugin-Einstellungen festlegen, ob die Website eine Organisation oder eine Person vertritt, Name, Logo und Profil-URLs eintragen, die Autorenprofile ausfüllen. Und darauf achten, dass nur ein Plugin Markup ausgibt; viele Themes und Shop-Erweiterungen bringen eigenes mit. Einen eigenen Block ohne Plugin hängst du im Child-Theme über den Hook wp_head ein:
add_action('wp_head', function () {
if (!is_front_page()) {
return;
}
$data = [
'@context' => 'https://schema.org',
'@type' => 'Organization',
'name' => 'Küchenstudio Lindner',
'url' => home_url('/'),
'logo' => home_url('/logo.png'),
];
echo '<script type="application/ld+json">' . wp_json_encode($data) . '</script>';
});
Drupal. Das Modul Schema.org Metatag erweitert das Metatag-Modul um schema.org-Felder. Du aktivierst die Untermodule für die Typen, die du brauchst, etwa Organization, WebSite und Article, und belegst die Felder unter Konfiguration → Suche und Metadaten → Metatag pro Inhaltstyp mit Tokens: [node:title] für die Überschrift, [node:changed:html_datetime] für das Änderungsdatum. So kommen die Werte aus dem Inhalt selbst und veralten nicht.
Next.js und React. Im App Router renderst du den Block als <script>-Element direkt in page.tsx oder layout.tsx; so empfiehlt es auch die Next.js-Dokumentation. Das replace verhindert, dass ein < aus dem Inhalt das Script-Element vorzeitig schließt:
export default async function Page({ params }) {
const { slug } = await params;
const post = await getPost(slug);
const jsonLd = {
"@context": "https://schema.org",
"@type": "Article",
headline: post.title,
datePublished: post.publishedAt,
dateModified: post.updatedAt,
author: { "@type": "Person", name: post.authorName },
};
return (
<article>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
}}
/>
{/* … */}
</article>
);
}
Weil die Seite auf dem Server gerendert wird, steht der Block im ausgelieferten HTML. Bei einer reinen Client-Anwendung, etwa einer Vite-App ohne Server-Rendering, ist das nicht der Fall; dort hilft nur Vorrendern der Seiten, die gefunden werden sollen.
Schritt 5: Prüfen
Zwei Werkzeuge, zwei Minuten. Der Rich-Results-Test von Google (search.google.com/test/rich-results) sagt dir, was Google aus deiner Seite herausliest und ob es für Darstellungsformen taugt. Der Validator unter validator.schema.org ist strenger und meldet auch Felder, die Google ignoriert, aber andere Systeme lesen. Beide nehmen eine URL entgegen, du musst also nichts installieren.
Der dritte Test ist der wichtigste und braucht kein Werkzeug: Seite im Browser öffnen, Quelltext anzeigen, den JSON-Block suchen und lesen. Steht dort wirklich das, was auf der Seite steht? Bei automatisch erzeugtem Markup ist die Antwort erstaunlich oft nein — ein altes Datum, ein Autor namens „admin", ein Preis ohne Währung.
Nach dem Livegang übernimmt die Search Console die Daueraufsicht. Unter „Verbesserungen" legt sie für jeden erkannten Typ mit eigener Darstellung in der Trefferliste einen Bericht an, etwa für Breadcrumbs oder Produkt-Snippets, mit gültigen und ungültigen Elementen und dem Fehler pro URL. Dort merkst du, wenn ein Theme-Update das Markup auf zweihundert Seiten auf einmal kaputt gemacht hat. Nicht jeder Typ bekommt einen Bericht, Organization, WebSite und Article zum Beispiel nicht; für sie bleibt der Rich-Results-Test. Nach einer Korrektur klickst du im Bericht auf „Fehlerbehebung überprüfen", dann sieht Google sich die betroffenen Seiten erneut an.
Der häufigste Fehler: Markup ohne Deckung im Text
Strukturierte Daten dürfen nur beschreiben, was auf der Seite sichtbar ist. Eine FAQPage-Auszeichnung für Fragen, die im Text gar nicht vorkommen, oder eine Bewertung, die nirgends steht, ist keine Optimierung, sondern eine Falschangabe. Google behandelt das als Spam und kann die Auszeichnung für die ganze Domain ignorieren; für KI-Systeme ist es schlicht ein Widerspruch zwischen zwei Quellen derselben Seite, und der beschädigt genau das Vertrauen, das du aufbauen wolltest.
Die Regel ist einfach: erst der Text, dann das Markup. Wer die Reihenfolge umdreht, baut eine hübsche Fassade vor einen leeren Raum.
Entitäten: aus einzelnen Blöcken einen Graphen machen
Bisher stehen die Blöcke nebeneinander: ein Artikel, eine Firma, ein Autor, jeder für sich. Damit ist für eine Maschine nicht gesagt, dass die Autorin auf der Artikelseite dieselbe Person ist wie die auf der Teamseite, oder dass der publisher im Artikel dieselbe Firma ist wie die Organization auf der Startseite. Sie kann es vermuten, weil die Namen gleich sind. Wissen kann sie es nur, wenn du es sagst.
Dafür gibt es zwei Werkzeuge. @id gibt jedem Objekt eine feste Kennung in Form einer URL, meist die Adresse der Seite, die es beschreibt, plus ein Fragment: https://kuechenstudio-lindner.de/#organization für die Firma, https://kuechenstudio-lindner.de/team/sabine-lindner#person für die Autorin. Überall sonst, wo die Firma vorkommt, steht dann nur noch { "@id": "https://kuechenstudio-lindner.de/#organization" }, statt sie neu zu beschreiben. Die Kennung muss nicht aufrufbar sein, sie muss nur überall exakt gleich geschrieben sein.
sameAs verbindet ein Objekt mit Profilen außerhalb deiner Website: Instagram, LinkedIn, das Branchenverzeichnis, bei bekannteren Unternehmen der Wikidata-Eintrag. Damit sagst du: Die Firma auf dieser Seite und die Firma auf jenem Profil sind dieselbe. Für Personen funktioniert das genauso, etwa mit dem LinkedIn-Profil. Trag nur Profile ein, die dir gehören und gepflegt werden; ein verwaister Account mit alter Adresse verbindet dich mit genau den falschen Angaben.
So sieht ein Ratgeberartikel des Küchenstudios aus, wenn Firma, Website, Artikel und Autorin in einem Graphen verbunden sind:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LocalBusiness",
"@id": "https://kuechenstudio-lindner.de/#organization",
"name": "Küchenstudio Lindner",
"url": "https://kuechenstudio-lindner.de/",
"logo": "https://kuechenstudio-lindner.de/logo.png",
"telephone": "+49 231 5550000",
"address": {
"@type": "PostalAddress",
"streetAddress": "Musterstraße 12",
"addressLocality": "Dortmund",
"postalCode": "44135",
"addressCountry": "DE"
},
"sameAs": [
"https://www.instagram.com/kuechenstudiolindner",
"https://www.linkedin.com/company/kuechenstudio-lindner"
]
},
{
"@type": "WebSite",
"@id": "https://kuechenstudio-lindner.de/#website",
"url": "https://kuechenstudio-lindner.de/",
"name": "Küchenstudio Lindner",
"inLanguage": "de-DE",
"publisher": { "@id": "https://kuechenstudio-lindner.de/#organization" }
},
{
"@type": "Person",
"@id": "https://kuechenstudio-lindner.de/team/sabine-lindner#person",
"name": "Sabine Lindner",
"jobTitle": "Inhaberin und Küchenplanerin",
"url": "https://kuechenstudio-lindner.de/team/sabine-lindner",
"worksFor": { "@id": "https://kuechenstudio-lindner.de/#organization" },
"sameAs": ["https://www.linkedin.com/in/sabine-lindner-kuechen"]
},
{
"@type": "Article",
"@id": "https://kuechenstudio-lindner.de/ratgeber/kosten#article",
"headline": "Was kostet eine Einbauküche?",
"datePublished": "2026-02-10",
"dateModified": "2026-09-01",
"mainEntityOfPage": "https://kuechenstudio-lindner.de/ratgeber/kosten",
"isPartOf": { "@id": "https://kuechenstudio-lindner.de/#website" },
"author": { "@id": "https://kuechenstudio-lindner.de/team/sabine-lindner#person" },
"publisher": { "@id": "https://kuechenstudio-lindner.de/#organization" }
}
]
}
</script>
Auf der Startseite reichen die ersten beiden Objekte. Auf Artikelseiten wiederholst du Firma und Website einfach mit; das kostet nichts, und jede Seite bleibt für sich verständlich. Entscheidend ist, dass die @id-Werte auf allen Seiten identisch sind. Öffnungszeiten und die übrigen Felder aus dem LocalBusiness-Block weiter oben kannst du ins erste Objekt übernehmen.
Warum der Aufwand? Ein Antwortsystem setzt sein Bild von deiner Firma aus mehreren Quellen zusammen: deinem Seitentext, deinem Markup, dem Unternehmensprofil, Verzeichnissen, Bewertungsportalen. Stimmen die überein, ist die Sache eindeutig. Steht im Markup „Küchenstudio Lindner GmbH", im Footer „Lindner Küchen", im Unternehmensprofil eine alte Telefonnummer und auf Instagram ein anderes Gründungsjahr, muss das System entscheiden, welche Angabe gilt, oder ob es überhaupt um dieselbe Firma geht. Es kann sich richtig entscheiden. Es kann aber auch die Angaben vermischen, und eine Quelle, die sich selbst widerspricht, zitiert man ungern.
Praktisch heißt das: Leg einmal fest, wie Firmenname, Adresse, Telefonnummer, Gründungsjahr und die Namen der Autoren geschrieben werden, und gleiche Seitentext, Markup und Profile darauf ab. Das ist dieselbe Disziplin, die die lokale Suche seit Jahren verlangt, nur mit mehr Lesern. Markup ersetzt diese Abstimmung nicht. Es macht nur sichtbar, ob du sie gemacht hast.
KI und strukturierte Daten: welche Systeme dein Markup lesen
Wer nach strukturierten Daten für KI sucht, könnte vermuten, es gebe ein zweites Vokabular — irgendetwas, das man zusätzlich zu schema.org speziell für Sprachmodelle hinterlegt. Gibt es nicht. Es ist dasselbe JSON-LD wie oben beschrieben; geändert hat sich nur, wer es liest und wozu.
Drei Gruppen von Lesern lohnt es zu unterscheiden. Googles KI-Übersichten sitzen direkt auf dem Google-Index: Alles, was dein Markup für die klassische Suche eindeutig macht — wer hinter der Seite steht, wann ein Text zuletzt geändert wurde, welche Frage ein Absatz beantwortet —, ist damit auch für die generierten Antworten eindeutig. Systeme wie ChatGPT und Perplexity füllen ihre Indexe mit eigenen Crawlern; wie viel Gewicht ihre Parser schema.org geben, veröffentlicht keiner von ihnen, aber das Auslesen kostet sie nichts, und dein Markup reicht ihnen die Fakten in der am wenigsten missverständlichen Form. Und die Crawler, die Trainingsdaten sammeln, nehmen Seiten im Ganzen mit — für sie zählt Markup am wenigsten, weil dort nichts nachgeschlagen, sondern nur aufgenommen wird.
Die praktische Folgerung ist beruhigend: Es gibt nichts Separates zu bauen. Eine Seite, deren Blöcke für die klassische Suche stimmen, ist für KI-Systeme so gut vorbereitet, wie Markup sie vorbereiten kann. Was sich darüber hinaus lohnt, ist nicht mehr Markup, sondern weniger Mehrdeutigkeit im Text selbst: sichtbare Daten, genannte Autoren, eine Frage pro Überschrift.
Was Markup für KI-Antworten leisten kann und was nicht
Es leistet zwei Dinge. Es macht Fakten eindeutig, sodass ein Antwortsystem Preis, Datum oder Autor ohne Interpretation übernehmen kann. Und es macht Beziehungen explizit — dass dieser Text zu dieser Organisation gehört, dass diese Antwort zu dieser Frage gehört.
Es leistet nicht, dass eine Seite besser rankt. Strukturierte Daten sind kein Rangfaktor, weder in der klassischen Suche noch, soweit man das von außen beurteilen kann, in der Quellenauswahl der Antwortsysteme. Sie sorgen dafür, dass eine bereits gute Seite korrekt verstanden wird, nicht dafür, dass eine schwache Seite gewinnt.
Und ein Punkt zur Erwartungshaltung bei FAQPage: Google zeigt die aufklappbaren FAQ-Ergebnisse in der Trefferliste seit 2023 fast nur noch für behördliche und medizinische Seiten. Das Markup ist deswegen nicht wertlos geworden — es wird weiterhin ausgelesen und macht deine Frage-Antwort-Struktur für jeden Parser eindeutig —, aber wer es wegen der bunten Darstellung in der Trefferliste einbaut, wird enttäuscht.
Checkliste: strukturierte Daten für KI
- Bestand aufnehmen. Quelltext von Startseite, Artikel und Leistungsseite nach
application/ld+jsondurchsuchen, doppelte Typen und Platzhalter notieren. - Typen pro Seitentyp festlegen.
OrganizationoderLocalBusinessplusWebSiteauf der Startseite,ArticlemitPersonauf Artikeln,ProductoderServiceauf Angebotsseiten,FAQPagenur bei sichtbaren Fragen. - JSON-LD schreiben. Datum, Preis und Autor aus dem System ziehen, nicht abtippen.
- Zum Graphen verknüpfen. Feste
@idfür Firma, Website und Personen,sameAsauf die eigenen, gepflegten Profile. - Serverseitig einbinden. Das Markup steht im ausgelieferten HTML, und nur ein Plugin oder Modul gibt es aus.
- Prüfen. Rich-Results-Test,
validator.schema.orgund ein Blick in den Quelltext. - Abgleichen und beobachten. Namen, Adresse und Fakten in Text, Markup und Profilen gleich halten, die Berichte unter „Verbesserungen" in der Search Console im Blick behalten.
Wo das hingehört
Markup ist der zweite von drei Handgriffen, mit denen du in KI-Antworten zitierfähig wirst. Der erste sind klare Fakten und geschlossene Absätze, der dritte ist eine llms.txt als Landkarte deiner besten Seiten. Wie die drei zusammenspielen und woher ChatGPT seine Quellen überhaupt nimmt, steht in In ChatGPT gefunden werden. Und weil Markup nur gelesen wird, wenn ein Crawler die Seite überhaupt abrufen darf, lohnt ein Blick in deine robots.txt: Was du dort zulässt und was nicht, steht in KI-Crawler steuern.
Häufige Fragen
Was sind strukturierte Daten?
Maschinenlesbare Zusatzangaben im Quelltext einer Seite, die benennen, was der sichtbare Inhalt bedeutet: dass diese Zeichenkette ein Preis ist, jene ein Veröffentlichungsdatum und die dritte der Name des Autors. Das übliche Vokabular dafür ist schema.org, das übliche Format JSON-LD.
Gibt es spezielle strukturierte Daten für KI?
Nein. Auch KI-Systeme lesen das normale schema.org-Vokabular im JSON-LD-Format — dieselben Blöcke, die Suchmaschinen seit Jahren auswerten, nur mit neuen Lesern. Eine Seite, deren Markup für Google stimmt, braucht für ChatGPT, Perplexity oder Googles KI-Übersichten nichts Zusätzliches.
Wie füge ich strukturierte Daten für KI hinzu?
Genauso wie für Google: als JSON-LD-Block mit schema.org-Vokabular im Quelltext der Seite. Erst prüfen, was Theme oder Plugin schon ausgeben, dann pro Seitentyp die passenden Typen wählen, den Block serverseitig einbinden und mit dem Rich-Results-Test und validator.schema.org testen. Ein eigenes Format für KI-Systeme gibt es nicht.
Liest ChatGPT Schema-Markup?
Ob und wie stark ChatGPT schema.org auswertet, veröffentlicht OpenAI nicht. Bekannt ist, dass ChatGPT für die Websuche Seiten mit eigenen Crawlern abruft, und ein JSON-LD-Block im Quelltext kommt dabei mit. Darauf, dass Markup zu einer Nennung führt, kannst du dich bei keinem Anbieter verlassen; darauf, dass es deine Fakten eindeutig macht, schon.
Welche Schema-Typen sind für KI-Sichtbarkeit am wichtigsten?
Organization oder LocalBusiness für die Frage, wer hinter der Website steht, Article mit Autor und Änderungsdatum für Inhalte, Product mit Offer für Shops und FAQPage dort, wo Fragen sichtbar beantwortet werden. Wichtiger als die Zahl der Typen ist, dass sie per @id miteinander verknüpft sind und mit dem Seitentext übereinstimmen.
Sind strukturierte Daten ein Rankingfaktor?
Nein. Sie beeinflussen die Platzierung nicht direkt. Sie entscheiden mit darüber, wie ein Treffer dargestellt wird und wie sicher Maschinen die Fakten einer Seite erfassen — was indirekt auf Klickrate und Zitierfähigkeit einzahlt, aber kein Rangsignal ist.
Welches Format soll ich nehmen, JSON-LD oder Microdata?
JSON-LD. Es steht als eigener Block im Quelltext und bleibt von Layout-Änderungen unberührt, während Microdata in das HTML des sichtbaren Inhalts eingeflochten wird und dabei leicht zerbricht. Alle großen Anbieter empfehlen JSON-LD.
Wie teste ich meine strukturierten Daten?
Mit dem Rich-Results-Test von Google für die Frage, was Google herausliest, und mit validator.schema.org für die strengere Prüfung gegen das Vokabular. Beide brauchen nur die URL. Ergänzend lohnt ein Blick in den Quelltext, ob das automatisch erzeugte Markup wirklich die aktuellen Angaben enthält.
Bringt FAQPage-Markup noch etwas?
Für die aufklappbaren FAQ-Ergebnisse in Googles Trefferliste kaum, die zeigt Google seit 2023 fast nur noch für behördliche und medizinische Seiten. Ausgelesen wird das Markup weiterhin, und für Systeme, die Frage-Antwort-Paare aus einer Seite ziehen, ist es die eindeutigste Form, sie anzubieten.
Was bedeutet sameAs in strukturierten Daten?
sameAs listet Adressen, die dasselbe Objekt an anderer Stelle beschreiben, zum Beispiel das Instagram-, LinkedIn- oder Wikidata-Profil einer Firma. Damit sagst du Maschinen ausdrücklich, dass diese Profile und deine Website zur selben Firma oder Person gehören. Eintragen solltest du nur Profile, die dir gehören und aktuell sind.
Wird JSON-LD gelesen, das per JavaScript oder Tag Manager eingefügt wird?
Von Google in der Regel ja, weil Google Seiten mit JavaScript rendert. Die meisten KI-Crawler führen dagegen kein JavaScript aus und sehen solches Markup nicht. Wer für beide schreibt, gibt den Block serverseitig im ausgelieferten HTML aus.