Was Maschinen von deiner Website lesen

Es gibt einen Grund, warum das gerade jetzt praktisch wird. Solange Menschen deine Seite über eine Suchergebnisliste angesteuert haben, war die Seite selbst das Ziel. Inzwischen fragen Leute einen Assistenten, und der ruft die Seite ab, liest sie und formuliert eine Antwort. Was er dabei nicht findet, kommt in der Antwort nicht vor. Die sechs Kapitel unten gehen der Reihe nach vor: erst ob der Inhalt überhaupt ausgeliefert wird, dann ob er sich vom Rahmen trennen lässt, dann wie gut er als Daten beschrieben ist, und zuletzt, wer ihn überhaupt holen darf.

Der Inhalt muss im HTML stehen, nicht nachgeladen werden

Jede Seite existiert in zwei Fassungen. Die eine ist das, was dein Server ausliefert. Die andere ist das, was am Ende auf dem Bildschirm steht. Bei vielen aktuellen Setups sind das nicht mehr dieselben Inhalte.

Was der Server liefert, ist eine HTTP-Antwort mit HTML darin. Ein Programm, das diese Antwort abruft und sonst nichts tut, sieht genau diesen Text.

Genau genommen gibt es allerdings nicht die eine Server-Antwort. Was ausgeliefert wird, kann von der Kennung des Abrufers abhängen, von Cookies, vom Standort oder von einem laufenden Test. Ein Abrufer sieht also den Inhalt der Antwort, die er bekommen hat, nicht zwingend die, die dein Browser bekommt.

Was der Browser zeigt, entsteht danach. Der Browser liest das HTML, lädt JavaScript nach, führt es aus, holt oft weitere Daten per Netzwerkanfrage und baut daraus das DOM. Dieses DOM ist das, was du siehst, und es kann deutlich mehr enthalten als die ursprüngliche Antwort.

Wenn dein Text erst in diesem zweiten Schritt entsteht, bekommt ein Abrufer ohne JavaScript-Ausführung im Extremfall nur ein Gerüst: ein div mit einer ID, ein paar Script-Tags, vielleicht ein Ladeindikator. Oft ist es kein völlig leeres Dokument, sondern eine Mischung aus Kopfdaten und Fragment. Für den Punkt hier zählt, was fehlt: der eigentliche Text.

Stand August 2026 gilt: Ein Teil der automatisierten Abrufer führt JavaScript aus, ein anderer Teil nicht. Welcher Abrufer was tut, ändert sich, und die Anbieter dokumentieren es unterschiedlich genau. Die praktische Konsequenz ist unabhängig davon stabil, allerdings nur in einer Richtung. Inhalt, der schon in der ersten Antwort steht, ist für jeden Abrufer erreichbar, der die Antwort überhaupt bekommt und vollständig liest. Auch das ist keine Garantie: Bot-Schutz kann den Abruf blocken, sehr große Seiten werden von manchen Abrufern nach einer bestimmten Menge abgeschnitten, und JavaScript kann Inhalt nach dem Laden wieder entfernen. Sicher ist nur die Umkehrung: Inhalt, der erst nach der Ausführung entsteht, fällt bei einem Teil der Abrufer weg.

Für Single-Page-Anwendungen ist das der Kernpunkt. Eine Anwendung, die im Browser die komplette Oberfläche zusammenbaut, liefert serverseitig oft nur ein Grundgerüst aus. Die Gegenmittel heißen Server-Side-Rendering, statische Generierung oder Prerendering. Alle drei sorgen dafür, dass Text serverseitig erzeugt wird statt erst im Browser. Automatisch für die ganze Seite gilt das nicht: Streaming, nachgereichte Teilbereiche und bewusst nur clientseitig gerenderte Inseln können weiterhin außerhalb der Erstantwort liegen. Prüfen musst du es trotzdem, Konfiguration ist kein Ersatz für den Blick in den Quelltext.

Bei Shopsystemen ist die Lage gemischter, und genau das macht sie tückisch. Ein Beispiel: Ein Kaffeeröster betreibt einen Shopify-Shop. In diesem Shop stehen Titel, Preis und Beschreibung im Theme-Template und damit im ausgelieferten HTML. Verlassen kannst du dich darauf nicht: Das hängt am Theme, und bei kopfloser Anbindung oder bei Preisen, die erst nach Variantenwahl aktualisiert werden, kann es anders aussehen. Deshalb prüfen statt annehmen. Die Röstprofil-Tabelle in diesem Beispiel kommt aus einer Metafeld-App, die ihr Widget per Skript nachlädt. Die Kundenbewertungen kommen von einem Bewertungsdienst. Bewertungsdienste binden ihre Inhalte oft per Skript ein, manche bieten zusätzlich eine serverseitige Ausgabe an, etwa über gespeicherte Felder im Shop. Welche Variante bei dir läuft, siehst du nur im Quelltext. Auf dem Bildschirm sieht die Seite vollständig aus, in der Server-Antwort fehlen Röstprofil und Bewertungen.

Der gleiche Effekt trifft Varianten. Wenn die Beschreibung der Mahlgrade erst erscheint, nachdem jemand eine Variante ausgewählt hat, und dieser Text per Netzwerkanfrage geholt wird, existiert er in der Erstantwort nicht.

Ein häufiges Missverständnis betrifft aufklappbare Bereiche. Ein Akkordeon mit Versandinformationen, dessen Text im Markup steht und nur per CSS ausgeblendet ist, ist unproblematisch: der Text ist da. Ein Akkordeon, das seinen Inhalt beim ersten Klick per fetch holt, ist ein Problem: der Text ist nicht da. Im aufgeklappten Zustand sehen beide gleich aus. Der Unterschied fällt erst auf, wenn der Inhalt beim Klick kurz auf sich warten lässt, und er ist im Quelltext oder im Netzwerk-Tab eindeutig zu sehen.

Zwei weitere Fälle blockieren Inhalt, ohne dass jemand JavaScript vermutet. Erstens Consent-Schichten, die den Seiteninhalt erst nach einer Zustimmung einbauen. Zweitens Inhalt, der beim Scrollen nachgeladen wird, etwa lange Kategorielisten oder weitere Bewertungen.

Ein Grenzfall verdient Erwähnung: Manche Frameworks legen die Seitendaten als JSON-Block ins HTML, aus dem der Browser die Oberfläche aufbaut. Dieser Block steht technisch im Quelltext. Ob ein bestimmter Abrufer daraus Fließtext gewinnt, sagt dir niemand zu, und es lässt sich von außen nicht zuverlässig prüfen. Einzelne Stichproben (taucht der Inhalt in einer Antwort oder einer Vorschau auf?) sind möglich, aber sie belegen nichts für andere Abrufer oder für später. Verlass dich nicht darauf, sondern liefere den Text zusätzlich als sichtbares Markup.

Die Regel, auf die alles hinausläuft: Was ein Mensch auf der Seite lesen können soll, soll als Text in der Server-Antwort stehen. JavaScript darf ergänzen, sortieren, personalisieren. Es darf nicht die einzige Quelle des Inhalts sein.

Die Framework-Familie allein entscheidet das nicht. React, Vue und Svelte lassen sich serverseitig rendern, meist über das jeweilige Meta-Framework. Wie aufwendig das ist, unterscheidet sich allerdings deutlich, und einzelne Bausteine im Projekt können clientseitig gebunden bleiben. Ausschlaggebend ist der gewählte Rendering-Modus, nicht der Name der Bibliothek.

So prüfst du es

Du brauchst dafür keinen Crawler und keine kostenpflichtige Software. Ein Browser reicht, ein Terminal hilft.

1. Quelltext ansehen, nicht Entwicklerwerkzeuge. Der Quelltext lässt sich per Rechtsklick, "Seitenquelltext anzeigen" öffnen, oder indem du der Adresse view-source: voranstellst. Die Tastenkürzel unterscheiden sich je nach Browser und Betriebssystem. Die Quelltextansicht zeigt in der Regel die Server-Antwort, aber sie kann die Seite dafür ein zweites Mal anfordern oder aus dem Cache bedienen. Wenn es genau darauf ankommt, nimm im Netzwerk-Tab der Entwicklerwerkzeuge die Antwort des Dokument-Requests selbst.

