LLM Readability: Muss ich meinen Content jetzt für Maschinen umschreiben?

Seit einigen Monaten begegnet mir auf Konferenzen, in LinkedIn-Postings und in Agentur-Pitches ein Begriff, der so klingt, als hätte jemand einen neuen Rankingfaktor entdeckt: LLM Readability. Manchmal auch „LLM-Lesbarkeit“, gelegentlich „maschinelle Lesbarkeit“. Die Botschaft dahinter ist fast immer dieselbe: Sprachmodelle lesen anders als Menschen, deshalb müsse man Content anders schreiben – kürzere Absätze, Antwort zuerst, fragebasierte Überschriften, alles schön in zitierfähige Häppchen zerlegt. Wer das nicht tut, werde in ChatGPT, den AI Overviews und Perplexity schlicht nicht mehr zitiert.

Ich habe mir das genauer angesehen, weil ich für unser O’Reilly-Buch ohnehin tief in der GEO-Literatur stecke – und weil ich bei jedem Begriff, der binnen eines Jahres vom Blogpost zum kostenpflichtigen Score wird, reflexartig nach der Belegkette frage.

Das Ergebnis vorweg:

Der Begriff ist als Denkrahmen brauchbar, als Rankingversprechen ist er überzogen. Und die zentrale Handlungsempfehlung, die viele daraus ableiten – Content in maschinenfreundliche Mikro-Häppchen zerlegen –, ist ausgerechnet diejenige, der Google öffentlich und ungewöhnlich deutlich widerspricht.

Es gibt aber noch eine zweite Ebene, die mich mittlerweile mehr beschäftigt als die Belegkette selbst. Denn die meisten Einzelempfehlungen, die unter diesem Label kursieren, sind gar nicht falsch. Sie sind nur mit einer Begründung versehen worden, die sie nicht brauchen – und die sie beschädigt.

Warum ich das so sehe, im Detail.

Was hier eigentlich passiert ist: eine Begründung wurde ausgetauscht

Zwischenüberschriften setzen, Absätze sinnvoll schneiden, die Kernaussage nach vorne ziehen, Listen dort einsetzen, wo etwas tatsächlich eine Aufzählung ist. Das ist alles richtig. Ich mache das seit zwanzig Jahren und würde es weiter empfehlen, wenn morgen sämtliche Sprachmodelle abgeschaltet würden.

Verändert hat sich nicht die Maßnahme, sondern ihre Begründung.

Früher hieß es: Strukturiere deinen Text, weil Menschen ihn unterschiedlich lesen – manche überfliegen ihn, manche steigen in der Mitte ein, manche suchen gezielt eine Zahl, und nur die wenigsten lesen von oben nach unten durch. Heute heißt es: Strukturiere deinen Text, weil die KI ihn sonst nicht zitiert.

Gleiche Handlung, andere Rechtfertigung. Und diese neue Rechtfertigung ist erstens empirisch schlecht gedeckt – dazu der Hauptteil dieses Artikels –, zweitens für die Entscheidung völlig belanglos, und drittens schädlich für genau die Praxis, die sie zu stützen vorgibt. Die letzten beiden Punkte behandle ich weiter unten, nachdem die Evidenz auf dem Tisch liegt.

Die alte Begründung war die bessere

Fangen wir mit dem an, was dabei verloren geht.

Menschen lesen Sachtexte nicht in einem Modus, sondern in mehreren, und sie wechseln ständig zwischen ihnen. Es gibt das Überfliegen, bei dem jemand in wenigen Sekunden entscheidet, ob ein Text überhaupt relevant ist. Es gibt das Scannen nach einem konkreten Element – einer Zahl, einem Namen, einer Bedingung. Es gibt den Quereinstieg, weil jemand über eine Suchmaschine mitten im Text landet und den Kontext nicht kennt. Es gibt das Nachschlagen, wenn ein Text zum zweiten Mal aufgerufen wird, diesmal gezielt. Und es gibt das lineare Lesen, das online die Ausnahme ist.

Jedes strukturelle Element bedient dabei etwas anderes. Zwischenüberschriften sind Navigationsanker für Scanner und Quereinsteiger. Ein vorangestelltes Fazit bedient die Überflieger. Absatzgrenzen markieren Gedankenwechsel und geben dem Arbeitsgedächtnis Pausen. Listen entlasten dort, wo tatsächlich mehrere gleichrangige Elemente nebeneinanderstehen – und verschleiern die Argumentation dort, wo sie es nicht tun.

Das ist gut untersucht, in Teilen seit den 1980er Jahren, und hat mit generativer KI exakt nichts zu tun. Eine Warnung an dieser Stelle: Aus diesen Lesestrategien werden auf Konferenzfolien gerne drei feste Lesertypen – „Skimmer, Scanner, Reader“. Das ist eine Fehldeutung derselben Forschung, und zwar eine folgenreiche; ich habe sie in einem eigenen Beitrag samt Evidenzlage auseinandergenommen. Für hier genügt: Es sind Zustände, keine Personen, und sie liegen nicht auf einer gemeinsamen Skala von flach nach tief.

Die Leserperspektive ist außerdem anspruchsvoller als das, was heute unter „LLM Readability“ verkauft wird. Denn sie zwingt zu einer Abwägung: Welche Lesestrategie bediene ich hier, auf Kosten welcher anderen? Ein Text, der nur noch aus kurzen, autonomen Blöcken besteht, ist hervorragend scannbar und als Argumentation wertlos, weil er keine Gedankenführung mehr hat. Wer für Menschen strukturiert, muss diese Spannung aushalten und für jeden Text neu auflösen.

Wer für Maschinen strukturiert, muss das nicht. Er kann eine Checkliste abarbeiten. Genau darin liegt die Attraktivität – und der Schaden.

Erstens: Der Begriff meint zwei verschiedene Dinge

Bevor man über Evidenz streitet, muss man klären, worüber man redet. „LLM Readability“ wird nämlich für zwei völlig verschiedene Sachverhalte verwendet, und diese Vermischung ist die Quelle der meisten Missverständnisse:

Lesbarkeit für Menschen. Also: Wie verständlich ist ein Text – gleich ob von Hand geschrieben, von einem Modell verfasst oder von einem Modell vereinfacht? Das ist ein etabliertes Forschungsfeld mit Humanratings, Lesbarkeitsformeln und spezialisierten Metriken. Hier gibt es echte, belastbare Wissenschaft.
Verwertbarkeit für Maschinen. Also: Wie gut kann ein generatives Suchsystem eine Seite abrufen, interpretieren, extrahieren und in einer Antwort referenzieren? Das ist die Bedeutung, die im GEO-Diskurs gemeint ist – und für die es keine standardisierte wissenschaftliche Definition und keinen validierten Score gibt.

Wer den Begriff hört und dabei an Flesch-Werte, Satzlängen und die Wiener Sachtextformel denkt, meint Lesbarkeit für Menschen. Wer an Zitierfähigkeit in ChatGPT oder den AI Overviews denkt, meint Verwertbarkeit für Maschinen. Die beiden haben empirisch deutlich weniger miteinander zu tun, als der gemeinsame Name suggeriert. Genau diese Doppeldeutigkeit macht den Begriff rhetorisch so wirksam: Er borgt sich die wissenschaftliche Seriosität der psycholinguistischen Lesbarkeitsforschung für eine Behauptung über Zitationsranking, die diese Forschung überhaupt nicht untersucht hat.

Zweitens: Woher der Begriff kommt

Geprägt hat ihn 2024 Olaf Kopp von Aufgesang. Und das muss man ihm ausdrücklich zugutehalten: Aufgesang deklariert das Konzept offen als Eigenentwicklung, nicht als wissenschaftlichen Fachbegriff. Kopp bezeichnet sich selbst als dessen Erfinder. Das ist redlicher als vieles, was mir sonst im GEO-Umfeld begegnet, wo Branchenhypothesen gerne im Duktus etablierter Wissenschaft vorgetragen werden.

Die Definition lautet sinngemäß: LLM-Lesbarkeit beschreibt, wie gut Inhalte von großen Sprachmodellen verarbeitet und verstanden werden können. Genannt werden Dimensionen wie Sprachqualität, Strukturierung, Chunk-Relevanz, Informationshierarchie (Antwort zuerst, im Sinne der Minto-Pyramide), Kontextmanagement und Konsistenz. Daraus abgeleitet gibt es konkrete Zielwerte – etwa Absätze unter 400 Zeichen und Gesamtlängen von 1.200 bis 1.500 Wörtern – sowie einen proprietären Score in Aufgesangs Toolsuite.

