Maschinenlesbarer Content ist Inhalt, dessen Bedeutung eine Maschine nicht erraten muss, weil sie ausdrücklich ausgezeichnet ist. Dein Text sagt dem Menschen, wer du bist und was du kannst. Strukturierte Daten sagen es der Maschine: Als Objekt, Eigenschaft und Wert. Seit 2026 zahlt diese Auszeichnung auf zwei Kanäle gleichzeitig ein.
Warum strukturierte Daten seit 2026 doppelt zahlen
Denselben Code liest heute zweierlei Publikum. In der klassischen Suche entscheidet er über die Darstellung: Sternebewertungen, Preise, Öffnungszeiten, Pfadangaben statt roher URL. In KI-Antworten entscheidet er darüber, ob ein System deine Inhalte einer klar identifizierbaren Quelle zuordnen kann. Fehlt diese Zuordnung, wandert dein Wissen trotzdem in die Antwort, nur eben ohne deinen Namen daneben. Du pflegst einmal, die Wirkung fällt zweimal an.
Der Suchkanal ist dabei schmaler geworden. Am 12. Juni 2025 hat Google sieben Auszeichnungstypen aus den Ergebnissen genommen, darunter Book Actions, Estimated Salary und Vehicle Listing. Am 7. Mai 2026 folgten die FAQ-Rich-Results, deren Dokumentation Google am 15. Juni 2026 ganz entfernt hat. Was bleibt, sind die Typen, die Entitäten beschreiben statt nur zu schmücken.
Eine Klarstellung gehört dazu, weil sie in Angeboten oft falsch steht: Strukturierte Daten sind kein Rankingfaktor. Sie verbessern nicht die Position, sondern die Darstellung und das Verständnis. Wer sie als Positionshebel verkauft, misst am Ende die falsche Kennzahl.
Die Grundidee: Aus Zeichenketten werden Entitäten
Auf deiner Seite stehen ein Firmenname, eine Adresse, ein Gründungsjahr. Eine Maschine sieht zunächst nur Text und muss erschließen, ob „Dr. Weber“ eine Person, eine Praxis oder eine Marke bezeichnet. Bei mehrdeutigen Namen, jungen Marken und Fachbegriffen liegt sie dabei falsch.
Strukturierte Daten nehmen ihr das Erschließen ab. Du erklärst: Dieser Name gehört zu einer Organisation, sie hat diese Adresse, dieses Gründungsjahr und diese Profile im Netz. Aus einer Zeichenkette wird eine Entität, also ein Ding mit Eigenschaften und einer festen Kennung.
Diese Kennung ist die wichtigste Eigenschaft im ganzen Konzept: @id. Du beschreibst deine Organisation genau einmal, etwa unter https://deine-domain.de/#organization. Jede weitere Seite verweist nur noch darauf:
{
"@context": "https://schema.org",
"@type": "WebPage",
"@id": "https://deine-domain.de/leistungen/#webpage",
"publisher": { "@id": "https://deine-domain.de/#organization" }
}Über die gemeinsame @id führen Suchmaschinen alle Angaben zu einem Knoten zusammen. Aus 40 Seiten wird eine Entität mit 40 Belegen.
Schema-Typen mit sichtbarer Wirkung
Sechs Typen decken den Alltag der meisten Websites ab:
| Typ | Was er bewirkt |
| Article | Ordnet Beitrag, Autor und Datum zu und ist die Grundlage für Nachrichten- und Discover-Darstellungen. |
| Product | Bringt Preis, Verfügbarkeit und Bewertung ins Suchergebnis. Stärkster sichtbarer Effekt im E-Commerce. |
| LocalBusiness | Liefert Adresse, Öffnungszeiten und Bewertungen und ist das Fundament lokaler Sichtbarkeit. |
| BreadcrumbList | Ersetzt die rohe URL im Ergebnis durch den Seitenpfad. Kleiner Aufwand, sofort sichtbar. |
| FAQPage | Seit dem 7. Mai 2026 ohne Rich Result, ordnet Fragen und Antworten aber weiterhin eindeutig zu. |
| speakable | Markiert die vorlesbare Kernaussage einer Seite. Der Typ steht bei Google noch im Beta-Status und wird angeblich nur für US-Nutzer mit englischem Google Home ausgespielt. |
Vier davon erzeugen eine sichtbare Darstellung, zwei arbeiten unsichtbar weiter. Setze nur, was die Seite wirklich ist: Eine Leistungsseite ist kein Product, und eine Übersicht mit drei Fragen ist keine FAQPage.
Wer bei null anfängt, geht in dieser Reihenfolge vor. Zuerst Organization und, bei lokalem Geschäft, LocalBusiness: Beide beschreiben, wer du bist, und wirken auf jeder einzelnen Seite. Danach BreadcrumbList, weil sie mit dem geringsten Aufwand sofort im Suchergebnis sichtbar wird. Dann der Typ, der zu deinem Kerninhalt passt, also Product im Shop und Article im Magazin. Alles Weitere lohnt erst, wenn diese Basis steht und fehlerfrei ausgeliefert wird.
JSON-LD als Format der Wahl
Drei Formate stehen zur Verfügung: JSON-LD, Microdata und RDFa. Microdata und RDFa verweben die Auszeichnung als Attribute mit dem sichtbaren HTML. Jede Layout-Änderung kann sie zerreißen.
Google empfiehlt ausdrücklich JSON-LD, weil es „die einfachste Lösung für Websitebetreiber ist, um es in großem Umfang zu implementieren und zu pflegen“. In der Praxis überzeugen drei Eigenschaften: Der Code liegt als ein Block getrennt vom Template, er ist an einer einzigen Stelle wartbar, und Google liest ihn im <head> wie im <body>, auch dynamisch per JavaScript eingefügt.
So sieht ein speakable-Block aus:
{
"@context": "https://schema.org",
"@type": "WebPage",
"@id": "https://deine-domain.de/ratgeber/#webpage",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".brand-claim", ".lead-def"]
}
}Die Klassen im cssSelector müssen im HTML wirklich vorkommen, sonst meldet der Test einen Fehler.
Der GEO-Hebel: Warum KI-Systeme eindeutige Quellen bevorzugen
Zuerst die unbequeme Wahrheit, weil sie selten jemand ausspricht. Google schreibt in seiner Anleitung zu generativen KI-Funktionen wörtlich: „Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.“ Es gibt kein AIPage und keine LLM-Eigenschaft.
Der Hebel liegt woanders, und er wirkt auf zwei Ebenen.
Erstens verknüpft die Auszeichnung deine Aussagen mit einer identifizierbaren Quelle. Ein Autorenname allein ist eine Zeichenkette. Derselbe Autor mit url, worksFor und sameAs auf seine öffentlichen Profile ist eine belegte Person. Systeme, die Aussagen einer Quelle zuordnen müssen, arbeiten mit dem zweiten Fall zuverlässiger. Praktisch heißt das: Über die Nennung deiner Marke in einer KI-Antwort entscheidet nicht allein die Qualität deines Textes, sondern auch, ob dahinter eine Organisation mit Historie steht oder nur eine URL.
Zweitens erzwingt die Auszeichnung Klarheit im Text. Wer einen Begriff als DefinedTerm auszeichnet, muss ihn in einem Satz definieren können. Genau solche Sätze greifen KI-Systeme auf. Bei uns hängt daran das gesamte Glossar: 90 Begriffserklärungen, jede als DefinedTerm an eine gemeinsame Hülle gehängt, dazu ein knowsAbout an der Organisation, das auf die wichtigsten dieser Begriffe zeigt. Damit ist maschinenlesbar hinterlegt, welche Themen wir belegbar bearbeiten, statt es nur zu behaupten. Diese Arbeit trägt später die Sichtbarkeit in KI-Antworten, weil dort Entitäten zählen und nicht Keyword-Dichte.
Typische Fehler aus der Agentur-Praxis
Markup ohne sichtbares Gegenstück. Ausgezeichnet wird, was auf der Seite steht. Bewertungen ohne Bewertungen, FAQ ohne sichtbare Fragen und Preise, die im Text fehlen, verstoßen gegen Googles Richtlinien und können eine manuelle Maßnahme auslösen. Der häufigste Fall in unserer Arbeit als SEO- und GEO-Agentur aus München: Ein Plugin zeichnet automatisch aus, was der Redakteur nie geschrieben hat.
Dubletten statt Verweise. Definiert jede Seite ihre eigene Organisation, entstehen viele gleich benannte Kandidaten statt einer Entität. Das passiert fast immer dann, wenn zwei Systeme parallel Schema ausgeben, etwa ein SEO-Plugin und ein Theme. Ein Blick in den Quelltext zeigt es sofort: Zwei <script type=“application/ld+json“>-Blöcke mit demselben Typ und unterschiedlichen @id.
Veraltete Typen und falsche Erwartungen. Abgeschaltete Darstellungen machen die Auszeichnung nicht ungültig. Dein FAQ-Markup bleibt korrektes schema.org und darf stehen bleiben. Was du streichen solltest, ist die Erwartung an ein Rich Result, das es nicht mehr gibt.
Kennungen, die sich still verändern. Eine @id taugt nur so viel wie ihre Konstanz. Steht in einer Vorlage http:// statt https://, eine Variante mit www oder fehlt der Schrägstrich am Ende, entstehen aus einem Knoten zwei. Der Fehler fällt niemandem auf, weil beide Blöcke gültig sind. Behandle Kennungen deshalb wie Konstanten: Einmal festlegen, dann nie wieder anfassen, auch bei einem Relaunch nicht.
Validieren und dranbleiben
Zwei Prüfungen gehören zu jedem Deploy. Der Rich-Results-Test zeigt, was Google aus der Seite herausliest und für welche Darstellung sie infrage kommt. Ein Schema-Validator prüft, ob der Code formal korrekt ist, auch bei Typen, die Google nicht auswertet.
Beide beantworten allerdings nur die Frage, ob der Code gültig ist, nicht ob er die Wahrheit sagt. Ein Preis von letztem Jahr, veraltete Öffnungszeiten und ein Autor, der längst nicht mehr im Haus ist, bestehen jede technische Prüfung. Diesen Abgleich mit der Realität macht nur ein Mensch.
Wichtiger als die einmalige Prüfung ist die Wiederholung. Strukturierte Daten fallen lautlos aus: Ein Theme-Update, ein neuer Cache oder eine geänderte Vorlage entfernen einen kompletten Block, ohne dass im Frontend etwas fehlt. Auffallen würde es erst Wochen später an weniger Rich Results. Ein praktikabler Rhythmus besteht aus zwei Terminen: Nach jedem Deploy die geänderten Vorlagen prüfen, einmal im Monat je eine Seite pro Seitentyp, also Startseite, Leistungsseite, Artikel und Produkt. Deshalb gehört die Auszeichnung in dein laufendes Monitoring und nicht in ein einmaliges Projekt.
Strukturierte Daten machen dich nicht sichtbar. Sie machen dich eindeutig. Und Eindeutigkeit ist die Voraussetzung dafür, dass Google und KI-Systeme dich als das erkennen, was du bist.
Quellen
- Henry Hsu: Simplifying the search results page. Google Search Central Blog, 12.06.2025.
- Google Search Central: Documentation updates (Einträge vom 08.05.2026 und 15.06.2026 zur Abschaltung der FAQ-Rich-Results).
- Google Search Central: Intro to structured data markup in Google Search.
- Google Search Central: Top ways to ensure your content performs well in Google’s AI experiences. Stand 10.07.2026.
- Google Search Central: Speakable (BETA) schema markup. Stand 10.12.2025.
