Letzte Woche erreichte mich die Frage eines Kunden: „In unserer Codebasis liegt eine Datei schemas.ts, aber niemand weiß mehr, warum es sie gibt und was die einzelnen Blöcke bewirken." Das ist kein Einzelfall. Bei mindestens der Hälfte der Projekte, die ich zu Gesicht bekomme, findet sich irgendwo eine verwaiste JSON-LD-Datei, die ein Entwickler irgendwann angelegt hat – ohne Dokumentation, ohne klares Ziel und oft ohne dass noch jemand weiß, ob ihr Inhalt überhaupt stimmt.
Das ist schade, denn strukturierte Daten sind genau die Art von Information, nach der KI-Systeme wie ChatGPT, Perplexity und Googles AI Overviews hungern. Sie liefern maschinenlesbaren Kontext, der aussagt: „Das sind wir, hier sind wir ansässig, das sind die Antworten auf häufig gestellte Fragen." Ohne diesen Kontext muss ein Sprachmodell anhand unstrukturierten Textes raten. Mit diesem Kontext erhält es eine direkte, verlässliche Quelle.
In diesem Artikel erkläre ich die drei am häufigsten verwendeten Schema-Typen – Organization, LocalBusiness und FAQPage – mit konkreten Beispielen, die Sie noch heute umsetzen können.
Warum strukturierte Daten im KI-Zeitalter noch immer zählen
Strukturierte Daten (meist als JSON-LD) gibt es seit 2011 dank schema.org, das Google, Bing, Yahoo und Yandex gemeinsam ins Leben gerufen haben. Das Ziel war damals schlicht: Suchmaschinen dabei helfen, Inhalte zu verstehen, um Rich Results auszuspielen – Sternebewertungen, Öffnungszeiten, aufklappbare FAQ-Blöcke in den Suchergebnissen.
Was sich verändert hat: Der „Leser" Ihrer strukturierten Daten ist längst nicht mehr nur ein Crawler, der für eine Ergebnisliste indexiert. Heute ist es auch ein Sprachmodell, das Ihre Inhalte auswertet, um eine Antwort für einen Nutzer zu formulieren, der Ihre Website womöglich nie besucht. Wenn jemand ChatGPT fragt, welche Unternehmen in Utrecht KI-Beratung anbieten, dann ist die Wahrscheinlichkeit, dass Ihre JSON-LD-Daten in die Antwort einfließen, um ein Vielfaches höher als die, dass ein Marketingtext interpretiert wird.
Der Grund: Strukturierte Daten sind eindeutig. Ein Satz wie „Wir sitzen im Herzen von Utrecht" muss von einem Modell gedeutet werden und lässt Annahmen zu. Ein PostalAddress-Objekt mit addressLocality: "Utrecht" bedarf keiner Interpretation – es ist ein Fakt, der sich direkt extrahieren lässt.
Für die übergreifende Strategie hinter dieser Art der Optimierung empfehle ich zusätzlich die Lektüre von was GEO genau bedeutet – strukturierte Daten sind nämlich nur ein Puzzleteil eines größeren Ganzen.
Die drei Schema-Typen, die Sie fast immer brauchen
Organization: Wer sind Sie – wirklich?
Das Organization-Schema ist die Grundlage. Es beantwortet die Frage, die KI-Systeme am häufigsten nicht beantworten können: Was ist dieses Unternehmen, und warum sollte ich ihm vertrauen? Dieses Schema gehört auf Ihre Startseite, und idealerweise wiederholen Sie es (oder verweisen darauf) auf jeder Seite über Ihr Layout.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "AI-native webontwikkeling en GEO/AEO-optimalisatie voor bedrijven die gevonden willen worden door ChatGPT, Perplexity en Google AI Overviews.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
Wichtig ist hierbei: sameAs ist keine Dekoration. Dieses Feld verknüpft Ihr Unternehmen mit externen, überprüfbaren Quellen – Ihrem LinkedIn-Profil, Ihrer Wikipedia-Seite (falls vorhanden), Ihrem Crunchbase-Profil. KI-Modelle nutzen solche Querverweise, um festzustellen, ob eine Entität „echt" ist. Ein Organization-Schema ohne sameAs gleicht einem LinkedIn-Profil ohne Kontakte: technisch gültig, aber wenig überzeugend.
Die description sollten Sie nicht aus Ihrer Meta-Description kopieren. Formulieren Sie einen Satz, der konkret benennt, was Sie tun und für wen – nicht „wir sind eine führende Agentur", sondern konkret: was, für wen, warum anders.
LocalBusiness: entscheidend, wenn Sie vor Ort auffindbar sein müssen
Wenn Sie einen physischen Standort haben – ein Büro, ein Geschäft, eine Praxis –, ist LocalBusiness (oder ein spezifischerer Subtyp wie ProfessionalService, Restaurant, Store) unverzichtbar. Dieses Schema ist der unmittelbare Grund dafür, dass KI-Assistenten Fragen nach „in der Nähe" beantworten können.
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Vredenburg 40",
"addressLocality": "Utrecht",
"postalCode": "3511 BD",
"addressCountry": "NL"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.0907,
"longitude": 5.1214
},
"telephone": "+31-30-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"priceRange": "€€€"
}
Zwei Dinge gehen häufig schief. Erstens: Die geo-Koordinaten werden vergessen, obwohl Systeme genau diese nutzen, um bei Abfragen nach dem nächstgelegenen Anbieter Entfernungen zu berechnen. Zweitens: Der @type ist oft zu allgemein gewählt. Verwenden Sie nicht standardmäßig LocalBusiness, wenn ein spezifischerer Subtyp existiert – Google und KI-Systeme können mit einem konkreten Typ (etwa Dentist, Accountant oder, wo verfügbar, MarketingAgency) deutlich zielgenauer auf die Suchabsicht eingehen.
Dieses Thema behandle ich ausführlicher in GEO für lokale Unternehmen – dort gehe ich auch darauf ein, wie Sie mit mehreren Standorten umgehen.
FAQPage: das am meisten unterschätzte Schema für AEO
Wenn es einen Schema-Typ gibt, der unmittelbar beeinflusst, ob Sie in einer KI-Antwort zitiert werden, dann ist es FAQPage. Warum? Weil er einem Sprachmodell buchstäblich die Struktur von Frage und Antwort liefert, die es benötigt, um Ihre Inhalte in seiner eigenen Antwort wiederzuverwenden – häufig Wort für Wort.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Wat kost een AI-native website?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Een AI-native website wordt in fases opgeleverd. Wat het kost hangt af van het aantal pagina's, het aantal talen en de koppelingen met bestaande systemen. Vraag een offerte op basis van je eigen scope, met uren per fase."
}
},
{
"@type": "Question",
"name": "Werkt structured data ook zonder een technisch team?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ja. De meeste CMS-systemen en frameworks ondersteunen JSON-LD via plugins of eenvoudige code-snippets. Je hebt geen dedicated developer nodig om Organization- of FAQPage-schema te implementeren."
}
}
]
}
Die Fallgrube hier: Viele befüllen das FAQPage-Schema mit Marketingfragen („Warum sollten Sie uns wählen?") statt mit Fragen, die Menschen tatsächlich einer Suchmaschine oder einem KI-Assistenten stellen. Werfen Sie einen Blick auf den Bereich „Ähnliche Fragen" in Google oder testen Sie selbst in ChatGPT und Perplexity, welche Fragen zu Ihrem Thema auftauchen. Formulieren Sie Antworten, die für sich stehen – eine Antwort muss verständlich sein, ohne dass die Frage erneut gelesen wird, denn genau so schneidet ein Sprachmodell sie heraus.
Ausführlicher habe ich das in dem praktischen AEO-Leitfaden ausgearbeitet, inklusive der Frage, wie Sie bestimmen, welche Fragen es lohnt zu beantworten.
Von der losen Datei zum funktionierenden System: die praktische Umsetzung
Wo platzieren Sie das in Ihrer Codebasis?
Wenn Sie bereits eine lib/schemas.ts haben (oder etwas Vergleichbares), ist die logische Struktur: Exportieren Sie Funktionen, die JSON-LD-Objekte auf Basis Ihrer Inhalte erzeugen, keine statischen Zeichenketten. Etwa so:
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Das verhindert, dass sich Ihre Schemata von Ihren Inhalten entfernen – ein häufiges Problem, bei dem der FAQ-Text auf der Seite angepasst wird, das dahinterliegende Schema aber nicht mitwächst. Eine Inkonsistenz zwischen sichtbarem Inhalt und Schema-Daten ist genau das, was Sie vermeiden wollen: Sie untergräbt das Vertrauen sowohl bei Google als auch bei KI-Crawlern.
Testen und validieren, bevor Sie live gehen
Nutzen Sie den Rich-Results-Test von Google und den Validator von Schema.org, bevor Sie etwas veröffentlichen. Ein häufiger Fehler ist ein Tippfehler im @type (etwa Organisation in britischer Schreibweise statt Organization) – das Schema schlägt dann still fehl, ohne Fehlermeldung auf Ihrer Website, und Sie merken es erst, wenn Sie sich fragen, warum nichts wirkt.
Vergessen Sie außerdem nicht zu prüfen, ob Ihre robots.txt nicht genau jene KI-Crawler blockiert, die diese Daten lesen sollen – siehe die Anleitung zu robots.txt und KI-Crawlern, wenn Sie unsicher sind, ob Ihre Konfiguration stimmt.