Folgendes Szenario: du wirst zu einem wichtigen Gespraech eingeladen. Thema: die Zukunft deiner Website. Es geht um alles. Am Tisch sitzt kein Mensch, sondern ein grosses Sprachmodell. Es hat deinen Quellcode gelesen. Alle 847 Zeilen davon. Und jetzt entscheidet es, ob es dich zitiert oder ignoriert.
Klingt dramatisch? Ist es aber nicht. Allerdings passiert genau das gerade, jeden Tag, millionenfach. Wenn ChatGPT, Google AI Overviews oder Perplexity eine Antwort zusammenstellen, durchsuchen sie den Index nach Seiten, aus denen Fakten zuverlaessig extrahiert werden koennen. Seiten mit sauberem semantischen Markup gewinnen. Seiten mit divid Suppe verlieren und verschwinden aus der Sicht des jeweiligen Users.
Dieser Dreamcodes Guide ist dein Fahrplan. Wir schauen uns an, wie LLMs HTML verarbeiten, warum JSON LD dabei eine Schluesselfunktion uebernimmt, und wie du deine Seiten so baust, dass KI-Systeme dich nicht nur finden, sondern auch zitieren wollen. Kein Buzzword Bingo, keine leeren Versprechen, nur Code, Konzepte und konkrete Beispiele.
Was du in diesem Dreamcodes Guide lernst:
- Wir zeigen dir wie LLMs HTML lesen und welche Signale dabei entscheidend sind
- Was semantisches HTML5 wirklich bedeutet (und was es nicht bedeutet)
- Wie JSON LD und Schema.org als Praezisionssprache fuer Maschinen funktionieren
- Welche Fehler selbst erfahrene Entwickler noch 2026 machen
- Praxisnahe Code Beispiele, die du sofort einsetzen kannst
- Expertentipps fuer Featured Snippets und KI-Zitate
- Einen vollstaendigen FAQ Bereich fuer alle deine noch offenen Fragen
Wie Sprachmodelle Webseiten wirklich lesen
Hier ist ein weit verbreitetes Missverstaendnis: Viele Entwickler denken, KI-Systeme wuerden Webseiten genauso aufnehmen wie ein Mensch, der einen Blog-Artikel liest. Von oben nach unten, Wort fuer Wort, Bild fuer Bild.
Falsch. Komplett falsch.
Grosse Sprachmodelle arbeiten mit Textreprasentationen. Wenn ein Crawler eine Seite fuer ein LLM aufbereitet, wird das HTML in eine bereinigte Textform umgewandelt, oft schlicht linear: Heading, Paragraph, Heading, Paragraph, Table als flache Struktur. Was bleibt, sind Muster, Relationen und semantische Signale.
Was ein LLM tatsaechlich sieht
Nimm eine typische Produktseite. Ohne semantisches Markup sieht das Modell so etwas:
| Nike Air Max 270 129,99 Grosse: 40 41 42 43 44 Farbe: Schwarz Weiss Neu | Auf Lager |
Fuenf Zeilen, null Kontext. Ist das ein Preis? Ein Name? Eine Kategorie? Das Modell muss raten. Und rate mal, was passiert, wenn es raet: Es macht Fehler, oder es ignoriert die Seite einfach.
Mit korrektem Schema.org Markup hingegen liest das Modell:
| { „@type“: „Product“, „name“: „Nike Air Max 270“, „offers“: { „@type“: „Offer“, „price“: „129.99“, „priceCurrency“: „EUR“, „availability“: „InStock“ }, „color“: „Schwarz“, „size“: „40-44“ } |
Jetzt hat das Modell Beziehungen. Es weiss: Das ist ein Produkt, der Preis ist 129,99 Euro, es ist vorratig. Wenn jemand fragt Was kostet der Nike Air Max 270?, kann das Modell diese Seite mit Zuversicht zitieren.
| Kernprinzip des LLM Lesens LLMs belohnen Eindeutigkeit. Je klarer die Beziehungen zwischen Entitaeten in deinem Markup, desto hoeher die Wahrscheinlichkeit, dass dein Inhalt korrekt extrahiert und zitiert wird. Ambiguitat ist der Feind. |
Der Unterschied zwischen Googles altem Bot und modernen LLMs
| Kriterium | Google-Bot (klassisch) | LLM-basierte KI |
| Fokus | Keywords, Backlinks, PageRank | Entitaeten, Relationen, Kontext |
| Markdown Verarbeitung | Begrenzt | Stark (strukturierte Daten bevorzugt) |
| Tabellen | Oft ignoriert | Hochwertige Wissensquelle |
| Quellennachweis | URL basiert | Semantisch validiert |
| Schema.org | Hilfreich fuer Rich Snippets | Zentral fuer Faktenextraktion |
| Fehlertoleranz | Mittel | Gering bei Ambiguitat |
Semantisches HTML5: Mehr als nur ein Schlagwort
Semantisches HTML ist einer dieser Begriffe, die jeder kennt und kaum jemand wirklich versteht. Manche denken, es bedeute einfach, die richtigen Tags zu verwenden. Andere glauben, es sei ein nettes Feature fuer Barrierefreiheit. Beides ist richtig, aber unvollstaendig.
Semantisches HTML5 bedeutet: Du kommunizierst die Bedeutung deiner Inhalte direkt im Markup. Nicht nur, was etwas aussieht, sondern was es ist.
Der Unterschied im Code
Schlechtes Beispiel, das man leider noch 2026 zu oft sieht:
| <div class=“header“> <div class=“nav“> <div class=“nav-item“>Startseite</div> <div class=“nav-item“>Blog</div> </div> </div> <div class=“content“> <div class=“title“>Mein Blogpost</div> <div class=“text“>Lorem ipsum…</div> </div> |
Dieses Markup ist fuer Menschen lesbar, weil wir den Klassen Namen verstehen. Fuer eine Maschine ist es eine Wueste aus generischen Containern. Kein Signal, keine Hierarchie, kein Kontext.
Das semantische Gegenstueck:
| <header> <nav aria-label=“Hauptnavigation“> <ul> <li><a href=“/“>Startseite</a></li> <li><a href=“/blog“>Blog</a></li> </ul> </nav> </header> <main> <article> <h1>Mein Blogpost</h1> <p>Lorem ipsum…</p> </article> </main> |
Jetzt weiss jedes System sofort: Das ist der Haupt Inhaltsbereich. Das ist ein eigenstaendiger Artikel. Das ist die primaere Ueberschrift. Diese Informationen sind fuer LLMs Gold.
Die wichtigsten semantischen HTML5-Elemente im Ueberblick
| Element | Bedeutung | Relevanz fuer LLMs |
| <header> | Kopfbereich der Seite oder Sektion | Mittel |
| <main> | Primaerer Inhalt der Seite | Hoch |
| <article> | Eigenstaendiger, redistributierbarer Inhalt | Sehr hoch |
| <section> | Thematisch zusammengehoeriger Bereich | Hoch |
| <nav> | Navigationsbereich | Mittel |
| <aside> | Ergaenzender Inhalt, Sidebar | Niedrig |
| <footer> | Abschlussbereich | Niedrig |
| <figure> + <figcaption> | Bild mit Beschreibung | Hoch fuer Bildverstaendnis |
| <time datetime=“…“> | Maschinenlesbare Zeitangabe | Sehr hoch |
| <address> | Kontaktinformationen | Hoch fuer lokale Suche |
| <mark> | Hervorgehobener Text mit Relevanz | Mittel |
| <abbr title=“…“> | Abkuerzung mit Vollform | Hoch fuer Fachbegriffe |
Heading Hierarchie: Der unsichtbare Inhaltsbaum
Eine saubere Heading Hierarchie ist fuer LLMs das, was ein Inhaltsverzeichnis fuer einen Buchleser ist: eine sofort verstaendliche Karte des Inhalts. Die Regel ist simpel und wird dennoch staendig gebrochen:
| <!– Richtig: Klare Hierarchie, keine Luecken –> <h1>Hauptthema der Seite</h1> <h2>Unterabschnitt 1</h2> <h3>Detail zu Unterabschnitt 1</h3> <h2>Unterabschnitt 2</h2> <h3>Detail A</h3> <h3>Detail B</h3> <!– Falsch: Luecken, mehrere H1s, Missbrauch fuer Styling –> <h1>Titel</h1> <h3>Abschnitt</h3> <!– H2 fehlt! –> <h1>Zweiter grosser Titel</h1> <!– Nur ein H1 pro Seite! –> |
Pro Tipp: Tools wie headingsMap fuer Chrome zeigen dir die Heading Struktur deiner Seite als Baumansicht. Schau sie dir an. Wenn es chaotisch aussieht, sieht es fuer KI genauso chaotisch aus.
JSON LD und Schema.org: Die Praezisionssprache fuer Maschinen
Wenn semantisches HTML5 die Grammatik ist, dann ist Schema.org das Woerterbuch. Und JSON LD ist die Art, wie du beides zusammenbringst.
Schema.org ist ein gemeinsames Vokabular, das von Google, Microsoft, Yahoo und Yandex entwickelt wurde. Es definiert Tausende von Entitaeten, von Person und Organization bis hin zu Recipe, Event und FAQPage. Wenn du einer Seite sagst, sie sei ein Rezept, und das im Schema.org Format, dann versteht nicht nur Google das, sondern auch jede andere Maschine, die dieses Vokabular kennt.
JSON-LD (JSON for Linking Data) ist das empfohlene Format fuer strukturierte Daten. Es wird in einem <script> Tag im <head> oder <body> der Seite eingebettet, beeinflusst das visuelle Layout ueberhaupt nicht und kann problemlos von einem CMS generiert werden.
JSON LD: Grundstruktur und erstes Beispiel
| <script type=“application/ld+json“> { „@context“: „https://schema.org“, „@type“: „Article“, „headline“: „Semantisches HTML fuer KI-Suchmaschinen“, „author“: { „@type“: „Person“, „name“: „Max Muster“, „url“: „https://example.com/autor/max“ }, „datePublished“: „2025-01-15“, „dateModified“: „2025-06-01“, „publisher“: { „@type“: „Organization“, „name“: „Dreamcodes“, „logo“: { „@type“: „ImageObject“, „url“: „https://dreamcodes.de/logo.png“ } }, „description“: „Wie JSON-LD und semantische HTML5-Strukturen…“, „mainEntityOfPage“: { „@type“: „WebPage“, „@id“: „https://dreamcodes.de/semantisches-html-ki“ } } </script> |
Was passiert hier? Wir teilen der Maschine mit: Dies ist ein Artikel. Er hat eine Ueberschrift, einen Autor mit eigenem Profil, ein Datum, einen Herausgeber mit Logo und eine eindeutige ID. Keine Interpretation noetig.
Die wichtigsten Schema.org Typen fuer deinen Use Case
| Schema-Typ | Wann verwenden | Wichtigste Properties |
| Article / BlogPosting | Redaktionelle Inhalte, Guides | headline, author, datePublished, description |
| FAQPage | FAQ-Seiten, Ratgeber | mainEntity mit Question + Answer |
| HowTo | Anleitungen, Tutorials | step mit HowToStep |
| Product | E-Commerce, Software | name, offers, review, brand |
| Organization | Firmen Homepage | name, url, logo, contactPoint, sameAs |
| Person | Autoren Profile | name, jobTitle, worksFor, sameAs |
| LocalBusiness | Lokale Unternehmen | address, geo, openingHours, telephone |
| BreadcrumbList | Navigation, Kategorieseiten | itemListElement mit ListItem |
| Event | Veranstaltungen | name, startDate, location, organizer |
| SoftwareApplication | App-Seiten | applicationCategory, operatingSystem, offers |
FAQ Schema: Der direkte Weg in die KI Antworten
Das FAQPage Schema ist fuer unsere Zwecke besonders spannend. Es strukturiert Fragen und Antworten so klar, dass LLMs sie direkt fuer ihre Antworten nutzen koennen. Hier ein vollstaendiges Beispiel:
| <script type=“application/ld+json“> { „@context“: „https://schema.org“, „@type“: „FAQPage“, „mainEntity“: [ { „@type“: „Question“, „name“: „Was ist JSON LD?“, „acceptedAnswer“: { „@type“: „Answer“, „text“: „JSON LD steht fuer JSON for Linking Data. Es ist…“ } }, { „@type“: „Question“, „name“: „Wie binde ich Schema.org in WordPress ein?“, „acceptedAnswer“: { „@type“: „Answer“, „text“: „In WordPress gibt es mehrere Moeglichkeiten…“ } } ] } </script> |
Wichtig: Der Text im text Feld der Antwort sollte die Antwort komplett und selbst erklaerend enthalten. Wenn ein LLM diese Seite durchsucht und eine Frage zu JSON LD findet, liest es genau diesen Text.
Tabellen als Wissensdatenbank fuer KI Systeme
Hier ist eine Info, die viele ueberrascht: Gut strukturierte HTML Tabellen gehoeren zu den wertvollsten Elementen fuer LLMs. Warum? Weil sie bereits eine relationale Struktur codieren. Zeile fuer Zeile, Spalte fuer Spalte, Kopfzeile fuer Kontext.
Ein LLM, das eine Tabelle verarbeitet, sieht: Jede Zeile ist eine Entitaet. Jede Spalte ist eine Eigenschaft. Der Kontext kommt aus dem th Element. Das ist strukturiertes Wissen, fast wie eine Mini-Datenbank.
So baust du KI freundliche Tabellen
| <!– Schlechte Tabelle ohne semantische Struktur –> <table> <tr><td>Schema-Typ</td><td>Verwendung</td></tr> <tr><td>Article</td><td>Blog-Artikel</td></tr> </table> <!– Optimale Tabelle fuer KI-Extraktion –> <table> <caption>Ueberblick ueber haeufig genutzte Schema.org-Typen</caption> <thead> <tr> <th scope=“col“>Schema-Typ</th> <th scope=“col“>Hauptverwendung</th> <th scope=“col“>Wichtigste Properties</th> </tr> </thead> <tbody> <tr> <td>Article</td> <td>Redaktionelle Inhalte</td> <td>headline, author, datePublished</td> </tr> </tbody> </table> |
Der Unterschied liegt in vier Details: dem caption Element (erklaert die Tabelle), dem thead (kennzeichnet Kopfzeilen), dem scope Attribut (sagt, fuer was die Kopfzeile gilt) und der tbody Trennung (trennt Kopf von Daten). Das sind kleine Aenderungen mit grosser Wirkung.
| Praxis Tipp aus eigener Erfahrung Vergleichstabellen (A vs. B, Produkt X vs. Produkt Y) werden von LLMs besonders haeufig zitiert. Der Grund ist simpel: Sie liefern bereits das, was ein Nutzer bei einem Vergleich moechte. Wenn du Vergleichsinhalte erstellst, investiere Zeit in eine saubere Tabellenstruktur. Es lohnt sich. |
Breadcrumbs und Site Architektur als KI Signal
Breadcrumbs sind nicht nur Navigationshilfe fuer Menschen. Fuer KI Systeme sind sie ein Kontext Anker. Sie sagen: Diese Seite gehoert zu dieser Kategorie, die zu dieser uebergeordneten Kategorie gehoert.
Wenn eine KI weiss, dass ein Artikel in Blog > Technik > SEO eingeordnet ist, kann sie seine Relevanz fuer technische SEO-Anfragen besser einschaetzen.
| <nav aria-label=“Breadcrumb“> <ol itemscope itemtype=“https://schema.org/BreadcrumbList“> <li itemprop=“itemListElement“ itemscope itemtype=“https://schema.org/ListItem“> <a itemprop=“item“ href=“https://dreamcodes.de“> <span itemprop=“name“>Startseite</span> </a> <meta itemprop=“position“ content=“1″> </li> <li itemprop=“itemListElement“ itemscope itemtype=“https://schema.org/ListItem“> <a itemprop=“item“ href=“https://dreamcodes.de/seo“> <span itemprop=“name“>SEO</span> </a> <meta itemprop=“position“ content=“2″> </li> <li itemprop=“itemListElement“ itemscope itemtype=“https://schema.org/ListItem“> <span itemprop=“name“>Semantisches HTML</span> <meta itemprop=“position“ content=“3″> </li> </ol> </nav> |
Alternativ geht das auch per JSON LD im Head, was etwas sauberer ist und HTML und Daten trennt:
| <script type=“application/ld+json“> { „@context“: „https://schema.org“, „@type“: „BreadcrumbList“, „itemListElement“: [ {„@type“: „ListItem“, „position“: 1, „name“: „Startseite“, „item“: „https://dreamcodes.de“}, {„@type“: „ListItem“, „position“: 2, „name“: „SEO“, „item“: „https://dreamcodes.de/seo“}, {„@type“: „ListItem“, „position“: 3, „name“: „Semantisches HTML“} ] } </script> |
Die haeufigsten Fehler und wie du sie vermeidest
Jetzt kommen wir zum Teil, den ich persoenlich am wichtigsten finde: Was laeuft schief. Ich habe in den letzten Jahren viele Websites analysiert, und die gleichen Fehler tauchen immer wieder auf. Hier ist die ehrliche Liste.
Fehler 1: JSON LD einbinden, aber Inhalt widerspricht sich
Du hast ein Rezept-Schema mit prepTime: PT30M (30 Minuten), aber im Artikel steht Diese Zubereitung dauert ungefaehr eine Stunde. Das Modell sieht den Widerspruch. Im besten Fall ignoriert es das Schema, im schlechtesten Fall wertet es die Seite als unzuverlaessig.
Loesung: Schema Daten und Seiteninhalt muessen uebereinstimmen. Immer. Kein Meinungsmanagement zwischen Code und Text.
Fehler 2: Leere oder generische Beschreibungsfelder
description: Willkommen auf unserer Website. ist keine Beschreibung. Es ist Platzhalterkaffee. LLMs nutzen die description Property, um schnell zu entscheiden, ob eine Seite fuer eine Anfrage relevant ist.
Loesung: Die description sollte die Kernaussage der Seite in ein bis zwei Saetzen klar formulieren. Spezifisch, informativ, keywordreich ohne Keyword-Stuffing.
Fehler 3: Mehrere @type auf einer Seite ohne Zusammenhang
Manche Entwickler packen auf jede Seite ein Article-Schema, ein Organization Schema, ein BreadcrumbList-Schema, ein WebPage-Schema und noch ein spezielles Schema. Das ist nicht per se falsch, aber wenn die Schemas nicht miteinander verbunden sind, entstehen isolierte Datenpunkte ohne Kontext.
Loesung: Nutze mainEntity und hasPart, um Schemas miteinander zu verknuepfen. Ein Artikel kann auf seine FAQ-Sektion als hasPart verweisen.
Fehler 4: Outdated dateModified
Du aktualisierst einen Artikel, vergisst aber, das dateModified-Feld im Schema zu aendern. Jetzt denkt das Modell, der Inhalt wurde seit zwei Jahren nicht angefasst.
Loesung: Automatisiere die Aktualisierung des dateModified Felds bei jeder inhaltlichen Aenderung. In den meisten CMS Systemen geht das mit einem einfachen Plugin oder Hook.
Fehler 5: Fehlende sameAs Verknuepfungen
Die sameAs-Property ist eine der maechtigen und am meisten unterschaetzten Moeglichkeiten. Sie sagt: Diese Entitaet (Person, Firma, Ort) ist identisch mit diesen externen Quellen. LLMs nutzen sameAs, um Entitaeten mit ihrem Weltwissen zu verknuepfen.
| „author“: { „@type“: „Person“, „name“: „Max Muster“, „sameAs“: [ „https://www.linkedin.com/in/maxmuster“, „https://twitter.com/maxmuster“, „https://de.wikipedia.org/wiki/Max_Muster“ ] } |
Wenn ein LLM Max Muster aus Wikipedia kennt und seine Seite dieselbe sameAs URL hat, ist das eine starke Autoritaetsbestaetigung.
Fehler 6: div Suppe statt semantischer Elemente
Diesen Fehler sehe ich am haeufigsten bei aelteren Projekten und bei Entwicklern, die mit Frameworks wie React oder Vue ohne semantische Disziplin arbeiten. Alles wird zu einem div. Das Ergebnis: eine Textmasse ohne Struktur fuer Maschinen.
Loesung: Mach ein Semantic-HTML Audit deiner wichtigsten Seiten. Installiere das Browser-Plugin headingsMap, schau dir die Titelstruktur an und pruefe mit dem WAVE-Tool, ob die semantische Struktur stimmt.
Fortgeschrittene Techniken fuer maximale KI Sichtbarkeit
Entity-Linking: Dein Inhalt in der Wissenslandschaft
Eines der maechtigen Konzepte in der KI optimierten Suchstrategie ist Entity-Linking. Die Idee: Wenn du ueber eine bekannte Entitaet schreibst, verlinke sie mit ihrer kanonischen Quelle.
Praktisch bedeutet das: Schreib ueber Schema.org, verlinke auf schema.org. Schreib ueber Google Search Central, verlinke dahin. Diese externen Links helfen LLMs, den Kontext deiner Aussagen zu verankern.
| Fortgeschrittenes JSONLD: Mention Property Die mention Property in Article-Schema erlaubt es, explizit auf erwaehnte Entitaeten zu verweisen: |
| „mentions“: [ { „@type“: „SoftwareApplication“, „name“: „Google Search Console“, „url“: „https://search.google.com/search-console“ }, { „@type“: „Organization“, „name“: „W3C“, „sameAs“: „https://www.w3.org“ } ] | ||
Abschnitte als eigenstaendige Wissenseinheiten
Eine Technik, die ich als besonders wirkungsvoll erlebt habe: Behandle jeden H2 Abschnitt als eigenstaendige Antwort auf eine Nutzerfrage. Beginne jeden Abschnitt mit einer klaren Aussage, die auch ohne Kontext Sinn ergibt.
Warum? Weil LLMs oft nur Teile einer Seite extrahieren. Sie nehmen einen Abschnitt und zitieren ihn. Wenn dieser Abschnitt unverstaendlich ohne den Rest der Seite ist, wird er nicht zitiert.
Gutes Beispiel: JSON LD wird in einem <script> Tag mit dem Typ application/ld+json eingebunden und enthaelt strukturierte Daten im JSON Format, die Maschinen direkt lesen koennen.
Schlechtes Beispiel: Wie bereits erwaehnt, gibt es hier mehrere Optionen.
Speakable Schema: Fuer Voice und KI Assistenten
Das Speakable Schema ist noch wenig bekannt, aber mit dem Aufkommen von KI Assistenten und Voice Search relevant. Es markiert, welche Teile deiner Seite besonders gut als gesprochene Antwort funktionieren.
| „speakable“: { „@type“: „SpeakableSpecification“, „cssSelector“: [„.article-intro“, „.key-facts“] } |
HowTo Schema: Der Turbo fuer Anleitungen
Wenn du Anleitungen erstellst, ist das HowTo Schema dein bester Freund. Es zerlegt einen Prozess in maschinenlesbare Schritte:
| { „@context“: „https://schema.org“, „@type“: „HowTo“, „name“: „JSON-LD in WordPress einbinden“, „totalTime“: „PT15M“, „estimatedCost“: { „@type“: „MonetaryAmount“, „currency“: „EUR“, „value“: „0“ }, „step“: [ { „@type“: „HowToStep“, „name“: „Plugin installieren“, „text“: „Installiere Yoast SEO oder RankMath…“, „position“: 1 }, { „@type“: „HowToStep“, „name“: „Schema konfigurieren“, „text“: „Oeffne die Plugin-Einstellungen…“, „position“: 2 } ] } |
Tools, Validierung und Workflow
Theorie ist toll, Praxis ist besser. Hier sind die Tools, die du wirklich brauchst.
Validation und Testing
| Tool | Verwendungszweck | URL |
| Google Rich Results Test | Schema Validierung fuer Google | search.google.com/test/rich-results |
| Schema.org Validator | Allgemeine Schema-Pruefung | validator.schema.org |
| Google Search Console | Performance Tracking | search.google.com/search-console |
| WAVE Web Accessibility | Semantik und Barrierefreiheit | wave.webaim.org |
| headingsMap Extension | Heading Hierarchie pruefen | Browser Extension |
| JSON-LD Playground | Interaktives Testen | json-ld.org/playground |
| Structured Data Linter | Erweiterte Schema Pruefung | linter.structured data.org |
Ein Empfohlener Workflow fuer neue Seiten wäre …
- Inhaltsplanung: Welche Fragen beantwortet die Seite? Welcher Schema Typ passt?
- HTML Grundstruktur: Semantische Elemente first, Klassen second
- Heading-Hierarchie: H1, H2, H3 logisch und lueckenlos
- JSON LD verfassen: Vollstaendige Properties, keine Leerstellen
- Validieren: Rich Results Test und Schema Validator
- Cross Check: Stimmen Schema-Daten und Seiteninhalt ueberein?
- Deployment und Monitoring: Search Console auf Fehler pruefen
E-E-A-T im Code: Wie du Vertrauen technisch signalisierst
Google bewertet Inhalte nach E-E-A-T: Experience, Expertise, Authoritativeness, Trustworthiness. Was viele nicht wissen: Auch strukturierte Daten koennen E-E-A-T-Signale verstaerken.
Autoren-Schema fuer Experience und Expertise
Wenn dein Artikel einen nachweisbaren Experten als Autor hat, signalisiere das explizit im Schema:
| „author“: { „@type“: „Person“, „name“: „Dr. Anna Schmidt“, „jobTitle“: „Senior SEO-Architektin“, „worksFor“: { „@type“: „Organization“, „name“: „Dreamcodes GmbH“ }, „hasCredential“: { „@type“: „EducationalOccupationalCredential“, „name“: „Google Analytics Certified“ }, „sameAs“: [ „https://linkedin.com/in/annaschmidt“ ], „knowsAbout“: [„SEO“, „Structured Data“, „LLM Optimization“] } |
Review und AggregateRating fuer Trustworthiness
Fuer Produkte und Dienstleistungen: Bewertungen im Schema zu haben ist nicht nur fuer die Sternchen in den Suchergebnissen gut. Es ist ein direktes Trust-Signal fuer LLMs.
| „aggregateRating“: { „@type“: „AggregateRating“, „ratingValue“: „4.8“, „reviewCount“: „247“, „bestRating“: „5“, „worstRating“: „1“ } |
Citation und isBasedOn fuer wissenschaftliche Inhalte
Wenn du Forschungsergebnisse oder Studien zitiertst, mache das auch im Schema explizit:
| „citation“: { „@type“: „CreativeWork“, „name“: „Structured Data and Search Performance“, „url“: „https://doi.org/10.xxxx“ } |
Praxisbeispiel: Eine vollstaendig optimierte Artikel Seite
Lass uns alles zusammenfuehren. Hier ist der Kopfbereich einer vollstaendig optimierten Seite, wie sie ein Dreamcodes Entwickler bauen wuerde:
| <!DOCTYPE html> <html lang=“de“> <head> <meta charset=“UTF-8″> <title>JSON-LD Guide 2025: Strukturierte Daten fuer KI</title> <meta name=“description“ content=“Vollstaendiger Guide zu JSON-LD…“> <link rel=“canonical“ href=“https://www.dreamcodes.de/json-ld-guide“> <!– Article Schema –> <script type=“application/ld+json“> { „@context“: „https://schema.org“, „@type“: „Article“, „@id“: „https://www.dreamcodes.de/json-ld-guide#article“, „headline“: „JSON-LD Guide 2025: Strukturierte Daten fuer KI“, „author“: { „@type“: „Person“, „name“: „Max Muster“, „sameAs“: „https://linkedin.com/in/maxmuster“ }, „datePublished“: „2025-01-15“, „dateModified“: „2025-06-01“, „hasPart“: { „@type“: „FAQPage“, „@id“: „https://www.dreamcodes.de/json-ld-guide#faq“ } } </script> <!– Breadcrumb Schema –> <script type=“application/ld+json“> { „@context“: „https://schema.org“, „@type“: „BreadcrumbList“, „itemListElement“: [ {„@type“: „ListItem“, „position“: 1, „name“: „Startseite“, „item“: „https://www.dreamcodes.de“}, {„@type“: „ListItem“, „position“: 2, „name“: „JSON-LD Guide“} ] } </script> </head> |
Und der HTML Koerper dazu:
| <body> <header> <nav aria-label=“Hauptnavigation“>…</nav> </header> <main> <article> <header> <h1>JSON-LD Guide 2025: Strukturierte Daten fuer KI</h1> <p>Von <a rel=“author“ href=“/autoren/max“>Max Muster</a></p> <time datetime=“2025-01-15″>15. Januar 2025</time> </header> <section id=“einleitung“ aria-labelledby=“h-einleitung“> <h2 id=“h-einleitung“>Einleitung</h2> <p>…</p> </section> <section id=“faq“ aria-labelledby=“h-faq“> <h2 id=“h-faq“>Haeufige Fragen</h2> <dl> <dt>Was ist JSON-LD?</dt> <dd>JSON-LD ist…</dd> </dl> </section> </article> </main> <footer>…</footer> </body> |
FAQ: Die wichtigsten Fragen zum Thema
Was ist der Unterschied zwischen JSON LD und Microdata?
Microdata bettet strukturierte Daten direkt in das HTML-Markup ein (mit itemprop, itemscope). JSON LD hingegen ist vollstaendig vom visuellen HTML getrennt und wird in einem Script-Tag eingebunden. Google empfiehlt JSON LD, da es einfacher zu pflegen, zu debuggen und von CMS-Systemen zu generieren ist.
Muss ich JSON LD fuer jede Seite einbinden?
Nein, und du solltest es nicht erzwingen. Jedes Schema sollte zur Seite passen. Ein reines Kontaktformular braucht kein Article-Schema. Wichtig ist Relevanz und Korrektheit, nicht Vollstaendigkeit um jeden Preis. Priorisiere deine wichtigsten Seiten: Startseite, ueber uns-Seite, Blog-Artikel und Produkte.
Wie viele Schema Typen kann ich auf einer Seite verwenden?
So viele wie sinnvoll. Typische Kombinationen: Article plus BreadcrumbList plus Organization plus FAQPage. Wichtig ist, dass alle Schemas korrekt und konsistent mit dem Seiteninhalt sind. Mehr ist nicht automatisch besser, wenn die Qualitaet leidet.
Werden strukturierte Daten direkt von ChatGPT gelesen?
ChatGPT durchsucht das Internet ueber das Bing Crawling System. Bing verarbeitet strukturierte Daten, und diese fliessen in den Index ein, aus dem Sprachmodelle schoefen. Die direkte Kausalitaet JSON LD fuehrt zu ChatGPT Zitat ist komplex, aber saubere strukturierte Daten sind Teil einer Strategie, die LLMs wahrscheinlicher dazu bringt, eine Seite als zuverlaessige Quelle zu nutzen.
Was bedeutet sameAs und warum ist es so wichtig?
sameAs ist eine Property, die einer Entitaet sagt: Ich bin dieselbe Entitaet wie diese externe Ressource. Wenn du also sagst, dass deine Firma dieselbe Entitaet ist wie der Wikipedia Eintrag deiner Firma, verbindet das Sprachmodell dein internes Schema Wissen mit seinem Weltwissen. Das staerkt Glaubwuerdigkeit und Autoritaet enorm.
Wie oft sollte ich meine strukturierten Daten aktualisieren?
Bei inhaltlichen Aenderungen immer. Preise, Daten, Bewertungszahlen und Statusangaben muessen stets aktuell sein. Fuer zeitlose Inhalte reicht eine jaehrliche Ueberpruefung. Setze Automatisierungen auf, wo moeglich.
Schadet schlechtes Schema meiner Website?
Falsches oder missbraeuchliches Schema kann zu einer Manual Action durch Google fuehren (also einer Abstrafung per Hand). Beispiele: gefaelschte Bewertungen im Review Schema oder Inhalte, die nicht dem Schema entsprechen. Fehlendes Schema schadet weniger als falsches Schema.
Kann ich Schema.org Daten auch fuer interne Suchsysteme nutzen?
Absolut, und das ist ein spannender Use Case. Unternehmen, die eigene KI Assistenten oder interne Suchen betreiben, koennen strukturierte Daten nutzen, um ihre Wissensbasis maschinenlesbar zu machen. Schema.org ist nicht nur fuer die externe Google Suche.
Dein naechster Schritt sollte nun sein …
Wir haben viel mit diesem Guide abgedeckt. Von den Grundlagen semantischer HTML5 Elemente ueber das vollstaendige JSON LD Oekosystem bis hin zu fortgeschrittenen Techniken wie Entity-Linking und Speakable Schema.
Aber Wissen ist nur so wertvoll wie seine Anwendung. Also: Was ist dein naechster konkreter Schritt?
Mein Vorschlag: Nimm deine wichtigste Seite, oeffne den Google Rich Results Test und schau dir an, was Google dort sieht. Dann schaue mit dem headingsMap Plugin auf die Heading Hierarchie. Du wirst in fuenf Minuten mehr ueber den Zustand deiner Seite wissen als in Stunden des Ratens.
Strukturierte Daten sind kein Hexenwerk. Sie sind sauberes Handwerk. Und sauberes Handwerk zahlt sich aus, heute mit besseren Featured Snippets und morgen mit mehr KI Zitaten.