Wichtig: "Untersuchen" beziehungsweise der Elements-Tab zeigt etwas anderes, nämlich das fertige DOM nach JavaScript-Ausführung. Dort steht der Inhalt fast immer. Das beweist nichts.

2. Im Quelltext nach einem konkreten Satz suchen. Kopiere einen Satz aus der sichtbaren Seite, sechs bis zehn Wörter, ohne Sonderzeichen. Suche ihn im Quelltext mit der Browser-Suche. Findest du ihn, steht er in der Server-Antwort. Findest du ihn nicht, entsteht er erst im Browser.

Mach das für mehrere Stellen einzeln: Produktbeschreibung, Bewertungen, Versandhinweise, Kategorietext, FAQ-Antworten. Das Ergebnis fällt oft pro Bereich unterschiedlich aus.

3. JavaScript abschalten. Stand August 2026: In Chrome lässt sich JavaScript über das Befehlsmenü der Entwicklerwerkzeuge abschalten, die Einstellung gilt nur, solange die Entwicklerwerkzeuge geöffnet sind. In Firefox gibt es dafür einen Schalter in about:config. Menüpunkte und Schalternamen ändern sich mit den Browser-Versionen, der zuverlässigere Weg bleibt der Abruf ohne Browser.

4. Mit curl abrufen.

curl -sL "https://deine-domain.de/produkt/xyz" > seite.html

Dann die Datei in einem Editor öffnen und nach demselben Satz suchen. Oder direkt:

curl -sL "https://deine-domain.de/produkt/xyz" | grep -i "roestprofil"

curl führt kein JavaScript aus, schickt aber auch eine andere Kennung als dein Browser und keine Cookies. Manche Server liefern deshalb etwas anderes aus oder blocken den Abruf ganz. Ein Treffer bei grep ist ein guter Hinweis, ein Fehltreffer ist noch kein Beweis: prüfe erst, ob überhaupt die erwartete Seite zurückkam.

Größe als grober Indikator:

curl -sL "https://deine-domain.de/produkt/xyz" | wc -c

Eine inhaltsreiche Produktseite, die nur wenige Kilobyte liefert, ist verdächtig. Das ist ein Hinweis, kein Beweis.

5. Auf Consent-Schichten prüfen. Rufe die Seite in einem privaten Fenster ohne vorherige Zustimmung ab und wiederhole Schritt 1. Vergleiche mit dem Quelltext nach erteilter Zustimmung.

6. Ergebnis festhalten. Leg eine kurze Tabelle an: Seitentyp, geprüftes Element, im Quelltext ja/nein. Damit hast du eine Arbeitsliste für die Entwicklung statt eines Bauchgefühls.

Semantische Struktur: genau ein main, Navigation außerhalb

Angenommen, der Text steht jetzt in der Server-Antwort. Damit ist die erste Hürde genommen und die zweite kommt sofort: der Text steht dort zusammen mit allem anderen, was auf jeder Seite steht.

Ein Extraktor bekommt dein HTML und muss daraus den Teil herauslösen, der nur zu dieser einen Seite gehört. Alles andere ist Rahmen.

Jede Seite deiner Site trägt Wiederholung: Hauptnavigation, Suchleiste, Consent-Banner, Footer mit Impressum und Newsletter-Block. Diese Blöcke stehen auf den Unterseiten weitgehend gleich da, bis auf Kleinigkeiten wie den Aktivzustand im Menü oder ein Consent-Banner, das nur beim ersten Besuch erscheint. Der seitenspezifische Teil ist der Rest. Wenn die Grenze zwischen beidem im Markup nicht gezogen ist, muss ein Extraktor raten, und er rät nicht immer so, wie du es hättest.

Das Element, das die Grenze zieht, heißt main. Der HTML-Standard erlaubt pro Dokument höchstens ein main-Element ohne hidden-Attribut. Dass du genau eines setzt, ist die Empfehlung, die daraus folgt, nicht der Wortlaut des Standards: ein Dokument ganz ohne main ist formal konform und für einen Extraktor trotzdem unbrauchbar.

Hinein gehört der Inhalt, der diese Seite von den anderen unterscheidet. Nicht hinein gehört der seitenübergreifende Rahmen: Hauptnavigation, Seiten-Header, Seiten-Footer, Cookie-Layer, Chat-Widget. Umgekehrt ist ein nav innerhalb von main erlaubt, wenn es zu dieser Seite gehört, etwa eine Blätter-Navigation oder das Inhaltsverzeichnis des Artikels; ebenso dürfen header und footer eines article in main stehen. Der Standard formuliert die Regel ohnehin in der anderen Richtung: main darf nicht in article, aside, footer, header oder nav verschachtelt sein.

Zwei main-Elemente machen die Grenze mehrdeutig. Was ein Extraktor dann tut, ist nirgends festgelegt: erstes, letztes oder beide zusammen sind alle denkbar. Du weißt nicht, welche Variante du triffst, und du kannst dich auf keine davon verlassen. Der Fehler entsteht selten absichtlich. Typischer Hergang: das Layout-Template setzt ein main um seine Kinder, und die Produktseiten-Komponente bringt ihr eigenes main mit. Im Browser fällt das meist nicht auf, weil main im Standard-Stylesheet nur display: block mitbringt und sonst nichts gestaltet. Sichtbar wird der Fehler erst, wenn eigenes CSS auf main zielt, etwa eine Maximalbreite, und dann zweimal greift.

Setz genau eine h1 pro Seite, und vergib die Ebenen darunter ohne Sprünge. Beides ist kein Parse-Fehler im HTML-Standard, sondern breit geteilte Konvention, auf die sich Auswertungswerkzeuge und Prüfregeln wie heading-order und page-has-heading-one stützen. Genau deshalb lohnt es sich, sie einzuhalten. Auf /kaffee/aethiopien-yirgacheffe heißt die h1 also nicht der Shopname, sondern der Produktname. Darunter h2 für die Hauptabschnitte, h3 nur unterhalb eines h2. Wer von h1 direkt auf h4 springt, weil h4 im Design kleiner aussieht, löst ein Gestaltungsproblem an der falschen Stelle: Größe regelt CSS, Ebene regelt Struktur.

Der Fehler, den die übliche Prüfung nicht sieht

Die verbreitete Checkliste fragt: hat die Seite ein nav? Hat sie ein main? Hat sie eine h1? Das sind Existenzprüfungen, und sie sind der Kern des Problems, nicht seine Lösung.

Ein nav kann vorhanden sein und trotzdem innerhalb von main liegen. Dann ist es sauber ausgezeichnet und falsch platziert. Die Prüfung meldet grün. Ein Extraktor, der sich auf main verlässt, zieht die Kategorienavigation dann mit heraus, und zwar auf jeder Produktseite neu. Manche Verfahren werfen reine Linklisten über Textdichte-Heuristiken trotzdem weg. Darauf kannst du dich aber nicht verlassen, weil du nicht weißt, welches Verfahren dich liest. Das ist der unangenehmere Fall, weil die Auszeichnung Korrektheit suggeriert und deshalb niemand mehr hinsieht.

Derselbe Fall bei der h1: vorhanden, aber dreimal, weil das Slider-Modul jede Kachel mit h1 überschreibt. Auch das besteht die Existenzprüfung.

Prüfe deshalb drei Eigenschaften statt einer:

• Existenz: gibt es main, h1, nav?

• Anzahl: main genau einmal, h1 genau einmal.

• Position: liegen nav, header und footer außerhalb von main?

Verlass dich nicht darauf, dass eine Checkliste mehr prüft als Existenz. Etablierte Regelsätze gehen weiter: axe-core, das unter anderem in Lighthouse steckt, prüft mit landmark-one-main die Anzahl und mit landmark-banner-is-top-level und landmark-contentinfo-is-top-level auch, ob header und footer in einem anderen Landmark liegen. Ein nav innerhalb von main dagegen meldet kein verbreitetes Werkzeug, weil es dort erlaubt sein kann. Genau diese Lücke musst du selbst schließen. (Regelstand August 2026, Regelsätze wachsen.)

