Schema Markup für AEO: Welche Typen KI wirklich liest

Dienstagabend, kurz nach zehn. Zweiter Espresso des Abends, der Laptop sollte eigentlich schon zu sein. Ich will nur noch kurz in die Search Console, Routine-Blick auf die Produkt-Snippets, dreißig Sekunden, dann Feierabend. Dann sehe ich die Zahl.

Einer unserer Kurse, regulärer Preis 1.990 Euro, steht im Google-Snippet mit 1,99 €.

Ich starre auf den Bildschirm und denke erst an einen Cache-Fehler. Also Rich Results Test geöffnet, Live-URL geprüft. Kein Cache-Fehler. Google hatte den Preis exakt so gelesen, wie er im Schema stand: „1.990". Nur dass Google den Punkt nicht als deutschen Tausenderpunkt interpretiert, sondern als Dezimaltrenner. Aus tausendneunhundertneunzig Euro wurde ein Euro neunundneunzig. Ein Kurs, an dem monatelange Arbeit hängt, stand für den Preis einer Apfelschorle im Suchergebnis.

Ich habe Laura einen Screenshot geschickt, mit genau einem Wort: „Guck." Ihre Antwort kam nach zehn Sekunden: „Bitte sag mir, dass das niemand gekauft hat."

Der Fix war ein Einzeiler. Ein regulärer Ausdruck, der alles außer Ziffern und Komma aus dem Preisfeld wirft, bevor es ins Schema geht. Aus „1.990" wird „1990", Google liest den Preis korrekt, Snippet repariert. Aber die Lektion aus diesem Abend ist größer als der Fix: Schema Markup ist Präzisionsarbeit. Ein einziges Zeichen ändert die Bedeutung komplett. Und weil 2026 nicht mehr nur Google dein Schema liest, sondern jede Answer Engine von ChatGPT bis Perplexity, entscheidet diese Präzision darüber, ob die Maschinen dich korrekt zitieren, falsch zitieren oder gar nicht.

Warum braucht KI dein Schema Markup überhaupt?

Ein Sprachmodell kann Text lesen, klar. Aber Lesen und Verstehen sind zwei verschiedene Baustellen. Wenn auf deiner Seite „Robby Schadt" steht, weiß die Maschine erstmal nicht: Ist das der Autor? Der Gründer? Ein zitierter Experte? Und welche „adcompany" ist gemeint, wenn es mehrere Firmen mit ähnlichen Namen gibt? Genau dieses Problem heißt Entity-Auflösung, und Schema Markup ist die sauberste Antwort darauf: Du sagst der Maschine explizit, welche Entitäten auf der Seite vorkommen und in welcher Beziehung sie zueinander stehen.

JSON-LD ist dafür das Format der Wahl: ein JSON-Block im Head der Seite, getrennt vom sichtbaren Text, basierend auf dem Linked-Data-Modell. Google nennt es das am einfachsten zu wartende Format, und für KI-Parser ist es ein gedeckter Tisch: keine Interpretation nötig, die Fakten stehen strukturiert da.

Für Answer Engine Optimization (AEO) kommt ein zweiter Punkt dazu, den viele übersehen: ChatGPT füttert seine Live-Suche unter anderem aus dem Bing-Index. Und Bing gewichtet klassische Struktursignale stärker als Google, sauberes HTML, präzise Meta-Tags, strukturierte Daten. In Deutschland liegt Bing im Juli 2026 bei 7,12% Suchmaschinen-Marktanteil (StatCounter, Juli 2026), klein gegen Googles 85,59%, aber als ChatGPT-Zulieferer weit wichtiger als die nackte Zahl vermuten lässt. Wer Schema sauber baut, baut für beide Welten gleichzeitig.