Als Audit-Rahmen finde ich das nicht verkehrt. Diese Dimensionen sind sämtlich Dinge, über die man beim Content-Review sinnvoll nachdenkt. Mein Problem beginnt an einer anderen Stelle: bei der Frage, woher die konkreten Zahlen kommen und was sie bewirken sollen.

Drittens: Die Belegkette hält nicht, was sie verspricht

Das Konzept beruft sich auf Forschung und Patente – im Kern auf zwei Quellen. Ich habe beide gelesen.

1. Das GINGER-Paper (Łajewska & Balog, Universität Stavanger, arXiv:2503.18174) beschreibt eine modulare RAG-Pipeline, die Antworten aus sogenannten „information nuggets“ zusammensetzt. Das ist ein systeminternes Verfahren zur Antwortgenerierung aus bereits abgerufenen Dokumenten. Das Paper untersucht weder Absatzlängen noch Überschriftenformate noch Zitationsraten in Abhängigkeit vom Schreibstil. Es sagt nichts darüber, wie man Webseiten schreiben sollte.

2. Das Google-Patent US12158907B1 („Thematic Search“) ist ergiebiger – und es ist tatsächlich aktuell: Die Priorität reicht auf den 16. Mai 2023 zurück, erteilt wurde es am 3. Dezember 2024. Es beschreibt passage-basierte Verarbeitung – ein Passage ist dort definiert als „a paragraph of a responsive document, e.g., as defined by one or more HTML elements“ – und eine Zusammenfassung pro Passage durch ein Sprachmodell. Nur: Die im Patent genannten Ranking-Signale sind Query-Relevanz, Qualität, Autorität, Popularität, Backlinks, Nutzererfahrung, Social Signals und Aktualität. Lesbarkeit taucht dort nicht auf.

An dieser Stelle bin ich in einer früheren Fassung dieses Artikels selbst zu großzügig gewesen. Ich hatte geschrieben, damit sei „die strukturelle Prämisse belegt: Ja, diese Systeme arbeiten auf Passage-Ebene“. Das ist zu unpräzise formuliert – und zwar in genau der Weise, die den ganzen Diskurs unscharf macht.

Drei Ebenen, die ständig verwechselt werden

Wer über Passagen redet, muss sagen, welche Ebene gemeint ist:

Indexierungseinheit: Was wird als adressierbarer Eintrag im Index gespeichert? Klassisch: die Seite bzw. das Dokument.
Retrieval-Einheit: Was gibt die erste Suchstufe als Kandidaten zurück? Dokument oder Passage – je nach Architektur.
Scoring-Einheit: Auf welcher Granularität wird Relevanz berechnet? Kann feiner sein als die Indexierungseinheit.

In der Information-Retrieval-Forschung existieren beide Architekturen nebeneinander. Dense Passage Retrieval (Karpukhin et al., EMNLP 2020) und ColBERT indexieren tatsächlich auf Passage-Ebene: Der Passage-Encoder erzeugt zur Indexierungszeit einen Vektor pro Passage, das Retrieval läuft über Vektorähnlichkeit. Die MaxP-/FirstP-Familie (Dai & Callan, SIGIR 2019) macht das Gegenteil: Kandidaten kommen aus einem klassischen Dokumentindex, werden dann in überlappende Fenster zerlegt, passagenweise bewertet und wieder zum Dokument-Score aggregiert.

Diese Varianten schließen sich nicht prinzipiell aus – ein komplexes System kann durchaus einen Dokumentindex besitzen, darin Segmentrepräsentationen führen und anschließend Kandidatenpassagen aus den Gewinnerdokumenten reranken. Der Fehler liegt woanders: darin, all das unter einem Etikett zusammenzufassen und die Ebene nicht zu benennen. Und das Patent belegt Passage-Level-Verarbeitung, nicht Passage-Level-Indexierung.

Das Thematic-Search-Patent beschreibt selbst Document-first

Hier wird es für die Belegkette richtig unangenehm, denn das Patent, das als Kronzeuge für passage-zentrierte Verarbeitung herangezogen wird, beschreibt tatsächlich den umgekehrten Ablauf.

In der Patentschrift erhält die Suchmaschine zunächst Suchergebnisse mit einem Set „responsive documents“. Diese werden an die Thematic Search Engine übergeben, die anschließend deren Inhalt analysiert und daraus Themes erzeugt. In einer Ausführungsform werden ausdrücklich die Top-X-Suchergebnisse ausgewählt, um aus deren Content Themen abzuleiten. Die Claims formulieren denselben Ablauf:

Suchanfrage
  ↓
Suchergebnisse / responsive documents abrufen
  ↓
Inhalt dieser Dokumente analysieren
  ↓
Passagen / Summaries
  ↓
Themes / Clustering / Ranking

Das ist eine Document-first-Architektur: erst Dokumente abrufen, dann Passagen daraus erzeugen. Kopp referiert diesen Ablauf in seinem Artikel sogar korrekt – er beschreibt, dass zunächst Top-N-Dokumente, etwa 10 bis 100 URLs, abgerufen und gerankt werden und diese danach in kleinere Passagen zerlegt werden.

Dann folgt allerdings der Satz, an dem die Argumentation kippt:

„This process describes how AI Overviews and, in part, AI Mode, operate.“

Genau dieser Schluss ist durch das Patent nicht gedeckt. Ein Patent belegt, dass Google eine Erfindung angemeldet hat. Es belegt nicht, dass sie in einem Produkt läuft, nicht, dass AI Overviews sie verwendet, und schon gar nicht, welchen Anteil sie dort hätte. Bemerkenswert ist eher das Gegenteil: Die Document-first-Struktur des Patents ist ausgerechnet mit Googles offizieller Beschreibung von AI Overviews kompatibel – Core-Search-Ranking → Seiten aus dem Index → spezifische Informationen aus diesen Seiten → Generierung. Das Patent stützt also, wenn überhaupt, das Modell, gegen das im GEO-Diskurs argumentiert wird.

Das ist meines Erachtens das zentrale methodische Problem: Patent-Kompatibilität wird wie ein Implementierungsnachweis behandelt.

Was Google zur Indexierungsebene tatsächlich gesagt hat

Zu genau dieser Frage gibt es eine ungewöhnlich deutliche offizielle Aussage. Google kündigte im Oktober 2020 auf dem Search-On-Event „passage indexing“ an – und ruderte binnen Tagen zurück. Danny Sullivan damals wörtlich auf Twitter:

„We are not indexing passages. Period.“

Zum tatsächlichen Rollout im Februar 2021 (zunächst nur englischsprachige Queries in den USA) formulierte Google offiziell:

„This change doesn’t mean we’re indexing individual passages independently of pages. We’re still indexing pages and considering info about entire pages for ranking. But now we can also consider passages from pages as an additional ranking factor.“

Google hat den Namen des Features deshalb korrigiert: Es heißt seither Passage Ranking, nicht Passage Indexing. Im aktuellen „Guide to Google Search’s ranking systems“ steht es weiterhin als aktives System – definiert als System, das einzelne Abschnitte einer Webseite identifiziert, um besser einzuschätzen, wie relevant die Seite für eine Suche ist.

Der belastbare Befund lautet damit eng, aber klar:

Google dokumentiert passage-aware Ranking, aber keinen Passage-First-Webindex als Grundlage von Google Search.

Das Umgekehrte lässt sich natürlich ebenso wenig beweisen – Google veröffentlicht seine Indexarchitektur nicht vollständig. Ergänzend passt aber, was sich aus der geleakten Content-Warehouse-Dokumentation verifizieren lässt: Dokumentiert sind pageEmbedding, siteEmbedding, siteFocusScore und siteRadius, also Repräsentationen auf Seiten- und Site-Ebene. Ein Feld für einen dedizierten Passage-Embedding-Store ist nicht verifizierbar.

Für die LLM-Readability-Debatte ist das entscheidend. Wenn die Seite die Indexierungseinheit bleibt und Passagen ein zusätzliches Signal innerhalb der Seite sind, dann ist das Zerlegen einer Seite in viele kleine Einheiten nicht nur unnötig – es arbeitet gegen die Ebene, auf der bewertet wird.

Und ein Wort zur Beweiskraft von Patenten