Ein Grenzfall, der Nachdenken verlangt: die Sidebar. Steht dort auf allen Seiten dieselbe Kategorienliste, ist sie Rahmen und gehört nach draußen. Enthält sie Angaben, die zum Hauptinhalt dieser Seite gehören, etwa die Röstprofil-Daten genau dieser Bohne, gehört sie in main. Seitenspezifisch allein ist kein ausreichendes Kriterium: ein Block wie "Kunden kauften auch" wechselt pro Seite und ist trotzdem Beiwerk, das du eher als aside außerhalb von main führst.

Warum das gerade jetzt zählt

Stand August 2026 kannst du nicht darauf bauen, dass ein Crawler dein JavaScript ausführt, bevor er den Inhalt liest. Welcher Anbieter wann rendert, ist von außen kaum prüfbar und ändert sich. Verlass dich deshalb auf das, was der Server ausliefert: Struktur, die erst clientseitig entsteht, erreicht einen Crawler ohne JavaScript-Ausführung nicht.

Ein zweiter Grund altert nicht: Dieselben Landmark-Elemente nutzen Screenreader-Nutzer zum Springen im Dokument. Deckungsgleich ist beides nicht: mehrere nav-Elemente brauchen zusätzlich unterscheidbare Namen, und header und footer melden sich nur dann als banner und contentinfo, solange sie nicht in article oder section stecken. Der Aufwand ist trotzdem derselbe Handgriff, du baust hier nichts Zusätzliches.

So prüfst du es

Du brauchst dafür einen Browser, sonst nichts.

1. Sieh dir das an, was der Server wirklich schickt. Rechtsklick auf die Seite, "Seitenquelltext anzeigen". Stand August 2026: Strg+U unter Windows und Linux, auf macOS Cmd+Alt+U in Chrome und Cmd+U in Firefox; in Safari erst, nachdem das Entwicklermenü aktiviert ist. Tastenbelegungen ändern sich mit den Browserversionen, im Zweifel über das Menü gehen. Nimm bewusst nicht die Entwicklerwerkzeuge: die zeigen das DOM nach JavaScript, der Quelltext zeigt die Auslieferung.

2. Zähl die main-Elemente. Im Quelltext nach <main suchen und nicht nach main, sonst zählst du class="main-nav", Wörter wie domain und JavaScript-Strings mit. Erwartung: 1. Bei 0 oder 2 hast du deinen Befund. Die Trefferzahl ist eine schnelle Näherung, kein Parser: bei Verdacht gegen einen HTML-Validator oder ein Landmark-Werkzeug gegenprüfen.

3. Zähl die h1. Suche nach <h1. Erwartung: 1. Lies den Text dahinter: benennt er diese Seite oder den ganzen Shop?

4. Prüf die Position von nav, header und footer. Suche nacheinander <main, </main, <nav, <footer. Notier grob, wo im Dokument die Treffer liegen (Scrollposition reicht). Jeder nav- und footer-Treffer, der zum Rahmen gehört, muss vor <main oder nach </main> liegen. Liegt einer dazwischen, prüf ihn gegen den Grenzfall oben.

5. Vergleich zwei Seiten. Nimm die Startseite und eine tiefe Produktseite. Markier in beiden den Text zwischen <main und </main> und kopier ihn in einen Editor. Taucht derselbe lange Textblock in beiden auf, ist das ein starker Hinweis auf Boilerplate in main. Prüf nach, bevor du umbaust: manche Wiederholung ist echter Seiteninhalt, etwa identische Pflegehinweise bei Produkten derselben Kategorie.

6. Überschriften auf Sprünge prüfen. Suche im Quelltext nach <h2, <h3, <h4. Geh die Treffer in Dokumentreihenfolge durch und schreib die Ziffern untereinander: 1, 2, 3, 3, 2, 3. Jede Ziffer darf gegenüber der vorigen um höchstens eins steigen. 1 gefolgt von 4 ist ein Befund.

7. Gegenprobe im Lesemodus. Stand August 2026 haben Firefox und Safari einen Lesemodus; ob und wie ein Browser den anbietet, kann sich ändern. Er entscheidet überwiegend über eigene Heuristiken wie Textdichte sowie Tag- und Klassennamen und nur am Rande über deine Landmark-Struktur. Ein sauberer Lesemodus beweist deshalb nichts, ein kaputter ist ein brauchbarer Alarm.

8. Wiederhol das pro Seitentyp, nicht pro Seite. Startseite, Kategorieseite, Produktseite, Blogartikel, Kontaktseite. Bei templategetriebenen Sites sitzen Struktur-Fehler meist im Template, also pro Seitentyp und nicht pro Einzelseite. Ausnahme sind redaktionell gepflegte Inhalte: eine zweite h1 aus dem Rich-Text-Editor trifft genau eine Seite und fällt bei einer Stichprobe pro Seitentyp durch.

Strukturierte Daten: vorhanden reicht nicht

Bis hierher ging es darum, dass der Text ankommt und sich vom Rahmen trennen lässt. Damit muss eine Maschine ihn immer noch interpretieren. Der nächste Schritt nimmt ihr diese Arbeit an den Stellen ab, an denen Interpretation teuer ist.

Eine Maschine, die deine Seite auswertet, hat zwei Wege. Sie kann den sichtbaren Text interpretieren und raten, welche Zahl auf der Seite der Preis ist. Oder sie liest ein Feld, das ausdrücklich price heißt. JSON-LD ist der zweite Weg: ein Block strukturierter Daten im Quelltext, üblicherweise in einem <script type="application/ld+json">.

Der Unterschied ist nicht Bequemlichkeit, sondern Fehlerrate. Interpretation kann danebengehen. Ein benanntes Feld verschiebt die Fehlerquelle: es wird nicht mehr geraten, sondern gelesen. Falsch sein kann der Wert trotzdem, und dann wird er zuverlässig übernommen.

Drei Stufen, die oft in einen Topf geworfen werden

Vorhanden heißt: es gibt einen Block. Das ist der Zustand, den manche Audit-Tools bereits mit einem grünen Haken quittieren und der im Reporting als "strukturierte Daten: ja" auftaucht.

Gültig heißt: der Block lässt sich als JSON parsen, hat @context und @type, und die Werte haben die Typen, die schema.org vorsieht. Der Schema Markup Validator unter validator.schema.org prüft im Kern diese Stufe. Googles Rich Results Test geht weiter und meldet fehlende Pflichtfelder, allerdings nur nach Googles Liste für das jeweilige Suchergebnis-Feature, nicht nach dem, was auf deiner Seite inhaltlich nötig wäre.

Vollständig für den Seitentyp heißt: die Felder sind da, die auf genau dieser Art von Seite eine Antwort tragen. Diese Stufe prüft kein Validator für dich, weil sie davon abhängt, was du verkaufst.

Ein Beispiel aus einem Kaffee-Shop. Die Produktseite der Espressomühle ist als Product ausgezeichnet, mit name, image, brand und offers inklusive price und priceCurrency. Alle Validatoren gehen durch. Die Frage "ist die Mühle lieferbar" beantwortet die Auszeichnung trotzdem nicht, weil availability fehlt. Was dann passiert, steuerst du nicht mehr: die Auswertung kann auf den Fließtext zurückfallen, den falschen Wert greifen oder die Seite unberücksichtigt lassen.

Zur Vollständigkeit gehört die Deckung mit der sichtbaren Seite. Steht im Markup ein anderer Preis als im Seitentext, ist eine der beiden Angaben falsch, und du entscheidest nicht, welche gelesen wird.

Die Sprache steht selten drin

Ein JSON-LD-Block sagt von sich aus nicht, in welcher Sprache seine Texte verfasst sind. Das lang-Attribut sitzt am HTML-Element, nicht in den Daten. Sobald der Block extrahiert, weitergereicht oder zwischengespeichert wird, kann dieser Kontext verloren gehen, und die Sprache muss aus dem Text selbst erschlossen werden.