Das große Ganze, also wie ChatGPT und Perplexity überhaupt entscheiden, wen sie zitieren, habe ich im Hub-Artikel GEO 2026 auseinandergenommen. Dieser Post hier ist die Vertiefung für genau eine Frage: Welche Schema-Typen lohnen sich 2026 noch, und welche kannst du streichen?

Welche Schema-Typen liest KI 2026 wirklich?

Nach dem Preis-Abend habe ich unser komplettes Schema-Setup neu aufgebaut, Typ für Typ, und dabei radikal aussortiert. Das hier ist die Liste, die übrig geblieben ist. Nicht die 800 Typen, die schema.org kennt, sondern die Handvoll, die für AEO tatsächlich Arbeit leistet.

Organization und Person sind das Fundament, weil sie die Entitäten definieren, auf die alles andere zeigt. Entscheidend ist das sameAs-Feld: Links zu Wikidata, Wikipedia, deinen Social-Profilen. Damit verbindest du deine Website-Entität mit dem Knowledge Graph, den die Modelle ohnehin kennen. Eine Organisation ohne sameAs ist für die Maschine ein Fremder ohne Ausweis.

Article beziehungsweise BlogPosting trägt zwei Signale, die 2026 schwerer wiegen als je: den Autor als Person-Entität (nicht als nackten String) und das dateModified-Feld. Answer Engines bevorzugen frische Quellen deutlich, ein Artikel mit gepflegtem dateModified schlägt denselben Artikel mit totem Datum. Wenn du Inhalte aktualisierst, muss das Schema das mitbekommen, sonst verschenkst du das Update.

FAQPage bleibt einer der meistmissverstandenen Typen, dazu gleich mehr im Abschnitt über tote Typen. Kurzfassung: Als sichtbares Google-Feature ist es fast überall abgeschaltet, als maschinenlesbare Frage-Antwort-Struktur ist es lebendig wie nie. Eine sauber formulierte 40-80-Wörter-Antwort im FAQPage-Schema ist exakt das Format, das eine Answer Engine als Antwort ausspielen kann. Wie du diese Antworten schreibst, damit sie zitierfähig sind, steht im Detail in Answer-First-Copywriting.

WebPage mit Speakable ist der Underdog der Liste. Speakable markiert per CSS-Selektor die 2-3 Passagen einer Seite, die sich als vorgelesene oder extrahierte Antwort eignen. Offiziell noch Beta bei Google, gedacht für Sprachassistenten. Aber die Logik dahinter, „diese Sätze sind die Essenz der Seite", ist genau die Information, die ein KI-Parser sucht. Wir nutzen es auf der adcompany-Startseite und zeigen damit auf die Definitions-Sektion direkt unter dem Einstieg: die Passage, die erklärt, was adcompany ist, in Sätzen unter 25 Wörtern.

Product ist Pflicht auf jeder Seite, die etwas Bezahlbares anbietet, mit Preis, Währung, Verfügbarkeit und priceValidUntil. Und ja: Das ist der Typ, der mir den Abend aus der Eingangsstory beschert hat. Preisfelder sind der Ort, an dem deutsche Formatierung und internationale Parser kollidieren.

Welche Schema-Typen sind tot und welche leben weiter?

Hier muss man ehrlich differenzieren, denn im Netz kursieren beide Extreme: „Schema ist tot" und „bau alles ein, schadet ja nicht". Beides ist falsch. Was wirklich passiert ist:

Google hat im August 2023 die HowTo- und FAQ-Rich-Results eingestellt beziehungsweise drastisch eingeschränkt. FAQ-Snippets erscheinen seitdem nur noch für ausgewählte autoritative Seiten, HowTo-Anzeigen sind komplett raus. Im Juni 2025 folgte der nächste Schnitt: Google kündigte das Ende weiterer Typen an, darunter Course-Info-Rich-Results, im September 2025 verschwand auch die Doku, weil diese Typen in den Suchergebnissen schlicht nicht mehr angezeigt werden.