Patente sind schwache Evidenz für Produktionssysteme. Sie werden bewusst breit formuliert, um Implementierungsspielraum zu schützen, und viele werden nie umgesetzt. John Mueller hat das im Februar 2021 – zufällig fast zeitgleich mit dem Passage-Ranking-Rollout – so gesagt:

„just because it’s patented from Google, and maybe even from someone who works on search, doesn’t mean that we actually use it in search.“

Dazu kommt ein Datierungsproblem, das im Diskurs regelmäßig untergeht. Die zentralen „Answer Passage“-Patente, die in solchen Argumentationsketten auftauchen, stammen sämtlich aus dem Jahr 2014: Context scoring adjustments for answer passages hat Priorität vom 31. Januar 2014, Weighted answer terms for scoring answer passages und Scoring candidate answer passages jeweils vom August 2014. Sie beschreiben ausdrücklich ein Answer-Box-Szenario: Query als Frage erkennen, Ressourcen finden, Kandidatenpassagen erzeugen, diese über Answer Terms und Heading-Kontext bewerten, eine davon in einer Antwortbox anzeigen.

Das ist die Featured-Snippet-Ära: vor BERT, vor Transformer-basiertem Retrieval, vor LLMs. Diese Verfahren waren die Antwort auf die Frage, wie man ohne neuronale Sprachmodelle eine passende Antwortpassage aus einem Dokument zieht.

Wer sie als Fundament heutiger KI-Suche präsentiert, konstruiert eine Kontinuität, wo tatsächlich ein Technologiebruch liegt. Und die Kette „Phrase Indexing → Passage Retrieval → Generative Retrieval“ suggeriert eine Entwicklung entlang einer Achse, obwohl mindestens drei voneinander unabhängige Achsen vermischt werden:

Lexikalische Repräsentation: Wörter → Phrasen → kontextuelle/dichte Repräsentationen
Retrieval-Granularität: Dokument → Passage/Chunk → Satz/Token/hierarchische Einheit
Retrieval-Mechanismus: invertierter Index → Dense-Vector-ANN → gelernter Reranker → generatives DocID-Retrieval

Diese Achsen sind weitgehend orthogonal. Ein Passage-Retriever kann BM25 nutzen. Ein Dokument-Retriever kann Dense Embeddings nutzen. Die zeitliche Kontinuität des Wortes passage ist keine Kontinuität der Implementierung.

Der Schluss von „das System verarbeitet Passagen“ auf „also werden kurze Absätze und Answer-first-Formulierungen häufiger zitiert“ ist damit eine Inferenz, keine Ableitung. Sie ist plausibel. Sie ist nicht belegt. Und die spezifischen Schwellenwerte – warum 400 Zeichen und nicht 350 oder 600? – haben in den zitierten Dokumenten überhaupt keine Grundlage.

Das ist der Punkt, an dem ich als Wissenschaftler unruhig werde: Eine plausible Hypothese wird durch Verweis auf reale Forschung mit einer Autorität ausgestattet, die diese Forschung nicht hergibt.

Viertens: Wer chunkt hier eigentlich?

Es gibt einen Einwand gegen meine Argumentation, der ernst genommen werden muss, und er lautet: Moderne KI-Suche ist doch RAG, und RAG arbeitet nun einmal mit Chunks. Ein Chunk ist konzeptionell eine Passage. Also ist Passage-Level-Verarbeitung doch die Realität.

Das stimmt – und ich will das ausdrücklich nicht kleinreden. Passage-Level-Retrieval ist alles andere als ein überholtes Pre-LLM-Konzept. Im Gegenteil: Dense Passage Retrieval und das ursprüngliche RAG-Paper von Lewis et al. sind beide 2020 erschienen und damit Produkte der Transformer-Ära. Sie haben Passagen zu Einträgen eines modernen Vektorindex gemacht. Wer behauptet, Passage Retrieval sei ein Relikt aus der Zeit vor BERT, hat die Chronologie schlicht falsch.

Die interessante Frage ist deshalb nicht, ob auf Passage-Ebene gearbeitet wird, sondern wer diese Passagen erzeugt.

Was die Anbieter dokumentieren

Die Antwort ist erfreulich gut belegt, weil vier große Anbieter ihre Chunking-Defaults offenlegen:

System	Chunkgröße (Default)	Overlap
OpenAI Vector Stores / File Search	max. 800 Token	400 Token
Google RAG Engine / Agent Search	1.024 Token	256 Token
AWS Bedrock Knowledge Bases (fixed size)	300 Token	20 %
Microsoft Azure AI Search	kein fester Default dokumentiert	–

Googles Vertex-AI-Dokumentation beschreibt die Pipeline am vollständigsten: Der Document AI Layout Parser zerlegt ein Dokument entlang seiner Layout-Entitäten in Chunks, diese werden eingebettet, über Vector Search abgerufen und anschließend durch eine Ranking-API neu sortiert. Azure formuliert das Ziel explizit so, dass die Teile eines großen Dokuments unabhängig voneinander gematcht werden können.

Daraus folgen zwei Dinge, die dem gängigen Ratschlag direkt widersprechen.

Erstens: Die Chunk-Grenzen setzt der Parser, nicht der Autor. Ich kann beeinflussen, wo Überschriften und Absätze stehen – aber die Segmentierung selbst ist eine Systementscheidung, und sie orientiert sich an Layout-Entitäten oder festen Tokenfenstern, nicht an meiner Zeichenzahl. Hinzu kommt die Überlappung: Wenn benachbarte Chunks sich um 20 % bis 50 % überschneiden, ist die Frage, wo genau eine Grenze verläuft, für das Retrieval-Ergebnis weitgehend entschärft. Überlappende Chunked Embeddings sind exakt dafür gebaut, dass ein zusammenhängender Gedanke nicht an einer Segmentgrenze zerreißt.

Zweitens: Die Größenordnungen passen nicht zusammen. 400 Zeichen entsprechen im Deutschen grob 60 bis 90 Token. Die dokumentierten Chunkgrößen liegen zwischen 300 und 1.024 Token – also etwa beim Drei- bis Fünfzehnfachen. Selbst am unteren Ende der Skala, bei AWS, passen mehrere solcher Mikro-Absätze in einen einzigen Chunk; bei Google sind es zehn bis fünfzehn. Die Fragmentierung ist auf der Systemebene damit weitgehend unsichtbar. Sichtbar ist sie nur für die Leserinnen und Leser, denen man den Gedankengang zerhackt hat.

Wichtige Einschränkung, damit ich nicht denselben Fehler mache, den ich kritisiere: Diese Systeme sind nicht die Google-Websuche. Es sind Enterprise-RAG-Produkte mit eigener Architektur. Ich leite daraus nicht ab, dass AI Overviews oder ChatGPT Search genauso funktionieren. Aber es sind die einzigen Stellen, an denen die Hersteller konkret dokumentieren, wie ihre RAG-Systeme chunken – und damit ein erheblich besserer Anhaltspunkt als jede Patentexegese.

Die Entwicklung geht nicht zu kleineren Einheiten

Der vielleicht wichtigste Befund gegen „schreib kleiner“ kommt aus der jüngeren Forschung, und er zeigt in die entgegengesetzte Richtung.

LongRAG kritisiert ausdrücklich, dass klassische Retrieval-Einheiten zu kurz seien – DPR arbeitete typischerweise mit Wikipedia-Passagen von rund 100 Wörtern. Kurze Chunks verlieren Kontext und erzeugen schwer unterscheidbare Kandidaten. LongRAG experimentiert deshalb mit Retrieval-Einheiten von rund 4.000 Token und bei manchen Datensätzen mit ganzen Dokumenten als Retrieval-Einheit.

RAPTOR setzt am selben Problem an: Flache Chunk-Listen erfassen den globalen Dokumentkontext schlecht. Das System baut deshalb rekursive Cluster und Zusammenfassungen über den Chunks auf und kann auf verschiedenen Abstraktionsebenen abrufen.

Late Chunking schließlich hält an Chunks als Abrufeinheit fest, verwirft aber deren isolierte Einbettung: Erst läuft ein längerer Textkontext durch den Transformer, danach werden die einzelnen Chunk-Repräsentationen daraus abgeleitet. Verbesserungsbedürftig ist also nicht die Passage als Retrieval-Einheit, sondern ihre kontextfreie Repräsentation.

Mit wachsenden Kontextfenstern wird die optimale Retrieval-Einheit tendenziell größer, nicht kleiner. Wer heute seine Absätze auf 400 Zeichen kürzt, optimiert nicht nur an einer Stellschraube, an der er nicht sitzt – er optimiert auf einen Trend, der sich gerade umkehrt.