Setz inLanguage explizit, mit einem Code nach BCP 47, also de-DE statt deutsch. In schema.org steht inLanguage unter anderem an CreativeWork und Event, daneben an Spezialtypen wie BroadcastService oder LinkRole. WebPage, Article und FAQPage gehören dazu. Product gehört nicht dazu; verlass dich dort nicht auf inLanguage, sondern setz die Angabe auf der WebPage, die das Produkt einbettet, und verknüpf die Sprachfassungen zusätzlich über hreflang.

Bei FAQ muss die Frage eine Frage sein

Bei FAQPage steht in name die Frage und in acceptedAnswer.text die Antwort. Ein Fehler, den man in Shop-Templates immer wieder sieht: im name-Feld landet das Themen-Etikett aus der Navigation, oft weil die Überschrift der Akkordeon-Sektion unverändert durchgereicht wird.

"Siebträger" ist keine Frage. "Wie bereite ich Espresso im Siebträger zu?" ist eine. Der Unterschied ist nicht kosmetisch: schema.org sieht in name eine Frage vor, ein Etikett erfüllt diese Vorgabe nicht. Wer das Feld mit Navigations-Überschriften füllt, liefert formal korrektes Markup mit dem falschen Inhalt.

Zweiter FAQ-Fehler: in acceptedAnswer.text steht ein Verweis, etwa "Details findest du auf unserer Versandseite". Die Antwort muss im Feld stehen, im Volltext, ohne Klick.

Stand August 2026: FAQ-Auszeichnung führt bei Google zu keinem Rich Result mehr. Google hatte die Anzeige im August 2023 auf wenige Site-Kategorien beschränkt und zum 7. Mai 2026 ganz eingestellt; seit Juni 2026 ist auch die Dokumentation dazu weg. Als maschinenlesbare Struktur bleibt die Auszeichnung sinnvoll, in der Darstellung im Suchergebnis spielt sie keine Rolle mehr.

Wo der Block ausgeliefert wird

Damit ist das erste Kapitel wieder da. Stand August 2026 führt ein Teil der Crawler kein JavaScript aus. JSON-LD, das erst im Browser nachgeladen wird, typischerweise über einen Tag-Manager, existiert für sie nicht. Liefere den Block serverseitig im HTML aus. Das ist der eine Punkt in diesem Kapitel, bei dem "vorhanden" und "nicht vorhanden" davon abhängen, wer schaut.

So prüfst du es

1. Ist überhaupt etwas da, ohne JavaScript? Seite im Browser öffnen, Rechtsklick, "Seitenquelltext anzeigen". Nicht "Untersuchen" nehmen, das zeigt den Zustand nach JavaScript. Im Quelltext nach ld+json suchen. Kein Treffer bedeutet: für einen Crawler ohne JavaScript ist kein Markup vorhanden, auch wenn dein SEO-Plugin etwas anderes behauptet.

2. Ist es gültig? Den Block markieren, kopieren, in den Schema Markup Validator (validator.schema.org) einfügen. Er meldet Syntax- und Typfehler. Grün heißt gültig. Grün heißt nicht vollständig.

3. Ist es vollständig für den Seitentyp? Von Hand gegen eine kurze Liste prüfen, pro Template einmal. Empfohlene Mindestfelder je Seitentyp (eigene Empfehlung, Stand August 2026):

• Produktseite: name, offers.price, offers.priceCurrency, offers.availability, eine Kennung (sku oder gtin), image, description

• FAQ: jede Question mit ausformulierter Frage in name, jede acceptedAnswer.text mit der Antwort im Volltext. Nutzen liegt hier in der Maschinenlesbarkeit, nicht mehr in einem Rich Result

• Ratgeber oder Artikel: headline, datePublished, dateModified, author, inLanguage

Was Google verlangt, steht in Googles Dokumentation zum jeweiligen Seitentyp und ändert sich; diese Liste ist die inhaltliche Untergrenze, nicht die formale.

4. Sprachtest. Im Block nach inLanguage suchen. Fehlt es, ergänze es auf der Ebene von WebPage, Article oder FAQPage. Bei mehrsprachigen Seiten zusätzlich prüfen, ob die englische Fassung nicht versehentlich de-DE trägt, das passiert, wenn der Wert im Template hart verdrahtet ist.

5. Abgleich mit dem, was der Kunde sieht. Preis, Verfügbarkeit und Titel aus dem Markup neben die sichtbare Seite legen. Typische Ursachen für Abweichungen zwischen Markup-Preis und sichtbarem Preis sind Brutto-Netto-Unterschiede und Rabatte, die nur im Frontend gerechnet werden. Prüf beides zuerst.

6. Vorlesetest für FAQ. Lies jeden name-Wert laut vor. Klingt er nicht wie etwas, das ein Kunde tippen oder fragen würde, ist es ein Etikett und keine Frage. Umschreiben.

7. Stichprobe über Templates, nicht über Seiten. Je eine Produktseite, eine Kategorieseite, eine Ratgeberseite, eine FAQ-Seite. Fehler in strukturierten Daten sitzen oft im Template. Wenn ja, betreffen sie alle Seiten desselben Typs, ein Fund auf einer Seite ist also ein Fund auf allen.

8. Wiederholen nach jedem Theme- oder Shop-Update. Strukturierte Daten verschwinden lautlos, es gibt keine Fehlermeldung im Frontend.

Eigenschaften gehören in Felder, nicht in Fließtext

Preis und Verfügbarkeit sind der offensichtliche Teil der strukturierten Daten. Der weniger offensichtliche betrifft alles, wonach jemand ein Produkt überhaupt auswählt.

Ein Kaffeeröster pflegt im Backend sauber: Herkunft Huila, Aufbereitung gewaschen, Röstgrad mittel, Packungsgröße 250 Gramm. Auf der Produktseite steht davon: "Diese Bohne aus dem kolumbianischen Huila wird gewaschen aufbereitet, mittel geröstet und kommt in der 250-Gramm-Packung." Inhaltlich ist alles da. Als Datum ist es schwächer geworden.

Der Grund ist einfach. Im Backend war "Röstgrad" ein Feld mit einem Wert. Auf der Seite ist daraus ein Satzteil geworden. Ein Programm, das diesen Satz liest, muss aus Wortstellung und Kontext erschließen, dass "mittel" zum Röstgrad gehört und nicht zur Packungsgröße. Das gelingt häufig. Verlässlich ist es nicht.

Und die Unsicherheit reist nicht mit. Ob eine Zuordnung geraten oder ausgelesen wurde, lässt sich in den gängigen Austauschformaten gar nicht mitschreiben, es gibt kein Feld dafür. Was als Vermutung entsteht, kommt im nächsten System als Angabe an.

Der Umbau

schema.org kennt für Product eigene Eigenschaften, unter anderem color, material, size und weight. Was dort keinen eigenen Platz hat, gehört in additionalProperty als PropertyValue mit name und value. Kommt eine Einheit ins Spiel, gehört sie in unitCode, das laut schema.org den dreistelligen UN/CEFACT Common Code erwartet oder alternativ eine URL. Für Gramm ist das GRM. Ersatzweise geht unitText.

"additionalProperty": [
  { "@type": "PropertyValue", "propertyID": "roestgrad",
    "name": "Röstgrad", "value": "mittel" },
  { "@type": "PropertyValue", "propertyID": "aufbereitung",
    "name": "Aufbereitung", "value": "gewaschen" }
],
"weight": { "@type": "QuantitativeValue",
            "value": 250, "unitCode": "GRM" }

Zahl und Einheit bleiben getrennt. "250g" muss erst zerlegt werden, und wer zerlegt, rät mit: bei "250 g", "0,25 kg" oder "250g/500g" fällt das Ergebnis unterschiedlich aus. 250 plus GRM braucht diesen Zwischenschritt nicht.

propertyID hält die Identität dort stabil, wo ein System sie überhaupt ausliest. schema.org sieht dafür bevorzugt einen etablierten Code oder eine URL vor. Ein selbst vergebener Bezeichner wie roestgrad ist erlaubt, trägt aber nur innerhalb deiner eigenen Systeme und deiner Sprachversionen.

Nicht alle Felder

Das ist ausdrücklich keine Fleißaufgabe über den gesamten Attributsatz. In vielen Katalogen sind deutlich mehr Felder gepflegt, als für die Kaufentscheidung eine Rolle spielen. Zolltarifnummer, Palettenmaß oder interne Lagerkennzeichen gehören nicht ins Auszeichnungs-Set.

