Wie LLMs deine Website wirklich lesen – und was dabei schief gehen kann
ChatGPT, Gemini, Perplexity und Claude sind längst zu Torwächtern des Webs geworden. Wer nicht KI-lesbar ist, existiert für Millionen Nutzer schlicht nicht. Wir erklären die 10 entscheidenden Faktoren – von Schema.org über robots.txt und llms.txt bis hreflang – und wie Sprachmodelle auf sie reagieren.
Suchmaschinenoptimierung ist nicht neu. Aber seit große Sprachmodelle (LLMs) als primäre Informationsquelle für Hunderte Millionen Menschen fungieren, hat sich die Spielregel fundamental geändert. Es geht nicht mehr nur darum, bei Google auf Seite 1 zu landen – es geht darum, ob ein KI-Assistent deinen Inhalt überhaupt versteht, korrekt einordnet und schließlich zitiert.
RobotCheck.coffee prüft Websites gegen einen lebenden Regelkatalog, der wöchentlich aus den offiziellen Dokumentationen der KI-Anbieter aktualisiert wird. Dieser Beitrag erklärt die zehn entscheidenden Faktoren in der Tiefe – geordnet nach ihrem Gewicht im Score: was steckt technisch dahinter, warum ist er für LLMs relevant – und mit welchem konkreten Schritt kannst du sofort handeln?
Schema.org Markup
Was ist das überhaupt?
Schema.org ist ein kollaboratives Vokabular für strukturierte Daten – entwickelt von Google, Bing, Yahoo und Yandex. Mit JSON-LD, Microdata oder RDFa gibst du HTML-Elementen maschinenlesbare Bedeutung: Artikel, Produkt, FAQ, Person.
Schema-Typen wie Article, BreadcrumbList, FAQPage, HowTo, Product oder LocalBusiness sind die semantische Grammatik des modernen Webs. Kein anderer Faktor wirkt im RobotCheck-Score stärker.
Warum LLMs darauf achten
Sprachmodelle sind hervorragend im Verarbeiten von Text – aber sie müssen interpretieren. Schema.org nimmt diese Arbeit ab. Wenn ein LLM eine Seite mit korrektem Article-Schema sieht, weiß es sofort: Autor, Datum, Herausgeber, Hauptinhalt – ohne raten zu müssen.
Besonders FAQPage-Markup ist Gold wert: LLMs extrahieren Fragen und Antworten direkt und präsentieren sie als Featured Snippets.
- Kein Schema → Modell muss Kontext aus Fließtext ableiten (fehleranfälliger)
- author-Feld vorhanden → bessere E-E-A-T-Bewertung (Expertise, Authority, Trust)
- datePublished + dateModified → ermöglicht zeitliche Einordnung
- Produktseiten mit aggregateRating → Shopping-fähige KI-Antworten
- Fehlerhaftes JSON-LD → Validator-Fehler reduzieren Crawler-Vertrauen
robots.txt
Was ist das überhaupt?
Die robots.txt ist eine Textdatei im Wurzelverzeichnis deiner Domain. Sie spricht eine Sprache aus dem Jahr 1994 – älter als Google – und ist trotzdem relevanter denn je. Sie teilt Crawlern mit, welche Bereiche sie besuchen dürfen und welche nicht.
Warum LLMs darauf achten
Jedes große KI-Unternehmen hat eigene Crawler – und oft mehrere mit unterschiedlichen Aufgaben: ClaudeBot (Anthropic, Training), Claude-SearchBot (Anthropic, Suche), GPTBot (OpenAI), Google-Extended (Google/Gemini), PerplexityBot. Sie respektieren die robots.txt – wer seinen Inhalt für KI-Systeme sichtbar machen will, darf diese Bots nicht aussperren.
Der häufigste Fehler: Entwickler blockieren pauschal alle Bots mit User-agent: * / Disallow: / – und schließen damit unbeabsichtigt auch sämtliche LLM-Crawler aus. Das Ergebnis: Die KI kennt den Inhalt schlicht nicht. Der zweithäufigste Fehler: nur einen der Bots eines Anbieters freigeben und die anderen vergessen – dann landet die Seite zwar im Training, aber nicht in den Live-Suchergebnissen des KI-Assistenten.
Eine robots.txt ohne explizite LLM-Bot-Regeln ist wie ein Schaufenster mit zugezogenen Vorhängen. – RobotCheck-Analyse
- Blockierter ClaudeBot/GPTBot → Inhalt erscheint nicht in KI-Antworten
- Nur Trainings-Bot erlaubt, Such-Bot vergessen → unsichtbar in Live-Antworten
- Explizit freigegebene Pfade → höhere Indexierungswahrscheinlichkeit
- Fehlende Sitemap:-Direktive → Crawler finden Sitemap nicht automatisch
llms.txt
Was ist das überhaupt?
Die llms.txt ist der jüngste Standard in dieser Liste – ein Vorschlag von Jeremy Howard (Answer.AI), der sich rasant verbreitet. Sie liegt wie die robots.txt im Wurzelverzeichnis und ist ein kuratiertes Inhaltsverzeichnis im Markdown-Format: Was bietet diese Website, was sind die wichtigsten Seiten, wo finden KI-Systeme die Essenz?
Während die robots.txt sagt wo Crawler hindürfen, sagt die llms.txt was sie dort finden – in einer Form, die LLMs direkt verarbeiten können: ein H1-Titel, eine prägnante Zusammenfassung als Blockquote, kommentierte Linklisten zu den Kernseiten.
Warum LLMs darauf achten
LLM-Systeme arbeiten mit begrenztem Kontextfenster. Statt hunderte Unterseiten zu crawlen und selbst zu gewichten, können sie mit einer llms.txt direkt zur Substanz springen. Anthropic, Perplexity und eine wachsende Zahl von Tools werten die Datei bereits aus.
Der Standard ist jung und entwickelt sich – genau deshalb prüft RobotCheck die llms.txt gegen die jeweils aktuelle Spezifikation von llmstxt.org, nicht gegen einen eingefrorenen Stand. Was heute optional ist, kann nächsten Monat empfohlen sein.
- Keine llms.txt → KI muss die Seitenstruktur selbst erraten
- H1 + Blockquote-Summary vorhanden → sofortiges Verständnis des Angebots
- Kommentierte Links zu Kernseiten → KI zitiert die richtigen Seiten
- Relative statt absolute URLs → Links für externe Systeme unbrauchbar
Sitemap XML
Was ist das überhaupt?
Eine XML-Sitemap ist das Inhaltsverzeichnis deiner Website – maschinenlesbar, strukturiert, mit Metadaten über jede URL: Änderungsdatum, Häufigkeit, Priorität. Sie ist der direkteste Weg, einem Crawler zu sagen: Hier ist alles, was ich habe.
Warum LLMs darauf achten
Crawlerbasierte KI-Systeme (insbesondere Perplexity, das live crawlt) nutzen Sitemaps aktiv zur Entdeckung neuer Inhalte. Fehlt die Sitemap oder ist sie veraltet, werden neue Blogbeiträge oder Produktseiten schlicht übersehen.
Besonders wichtig: die lastmod-Angabe. LLMs bevorzugen frische Inhalte. Ein korrekt gesetztes Datum signalisiert Aktualität und erhöht die Chance, in zeitkritischen Suchanfragen zitiert zu werden.
- Fehlende Sitemap → Crawler entdecken Inhalte nur über interne Links
- Veraltete lastmod-Daten → Inhalt wird als veraltet eingestuft
- Image-Sitemap vorhanden → Multimodale Modelle indizieren Bilder besser
- Sitemap-Index → ermöglicht selektives Crawling bestimmter Sektionen
Open Graph Meta Tags
Was ist das überhaupt?
Open Graph (OG) wurde ursprünglich von Facebook entwickelt, um Links in sozialen Netzwerken darzustellen. Heute sind OG-Tags Standard für alle Plattformen und KI-Tools. Die wichtigsten Tags: og:title, og:description, og:image, og:type.
Warum LLMs darauf achten
Wenn ein LLM-System eine URL abruft, liest es zuerst den head-Bereich. OG-Tags sind eine schnelle, verlässliche Quelle für Titel und Zusammenfassung – eine präzise og:description ist oft die Basis für Quellenvorschauen in KI-Antworten und meist treffender als der Fließtext.
Besonders Perplexity nutzt OG-Daten intensiv für Quellenlinks. Eine fehlende og:description führt zu schwachen Quellenvorschauen – und damit zu weniger Klicks. Open Graph macht eine Seite nicht KI-lesbar, aber sein Fehlen kann eine sonst gute Seite schwächer aussehen lassen.
- Fehlende OG-Tags → Titel und Description werden aus dem DOM geraten
- Einzigartiges og:image → erhöht Social-Sharing und multimodale Sichtbarkeit
- og:type: article mit article:published_time → präzisere Zeiteinordnung
- Twitter-Card-Tags zusätzlich → volle Abdeckung aller großen Plattformen
HTML-Struktur & Semantik
Was ist das überhaupt?
HTML5 brachte semantische Elemente: article, section, nav, header, footer, main, aside. Sie beschreiben nicht nur das Aussehen, sondern die Bedeutung des Inhalts.
In der Praxis ist dies der häufigste Schwachpunkt bestehender Websites: Viele Sites wurden mit div und span aufgebaut, ohne jede semantische Struktur.
Warum LLMs darauf achten
Für einen Menschen ist schlechtes HTML ein visuelles Problem. Für ein LLM ist es ein konzeptuelles Problem. Ohne semantische Tags muss das Modell erraten, was der Hauptinhalt ist – und was Navigation, Werbung oder Footer ist.
Moderne LLM-Crawler nutzen main als primären Inhaltscontainer. Fehlt dieses Tag, wird der gesamte Body verarbeitet – inklusive Menü, Cookie-Banner und Footer-Links.
main, stelle sicher dass du genau ein h1 pro Seite hast, und nutze article für eigenständige Inhaltsstücke.- Kein main → Crawler verarbeitet gesamten Body (inkl. Navigation, Footer)
- Mehrere h1 → Thema der Seite unklar für Modell
- Flache Heading-Hierarchie → Struktur des Artikels nicht erkennbar
- Verschachtelte div-Suppe → höhere Fehlerrate bei Inhaltsextraktion
- Korrekte Landmark-Rollen → assistive Technologien UND KI profitieren gleichermaßen
Alt-Texte für Bilder
Was ist das überhaupt?
Das alt-Attribut im img-Tag ist eine Textbeschreibung eines Bildes – primär für Screenreader entwickelt. Ein leeres alt signalisiert: dieses Bild ist dekorativ. Ein aussagekräftiger Alt-Text beschreibt Inhalt und Kontext des Bildes.
Warum LLMs darauf achten
Auch wenn multimodale Modelle Bilder direkt sehen können – beim Crawling von Text-Quellen verlassen sich LLMs fast ausschließlich auf Alt-Texte. Ein Bild ohne Alt-Text ist für ein textbasiertes Crawling-System schlicht unsichtbar.
Gut geschriebene Alt-Texte verbessern das semantische Feld einer Seite: Sie fügen Keywords hinzu, die natürlich zum Thema passen – ohne Keyword-Stuffing.
- Fehlende Alt-Texte → Bilder werden bei Textcrawling ignoriert; Inhaltslücken entstehen
- Beschreibende Alt-Texte → erweitertes semantisches Feld der Seite
- Keyword-gefüllte Alt-Texte → als Spam erkannt, negative Auswirkung möglich
- Alt-Texte für Infografiken → kritisch: Daten in Grafiken sonst für LLMs nicht zugänglich
Performance & Core Web Vitals
Was ist das überhaupt?
Performance bedeutet: wie schnell und stabil lädt deine Seite? Google hat mit den Core Web Vitals (LCP, CLS, INP/FID) konkrete Metriken definiert. LCP misst Ladegeschwindigkeit, CLS visuelle Stabilität, INP Interaktivität.
Warum LLMs darauf achten
Für LLM-Crawler hat Performance eine andere Dimension: Headless-Browser und HTTP-Clients warten nicht endlos. Seiten, die länger als 5–10 Sekunden laden, werden von manchen Crawlern abgebrochen. JavaScript-heavy Apps ohne Server-Side Rendering sind für viele Crawler unsichtbar.
Außerdem: Google verwendet Performance als Ranking-Signal. Da LLMs wie Perplexity Google-Ergebnisse als Basis nutzen, fließt Performance indirekt in die KI-Sichtbarkeit ein.
- Rein clientseitiges JS-Rendering → Inhalt oft nicht indexiert
- Langsamer TTFB → Crawler-Timeout wahrscheinlicher
- Große, unkomprimierte Bilder → niedrigere Crawl-Frequenz
- Gute Core Web Vitals → indirekter Boost durch besseres Google-Ranking
Canonical Tags
Was ist das überhaupt?
Ein Canonical Tag teilt Crawlern mit: Das ist die maßgebliche, originale Version dieser Seite. Es ist das Gegenmittel gegen Duplicate Content – dasselbe Problem in verschiedenen URLs.
Warum LLMs darauf achten
LLMs trainieren auf Crawling-Datensätzen. Wenn dieselbe Information auf 5 verschiedenen URLs existiert, wird sie 5-mal gecrawlt – aber keine bekommt die volle Autorität. Mit Canonical Tags wird der Linkjuice konzentriert.
Besonders wichtig bei Blogs mit Tags, Kategorien und Archivseiten: Ohne Canonicals verdünnt jede Archivseite die Autorität des Originalartikels.
- Fehlendes Canonical → Autorität verteilt sich auf Duplikate
- Self-referencing Canonical → korrekte Praxis, bestätigt Originalität
- Canonical auf HTTPS → eliminiert HTTP/HTTPS-Duplikat-Problem
- Paginierung ohne Canonical → Seite 2, 3, ... als eigene Dokumente behandelt
- Hreflang + Canonical kombiniert → mehrsprachige Sites korrekt strukturiert
hreflang
Was ist das überhaupt?
Das hreflang-Attribut sagt Crawlern, in welcher Sprache und für welche Region eine Seite gedacht ist – und wo die Entsprechungen in anderen Sprachen liegen. Notiert wird es als <link rel="alternate" hreflang="de" href="..."> im head, je eine Zeile pro Sprachversion, plus idealerweise ein hreflang="x-default" als Fallback.
Warum LLMs darauf achten
Mehrsprachige Sites ohne hreflang verwirren Crawler: Sie können nicht zuverlässig erkennen, dass die deutsche und die englische Fassung dieselbe Seite sind – und behandeln sie schlimmstenfalls als Duplikate, die sich gegenseitig die Autorität verwässern. Mit korrektem hreflang weiß ein KI-System, welche Sprachversion es einem Nutzer ausspielen soll.
Der x-default-Eintrag ist der Sicherheitsanker: Er sagt dem System, welche Version es zeigen soll, wenn keine der angegebenen Sprachen zur Nutzeranfrage passt. Fehlt er, raten Crawler – meist zu Ungunsten kleinerer Sprachen.
- Keine hreflang-Tags → Sprachversionen wirken wie konkurrierende Duplikate
- Mindestens zwei Sprachen verlinkt → klares Signal für eine internationale Site
- hreflang='x-default' gesetzt → verlässlicher Fallback für unbekannte Locales
- hreflang + Canonical kombiniert → jede Sprachversion behält ihre eigene Autorität
Zusammenfassung: Die 10 Faktoren auf einen Blick
| # | Faktor | Wichtigkeit für LLMs |
|---|---|---|
| 1 | Schema.org | Semantische Interpretation – stärkster Faktor |
| 2 | robots.txt | Zugangskontrolle für alle KI-Crawler |
| 3 | llms.txt | Kuratiertes Inhaltsverzeichnis für KI-Systeme |
| 4 | Sitemap XML | Vollständige Inhaltserfassung |
| 5 | Open Graph | Schnelle Vorschau im head-Bereich |
| 6 | HTML-Struktur | Inhaltsextraktion und Kontext |
| 7 | Alt-Texte | Bildverständnis ohne Multimodal |
| 8 | Performance | Crawler-Erreichbarkeit und Ranking |
| 9 | Canonical Tags | Autoritätskonzentration |
| 10 | hreflang | Korrekte Zuordnung der Sprachversionen |
Die KI-Lesbarkeit einer Website ist kein Luxus mehr – sie ist Grundvoraussetzung für Sichtbarkeit in der neuen Ära der Informationssuche. Und sie ist ein bewegliches Ziel: Die Regeln, gegen die RobotCheck prüft, werden wöchentlich aus den offiziellen Quellen der KI-Anbieter aktualisiert – wie das funktioniert, liest du hier.
Teste deine eigene Website unter robotcheck.coffee/check – kostenlos, ohne Anmeldung, mit sofortigem Ergebnis.