Hinweis: Dieser Beitrag gehört zur Wissensrubrik Strukturierte Daten: Die Sprache, die KI braucht, um deiner Marke zu vertrauen im Mehrklicks-Wissensportal.
Die Inhalte beschreiben Methoden und Strukturen, mit denen wir Marken für KI-Systeme wie ChatGPT, Perplexity und Google AI Overviews sichtbar machen.
Eine thematische Einordnung und die operative Umsetzung findest du auf der Seite Agentur für KI-Sichtbarkeit.
Ich sehe es immer wieder: perfekt optimierte Seiten, die bei Google ganz oben stehen, aber von KI-Systemen wie ChatGPT oder Perplexity komplett ignoriert werden. Der Grund ist oft erschreckend einfach: Ihre Daten sind für Maschinen unlesbar. Sie liegen flach und unverbunden auf der Seite wie einzelne Puzzleteile ohne Bildvorlage.
Eine Maschine sieht eine Veranstaltung, einen Sprecher und einen Ort. Aber sie versteht nicht, dass dieser spezifische Sprecher auf genau dieser Veranstaltung und an exakt diesem Ort auftritt. Der Kontext, die Beziehung – das, was Information in Wissen verwandelt – fehlt komplett.
Flache, getrennte Datenstrukturen sind der Tod für maschinelles Verständnis. Und in einer Welt, die von Empfehlungsmaschinen und KI-Assistenten dominiert wird, ist mangelndes Verständnis gleichbedeutend mit digitaler Unsichtbarkeit.
Stellen Sie sich vor, Sie geben einer Maschine drei separate Visitenkarten: eine für ein Event, eine für einen Speaker und eine für einen Veranstaltungsort.
Für einen Menschen ist der Zusammenhang vielleicht offensichtlich, weil die Karten auf demselben Tisch liegen. Für eine Maschine ist das pures Raten. Ist Dr. Schmidt die Veranstalterin? Eine Teilnehmerin? Oder ist ihre Erwähnung auf der Seite reiner Zufall? Gehört das Congress-Center zum Event oder wird es nur als Beispiel genannt?
Genau das passiert, wenn Sie drei separate Schema-Blöcke auf Ihrer Seite platzieren: Event, Person und Place. Sie existieren nebeneinander, aber nicht miteinander. Sie sind isolierte Fakten, keine vernetzte Geschichte. Sie zwingen die Maschine, Zusammenhänge zu erraten – und Maschinen hassen es zu raten.
Für eine KI, die versucht, die Welt in Entitäten zu verstehen, ist diese Ambiguität pures Gift. Das Ergebnis: Ihre Inhalte werden als unzuverlässig oder unvollständig eingestuft und in den Antworten der KI gar nicht erst berücksichtigt.
Nested Schema (verschachteltes Schema) löst dieses Problem elegant. Anstatt separate Informationsinseln zu schaffen, bauen Sie eine logische Hierarchie. Sie definieren eine Hauptentität – in unserem Fall das Event – und betten die zugehörigen Entitäten (Person, Place) direkt in deren Eigenschaften ein.
Sie sagen der Maschine nicht mehr: „Hier sind drei Dinge.“ Sie sagen: „Hier ist ein Event, und Teil dieses Events ist ein Sprecher und Teil dieses Events ist ein Veranstaltungsort.“
Dieser simple Akt des Verschachtelns transformiert lose Datenpunkte in eine reiche, kontextuelle Erzählung.
Die gute Nachricht: Das ist keine Grauzonen-Technik oder ein cleverer Hack. Google selbst empfiehlt diesen Ansatz ausdrücklich, um detailliertere und vernetzte Informationen bereitzustellen. Sie arbeiten also nicht gegen das System, sondern nutzen seine Sprache so, wie sie gedacht war. Wenn Sie die Grundlagen noch nicht kennen, lesen Sie zuerst die Schema Markup Grundlagen.
Schauen wir uns an, wie wir unser Event-Beispiel von drei losen Visitenkarten in eine einzige, kohärente digitale Story verwandeln.
// Block 1: Event{ "@context": "https://schema.org", "@type": "Event", "name": "KI-Sichtbarkeits-Gipfel 2024"}// Block 2: Person (irgendwo anders auf der Seite){ "@context": "https://schema.org", "@type": "Person", "name": "Dr. Eva Schmidt"}// Block 3: Ort (noch woanders){ "@context": "https://schema.org", "@type": "Place", "name": "Muster-Congress-Center"}Hier fehlt jede Verbindung. Es ist ein reines Glücksspiel, ob eine Maschine den Zusammenhang herstellt.
Jetzt bauen wir eine einzige, in sich geschlossene Struktur. Wir beginnen mit dem Event als Container. Anschließend füllen wir die Eigenschaften performer und location – nicht mit bloßem Text, sondern mit kompletten, eigenständigen Person- und Place-Entitäten.
{ "@context": "https://schema.org", "@type": "Event", "name": "KI-Sichtbarkeits-Gipfel 2024", "startDate": "2024-11-15T09:00", "endDate": "2024-11-15T17:00", // Hier beginnt die Magie: Wir verschachteln die Person-Entität "performer": { "@type": "Person", "name": "Dr. Eva Schmidt", "jobTitle": "Expertin für semantische Architekturen", "url": "https://beispiel-domain.de/dr-eva-schmidt" }, // Und hier verschachteln wir die Orts-Entität "location": { "@type": "Place", "name": "Muster-Congress-Center", "address": { "@type": "PostalAddress", "streetAddress": "Musterstraße 1", "addressLocality": "Berlin", "postalCode": "10115", "addressCountry": "DE" } }, // Bonus: die Veranstalter-Entität "organizer": { "@type": "Organization", "name": "mehrklicks.de", "url": "https://mehrklicks.de" }}Sehen Sie den Unterschied? Es ist nicht mehr nur eine Liste von Fakten. Es ist eine logische Aussage: Dieses Event hat diesen Sprecher und findet an diesem Ort statt. Eindeutig. Maschinenlesbar. Intelligent.
Was passiert, wenn Dr. Schmidt auf mehreren Events spricht oder das Muster-Congress-Center für verschiedene Veranstaltungen genutzt wird? Müssen wir die Daten jedes Mal kopieren?
Nein. Hier kommt die Eigenschaft @id ins Spiel. Stellen Sie sich @id am besten wie einen einzigartigen digitalen Pass oder eine URL für eine Entität vor. Sobald Sie eine Entität einmal mit einer @id definiert haben, können Sie sie überall sonst referenzieren, anstatt sie komplett neu zu deklarieren.
Beispiel: Wir geben unserem Veranstaltungsort eine ID.
"location": { "@type": "Place", "@id": "https://mehrklicks.de/locations#muster-congress-center", // Der digitale Pass "name": "Muster-Congress-Center", ...}Wenn Sie nun ein zweites Event anlegen, das am selben Ort stattfindet, schreiben Sie nicht den ganzen Place-Block erneut, sondern referenzieren ihn einfach:
"location": { "@id": "https://mehrklicks.de/locations#muster-congress-center"}Das macht Ihren Code schlanker, vermeidet Redundanz und stellt sicher, dass Maschinen verstehen: Es handelt sich um exakt denselben Ort. Sie bauen ein vernetztes System, keinen Haufen von Kopien.
Wir verlassen das Zeitalter, in dem es reichte, Keywords auf einer Seite zu platzieren. Wir treten ein in eine Ära, in der Maschinen nicht mehr nur indexieren, sondern verstehen und empfehlen. Das ist der Kern der Transformation vom Keyword zur Entität.
Nested Schema ist keine technische Spielerei für bessere Rich Results. Es ist eine grundlegende Voraussetzung, um in dieser neuen Ära überhaupt stattzufinden.
Wer heute noch in flachen Strukturen denkt, optimiert für eine Vergangenheit, in der Suchmaschinen bloße Indexierer waren. Die Zukunft gehört denen, die ihre Inhalte als vernetzte Wissensarchitekturen begreifen und Maschinen eine klare, kontextreiche Geschichte erzählen.
Nested Schema ist die Praxis, eine Schema.org-Entität (z. B. eine Person) innerhalb einer Eigenschaft einer anderen Schema.org-Entität (z. B. performer in einem Event) zu definieren, anstatt sie als separate, unverbundene Blöcke auf einer Seite zu platzieren.
Separate Schemas schaffen Ambiguität. Eine Maschine kann die Beziehung zwischen ihnen nur erraten. Verschachtelung definiert diese Beziehung explizit und schafft einen eindeutigen Kontext, der für maschinelles Verständnis unerlässlich ist.
Nein, das hängt von den verfügbaren Eigenschaften der übergeordneten Entität ab. Die Schema.org-Dokumentation legt genau fest, welche Eigenschaften welchen Entitätstyp als Wert erwarten („Expected Type“). So erwartet die performer-Eigenschaft eines Events beispielsweise eine Person oder Organization.
@id ist ein eindeutiger Bezeichner (eine URL oder ein Fragment-Identifier) für eine Entität. Sie müssen es nicht immer verwenden, aber es ist extrem nützlich, wenn Sie dieselbe Entität (z. B. denselben Autor, Veranstaltungsort oder dasselbe Unternehmen) an mehreren Stellen auf Ihrer Website referenzieren wollen, ohne Daten zu duplizieren.
Nein. Während Google ein großer Treiber war, sind strukturierte, kontextreiche Daten die Grundlage für fast alle modernen KI-Systeme. Von Sprachassistenten über Empfehlungs-Engines bis hin zu generativen KI-Modellen wie ChatGPT – sie alle profitieren von Daten, die nicht nur Fakten auflisten, sondern auch deren Beziehungen erklären.
Hören Sie auf, Daten für Webseiten zu schreiben. Fangen Sie an, Wissensgraphen für Maschinen zu bauen. Der erste und wichtigste Schritt ist, Ihre Entitäten nicht mehr nebeneinander, sondern ineinander zu denken. Das ist keine Optimierung. Das ist die neue Architektur des Webs.