Relevant sind die Eigenschaften, nach denen jemand tatsächlich auswählt. Drei Quellen im eigenen Haus sind brauchbare Anhaltspunkte: die Filter der Kategorienavigation, die wiederkehrenden Fragen im Pre-Sale-Support, die Retourengründe. Was in zweien davon auftaucht, ist ein starker Kandidat. Ein vorhandener Filter beweist für sich noch keine Nachfrage, er beweist nur, dass ihn jemand angelegt hat.

Der Rest kann im Fließtext bleiben. Eine kurze, gepflegte Liste ist mehr wert als eine lange, in der die Hälfte veraltet ist.

Die Übersetzungsfalle

Ein Wert in additionalProperty liest sich anders als ein Absatz. Ein Feldwert ist dafür gedacht, als Angabe gelesen zu werden, ein Absatz als Beschreibung. Was ein konsumierendes System daraus tatsächlich macht, ist von außen nicht kontrollierbar, aber die Auszeichnung erhebt den Wert zur Angabe. Genau deshalb ist er heikel, sobald automatisch übersetzt wird.

Beim Röstkaffee geht "gewaschen" nach "washed" noch gut. Bei einem Taschenhersteller kann aus dem Material "Kalbnappa" je nach Übersetzer "calf nappa" werden, "calfskin", oder schlicht "leather". Das sind drei verschiedene Aussagen, und keine davon hat der Hersteller getroffen. Bei Konfektionsgrößen wie "34 kurz" oder bei Sortennamen wie "Bourbon" kann eine Übersetzung den Wert schlicht zerstören. Wer Eigenschaften übersetzen lässt, riskiert, Tatsachenbehauptungen zu ändern und nicht nur Formulierungen.

Die Lösung ist eine Freigabe-Liste statt freier Übersetzung: pro Eigenschaft und pro Sprache ein definierter Wertevorrat, den ein Mensch einmal freigegeben hat. Was nicht auf der Liste steht, bleibt in der Ausgangssprache oder fällt in dieser Sprachversion weg. Weglassen ist besser als falsch behaupten.

Trenne dabei Bezeichner und Beschriftung. propertyID bleibt sprachunabhängig stabil, name ist die lokalisierte Beschriftung. Dann kann die Beschriftung übersetzt werden, ohne dass die Identität der Eigenschaft in deinen Systemen wandert.

Zwei Randbedingungen

Der sichtbare Text bleibt. Strukturierte Daten ersetzen die Produktbeschreibung nicht, sie doppeln die Auswahleigenschaften maschinenlesbar. Googles allgemeine Richtlinien für strukturierte Daten verlangen, dass ausgezeichnete Inhalte den Hauptinhalt der Seite repräsentieren. Für Produktdaten gibt es Ausnahmen, etwa Felder aus dem Händler-Feed. Prüfe die Richtlinie vor dem Ausspielen, sie wird laufend geändert.

Und die Werte müssen aus derselben Quelle kommen wie das Backend-Feld. Sobald jemand sie im Template ein zweites Mal pflegt, gibt es zwei Wahrheiten, und nichts hält sie zusammen. Wenn sie auseinanderlaufen, fällt es niemandem auf, weil die sichtbare Seite weiter richtig aussieht. Was du ausspielst, sollte technisch dieselbe Zeile in der Datenbank sein wie das, was deine Mitarbeiter im PIM sehen.

So prüfst du es

Alle Schritte gehen mit Browser und Textdokument, ohne Spezialwerkzeug.

1. Auswahleigenschaften auflisten. Schreib die drei bis fünf Eigenschaften auf, nach denen deine Kunden tatsächlich auswählen. Quellen: deine eigenen Kategoriefilter, die häufigsten Pre-Sale-Fragen im Support, die häufigsten Retourengründe. Diese Liste ist der Maßstab für alles Weitere.

2. Quelltext einer echten Produktseite ansehen. Produktseite öffnen, Rechtsklick, "Seitenquelltext anzeigen". In Chrome, Firefox und Edge liegt der Eintrag im Rechtsklick-Menü, in Safari erst nach Aktivierung des Entwickler-Menüs. Nach additionalProperty suchen, dann nach den Werten aus Schritt 1, zum Beispiel mittel oder gewaschen. Entscheidend ist, wo der Treffer liegt: in einem "value"-Feld oder mitten im Beschreibungsabsatz. Nur der erste Fall zählt.

Ein Vorbehalt zu diesem Schritt: JSON-LD, das erst per JavaScript eingefügt wird, etwa über einen Tag-Manager, steht nicht im Quelltext, sondern nur im gerenderten DOM. Wer nur im Quelltext sucht, hält vorhandene Auszeichnung fälschlich für fehlend. Für einen Crawler ohne JavaScript-Ausführung ist sie allerdings tatsächlich nicht da, insofern ist der Befund trotzdem verwertbar.

3. Der Absatztest. Kopier nur den Beschreibungsabsatz in ein leeres Dokument, ohne Überschrift, ohne Tabelle, ohne Bilder. Lies ihn und trag die Eigenschaften aus Schritt 1 in eine Liste ein. Wenn du dabei irgendwo raten oder zurückblättern musst, muss eine Maschine an derselben Stelle auch raten.

4. Einheiten prüfen. Such im Quelltext nach der Mengenangabe. Steht dort eine reine Zahl mit separater Einheit, oder eine Zeichenkette wie "250g", "ca. 250 g" oder "0,25 kg"? Uneinheitliche Schreibweisen über verschiedene Produkte hinweg sind ein Befund, kein Detail: vergleich dieselbe Angabe bei fünf Produkten aus unterschiedlichen Kategorien.

5. Sprachversionen nebeneinanderlegen. Öffne dasselbe Produkt in zwei Sprachversionen in zwei Browserfenstern. Schreib die Werte der Auswahleigenschaften untereinander in eine Tabelle. Achte besonders auf Materialnamen, Sortennamen, Größenangaben und Farbtöne. Jede Abweichung, die nicht offensichtlich dieselbe Sache benennt, ist eine unbeabsichtigte neue Tatsachenbehauptung.

6. Freigabe-Liste einfordern. Frag die Person, die die Übersetzungen verantwortet, eine einzige Frage: "Gibt es pro Eigenschaft eine feste Liste erlaubter Werte je Sprache, oder wird der Wert mitübersetzt wie normaler Text?" Gibt es keine Liste, ist der Befund aus Schritt 5 kein Einzelfall, sondern der Normalzustand.

7. Backend-Abgleich per Stichprobe. Nimm zehn Produkte aus verschiedenen Kategorien, möglichst auch ältere. Vergleich den Feldwert im Backend mit dem, was im Quelltext ausgeliefert wird. Jede Abweichung deutet darauf hin, dass der Wert irgendwo im Template zweitgepflegt wird statt aus der Quelle zu kommen.

8. Optional, immer noch ohne Installation. Ein öffentlicher Validator für strukturierte Daten im Browser zeigt dir dieselbe Seite geparst an. Nützlich als Gegenprobe zu Schritt 2, aber verzichtbar: die Suche im Quelltext beantwortet die Kernfrage bereits. Solche Werkzeuge verschwinden auch wieder, prüf bei Bedarf, was gerade läuft.

Eine maschinenlesbare Zweitfassung ausliefern

Die vier Kapitel bisher arbeiten alle an derselben Datei: dem HTML. Es gibt einen zweiten Weg, der das HTML unangetastet lässt und daneben eine zweite Fassung stellt.

Ein Abrufer, der deine Seite holt, bekommt HTML. Darin steckt dein Text, daneben aber auch Navigation, Hinweisbanner, Bewertungs-Widget und Skripte. Eine Zweitfassung in Markdown liefert denselben Inhalt ohne diese Hülle.

Der Nutzen ist nüchtern. Die Datei ist in aller Regel deutlich kleiner, unkomprimiert oft um ein Vielfaches, mit Brotli oder gzip weniger dramatisch. Die Gliederung steht ohne Umschweife im Quelltext, ohne Wrapper-Elemente und ohne per CSS groß gemachte div-Container, die nur wie eine Überschrift aussehen, vorausgesetzt, dein Generator setzt die Ebenen sauber. Und in der Zweitfassung lässt du alles weg, was erst ausgeführt werden müsste. Markdown könnte zwar Roh-HTML mitschleppen, aber genau darauf verzichtest du hier.