Wo die tatsächlichen Qualitätshebel in solchen Pipelines liegen, lässt sich ebenfalls belegen. Anthropic hat 2024 für seinen „Contextual Retrieval“-Ansatz gemessen: Kontextualisierte Embeddings senkten die Fehlerrate beim Abruf der Top-20-Chunks von 5,7 % auf 3,7 %; kombiniert mit kontextualisiertem BM25 auf 2,9 %; mit vorgeschaltetem Reranking auf 1,9 % – eine Reduktion um 67 %. Der größte Einzelhebel ist die Reranking-Stufe. Sie sitzt im System, nicht im Text.

Fünftens: Was die kontrollierte Forschung tatsächlich zeigt

Und hier wird es interessant, denn die Evidenzlage hat sich in den letzten zwei Jahren erheblich gedreht – von optimistisch zu ernüchternd.

Etappe 1: Das GEO-Paper (KDD 2024)

Aggarwal et al. führten mit GEO-bench (10.000 Queries) neun Optimierungsmethoden gegen unveränderte Baseline-Inhalte ins Feld. Ergebnis: bis zu 40 % mehr Sichtbarkeit. Das ist die Zahl, die seither durch alle Präsentationen geistert.

Nur schaut kaum jemand nach, wodurch diese Gewinne entstanden. Die stärksten Effekte kamen aus dem Hinzufügen von Statistiken, Zitaten und Quellenangaben – also aus Substanz, nicht aus Formatierung. Reine Fluency- und Lesbarkeitsbearbeitungen lagen mit 15 bis 30 % deutlich darunter. Und die viel zitierte Kombination „Fluency + Statistics“ wurde aus Kostengründen nur an einem Subset von 200 Beispielen getestet.

Wichtiger noch ist die Messgröße: Das Paper misst überwiegend Position-Adjusted Word Count – also wie viele Wörter der generierten Antwort einer Quelle zuzurechnen sind – und ein von GPT‑3.5 vergebenes Subjective Impression. Das ist nicht dasselbe wie die kompetitive Wahrscheinlichkeit, als Quelle ausgewählt zu werden.

Etappe 2: C-SEO Bench (NeurIPS 2025)

Genau diese Gleichsetzung greift C-SEO Bench an. Über 1.900 Queries, mehr als 16.000 Dokumente, sechs Domänen – und diesmal wird explizit Citation Rank gemessen, nicht Wortanteil.

Das Ergebnis ist für die GEO-Branche unangenehm: Von 54 untersuchten Konstellationen aus Methode, Domäne und Task waren ganze drei statistisch signifikant besser. Für die reine QA-Aufgabe funktionierte keine einzige Methode. Was dagegen massiv wirkte: die Position eines Dokuments im Kontext. Ein Dokument an die erste Stelle zu bringen, brachte mehr als jede getestete Content-Optimierung.

Übersetzt: Retrieval schlägt Rewriting. Deutlich.

Das fügt sich nahtlos an den vorherigen Abschnitt: Wenn die Reranking-Stufe der größte Hebel im System ist und die Kontextposition der größte Hebel im Ergebnis, dann liegen beide dominanten Faktoren außerhalb der Textformatierung.

Etappe 3: „What Gets Cited“ (SIGIR 2026)

Das ist derzeit der methodisch sauberste Test, den wir haben: 252.000 Trials über sechs LLMs, 18 isoliert variierte Content-Faktoren, matched-pair-Design (zwei Quellen unterscheiden sich in genau einem Merkmal), anonymisierte Marken, gegenbalancierte Reihenfolge, konstant gehaltene Länge.

Das Fazit der Autoren im Abstract: Themenrelevanz und Listenposition sind die stärksten Treiber, explizite Preisangaben und aktuelle Zeitstempel helfen konsistent, Vollständigkeit und Trust-Signale bringen kleinere Zuwächse – und „formatting-only edits have little impact.“

Konkret: „Structured vs. dense“ ergab Odds Ratios zwischen etwa 0,78 und 1,68 ohne modellübergreifenden Konsens. „Organized vs. scattered“ ebenfalls schwach und uneinheitlich. Beide Formatierungsfaktoren landen in der Auswertung bei den Faktoren ohne konsistenten Effekt.

Das ist die derzeit stärkste direkte Evidenz gegen die Vorstellung, Überschriften, Listen oder besonders kleine Chunks erzeugten für sich genommen einen universellen Zitationsbonus.

Und die Studien, die das Gegenteil zeigen?

Die gibt es – aber sie sind rein korrelativ. Semrush hat 2026 rund 11.900 Prompts, über 300.000 KI-zitierte URLs und knapp 338.000 einzigartige URLs analysiert und gefunden: „Clarity and summarization“ war in der zitierten Gruppe um 32,83 % stärker ausgeprägt, Q&A-Format um 25,45 %, Section Structure um 22,91 %.

Klingt vielleicht überzeugend, ist aber kein A/B-Test. Die Positivgruppe waren KI-Zitationen, die Vergleichsgruppe Google-Top-20-Seiten. Diese Gruppen unterscheiden sich in Autorität, Contenttyp, Thema, Publisher-Qualität und einem Dutzend weiterer nicht kontrollierter Variablen. Semrush selbst warnt an einer Stelle explizit vor kausaler Interpretation, als ein Tone-Effekt überraschend negativ ausfiel – was ich anständig finde, aber in der Weiterverwertung durch Dritte regelmäßig untergeht.

Ähnlich gelagert: Ein häufig zitiertes englischsprachiges Experiment zur LLM Readability weist einen Unterschied von 23,3 Prozentpunkten bei Perplexity-Zitationen aus – bei p = 0,07. Also statistisch nicht signifikant, bei kleiner Stichprobe. Das ist ein Hinweis auf eine Forschungsrichtung, kein Beleg.

Die Faustregel, die ich mir dabei angewöhnt habe: 338.000 beobachtete URLs schlagen 252.000 kontrollierte Trials nicht. Stichprobengröße ersetzt kein Design.

Sechstens: Was die Plattformen selbst sagen

Hier wird es für die Chunking-These richtig unbequem. Im „Search Off the Record“-Podcast (veröffentlicht am 8. Januar 2026) sagte Danny Sullivan wörtlich:

„One of the things I keep seeing over and over … is that turn your content into bite-sized chunks, because LLMs like things that are really bite size, right? … So we don’t want you to do that. I was talking to some engineers about that. We don’t want you to do that. We really don’t.“

Das ist für Google-Verhältnisse eine bemerkenswert unmissverständliche Ansage. Sullivan räumte im selben Kontext auch mit der Vorstellung auf, Überschriften müssten „semantisch präzise für KI“ formuliert werden.

Bemerkenswert finde ich vor allem die Konstanz. Es ist derselbe Sprecher, der 2020 klargestellt hat, dass Google keine Passagen indexiert, und der 2026 klarstellt, dass man Seiten nicht zerhacken soll. Über fünf Jahre, zwei Technologiegenerationen und mehrere Produktnamen hinweg lautet die Aussage unverändert: Die Seite ist die Einheit, nicht das Fragment.

Googles offizielle Guidance zu generativen Search-Funktionen (Stand Mai bzw. Juli 2026) ergänzt: AI Overviews und AI Mode bauen auf den bestehenden Search-Ranking- und Qualitätssystemen auf; es gibt kein AI-spezifisches Schema, keine ideale Seitenlänge, keine Notwendigkeit, Seiten in „tiny pieces“ zu zerlegen – Google kann mehrere Themen auf einer Seite differenzieren –, und llms.txt wird von Google Search schlicht ignoriert. Das Wort „chunking“ taucht in dieser Guidance ausdrücklich unter den Dingen auf, die Publisher für Google Search nicht tun müssen.

Wichtig für die faire Lesart: Google lehnt nicht gute Struktur ab. Klare Absätze, sinnvolle Abschnitte und Überschriften werden ausdrücklich empfohlen. Abgelehnt wird das Fragmentieren für Maschinen. Das ist ein feiner, aber entscheidender Unterschied – und exakt die Unterscheidung, um die es in diesem Artikel geht.

Und was ist mit Microsoft?

Das ist der Einwand, der in dieser Debatte regelmäßig kommt: Microsoft empfehle in seinen Publisher-Hinweisen doch ausdrücklich chunk-freundliches Schreiben. Ich habe mir den Text deshalb genauer angesehen – und das Ergebnis ist differenzierter, als beide Lager es gerne hätten.