Die entscheidende Unterscheidung, die dabei fast immer verloren geht: Rich Result ist nicht gleich Schema-Typ. Gestorben ist die visuelle Sonderdarstellung in der Google-Suche, die ausklappbaren FAQ-Boxen, die Schritt-Anleitungen mit Bildern, die Kurs-Karussells. Der Schema-Typ selbst ist weiterhin gültiges schema.org-Vokabular und wird von Parsern weiterhin gelesen. Ein HowTo-Block klassifiziert deine Anleitung als Anleitung, ein Course-Block klassifiziert deinen Kurs als Kurs, auch wenn Google daraus kein hübsches Suchergebnis mehr baut.

Was heißt das praktisch? Drei Regeln:

• ·Baue keinen Typ mehr ein, nur um ein Google-Rich-Result zu jagen, das es nicht mehr gibt. Der Aufwand für HowTo-Markup mit Bildern pro Schritt lohnt sich 2026 nicht mehr.
• ·Wirf vorhandene Typen nicht panisch raus. Als Entity-Klassifikation für KI-Parser schaden sie nicht, solange sie den sichtbaren Inhalt korrekt beschreiben.
• ·Investiere die gesparte Zeit in die Typen aus der Tabelle oben. Organization, Person, Article, FAQPage: Das ist das Fundament, das beide Welten bedient.

Bei uns heißt das konkret: Produktseiten laufen auf Product-Schema mit echten Preisen statt auf Course-Markup, das Google ohnehin ignoriert. Und die FAQ-Blöcke bleiben, weil sie für Answer Engines arbeiten, nicht für Google-Sternchen.

Wie baust du einen Entity-Graph mit @id-Ankern?

Jetzt zum Teil, der den größten Unterschied macht und den die wenigsten umsetzen: @id-Anker. Ohne sie hast du eine Sammlung loser Schema-Blöcke. Mit ihnen hast du einen Graph, in dem jede Entität genau einmal definiert wird und alle anderen Blöcke auf diese Definition zeigen.

Ein @id ist eine stabile URI, die eine Entität eindeutig benennt, typischerweise deine Domain plus ein Fragment. So sieht das Grundgerüst aus:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://deinedomain.de/#organization",
      "name": "Deine Firma GmbH",
      "url": "https://deinedomain.de",
      "founder": { "@id": "https://deinedomain.de/#person-gruender" },
      "sameAs": [
        "https://www.wikidata.org/wiki/Q...",
        "https://www.instagram.com/deinprofil/"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://deinedomain.de/#person-gruender",
      "name": "Vorname Nachname",
      "worksFor": { "@id": "https://deinedomain.de/#organization" },
      "sameAs": ["https://www.youtube.com/@deinkanal"]
    },
    {
      "@type": "WebSite",
      "@id": "https://deinedomain.de/#website",
      "publisher": { "@id": "https://deinedomain.de/#organization" }
    }
  ]
}

Der Effekt: Wenn dein Blog-Post ein BlogPosting-Schema trägt und als Autor nur `{ "@id": "https://deinedomain.de/#person-gruender" }` referenziert, muss die Maschine nicht raten, ob der Autor dieselbe Person ist wie der Gründer auf der Startseite. Es ist per Definition dieselbe Entität. Genau so läuft es bei uns live: Jeder adcompany-Blog-Post referenziert den Anker #person-robby, der genau einmal auf der Startseite definiert ist, verbunden mit #organization und #website. Ein Graph, drei Knoten, null Mehrdeutigkeit.

Zwei Dinge machen den Graph komplett. Erstens sameAs nach außen: Der Verweis auf ein Wikidata-Item verankert deine Entität in dem Knowledge Graph, aus dem Sprachmodelle ihr Weltwissen beziehen. Zweitens Konsistenz über alle Oberflächen: Firmenname, Gründungsjahr und Beschreibung müssen auf Website, Wikidata und in deiner llms.txt identisch sein. Widersprechen sich deine Quellen, sinkt das Vertrauen der Maschine in jede einzelne davon.