Zum Crawler-Verhalten gibt es an dieser Stelle eine belastbare Messung. Die gemeinsame Auswertung von Vercel und MERJ (Dezember 2024, rund 500 Millionen Crawler-Requests) fand bei GPTBot, ClaudeBot und PerplexityBot keinen Hinweis auf JavaScript-Ausführung: JS-Dateien werden teils geladen, aber nicht ausgeführt. Ausnahme ist die Googlebot-Familie, über die Gemini läuft, weil dort gerendert wird. Ob das im Sommer 2026 noch unverändert gilt, prüfst du am besten in deinen eigenen Server-Logs.

Ob eine Zweitfassung dir mehr Sichtbarkeit in KI-Antworten bringt, kann ich Stand August 2026 nicht belegen, und mir ist auch keine Untersuchung bekannt, die es zeigt. Sie beseitigt eine Fehlerquelle, mehr behaupte ich nicht.

Zum Aufwand: Wenn deine Seiten aus einer strukturierten Quelle erzeugt werden, fällt der Hauptaufwand einmal beim Generator an. Danach bleibt Pflege übrig, jedes Mal wenn sich Template oder Datenmodell ändern. Bei handgepflegtem HTML rechne dagegen mit Aufwand je Seite, und überleg dir, ob es das dann noch wert ist.

Was hineingehört

Erstens der Fließtext, in derselben Reihenfolge wie im HTML.

Zweitens die strukturierten Daten im Klartext. Nimm den Kaffeeröster von oben, dessen Produktseite JSON-LD mit Preis, Verfügbarkeit, Füllmenge und Röstgrad ausliefert. Diese Angaben stecken im HTML in einem Skript-Block. In der Markdown-Fassung stehen sie als kleine Tabelle oder Liste, direkt unter der Überschrift. Wichtig: beide Fassungen aus derselben Datenquelle erzeugen. Zwei handgepflegte Fassungen laufen erfahrungsgemäß auseinander, meist zuerst beim Preis. Belegen kann ich das nicht, aber ich habe es noch bei keinem redundant gepflegten Feld anders erlebt.

Drittens die Navigation als Links. Das wird am häufigsten vergessen.

Warum die Navigation mit hinein muss

Eine Markdown-Seite ohne Links ist eine Einbahnstraße: aus dieser Datei heraus führt kein Weg weiter. Der Abrufer kommt vielleicht über Sitemap oder HTML-Fassung an den Rest, aber du überlässt das dem Zufall. Er kennt deine Kategorien nicht, findet die Versandbedingungen nicht und sieht die verwandten Produkte nicht.

Nimm mindestens auf: Hauptnavigation, den Pfad der aktuellen Seite (Startseite, Kategorie, Produkt), verwandte Seiten und die Service-Seiten, die den Inhalt erklären (Versand, Rücksendung, Kontakt).

Alle Links absolut, mit Protokoll und Domain. Relative Links laufen ins Leere, sobald der Inhalt ohne seine Basis-URL weitergereicht wird, etwa als Textblock in einem Modell-Kontext. Beim direkten Abruf funktionieren sie, aber darauf kannst du dich nicht verlassen. Lass die Links auf die HTML-Originale zeigen, denn das sind die URLs, die du ohnehin stabil hältst.

Kein Doppel-Inhalt

Vier Punkte reichen.

Eigener Pfad, ableitbar: /kaffee/hochland-espresso bekommt /kaffee/hochland-espresso.md. Kein Query-Parameter, kein zweites Verzeichnis mit eigener Logik. Ein ableitbares Muster macht die Zuordnung für einen Menschen und für selbstgebaute Abrufer nachvollziehbar. Verlass dich nicht darauf, dass ein Crawler die Variante von sich aus errät. Verlinke oder liste sie, etwa in der llms.txt.

Kanonischer Verweis per HTTP-Header. Eine Markdown-Datei hat kein head-Element, und ein hineinkopiertes link-Element oder ein Frontmatter-Feld wird von keinem dokumentierten Auswerter gelesen. Der Header ist der einzige Weg, der außerhalb von HTML dokumentiert funktioniert. Der Server setzt auf die Markdown-Antwort: Link: <https://example.com/kaffee/hochland-espresso>; rel="canonical". Google dokumentiert die Auswertung dieses Headers ausdrücklich für Nicht-HTML-Dateien, allerdings nur für die Websuche und nur als Hinweis, nicht als Anweisung: Google Search Central, "Consolidate duplicate URLs" (Doku-Stand 10.07.2026). Ob KI-Crawler den Header auswerten, ist nirgends dokumentiert.

Richtiger Medientyp: Content-Type: text/markdown; charset=utf-8. Nicht text/html, nicht text/plain. text/markdown ist seit RFC 7763 (2016) offiziell registriert. Rechne damit, dass Browser die Datei damit herunterladen statt anzuzeigen. Das ist kein Fehler, sondern erwartetes Verhalten, aber es überrascht beim ersten Test.

Entweder canonical oder X-Robots-Tag: noindex, nicht beides auf derselben URL. Google rät von der Kombination ab, weil sich die Signale widersprechen: canonical sagt "falte die Signale in die Haupt-URL", noindex sagt "nimm die Seite raus". Meine Empfehlung: canonical, weil es die informativere Angabe ist. Das ist eine Abwägung, keine Regel.

Du kannst im HTML per link rel="alternate" type="text/markdown" auf die Zweitfassung zeigen. Das ist gültiges HTML und kostet nichts, aber mir ist kein Abrufer bekannt, der darauf reagiert. Betrachte es als Dokumentation für Menschen, nicht als Verteilweg.

llms.txt, ehrlich eingeordnet

llms.txt ist eine Datei im Wurzelverzeichnis, also /llms.txt, mit einer kurzen Beschreibung der Site und einer kommentierten Linkliste. Der Vorschlag stammt von Jeremy Howard (Answer.AI) und wurde im September 2024 veröffentlicht (llmstxt.org; Einordnung bei Search Engine Land, September 2024).

Stand August 2026 ist es kein verabschiedeter Standard: kein RFC, keine Arbeitsgruppe bei IETF oder W3C, die Spezifikation wird vom Urheber gepflegt. Ein Standardisierungsverfahren wurde diskutiert, ist aber bis dahin nicht zustande gekommen. Wenn du das liest, prüfe den Stand neu.

Etliche Tech-Anbieter veröffentlichen inzwischen selbst eine llms.txt für ihre Doku. Das heißt nicht, dass ihre Crawler fremde llms.txt-Dateien auswerten. Eine dokumentierte, verbindliche Auswertung durch einen der großen Anbieter ist mir Stand August 2026 nicht bekannt. Wie stark die Datei insgesamt verbreitet ist, kann ich nicht seriös beziffern. Wer dir llms.txt als Hebel für KI-Sichtbarkeit verkauft, hat den Beleg nicht.

Trotzdem liefern: wenn du eine XML-Sitemap hast, ist die Datei in kurzer Zeit generiert. Sie kostet fast nichts, solange sie mitgeneriert wird. Eine llms.txt, die von Hand angelegt und dann vergessen wird, ist schlechter als keine.

Was nicht hineingehört: Zugriffsregeln. Dafür ist robots.txt zuständig. llms.txt ist ein Inhaltsverzeichnis, keine Anweisung.

Die Reihenfolge, wenn du Aufwand priorisieren musst: sauberes HTML zuerst, Markdown-Zweitfassung mit Navigation zweitens, llms.txt als Beigabe.

So prüfst du es

Du brauchst einen Browser und ein Terminal.

1. Existiert die Zweitfassung? Öffne eine Produktseite, häng .md an die URL an. Erwartung: Klartext im Browser oder ein Download. Erwartung nicht erfüllt: 404 oder die HTML-Seite kommt zurück.