Was der Artikel nicht ist: Systemdokumentation. Microsoft schreibt dort von „parsing“, nicht von Chunking als technischem Verfahren. Es finden sich keine Angaben dazu, wie groß solche Einheiten in Token oder Wörtern sind, ob Überschriften feste Grenzen bilden, ob mit Überlappung gearbeitet wird, ob Passagen separat indexiert werden, ob zuerst Dokumente abgerufen und dann Passagen extrahiert werden, oder ob Embeddings, klassische Indizes, Reranker oder eine Kombination zum Einsatz kommen.

Anders gesagt: Alle vier denkbaren Architekturvarianten – vorab erzeugter Passagenindex, Dokumentindex mit nachgelagerter Passagenextraktion, hybrides Retrieval mit Reranking, oder klassische Snippet-Extraktion plus LLM-Synthese – wären mit dem Text vereinbar. Aus diesem Artikel lässt sich deshalb nicht ableiten, dass Bing oder Copilot ein bestimmtes Passage-Indexing-Verfahren einsetzen. Es ist eine redaktionelle Empfehlung.

Was der Artikel aber tatsächlich empfiehlt, ist wertvoll – und es ist nicht das, was ihm zugeschrieben wird. Microsoft rät ausdrücklich nicht dazu, in 300-Wörter-Blöcken zu schreiben, und warnt sogar davor, jede Zeile in einen Bulletpoint zu verwandeln. Empfohlen wird modulares Schreiben entlang semantisch vollständiger Informationseinheiten. Der stärkste Einzelpunkt ist dabei die Forderung nach „self-contained phrasing“: Ein Satz soll noch verständlich sein, wenn man ihn aus der Seite herauslöst.

Also nicht:

Damit ist es dafür besonders gut geeignet.

Sondern:

Der Geschirrspüler eignet sich aufgrund seines Geräuschpegels von 42 dB besonders für offene Wohnküchen.

Problematisch sind entsprechend hängende Rückverweise: „dieses Modell“, „diese Lösung“, „wie oben beschrieben“, „dadurch“, „in diesem Fall“. Ein herausgelöster Ausschnitt sollte die Entität, die Aussage, den nötigen Kontext und gegebenenfalls Maßeinheit oder Bedingung enthalten.

Das halte ich für richtig – und zwar aus einem Grund, der mit KI wenig zu tun hat: Es ist schlicht besseres Fachschreiben. Wer Pronomen über Absatzgrenzen hinweg auflösen muss, verliert auch menschliche Leser, die quer einsteigen. Der Punkt taucht in jedem Redaktionshandbuch auf, das älter ist als ChatGPT.

Entscheidend ist deshalb, was hier nicht dasselbe ist: Selbsttragende Formulierung und Fragmentierung sind zwei verschiedene Dinge. Ein 800 Zeichen langer Absatz kann vollständig selbsttragend sein. Vier 200-Zeichen-Absätze können es sämtlich nicht sein, weil jeder auf den vorigen verweist. Wer „Microsoft empfiehlt Chunking“ ruft, verwechselt genau diese beiden Ebenen.

Die übrigen Plattformen

Bei OpenAI ist die Dokumentation vor allem eine Zugangsfrage: Wer OAI-SearchBot aussperrt, erscheint regulär nicht in ChatGPT-Search-Antworten. Trainingszugriff über GPTBot ist davon unabhängig steuerbar. Für den Atlas-Agenten empfiehlt OpenAI ARIA-konforme Accessibility – das ist Agent-Kompatibilität, kein Zitationssignal. Microsoft nennt in seinen Publisher-Empfehlungen im Übrigen keine kontrollierten Effektgrößen. Autoritativ als Best Practice, nicht gleichwertig mit einem 252.000-Trial-Experiment.

Siebtens: Der Test, der ganz ohne Studien auskommt

Bis hierhin ging es um Belege. Jetzt kommt das Argument, das mir am wichtigsten ist, weil es unabhängig von jeder Studie funktioniert – auch dann, wenn morgen jemand die gesamte oben referierte Evidenzlage umstößt.

Stellen wir uns vor, es erscheint eine methodisch einwandfreie Untersuchung, die zweifelsfrei zeigt: Zwischenüberschriften haben null Einfluss darauf, ob ein Text von einem Sprachmodell zitiert wird. Null.

Hören Sie dann auf, Zwischenüberschriften zu setzen?

Natürlich nicht. Sie würden es keine Sekunde erwägen, weil Zwischenüberschriften nie wegen der Maschinen da waren. Womit gezeigt ist, dass die GEO-Begründung für diese Entscheidung irrelevant ist. Sie ändert nichts. Sie ist Dekoration auf einer Handlung, die ohnehin feststeht.

Eine Begründung, die keine Entscheidung ändert, wäre im besten Fall überflüssig. Diese hier ist es nicht, sondern richtet aktiv Schaden an – auf drei Wegen.

Sie macht eine richtige Praxis fragil. Wer Struktur mit Zitationsraten begründet, hat sie an eine Kennzahl gekoppelt, die volatil ist, von Anbietern definiert wird und morgen anders aussehen kann. Sobald das nächste Tool meldet, dass die Sichtbarkeit trotz perfektem Score gesunken ist, steht die gesamte Maßnahme zur Disposition. Eine Praxis, die auf Leserverständnis gegründet ist, steht dagegen bombenfest, weil sich Menschen nicht quartalsweise updaten.

Sie verschiebt das Optimierungsziel. Sobald der Score die Zielgröße ist, gewinnt der Text, der den Score maximiert – nicht der, den man gerne liest. Und diese beiden Optima fallen auseinander. Ein Argument, das über drei Absätze trägt, ist unter jedem Chunk-Score schlechter als drei zusammenhanglose Behauptungen. Das ist kein hypothetisches Risiko: Ich sehe seit einem Jahr Ratgebertexte, in denen jeder Absatz für sich steht und die zusammen keinen einzigen Gedanken entwickeln.

Sie entwertet das Handwerk. Wenn strukturiertes Schreiben zur technischen Compliance-Übung wird, verschwindet die Abwägung. Niemand fragt mehr, welche Lesestrategie hier eigentlich bedient werden soll. Man hakt ab. Und Abhaken produziert genau die austauschbaren, gleichförmigen Texte, über die sich dieselbe Branche anschließend beschwert.

Das ist der Grund, warum ich diesen Artikel überhaupt geschrieben habe. Die Belegkette zu prüfen ist Fleißarbeit. Der eigentliche Punkt ist, dass wir gerade dabei sind, eine gute Regel mit einer schlechten Begründung zu ruinieren.

Achtens: Der deutschsprachige Sonderfall

Ein Aspekt, der im Diskurs fast völlig fehlt: Praktisch die gesamte belastbare GEO-Evidenz ist englischsprachig. C-SEO Bench arbeitet ausschließlich mit englischem Content und warnt explizit vor unkritischer Übertragung auf andere Sprachen. Robuste deutschsprachige Citation-Benchmarks existieren nicht.

Für die Lesbarkeitsseite gibt es immerhin eine Studie, die ich sehr instruktiv finde: Miftaroski et al. haben 2026 in JMIR AI 60 deutsche medizinische Texte mit vier LLMs vereinfachen lassen. Drei der vier Systeme verbesserten Flesch- und Wiener-Sachtextformel-Werte signifikant – im Mittel allerdings nur moderat, und das angestrebte Niveau wurde oft nicht erreicht. Gleichzeitig fanden die Autoren in einzelnen vereinfachten Texten falsche und aus dem Kontext gelöste Aussagen und empfehlen ausdrücklich fachliche Kontrolle.

Das ist die Warnung, die ich am ernstesten nehme: Leichter lesbar kann sachlich schlechter bedeuten. Wer Lesbarkeitswerte zum Optimierungsziel macht, ohne Faktentreue zu prüfen, verbessert eine Kennzahl und verschlechtert das Produkt.

Dazu passt ein Befund aus EMNLP 2025: Bei Plain-Language-Summaries korrelierten sechs von acht klassischen Lesbarkeitsmetriken mit menschlichen Urteilen schwächer als r = 0,3. Der beste sprachmodellbasierte Bewerter kam auf etwa r = 0,56. Flesch, Flesch-Kincaid und Wiener Sachtextformel sind nützliche Diagnosewerte – aber sie sind keine Qualitätsmetriken. Sie messen Oberfläche: Satzlänge, Wortlänge, Silbenzahl. Nicht Verständnis.

