Strukturierte Daten für KI-Sichtbarkeit: JSON-LD in der Praxis
Strukturierte Daten in JSON-LD sagen Maschinen ausdrücklich, was auf deiner Seite steht — Typ, Ort, Leistung, Preise, Verknüpfungen zu deinen Profilen. Für KI-Sichtbarkeit wirken sie vor allem indirekt über den Suchindex, aus dem die Live-Websuche ihre Quellen zieht.
Was strukturierte Daten sind
Ein Mensch sieht auf deiner Seite „Ottenser Hauptstraße 12, 22765 Hamburg“ und weiß: Adresse. Eine Maschine sieht eine Zeichenkette. Strukturierte Daten schließen diese Lücke, indem sie parallel zum sichtbaren Text ein maschinenlesbares Datenblatt mitliefern: Das hier ist eine PostalAddress, das ist die Straße, das die Postleitzahl.
Das Vokabular dafür ist Schema.org, ein gemeinsamer Standard von Google, Microsoft, Yahoo und Yandex mit über 800 Typen. Das übliche Format ist JSON-LD — ein Block im <head>, getrennt vom Seiteninhalt und damit ohne Risiko fürs Layout.
Die unbequeme Wahrheit zuerst
Bevor es an die Umsetzung geht, eine Einordnung, die in vielen Anleitungen fehlt: Strukturierte Daten sind keine Direktleitung in die KI-Antwort.
Wenn ein KI-Crawler eine Seite abruft, um eine Frage zu beantworten, extrahiert er überwiegend den sichtbaren Text. Skript-Blöcke — und JSON-LD steht in einem <script>-Tag — fallen dabei meist heraus. Was also ausschließlich im Markup steht und nirgends im lesbaren Text, kommt so nicht in der Antwort an.
Warum sich der Aufwand trotzdem lohnt: Beide großen KI-Suchen setzen auf einem klassischen Suchindex auf — ChatGPT auf der Bing-Infrastruktur, die AI Overviews auf dem Google-Index. Und dort werden strukturierte Daten sehr wohl ausgewertet. Sie verbessern deine Position und die Themenzuordnung in genau dem Index, aus dem die KI ihre Quellen zieht.
Die praktische Regel daraus: Alles, was in einer Antwort auftauchen soll, muss auch im sichtbaren Text stehen. Das Markup verstärkt, es ersetzt nicht.
Der Grundbaustein für Unternehmen
Für lokale Betriebe ist LocalBusiness der passende Typ, für alle anderen Organization. Aufbau und die Stellen, an denen es meist hakt:
Zum Kopieren, mit den eigenen Werten zu füllen:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "HairSalon",
"@id": "https://schnittwerk-hamburg.de/#org",
"name": "Schnittwerk Hamburg",
"url": "https://schnittwerk-hamburg.de/",
"telephone": "+49 40 1234567",
"email": "hallo@schnittwerk-hamburg.de",
"address": {
"@type": "PostalAddress",
"streetAddress": "Ottenser Hauptstraße 12",
"postalCode": "22765",
"addressLocality": "Hamburg",
"addressCountry": "DE"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 53.5511,
"longitude": 9.9337
},
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00",
"closes": "19:00"
}],
"priceRange": "€€",
"sameAs": [
"https://www.wikidata.org/wiki/Q123456789",
"https://www.instagram.com/schnittwerk.hamburg/"
]
}
</script>
HairSalon ersetzt du durch den Untertyp, der am genauesten passt — Dentist, Plumber, LegalService, Restaurant, Electrician. Je genauer der Typ, desto klarer die Einordnung. Damit hat's sich aber noch nicht: Der Block gehört einmal pro Website in den <head>, nicht auf jede Unterseite in abweichender Fassung.
Welche Typen sich wirklich lohnen
| Typ | Wofür | Nutzen |
|---|---|---|
Organization / LocalBusiness | Einmal pro Website | Hoch — trägt die gesamte Entität |
FAQPage | Frage-Antwort-Blöcke | Hoch — passt exakt zur Struktur von KI-Antworten |
Article mit dateModified | Ratgeber, Blog | Hoch — Aktualität ist ein starkes Signal |
Product mit Offer | Shop-Artikel | Hoch — Preis und Verfügbarkeit werden übernommen |
Service | Einzelne Leistungsseiten | Mittel — sinnvoll bei klar getrennten Leistungen |
BreadcrumbList | Alle Unterseiten | Mittel — hilft bei der Einordnung in die Struktur |
Person | Autorenprofile | Mittel — zahlt auf E-E-A-T ein |
HowTo | Anleitungen | Mittel — Schritte werden gern übernommen |
Für die meisten Firmen-Websites reichen die ersten drei. Wer alles auszeichnet, was auszeichenbar ist, gewinnt nichts dazu und hat mehr zu pflegen.
Klein anfangen: der Minimalblock
Wer heute nichts hat, braucht keine vollständige Auszeichnung. Diese sechs Zeilen sind bereits mehr, als die meisten Firmen-Websites mitbringen, und decken den Kern ab:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Ostwald Kältetechnik GmbH",
"url": "https://ostwald-kaelte.de/",
"sameAs": ["https://www.wikidata.org/wiki/Q123456789"]
}
</script>
Von dort aus erweiterst du in dieser Reihenfolge: Adresse und Telefon, dann Öffnungszeiten, dann FAQPage auf den Leistungsseiten, dann alles Weitere. Jeder Schritt bringt für sich schon etwas — es gibt keinen Grund, auf die perfekte Fassung zu warten.
Ein Sonderfall, der oft falsch gelöst wird: mehrere Standorte. Dafür gehört auf jede Standortseite ein eigener LocalBusiness-Block mit eigener @id und eigener Adresse, verknüpft über parentOrganization mit dem Hauptunternehmen. Ein einziger Block mit mehreren Adressen ist nicht auswertbar.
Die vier häufigsten Fehler
- Markup und sichtbarer Text weichen ab. Steht im JSON-LD ein Preis, der auf der Seite nicht auftaucht, wird die Auszeichnung ignoriert — im schlechteren Fall als irreführend gewertet. Beides muss übereinstimmen.
- Mehrere widersprüchliche Organisationen. Ein Plugin setzt einen
Organization-Block, das Theme einen zweiten mit anderem Namen. Eine feste@idund ein aufgeräumter Quelltext verhindern das. - Öffnungszeiten als Fließtext.
"Mo-Fr 9-18 Uhr"in einem Feld ist für Maschinen nicht auswertbar.OpeningHoursSpecificationmit getrennten Feldern schon. - Einmal einbauen, nie prüfen. Nach jedem Relaunch oder Plugin-Update erneut testen — Auszeichnungen verschwinden lautlos.
Prüfen, ob es funktioniert
Zwei Werkzeuge, beide kostenlos und ohne Anmeldung:
- 01Googles Test für Rich-Suchergebnisse — zeigt, welche Typen erkannt werden und welche Pflichtfelder fehlen.
- 02Der Schema-Markup-Validator von Schema.org — prüft strenger gegen den Standard, unabhängig davon, was Google davon nutzt.
Dazu ein Blick von der Kommandozeile, der schnell zeigt, ob überhaupt etwas ausgeliefert wird:
curl -s https://deine-domain.de/ | grep -A5 'application/ld+json'
Kommt nichts zurück, wird das Markup entweder per JavaScript nachgeladen — dann sehen es viele Crawler nicht — oder es fehlt schlicht.
Wie es zur Entität passt
Strukturierte Daten sind die eine Hälfte der Entitätsarbeit, die Verknüpfung nach außen die andere. sameAs ist dabei die wichtigste Eigenschaft und wird am häufigsten weggelassen: Sie verbindet deine Website mit deinen Profilen — Unternehmensprofil, Branchenverzeichnisse, Wikidata, Social-Media-Konten.
Erst dadurch entsteht aus verstreuten Erwähnungen ein zusammenhängendes Bild: Diese Website, dieses Verzeichnisprofil und dieser Datensatz beschreiben dasselbe Unternehmen. Genau diese Eindeutigkeit ist es, die ein Sprachmodell braucht, um dich sicher zu nennen — ausführlich im 5-Hebel-Guide.
Häufige Fragen
Brauche ich ein Plugin?
Für WordPress erledigen Yoast, RankMath oder Schema-Plugins die Grundtypen zuverlässig. Prüf danach mit dem Rich-Results-Test, ob nicht zwei Plugins gleichzeitig Blöcke setzen — das ist der häufigste Konflikt.
Wirken strukturierte Daten aufs Ranking?
Nicht direkt. Sie beeinflussen die Darstellung in den Ergebnissen und die Zuordnung deiner Inhalte. Über bessere Sichtbarkeit und höhere Klickraten wirkt das mittelbar — ein Rankingfaktor im engeren Sinn sind sie nicht.
Reicht Microdata statt JSON-LD?
Es funktioniert, aber JSON-LD ist die empfohlene und deutlich wartungsfreundlichere Variante, weil es vom Markup des Seiteninhalts getrennt bleibt. Bei einem Relaunch überlebt ein JSON-LD-Block, verstreute Microdata-Attribute selten.
Wie lange dauert es, bis etwas passiert?
Bis Google die Auszeichnung berücksichtigt, vergehen meist Tage bis wenige Wochen nach dem nächsten Crawl. Der Effekt auf KI-Sichtbarkeit läuft über den Index und braucht entsprechend länger.
Ob deine strukturierten Daten sitzen, prüft der Check zusammen mit dem Rest der Technik.
Technik prüfen →