Falls dir das nach Entwickler-Arbeit klingt: Es ist weniger, als du denkst. Ich habe unseren kompletten Entity-Graph an einem Abend mit Claude Code gebaut, beschreiben was rein soll, generieren lassen, validieren, fertig. Genau dieses Selbst-Bauen ohne Programmier-Vorwissen ist übrigens der Kern der NoCode Mastery, falls du solche Systeme lieber einmal richtig lernst statt sie zu erraten.

Welche Schema-Fehler kosten dich Sichtbarkeit?

Zurück zu meinem Dienstagabend. Der Preis-Fehler war kein Exot, sondern ein Vertreter einer ganzen Fehlerklasse: Schema, das syntaktisch gültig ist und trotzdem etwas anderes sagt, als du meinst. Der Validator zeigt grün, die Bedeutung ist falsch. Das sind die fünf, die ich seitdem bei jedem Audit zuerst prüfe:

Der Preis-Fall hat für mich noch eine zweite Ebene: Wenn du bezahlten Traffic auf so eine Seite schickst, zahlst du doppelt, einmal fürs Klicken und einmal für das Vertrauen, das ein widersprüchliches Preissignal kostet. Warum saubere Conversion- und Preissignale über Erfolg und Scheitern ganzer Kampagnen entscheiden, habe ich im Google-Ads-Guide für Coaches und Berater an echten Konten durchgespielt.

Wie testest du, ob dein Schema funktioniert?

Mein Test-Ritual nach jedem Schema-Change dauert keine zehn Minuten:

• ·Schema Markup Validator: prüft die Syntax gegen das schema.org-Vokabular. Pflicht nach jeder Änderung.
• ·Google Rich Results Test: zeigt, wie Google die Live-URL parst, inklusive der Werte. Hier wäre mein 1,99-Euro-Fehler sofort sichtbar gewesen, wenn ich nach dem Deploy hingeschaut hätte.
• ·Search Console: die Berichte unter „Verbesserungen" zeigen Fehler über alle Seiten hinweg, nicht nur die eine, die du gerade prüfst.
• ·Der Maschinen-Test: Frag ChatGPT oder Perplexity nach deiner Firma, deinem Gründer, deinem Produktpreis. Kommen die Fakten korrekt zurück, arbeitet dein Graph. Kommen sie falsch zurück, weißt du, wo du suchen musst.

Und dann der wichtigste Punkt, der kein Tool ist: Wiederholung. Schema ist kein Projekt, das du einmal abschließt. Jede neue Seite, jeder Preis-Change, jedes Rebranding fasst den Graph an. Seit dem Dienstagabend läuft der Rich-Results-Check bei uns nach jedem Deploy, der Preise berührt. Einmal 1,99 € reicht.

Die komplette GEO-Checkliste als PDF

Schema Markup ist einer von mehreren Hebeln, mit denen du in KI-Antworten sichtbar wirst. Wenn du das ganze System systematisch abarbeiten willst, ohne dir die Maßnahmen aus fünf Blog-Posts zusammenzusuchen, habe ich alles in eine Checkliste gepackt: 15 Maßnahmen als 12-Seiten-PDF, von der Entity-Definition über llms.txt bis zum Schema-Setup, in der Reihenfolge, in der sie den größten Unterschied machen.

→ GEO-Checkliste als PDF herunterladen

Kostenlos, mit E-Mail. Kein Spam, nur die Checkliste plus ein Update, wenn sich bei den Answer Engines wieder etwas Grundlegendes ändert.

FAQ

Robby Schadt

9,5 Mio€ verwalteter Ad-Spend auf META · 9.000+ Leads/Monat · Speaker: Contra, Founder Summit, DRX, OMKO, IMK · Alumni: Investment Punk · Weissenhaus & Champions Mastermind