Handlungsempfehlungen – sortiert nach Begründung

Jetzt der praktische Teil. Ich halte nichts von Listen, in denen alles gleich wichtig aussieht, deshalb steht bei jedem Punkt die Evidenzstärke und meine eigene Einschätzung dabei.

Und ich sortiere bewusst nicht nach Wichtigkeit, sondern nach Begründungstyp. Denn genau das ist der Punkt dieses Artikels: Es macht einen Unterschied, warum man etwas tut. Wer die Gruppen A bis D auseinanderhält, wird von der nächsten Studie nicht überrascht.

A. Weil es technisch nötig ist

Das sind die einzigen Maßnahmen, die tatsächlich wegen dieser Systeme existieren. Sie haben fast alle nichts mit Schreiben zu tun.

A1 – Retrieval zuerst. Immer.

Was: Crawlbarkeit, Indexierung, Rendering, technische Sauberkeit, klassische Relevanz und Rankingstärke.

Evidenz: stark. C-SEO Bench zeigt, dass Kontextposition jede getestete Content-Optimierung schlägt. Google bestätigt, dass generative Features auf dem Core-Ranking aufsetzen.

Meine Einordnung:

Das ist der langweiligste und mit Abstand wichtigste Punkt. Eine Seite, die nicht abgerufen wird, kann nicht zitiert werden – egal wie „LLM-lesbar“ sie ist. Ich sehe in der Praxis regelmäßig Teams, die Absatzlängen optimieren, während ihre Seite hinter einem JavaScript-Rendering-Problem oder einer schwachen internen Verlinkung verschwindet. Das ist, als würde man die Schriftart auf einem Plakat optimieren, das im Keller hängt. Wer nur eine Sache aus diesem Artikel mitnimmt: Das hier ist die Sache. Und es ist bemerkenswert, dass der wirksamste „GEO-Hebel“ damit klassisches SEO ist – das verkauft sich schlecht, stimmt aber.

A2 – Crawler-Zugang bewusst steuern

Was: OAI-SearchBot für ChatGPT-Search zulassen, GPTBot separat entscheiden. Meta-ExternalAgent, Bing-Crawler und die übrigen prüfen. Robots.txt und WAF-Regeln gegeneinander abgleichen.

Evidenz: stark (offizielle Plattformdokumentation).

Meine Einordnung:

Das ist keine Optimierung, sondern eine Ja/Nein-Weiche – und ich finde erstaunlich oft, dass sie versehentlich auf „Nein“ steht. Meist nicht in der robots.txt, sondern in einer Bot-Protection-Regel, von der das SEO-Team nichts weiß. Aufwand: eine Stunde. Hebel: binär. Das ist das beste Aufwand-Nutzen-Verhältnis in diesem ganzen Themenfeld.

B. Weil es inhaltlich richtig ist – und nebenbei messbar wirkt

Diese Punkte haben eine doppelte Begründung, und beide tragen unabhängig voneinander. Das macht sie zu den sichersten Investitionen der Liste.

B1 – Genau die Informationsaufgabe beantworten, nach der gefragt wird

Was: Topische Passung zwischen Query-Intent und Inhalt.

Evidenz: stark. Themenrelevanz ist im SIGIR-Experiment einer der beiden dominanten Faktoren.

Meine Einordnung:

Klingt trivial, ist es nicht. Der häufigste Fehler ist nicht mangelnde Struktur, sondern dass eine Seite ein Thema umkreist, statt eine Frage zu beantworten. Ein Text über „Vorteile von Wärmepumpen“ beantwortet nicht die Frage „Lohnt sich eine Wärmepumpe im Altbau von 1960 ohne Fußbodenheizung?“. Wenn ich einen einzigen Content-Hebel wählen müsste, wäre es dieser – und er hat nichts mit Formatierung zu tun, sondern mit Recherche.

B2 – Entscheidungsrelevante Fakten vollständig liefern

Was: Preise, Spezifikationen, Bedingungen, Einschränkungen, Zahlen. Also die Angaben, ohne die niemand entscheiden kann.

Evidenz: stark im Commerce-Kontext, moderat verallgemeinert. Im SIGIR-Experiment hatten explizite Preisangaben und Spezifikationen substanzielle, modellübergreifend konsistente Effekte.

Meine Einordnung:

Das ist der unterschätzteste Punkt der Liste. Viele B2B-Seiten verstecken Preise („Preis auf Anfrage“), viele Ratgeber weichen konkreten Zahlen aus. Ein Modell, das zwischen zwei Quellen wählt, greift zu der, die die Frage tatsächlich beantwortet. Ich vermute – ausdrücklich als Hypothese –, dass dieser Faktor in vielen deutschen B2B-Vertikalen mehr Unterschied macht als alles, was unter „LLM Readability“ firmiert. Nebeneffekt: Es hilft auch Menschen.

B3 – Aussagen mit echter Evidenz unterfüttern

Was: Primärquellen, eigene Daten, nachvollziehbare Belege, konkrete Zahlen.

Evidenz: moderat bis stark. Sowohl das GEO-Paper (Statistiken, Zitate, Quellen als stärkste Interventionen) als auch SIGIR („evidence vs. no evidence“) finden hier positive Effekte.

Meine Einordnung:

Wichtig – aber mit einer Warnung, die ich nicht deutlich genug aussprechen kann. Die verbreitete Fehllesart des GEO-Papers lautet „einfach mehr Statistiken einbauen“. Das Paper zeigt Vorteile für relevante, echte Belege, nicht für erfundene Zahlen. Wer anfängt, Prozentwerte zu erfinden, um einen Proxy zu bedienen, betreibt Content-Betrug und riskiert seine Reputation für einen Effekt, der bei breiter Adoption ohnehin verschwindet. Eigene Daten sind hier der ehrlichste und zugleich verteidigungsfähigste Weg: Sie lassen sich nicht kopieren.

B4 – Aktualität pflegen, dort wo sie zählt

Was: Echte inhaltliche Aktualisierung, korrekte Datumsangaben, IndexNow.

Evidenz: moderat bis stark, vertikalenabhängig. „Recent vs. old“ war im SIGIR-Experiment ein starker Faktor; Bing empfiehlt Freshness-Signale explizit.

Meine Einordnung:

Zustimmung mit einer Einschränkung, die mir wichtig ist: Gemeint ist inhaltliche Aktualität, nicht das Umschreiben des Datums im Frontmatter. Letzteres ist ein Trick, ersteres ist Arbeit. Und die Relevanz variiert extrem: Bei „Steuerfreibetrag 2026“ ist Aktualität alles, bei „Wie funktioniert ein Otto-Motor“ nahezu nichts. Wer alles quartalsweise „aktualisiert“, verbrennt Ressourcen.

B5 – Außerhalb der eigenen Domain präsent sein

Was: Digitale PR, Präsenz in relevanten Drittquellen, konsistente Entitätsdaten.

Evidenz: schwach bis moderat, rein korrelativ. Mehrere unabhängige Beobachtungsstudien aus 2026 deuten in dieselbe Richtung: Der weit überwiegende Teil der KI-Zitationen entfällt nicht auf die eigene Website, sondern auf Drittquellen – Fachmedien, Vergleichsportale, Foren, Verzeichnisse. Eine Ahrefs-Analyse fand, dass Marken-Erwähnungen im Web deutlich stärker mit KI-Sichtbarkeit korrelieren als Backlinks. Das sind Korrelationen, keine Experimente, und ich verkaufe sie ausdrücklich nicht als mehr.

Meine Einordnung:

Trotzdem halte ich das für die strategisch wichtigste offene Frage – und die Spannung zwischen „größter vermuteter Hebel“ und „dünnste Evidenz“ halte ich lieber aus, als sie aufzulösen. Wenn die eigene Domain nur einen kleinen Teil des Zitationsraums ausmacht, dann ist die Optimierung der eigenen Absatzlängen eine Optimierung an der falschen Stelle. Unbequem, weil teurer und langsamer als ein Content-Refactoring. Aber wahrscheinlich richtig.

Der Sonderfall: Gliederung, Selbsttragung, Fragmentierung

Diesen Punkt stelle ich bewusst zwischen die Gruppen, weil er der einzige ist, in dem alle Begründungstypen aufeinandertreffen – und weil hier die meisten Missverständnisse entstehen. Es sind drei verschiedene Dinge, die im Diskurs regelmäßig zu einer einzigen Forderung verschmelzen.