2. Ist der Inhalt vollständig? Leg beide Fassungen nebeneinander. Geh die Überschriften der HTML-Seite von oben nach unten durch und such jede in der Markdown-Datei. Prüf danach gezielt die Werte aus den strukturierten Daten: Preis, Verfügbarkeit, Füllmenge. Fehlt der Preis, ist die Datei für eine Produktfrage wertlos.

3. Kommt man von hier weiter? Zähl die Links in der Markdown-Datei. Kein Link heißt: Einbahnstraße, zurück an die Technik. Sind Links da, kopier zwei davon in die Adresszeile. Sie müssen laden. Beginnt ein Link mit / oder ../ statt mit https://, ist er relativ und damit unzuverlässig.

4. Header prüfen. Im Terminal:

curl -sI https://example.com/kaffee/hochland-espresso.md

Such in der Ausgabe nach zwei Zeilen: content-type: text/markdown und link: <...>; rel="canonical". Die URL im Link-Header muss auf die HTML-Seite zeigen, nicht auf die .md-Datei selbst.

5. Verweist das HTML zurück? Auf der HTML-Seite den Quelltext öffnen und nach alternate suchen. Erwartung: ein Eintrag mit type="text/markdown" und der .md-URL. Das ist Dokumentation, kein Verteilweg, siehe oben.

6. llms.txt. Ruf https://deine-domain.de/llms.txt auf. Erwartung: Text, kein 404. Klick fünf Links stichprobenartig an. Jeder 404 darin ist schlimmer als eine fehlende Datei, weil er zeigt, dass die Liste nicht gepflegt wird.

7. Drift-Test, der wichtigste. Ändere im CMS eine Kleinigkeit an einer Produktseite, etwa den Preis oder einen Satz in der Beschreibung. Warte den Cache ab. Ruf danach die .md-Fassung erneut auf. Zieht sie nicht mit, hast du keine Zweitfassung, sondern eine Altlast mit falschen Angaben.

8. Wirkung, nach einigen Wochen. Lass dir aus dem Server-Logfile alle Zugriffe auf Pfade mit .md und auf /llms.txt filtern, mit User-Agent. Das beantwortet nur die Frage, ob jemand abruft, nicht ob es dir nützt. Keine Zugriffe heißt: nichts kaputt, aber auch kein belegter Nutzen. Diesen Unterschied solltest du intern klar benennen, bevor jemand die Zweitfassung als Erfolg verbucht.

robots.txt: differenzieren statt pauschal sperren

Alles bisher ging davon aus, dass der Abruf überhaupt stattfindet. Diese Annahme steht in einer Datei, die schneller geschrieben ist als jedes Template.

Eine robots.txt ist in zehn Minuten geschrieben. Genau das ist das Problem: oft entsteht die Datei als Liste von Namen mit einem Disallow: / dahinter, und damit ist jede Unterscheidung schon verloren. Alle Bots landen im selben Topf, und dann wird pauschal entschieden. Das ist die teuerste Vereinfachung an dieser Stelle, weil die Bots verschiedene Dinge tun.

Drei Rollen, drei Entscheidungen

Es hilft, die Bots nach dem zu sortieren, was sie mit deinen Inhalten anstellen. Drei Rollen reichen für die Entscheidung. Achtung: eine einzelne Kennung kann mehrere Rollen bedienen, die Klassen sind ein Entscheidungsraster, keine saubere Taxonomie.

Trainings-Crawler holen Inhalte, um Modelle zu trainieren. Sie liefern dir keinen direkten Klick und keine nachweisbare Quellenangabe. Ob Trainingsinhalte später in einer Antwort auftauchen, lässt sich von außen weder belegen noch ausschließen. Ob du sie zulässt, ist eine inhaltliche und rechtliche Entscheidung, keine Reichweiten-Entscheidung.

Such-Index-Bots füllen die Indizes, aus denen KI-Antworten ihre Quellen ziehen. Welcher Assistent welchen Index nutzt, teils den eigenen, teils den eines Suchanbieters, ist anbieterabhängig und ändert sich. Wer hier sperrt, konkurriert nicht um einen schlechteren Platz, sondern fällt als eigene Quelle weitgehend aus. Was dann noch über dich in der Antwort steht, stammt von anderen Seiten.

Live-Abrufe passieren, während ein Mensch auf eine Antwort wartet. Jemand fragt einen Assistenten "was kostet die Bio-Hausmischung bei diesem Röster, und ist sie für Vollautomaten geeignet", und der Assistent ruft genau diese Produktseite ab. Wer diese Klasse sperrt, hält nicht einen Konzern draußen. Die Antwort entsteht trotzdem, nur ohne deine Seite, obwohl gerade jemand nach genau ihr gefragt hat.

Die Namen unterscheiden sich pro Anbieter, und sie ändern sich. Stand August 2026 dokumentieren die großen Anbieter ihre Kennungen öffentlich, einige davon nach Rollen getrennt. Welche Namen aktuell gelten, steht in der Doku des jeweiligen Anbieters, nicht hier und nicht in einer kopierten robots.txt aus einem Blogartikel.

Ein Beispiel für die Trennschärfe: Google bietet mit Google-Extended eine Kennung, die die Nutzung der Inhalte für das Training und das Grounding der Gemini-Modelle steuert. Sie betrifft weder die klassische Suchindexierung durch Googlebot noch das Erscheinen in den KI-Antworten der Google-Suche selbst, dafür gelten Snippet-Steuerungen wie nosnippet oder max-snippet. Stand August 2026, verbindlich ist die Google-Doku zu AI-Features. Wer stattdessen Googlebot sperrt, verliert praktisch seine Sichtbarkeit in der Suche. Reste können als nackte URL ohne Beschreibung übrig bleiben, siehe unten.

Was robots.txt nicht ist

Eine Sperre in der robots.txt ist eine Bitte. Der Standard (RFC 9309, seit 2022) beschreibt freiwilliges Verhalten, keine Zugriffskontrolle. Die großen, namentlich auftretenden Crawler halten sich überwiegend daran, Stand August 2026. Es gab in den Jahren davor mehrfach öffentlich dokumentierte Vorwürfe gegen einzelne benannte KI-Crawler, robots.txt umgangen zu haben. Verlass dich also nicht darauf, dass die Datei etwas erzwingt. Wer deine Inhalte gegen deinen Willen abziehen will, liest die Datei bestenfalls als Inhaltsverzeichnis. Ein Pfad, den du dort ausschließt, ist damit öffentlich benannt.

Ein User-Agent ist eine Behauptung, kein Ausweis. Jeder kann sich ChatGPT-User nennen. Ernst gemeinte Verifikation läuft über die Herkunft der Anfrage: forward-bestätigte Reverse-DNS-Prüfung oder, wo der Anbieter sie veröffentlicht, seine IP-Bereiche. Nicht jeder Anbieter stellt beides bereit. Das gehört in den Server, den Reverse-Proxy oder die WAF, nicht in die robots.txt.

Was in eine robots.txt für einen Shop gehört

Wenig. Ein Sitemap:-Eintrag mit vollständiger URL. Er ist zwar kein Teil des Standard-Kerns, wird aber von den großen Crawlern seit Jahren ausgewertet.

Dazu der Ausschluss echter Nicht-Inhalte: Warenkorb, Checkout, Kundenkonto, interne Suchergebnisse mit Query-Parametern, Filter-Kombinationen, die dieselben Produkte in beliebig vielen Varianten ausspielen. Wichtig: das spart Crawl-Budget, es entfernt nichts aus einem Index. Seiten, die aktiv aus dem Index sollen, brauchen noindex und müssen dafür crawlbar bleiben.

Alles andere offen, insbesondere CSS, JavaScript, Bilder und Schriftdateien, weil eine blockierte Ressource die Seite für den Abrufenden unvollständig macht.

Und eine bewusste Entscheidung pro Rolle statt einer pro Anbieter. In der Praxis heißt das für einen Shop, der gefunden werden will: Such-Index-Bots offen, Live-Abrufe offen, Training entscheidest du.

Aberglaube

Crawl-delay ist nicht Teil von RFC 9309. Google ignoriert die Angabe erklärtermaßen und regelt seine Crawl-Rate selbst, Bing und Yandex werten sie aus. Stand August 2026. Als verlässliche Bremse taugt sie damit nicht.