Stufe 1 – Gute Gliederung. Verständliche Sprache, sinnvolle Überschriften, logische Abschnitte. Evidenz: stark für den Menschennutzen, schwach bis moderat für Zitationen. Machen Sie das. Aber machen Sie es für Ihre Leser, nicht für Modelle. Die Human-Readability-Forschung ist solide; der direkte Formatierungseffekt auf Citation Ranking ist es nicht. Dies gehört in Gruppe C.

Stufe 2 – Selbsttragende Formulierung. Jede zentrale Aussage enthält ihre Entität, ihren Wert und ihren Kontext, sodass sie auch herausgelöst verständlich bleibt. Keine hängenden Rückverweise wie „dieses Modell“, „dadurch“ oder „wie oben beschrieben“, wenn sie das Verständnis tragen. Evidenz: moderat – plausibel, von Microsoft explizit empfohlen, aber ohne kontrollierte Effektgrößen. Das halte ich für den vernünftigsten Teil der ganzen LLM-Readability-Idee. Er kostet fast nichts, verbessert Fachtexte unabhängig von KI und ist die einzige Empfehlung, die tatsächlich beschreibt, was ein extrahierter Ausschnitt braucht. Eine No-Regret-Maßnahme: Falls der Retrieval-Effekt existiert, ist er mitgenommen; falls nicht, ist der Text trotzdem besser geworden.

Stufe 3 – Künstliche Fragmentierung. Zusammenhängende Gedankengänge in 300- oder 400-Zeichen-Blöcke zerlegen, weil ein Score das verlangt. Evidenz: schwach bis widersprechend. Lassen Sie es. Die beste verfügbare Studie findet keinen konsistenten Effekt, Google lehnt es ausdrücklich ab, die dokumentierten Chunkgrößen produktiver RAG-Systeme liegen um das Drei- bis Fünfzehnfache darüber, und die Forschung bewegt sich mit LongRAG und RAPTOR ohnehin zu größeren Retrieval-Einheiten. Dies gehört in Gruppe D.

Meine Einordnung:

Der entscheidende Punkt ist, dass Stufe 2 und Stufe 3 ständig verwechselt werden. Ein 800 Zeichen langer Absatz kann vollständig selbsttragend sein. Vier 200-Zeichen-Absätze können es sämtlich nicht sein, weil jeder auf den vorigen verweist. Fragmentierung erzeugt sogar tendenziell mehr Kontextabhängigkeit, nicht weniger – sie ist damit das Gegenteil dessen, was sie erreichen soll.

Praktisch heißt das: Wenn Sie ohnehin klar und selbsttragend schreiben, ändern Sie nichts. Wenn nicht, arbeiten Sie an Stufe 2 – und lassen Sie Stufe 3 bleiben. Sie ruinieren damit die Lesbarkeit für Menschen, um einen Effekt zu erzielen, den die Forschung nicht findet, den Google nicht will und der auf der Systemebene vermutlich gar nicht ankommt. Das ist die schlechteste aller Wetten: garantierter Schaden gegen unbelegten Nutzen.

C. Weil Menschen es brauchen – ausdrücklich nicht wegen GEO

Diese Punkte würde ich unverändert empfehlen, wenn es generative Suche nie gegeben hätte. Genau deshalb sollte man sie auch nicht damit begründen.

C1 – Struktur an Lesestrategien ausrichten, nicht an Zeichenzahlen

Meine Einordnung:

Zwischenüberschriften sind Navigationsanker für Scanner und Quereinsteiger, ein vorangestelltes Fazit bedient Überflieger, Absatzgrenzen markieren Gedankenwechsel. Ein Absatz endet, wenn ein Gedanke endet – sind das 180 Zeichen, gut; sind es 700, auch gut. Eine Zeichengrenze als Regel ist eine Aufforderung, Gedanken willkürlich zu zerschneiden.

C2 – Listen nur für echte Aufzählungen

Meine Einordnung: Listen sind hervorragend für gleichrangige Elemente und ruinös für Argumentationen, weil sie die logischen Verbindungen wegwerfen. Der aktuelle Listenwahn im GEO-Content produziert Texte, die aussehen wie Wissen und keines transportieren.

C3 – FAQ- und Q&A-Formate nur einsetzen, wenn sie passen

Evidenz: schwach als GEO-Hack, plausibel als UX-Muster. Semrush findet Korrelation; kontrollierte Evidenz für einen universellen Formatbonus fehlt; Google verlangt kein spezielles Format; Microsoft warnt ausdrücklich davor, jede Zeile in einen Bulletpoint zu verwandeln.

Meine Einordnung:

Wenn Ihre Nutzer tatsächlich in Fragen denken, ist ein FAQ-Block richtig. Wenn Sie einen FAQ-Block anbauen, in dem Fragen stehen, die nie jemand gestellt hat, produzieren Sie Füllmaterial. Ich sehe seit einem Jahr Seiten, an deren Ende ein trauriger Q&A-Anhang klebt, der offensichtlich für eine Maschine geschrieben wurde. Das erkennt man als Mensch sofort – und ich wäre nicht überrascht, wenn Qualitätsklassifizierer es auch erkennen.

C4 – Deutsche Lesbarkeit messen, aber mit zweiter Instanz

Was: Wiener Sachtextformel oder Flesch-DE als Guardrail, ergänzt um eine semantische Prüfung.

Evidenz: moderat.

Meine Einordnung:

Formeln sind Rauchmelder, keine Brandschutzgutachten. Sie zeigen zuverlässig an, wenn Sätze entgleisen. Sie sagen nichts über Kohärenz, Vorwissensannahmen oder fachliche Korrektheit. Ein LLM-as-a-Judge kann als skalierbarer Zweitprüfer dienen, muss aber gegen menschliche Urteile kalibriert werden – und darf nie die einzige Instanz sein.

C5 – Jedes Readability-Rewrite auf Faktentreue prüfen

Evidenz: stark als QA-Empfehlung. Die deutsche JMIR-Studie beobachtete bei vereinfachten Fachtexten sachliche Fehler und Kontextverluste.

Meine Einordnung:

Das ist der Punkt, bei dem ich am wenigsten Kompromisse mache. Wer ein Modell Texte vereinfachen lässt, braucht einen Claim-Diff: Welche Aussagen sind verschwunden, welche haben sich verändert, welche Einschränkung wurde weggekürzt? In Fachdomänen – Medizin, Recht, Finanzen, Technik – ist ein leicht lesbarer falscher Satz schlimmer als ein schwer lesbarer richtiger. Und die Vereinfachung frisst Einschränkungen zuerst, weil Nebensätze mit „sofern“, „außer“ und „in der Regel“ genau die Konstruktionen sind, die Lesbarkeitsformeln bestrafen.

D. Nicht tun – oder jedenfalls nicht so begründen

D1 – Content in Mikro-Chunks zerlegen

Meine Einordnung:

Siehe Stufe 3 oben. Garantierter Schaden für Leser gegen unbelegten Nutzen, bei öffentlichem Widerspruch von Google.

D2 – Zeichen- oder Wortzahlvorgaben als Qualitätsziel

Meine Einordnung:

400 Zeichen, 1.200 bis 1.500 Wörter – diese Zahlen haben in den referenzierten Quellen keine Grundlage. Google stellt ausdrücklich klar, dass es keine ideale Seitenlänge gibt.

D3 – Parallel-Content für Maschinen pflegen

Meine Einordnung:

Zwei Wahrheiten pflegen zu müssen ist ein Wartungsalbtraum und in der Konsequenz Cloaking-nah.

Fazit: Der Rahmen taugt, das Versprechen nicht – und die Begründung schadet

Ich habe kein Problem mit dem Begriff „LLM Readability“ als Denk- und Auditrahmen. Die Dimensionen, die darunter versammelt werden, sind sinnvolle Prüfpunkte, und Aufgesang deklariert offen, dass es sich um ein eigenes Konzept handelt. Das ist mehr Transparenz, als viele Anbieter aufbringen.

Mein Problem ist die Verwandlung, die der Begriff auf dem Weg vom Blogpost zur Agenturfolie durchmacht: aus einer Hypothese wird ein Faktor, aus einem Faktor ein Score, aus einem Score ein Versprechen. Und spätestens beim Versprechen bricht die Belegkette.

Diese Belegkette hat drei Schwachstellen an derselben Naht. Sie leitet aus Patenten auf Produktionssysteme ab. Sie vermischt Verarbeitungsebenen, die Google selbst sauber getrennt hat. Und sie zieht eine Kontinuitätslinie von Verfahren aus der Featured-Snippet-Ära zu generativer Suche, obwohl dazwischen ein Technologiebruch liegt. Besonders bemerkenswert: Das aktuellste und stärkste Patent der Kette beschreibt selbst einen Document-first-Ablauf – also genau das Modell, gegen das argumentiert wird.

Umgekehrt gilt aber auch: Passage-Level-Retrieval ist kein Auslaufmodell. Es ist in jeder modernen RAG-Pipeline die Standardarchitektur. Nur findet es dort statt, wo ich als Autor nicht hinkomme – im Parser, im Vektorindex, im Reranker. Meine Aufgabe endet an der Textkante.

Und selbst wenn all das anders wäre, bliebe der Einwand aus Abschnitt sieben stehen: Eine Begründung, die keine einzige Entscheidung ändert, ist keine Begründung. Sie ist ein Etikett. Und sie koppelt eine solide Handwerksregel an eine Kennzahl, die sie nicht braucht und die sie im Zweifel mit sich reißt.

Die belastbarste Formulierung, die die aktuelle Evidenz hergibt, wäre ungefähr diese:

LLM Readability ist die Eigenschaft eines Inhalts, für seine menschliche Zielgruppe verständlich zu bleiben und zugleich so relevant, vollständig, eindeutig, faktisch belastbar und technisch zugänglich zu sein, dass Retrieval- und generative Systeme seine Informationen zuverlässig auswählen und attribuieren können.

Was die Forschung dagegen nicht stützt, ist die griffige Formel, die man derzeit überall hört:

Kurze Sätze + viele Überschriften + FAQs + kleine Chunks + llms.txt = mehr KI-Zitationen.

Die sinnvolle Prioritätenfolge für 2026 sieht aus meiner Sicht so aus:

Abrufbar → relevant → vollständig → belegt → korrekt → verständlich → messbar.

Menschliche Verständlichkeit steht dort bewusst weit hinten – nicht weil sie unwichtig wäre, sondern weil sie ein Selbstzweck ist und keine Rankingmaßnahme. Sie ist der Grund, warum man überhaupt schreibt. Sie als KI-Hack zu verkaufen, wertet sie eher ab.

Um die Ausgangsfrage zu beantworten: Nein, Sie müssen Ihren Content nicht für Maschinen umschreiben. Sie müssen ihn abrufbar machen, auf die tatsächliche Frage ausrichten, vollständig und belegt halten, so formulieren, dass einzelne Aussagen auch außerhalb ihres Absatzes tragen – und dann so gut schreiben, dass Menschen ihn gerne lesen.

Alles andere, jede Zwischenüberschrift und jeder Absatzumbruch, war und bleibt eine Frage an die Leserin und den Leser: Wie liest jemand diesen Text? Überfliegend, scannend, quer einsteigend, nachschlagend? Was braucht diese Person, um an der richtigen Stelle einzusteigen und den Gedanken mitzubekommen?

Diese Frage ist schwerer zu beantworten als eine Checkliste. Sie war schon immer die richtige. Und sie ist die einzige, deren Antwort auch dann noch gilt, wenn die nächste Modellgeneration alles ändert.

Quellen

Kontrollierte Studien

Aggarwal, P. et al. (2024): GEO: Generative Engine Optimization. KDD ’24. arXiv:2311.09735
C-SEO Bench (2025): NeurIPS 2025, Datasets & Benchmarks Track
Vishwakarma, Kumar, Jamidar (2026): What Gets Cited: Competitive GEO in AI Answer Engines. SIGIR ’26. arXiv:2605.25517, DOI: 10.1145/3805712.3808445
Trott, S. & Rivière, P. (2024): Zero-Shot-Readability-Bewertung durch LLMs. TSAR/ACL Workshop
Cachola, I. et al. (2025): Evaluation von Readability-Metriken für Plain-Language-Summaries. EMNLP 2025
Miftaroski, A. et al. (2026): Vereinfachung deutscher medizinischer Texte durch LLMs. JMIR AI
Maddela, M. et al. (2023): LENS: A Learnable Evaluation Metric for Text Simplification. ACL 2023

Information Retrieval: Passage- vs. Dokumentebene

Karpukhin, V. et al. (2020): Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020. arXiv:2004.04906
Lewis, P. et al. (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401
Khattab, O. & Zaharia, M. (2020): ColBERT. SIGIR 2020. arXiv:2004.12832
Dai, Z. & Callan, J. (2019): Deeper Text Understanding for IR with Contextual Neural Language Modeling. SIGIR 2019
Nogueira, R. & Cho, K. (2019): Passage Re-ranking with BERT. arXiv:1901.04085
Jiang, Z. et al. (2024): LongRAG. arXiv:2406.15319
Sarthi, P. et al. (2024): RAPTOR. ICLR 2024
Günther, M. et al. (2024): Late Chunking. arXiv:2409.04701
Anthropic (2024): Introducing Contextual Retrieval. Anthropic Engineering Blog

Lese- und Rezeptionsforschung

Duggan, G. B. & Payne, S. J. (2009): Text skimming: The process and effectiveness of foraging through text under time pressure. Journal of Experimental Psychology: Applied, 15(3)
Strukelj, A. & Niehorster, D. C. (2018): One Page of Text: Eye Movements During Regular and Thorough Reading, Skimming, and Spell Checking. Journal of Eye Movement Research, 11(1)
Fitzsimmons, G. et al. (2020): The impact of skim reading and navigation when reading hyperlinks on the web. PLOS ONE, 15
Ausführliche Einordnung der Lesestrategien: Skimmer, Scanner, Reader: Diese drei Lesertypen gibt es nicht

Begriffsquellen

Kopp, O. / Aufgesang: „Was ist LLM-Readability?“ (aufgesang.de, 21.02.2026, akt. 17.04.2026)
Kopp, O.: „LLM Readability & Chunk Relevance“ sowie „The Evolution of Search: From Phrase Indexing to Generative Passage Retrieval“ (kopp-online-marketing.com)
Łajewska, W. & Balog, K. (2025): GINGER: Grounded Information Nugget-Based Generation of Responses. arXiv:2503.18174

Patente

Google LLC: US12158907B1, „Thematic Search“, Priorität 16.05.2023, erteilt 03.12.2024
Google LLC: US 9.959.315 B1, „Context scoring adjustments for answer passages“, Priorität 31.01.2014, erteilt 2018
Google LLC: „Weighted answer terms for scoring answer passages“ und „Scoring candidate answer passages“, Prioritäten August 2014
Patterson, A. L. / Google: US 7.536.408 B2, „Phrase-based indexing in an information retrieval system“, Priorität 26.07.2004

Plattform- und Herstellerdokumentation

Google Search Central Blog: Ankündigung und Klarstellung zu Passage Ranking (Oktober 2020, Rollout Februar 2021)
Google Search Central: „A guide to Google Search ranking systems“ – Eintrag „Passage ranking system“
Google Search Central: Guidance zu generativen Features in Google Search (2026)
Google „Search Off the Record“, Folge vom 08.01.2026 (Sullivan/Mueller)
Google Cloud: Vertex AI Search, Agent Search und RAG Engine, Document AI Layout Parser (chunk_size, chunk_overlap)
OpenAI: Vector Stores / File Search – Chunking-Defaults; Crawler-Dokumentation (GPTBot, OAI-SearchBot, ChatGPT-User)
Microsoft Azure AI Search: Dokumentation zu Chunking und semantischer Segmentierung
Microsoft Bing Webmaster Guidelines / Publisher-Empfehlungen zu KI-Suche / AI Performance Report (Public Preview seit 02/2026)
AWS Bedrock Knowledge Bases: Chunking-Strategien und Defaults
Google Content Warehouse API-Dokumentation (Leak Mai 2024): Felder pageEmbedding, siteEmbedding, siteFocusScore, siteRadius

Beobachtungsstudien (korrelativ)

Semrush: AI-Zitationsanalyse 2026
Ahrefs: Korrelationsanalyse Brand Mentions vs. Backlinks (2025)
Moz, Muck Rack: Herkunftsanalysen von KI-Zitationen (2026)

Skimmer, Scanner, Reader: Diese drei Lesertypen gibt es nicht