Eine robots.txt ist kein Datenschutz und kein Zugriffsschutz. Disallow verhindert das Crawlen, nicht zwingend das Auftauchen der URL in einem Index: wenn du eine Seite aus dem Index haben willst, brauchst du ein noindex, und das kann nur lesen, wer die Seite crawlen darf. Beides zusammen hebt sich auf.

Auch falsch: dass eine pauschale Sperre gegen alles mit KI im Namen die eigene Sichtbarkeit schützt. Eine Trainings-Sperre ist eine legitime Rechteentscheidung. Eine Sperre von Index-Bots und Live-Abrufen dagegen nimmt dich aus dem Raum, in dem die Antwort entsteht.

So prüfst du es

1. Ruf die Datei im Browser auf. https://deine-domain.de/robots.txt. Kommt reiner Text, ist alles in Ordnung. Kommt ein 404, gibt es keine Regeln, alles ist erlaubt. Kommt eine gestaltete HTML-Seite mit Status 200, liest der Crawler Markup als Regelwerk, das ist der schlechteste Fall. Serverfehler im 5xx-Bereich können zeitweise als Komplettsperre gewertet werden.

2. Prüf jede Hostname-Variante einzeln. Die robots.txt gilt pro Host, Schema und Port. shop.deine-domain.de hat eine eigene, www.deine-domain.de ebenfalls. Ruf alle Varianten auf, die du tatsächlich betreibst, und vergleiche den Inhalt.

3. Geh eine echte Produkt-URL Zeile für Zeile durch. Nimm eine URL, mit der du gefunden werden willst, und lies die Regeln von oben nach unten. Muster wie Disallow: /*? treffen bei den Crawlern, die Wildcards unterstützen, jede URL mit Fragezeichen, oft also deutlich mehr Seiten als gedacht. Prüfe das Muster gegen konkrete URLs, bevor du es scharf schaltest. Pfade sind case-sensitiv.

4. Such nach der Selbstblockade. Wenn ein Pfad in robots.txt gesperrt ist und die Seite gleichzeitig ein noindex trägt, arbeitet die Konfiguration gegen sich selbst. Ein noindex als Meta-Tag steht im Seitenquelltext. Es kann aber auch als X-Robots-Tag im HTTP-Header gesetzt sein, dann siehst du es nur in den Response-Headern, etwa in den Entwicklertools unter Netzwerk.

5. Lass die Suchmaschinen-Konsole rechnen. Stand August 2026 findest du in der Google Search Console einen robots.txt-Bericht und die URL-Prüfung, die dir für eine konkrete Adresse sagt, ob sie blockiert ist. Das ist die verlässlichste Prüfung ohne eigenes Werkzeug.

6. Schau nach, wer wirklich kommt. Im Server- oder Hoster-Log (bei vielen Hostern als "Zugriffsstatistik" oder "Roh-Logfiles") nach User-Agent-Namen filtern. Server-Logs zeigen, welche Kennungen sich als Besucher ausgeben. Wer wirklich dahintersteckt, klärt erst die Prüfung von Reverse-DNS oder IP-Bereich.

7. Mach den Live-Test. Öffne einen KI-Assistenten mit Web-Zugriff, gib eine deiner Produkt-URLs an und frag nach dem Preis und einem Detail, das nur auf dieser Seite steht. Wenn die Antwort lautet, die Seite sei nicht abrufbar oder gesperrt, blockierst du den Live-Abruf. Wiederhol das mit zwei, drei Assistenten. Welche Kennung ein Assistent für Live-Abrufe nutzt, steht in seiner Doku und ändert sich, prüfe das beim Aufsetzen neu.

8. Datier deine Datei. Schreib als Kommentarzeile das Datum der letzten Prüfung hinein (# geprüft: 2026-08-14). Crawler-Namen ändern sich, deine Datei tut es nicht von allein.

Was ein Prüfskript für dich tun kann und was nicht

Die sechs Prüfblöcke oben sind Handarbeit. Ein Teil davon lässt sich automatisieren, und es lohnt sich, weil Template-Änderungen und Shop-Updates Befunde lautlos zurückbringen.

Automatisierbar ist alles, was eine Zählung oder ein Vorhandensein ist. Ein Skript kann eine Liste von URLs abrufen, für jede die Antwortgröße protokollieren, <main- und <h1-Vorkommen zählen, prüfen ob nav und footer innerhalb der main-Grenzen liegen, JSON-LD-Blöcke extrahieren und gegen eine Feldliste pro Seitentyp abgleichen, die .md-Variante anfragen und ihre Header lesen, und die robots.txt gegen konkrete URLs auswerten. Das Ergebnis ist eine Tabelle mit Befunden pro URL, die du bei jedem Deploy neu erzeugen kannst.

Nicht entscheiden kann ein Skript, ob ein Befund ein Problem ist. Es sieht, dass derselbe Textblock im main zweier Seiten steht, aber nicht, ob das Boilerplate ist oder ein identischer Pflegehinweis. Es sieht, dass h1 den Shopnamen enthält, aber nicht, ob das auf der Startseite richtig ist. Es sieht ein nav in main, aber nicht, ob es eine Blätter-Navigation ist, die dort hingehört. Es sieht einen Wert in additionalProperty, aber nicht, ob die englische Fassung noch dieselbe Sache benennt.

Zwei Grenzen sind grundsätzlicher. Ein Skript ruft mit seiner eigenen Kennung ab und bekommt deshalb möglicherweise etwas anderes als ein Crawler oder als dein Browser. Und es kann nicht feststellen, ob ein Abrufer den ausgelieferten Inhalt tatsächlich verwertet: Der Nachweis der Wirkung steht in keiner Antwort des Servers.

Sinnvolle Arbeitsteilung: das Skript läuft bei jedem Deploy und meldet Abweichungen zum letzten Lauf. Die Bewertung machst du einmal pro Seitentyp von Hand, und danach nur noch bei einer Meldung.

Was dieser Text nicht leistet

Er beschreibt Handwerk, keine Wirkung. Kein Abschnitt oben belegt, dass eine Maßnahme dich in mehr KI-Antworten bringt. Was sie belegbar tun: sie beseitigen Stellen, an denen Inhalt gar nicht erst ankommt oder falsch ankommt. Das ist eine notwendige Bedingung, keine hinreichende.

Alle Aussagen beschreiben den Stand August 2026. Am schnellsten altert alles, was mit Crawler-Verhalten zu tun hat: welche Kennung ein Anbieter verwendet, ob JavaScript ausgeführt wird, ob ein Header ausgewertet wird, welche Rich Results existieren. Die Vercel/MERJ-Auswertung stammt von Dezember 2024, die FAQ-Rich-Results sind zum 7. Mai 2026 eingestellt worden, Crawl-delay wird heute von Google ignoriert und von Bing gelesen. Alle vier Aussagen können in einem Jahr anders lauten. Genauso Browser-Menüs, Tastenkürzel und Werkzeugnamen.

Näherung ist an mehreren Stellen im Spiel und dort auch benannt: die Zählung per Browser-Suche ist kein Parser, der Lesemodus ist eine Heuristik, die Antwortgröße ist ein Indikator. Diese Schritte finden Verdachtsfälle, sie beweisen nichts.

Nicht behandelt sind Rechtsfragen. Ob du Trainings-Crawler zulassen willst, ist eine Entscheidung über Nutzungsrechte an deinen Inhalten, und dazu steht hier nichts. Ebenso wenig zu Lizenzverträgen mit Anbietern, zu Bezahlmodellen für Crawler-Zugriff und zu dem, was in der EU oder anderswo daraus rechtlich folgt.

Und ein Punkt, den man leicht übersieht: der größte Teil der Arbeit oben besteht darin, HTML richtig zu bauen und Produktdaten sauber zu pflegen. Das war vor den Assistenten schon richtig, für Screenreader, für Suchmaschinen, für den eigenen Datenbestand. Neu ist nur, dass Nachlässigkeit an dieser Stelle jetzt schneller sichtbar wird, weil ein zweiter Leser dazugekommen ist, der weniger verzeiht als ein Mensch mit Browser.