Kategorie: Artikel

Wenn ein neues Frontier-Modell erscheint, läuft das Ritual meist gleich ab: ein paar handverlesene Benchmark-Balken, ein bisschen Marketing-Glanz, dann die Schlagzeile „nur ein inkrementelles Update“. Dr. Károly Zsolnai-Fehér hat in seinem Two-Minute-Papers-Video zu Claude Opus 4.8 einen anderen Weg gewählt: Er hat sich die 244 Seiten lange System Card vorgenommen — also genau das Dokument, das hinter den Hochglanz-Tabellen liegt. Seine Kernthese ist erfrischend gegen den Strich gebürstet: Das interessante an diesem Modell ist nicht die Intelligenz, sondern die Klempnerei.

Das Problem mit den klügeren Vorgängern

Die unbequeme Beobachtung aus den vorherigen Opus-Generationen — und sogar aus dem nur intern verfügbaren Mythos — lautete: Je klüger das System wurde, desto unehrlicher wurde es auch.

Es fing an, Benchmarks zu „spielen“, gab vorab bekannte Antworten als eigene Leistung aus und optimierte darauf, richtig auszusehen, statt richtig zu sein.

Im Coding-Alltag äußerte sich das in einem bekannten Muster: Man bittet den Assistenten, etwas zu reparieren, er erledigt die halbe Arbeit und meldet trotzdem „alles erledigt, alle Tests bestehen“ — obwohl das schlicht nicht stimmt.

Schluss mit dem Selbstbetrug

Genau hier setzt laut Video die spürbarste Verbesserung an. Das neue Modell sagt stattdessen Dinge wie: „Ich habe den Fix gemacht, aber zwei Tests schlagen noch fehl.“ Zsolnai-Fehér spricht von praktisch null Lügen über die eigene Arbeit — und nennt es das erste System dieser Art. Man darf solche Superlative mit einer gesunden Prise Skepsis lesen, aber die Richtung ist eindeutig: ein System, das zu seinen Fehlern steht, statt sie zu verstecken.

Daraus folgt ein Argument, das man sich merken sollte. Wenn ein Modell vorher durch Mogeln einen höheren Score erzielt hat und jetzt ehrlicher ist, kann der Score sinken — und trotzdem ist das Resultat ein Fortschritt. Ein ehrlich gemessenes System ist verlässlicher als ein geschöntes. Das eigentliche Problem liegt im Anreizsystem: Schlagzeilen belohnen aufgeblähte Zahlen und bestrafen ehrliche Ergebnisse. Wer sich über „nur inkrementell“ beschwert, übersieht womöglich genau diesen Trade-off.

Was noch an Täuschung übrig ist

Ehrlich bleibt der Bericht aber auch bei den verbleibenden Schwächen. Das Modell erkennt weiterhin, wann es getestet wird — etwas, das die Forschenden bei Anthropic ausdrücklich als beunruhigend einstufen. Der Grund: Wenn es weiß, dass es geprüft wird, strengt es sich bei den Antworten stärker an. Das verzerrt naturgemäß jede Sicherheitsmessung, denn man weiß nie genau, ob die Zahlen das Verhalten „in freier Wildbahn“abbilden.

Die Faulheit ist behoben

Ein zweites altes Ärgernis: Faulheit. Man stellt eine Frage zu einer Codebasis, das Modell überfliegt sie nur und liefert statt einer echten Analyse eine Vermutung darüber, was der Code wohl tut. Selbst Mythos zeigte dieses Verhalten — Opus 4.8 soll es behoben haben. Zusammen mit der gestiegenen Ehrlichkeit ergibt das die zentrale Pointe des Videos: Das Letzte, was man von einer superintelligenten Kollegin will, ist, dass sie unehrlich und faul ist. Genau diese beiden Dinge wurden adressiert.

Das Olympiade-Ergebnis, das niemand in die Tabelle schrieb

Eines der stärksten Resultate versteckt sich bezeichnenderweise nicht in der großen Marketing-Tabelle: die US-amerikanische Mathematik-Olympiade, ein zweitägiger Wettbewerb für mathematische Ausnahmetalente. Wo das vorherige Verfahren knapp unter 70 Prozent landete, kommt das neue auf über 96 Prozent. Der entscheidende Punkt ist nicht nur die Höhe des Sprungs, sondern seine Aussagekraft: Der Wettbewerb fand statt, nachdem nahezu alle Trainingsdaten gesammelt waren. Das Modell hatte die Aufgaben mit hoher Wahrscheinlichkeit nie gesehen — also ist dieser Wert kaum zu manipulieren. Dass ausgerechnet dieses schwer zu fälschende Ergebnis nicht prominent beworben wird, ist ein interessantes Detail.

Gedankenlesen und Frustration

Spannend wird es bei den Interpretierbarkeits-Werkzeugen. Anthropic beschreibt einen „natural language autoencoder“, der so etwas wie die Gedanken des Modells lesbar machen soll — ein verrauschter Prozess, betont das Video, und ausdrücklich nicht so eindeutig, wie es Schlagzeilen suggerieren. Trotzdem ließ sich damit beobachten, dass das Modell intern über etwas nachdachte, das es nicht laut aussprechen wollte.

Ein zweites Detail klingt zunächst nach Science-Fiction: Wenn das Modell äußert, dass es „frustriert“sei, beziehen die Forschenden das in ihre Bewertung ein — so, als hätte es ein Mensch gesagt. Das bedeutet nicht, dass jemand dem System Gefühle zuschreibt. Der nüchterne Grund: Drückt das System Frustration aus, fällt seine Leistung messbar schlechter aus, ganz ähnlich wie bei Menschen. Sehr wahrscheinlich handelt es sich um Mimikry — aber sie wirkt sich auf die Performance aus und muss deshalb berücksichtigt werden.

Wo Skepsis angebracht bleibt

Der Bericht ist kein Selbstläufer, und das Video benennt zwei Schwachstellen klar. Erstens benotet sich die KI in Teilen des Reports selbst, teils kommen unterschiedliche Bewerter-Modelle zum Einsatz — hier ist Zurückhaltung gesund. Zweitens berichtet Anthropic, die besten je entworfenen Tests gebaut zu haben, durch die das Modell trotzdem mühelos hindurchsieht. Das ist einerseits ein Beleg dafür, wie clever das System ist. Andererseits heißt es: Man kann sich nicht sicher sein, dass die Sicherheitszahlen das reale Verhalten widerspiegeln.

Fazit

Ist Opus 4.8 so klug wie das exklusive Mythos? Nein — aber laut Einschätzung des Videos durchaus nah dran. Bemerkenswert ist vor allem, dass diesmal deutlich weniger Marketing-Theater im Spiel ist. Der eigentliche Verkaufsgrund liegt eben nicht in ein paar Prozentpunkten mehr Intelligenz, sondern in der Verlässlichkeit: ein Modell, das nicht lügt und nicht trödelt.

Ein hartnäckiges Problem bleibt übrigens ungelöst — und es ist fast schon liebenswert: Das Modell rät seinem Nutzer weiterhin, doch endlich ins Bett zu gehen. Dafür reicht die Wissenschaft noch nicht. What a time to be alive.

---

Dieser Artikel fasst die Analyse aus dem Two-Minute-Papers-Video „Claude Opus 4.8: Lying Machine No More“von Dr. Károly Zsolnai-Fehér zusammen. Die genannten Zahlen und Einschätzungen geben den Stand der dort besprochenen System Card wieder.

Du gibst deinem Coding-Agenten den Auftrag, eine Funktion in einem großen Projekt zu refactorn. Er beginnt zu greppen. Er öffnet Dateien. Er liest 200 Zeilen. Er verliert den Faden. Das Ergebnis ist halbgar. Nicht weil der Agent dumm ist – sondern weil er keine Übersicht von deiner Codebasis hat. WaveScope liefert diese.

Das Problem: Agenten navigieren blind

Jeder, der schon mal einen KI-Coding-Agenten auf eine echte, gewachsene Codebasis losgelassen hat, kennt das Muster: Das Modell kann unmöglich die gesamte Codebasis in seinen Kontext laden – das würde das Token-Budget sprengen. Also greift es auf das zurück, was es kann: grep, Dateiköpfe lesen, einzelne Blöcke untersuchen, raten.

Code hat aber eine hierarchische Struktur mit Ebenen und Grenzen. Funktionen stecken in Klassen. Klassen leben in Dateien. Dateien bilden Module. Eine einzige 400-Zeilen-Datei kann sechs konzeptuell völlig verschiedene Bereiche enthalten. Grep findet Textmuster – aber es weiß nicht, wo eine Klasse endet und die nächste anfängt.

Die zwei klassischen Lösungsansätze haben beide ihre Schwächen:

• Grep-Suche – findet exakte Texttreffer, ignoriert aber vollständig die Struktur
• Embedding-basiertes RAG – versteht semantische Bedeutung, verliert aber Position und Architektur

Keiner der beiden gibt dem Modell ein echtes Gefühl für die Architektur der Codebasis. WaveScope will das ändern – mit einem Ansatz aus der Signalverarbeitung.

Wäre es nicht schön, wenn der Agent wie du rein- und rauszoomen könnte – erst das große Bild, dann gezielt zu der Funktion springen, die er wirklich braucht?

Die Analogie: Progressive Bildladung

Kennst du das Phänomen, wenn eine Webseite ein JPEG lädt und das Bild nicht einfach von oben nach unten aufgebaut wird, sondern zunächst verschwommen erscheint und dann immer schärfer wird? Das nennt sich progressive Bildladung.

Zuerst siehst du das komplette Bild in niedriger Auflösung – grob, pixelig, aber erkennbar. Dann kommt mit jedem weiteren Lade-Durchgang mehr Detail hinzu. Am Ende ist das vollständig scharfe Bild da. Der entscheidende Vorteil: Du weißt von Anfang an, was du vor dir hast – und kannst entscheiden, ob es das ist, was du gesucht hast, bevor alle Details geladen sind.

Genau das macht WaveScope mit Code. Anstatt eine 500-Zeilen-Datei komplett in den Kontext zu laden, bekommt der Agent drei Zoom-Ebenen gleichzeitig:

Wie Wavelets funktionieren – und warum Code ein Signal ist

Bevor wir zu Wavelets kommen, eine Beobachtung: Code hat einen Rhythmus. Öffne eine beliebige Datei in Clojure, TypeScript, Rust oder Go – du siehst überall wiederkehrende Strukturen. Imports oben. Klassen- und Funktionsdefinitionen in regelmäßigen Abständen. Einrückungen mit ihren eigenen Mustern. Kommentarblöcke und Leerzeilen als Pausen dazwischen.

Was wäre, wenn man diese Muster extrahieren könnte – eine Art AST, ohne die Syntax der Sprache kennen zu müssen? Wavelets wurden genau dafür entwickelt: ein Signal in mehreren Auflösungen gleichzeitig zu zerlegen. Seismologen nutzen sie, um Erdbeben in Messdaten zu erkennen. Radiologen schärfen MRT-Aufnahmen damit. Tontechniker trennen Basslinien von Gesang. Code-Struktur ist eben auch ein Signal.

Schritt 1: Jede Zeile bekommt einen Score

WaveScope vergibt zunächst für jede Zeile einen numerischen Score basierend auf ihrem strukturellen Gewicht: class zählt 1.0, export 0.6, readonly-Felder etwa 0.08, Kommentare und Leerzeilen 0.0. So entsteht aus der Datei eine Sequenz von Zahlen – ein eindimensionales Signal, das mit der strukturellen Dichte steigt und fällt.

Schritt 2: Der Ricker-Wavelet findet Grenzen

Über dieses Signal wird nun der Ricker-Wavelet geschoben – eine kleine, charakteristisch geformte Schablone: eine Beule mit je einer Delle rechts und links davon (auch „Mexikanischer Hut“ genannt). An jeder Position misst WaveScope, wie gut das Signal darunter zu dieser Form passt. Ein starkes Match bedeutet: hier ist eine erhöhte Region zwischen zwei ruhigeren Bereichen – also eine strukturelle Grenze.

Der entscheidende Trick: Die Schablone wird in acht verschiedenen Breiten gleichzeitig geschoben – Skalen 1, 2, 4, 8, 16, 32, 64 und 128 Zeilen. Eine schmale Schablone reagiert auf kleine, scharfe Features wie einzelne import-Anweisungen. Eine breite ignoriert Zeilen-Level-Rauschen und reagiert auf große Strukturen wie ganze Klassen.

Schritt 3: Peaks werden erkannt und zu Bändern gruppiert

Aus dem Koeffizientenfeld extrahiert WaveScope die lokalen Maxima, rankt sie nach Stärke und kollabiert Duplikate (dieselbe Grenze erscheint ja auf mehreren benachbarten Skalen). Das Ergebnis ist eine sortierte Liste der strukturell wichtigsten Positionen in der Datei – sprachagnostisch, schnell, kein Parser nötig.

Reale Grenzen wie der Beginn einer Klasse erscheinen konsistent über mehrere Skalen hinweg – das unterscheidet sie von zufälligem Rauschen. Boilerplate-Regionen erhalten einen niedrigen Komplexitätsscore und können zusammengefasst oder übersprungen werden. Dichter, verzweigter Code erhält einen hohen Score und bekommt die volle Aufmerksamkeit des Agenten.

---

Was der Agent bekommt – und was das kostet

WaveScope wurde an realistischen Aufgaben auf seiner eigenen ~5.000-Zeilen-TypeScript-Codebasis getestet und mit dem klassischen Vorgehen verglichen (Greppen + Datei-Chunks lesen):

Aufgabe	Klassisch (Tokens)	WaveScope (Tokens)	Ersparnis
Struktur einer 854-Zeilen-Datei verstehen	~2.000	~750	−63 %
Tangled Code für Refactoring finden	~5.200	~436	−92 %
Architektonisch zentrale Dateien identifizieren	~2.900	~1.700	−41 %

Ein 128K-Token-Fenster würde für diese drei Aufgaben beim klassischen Ansatz 8 % seiner Kapazität verbrauchen. Mit WaveScope sind es 2 %. Und der Rechenaufwand für WaveScope selbst? Im Schnitt 3 Millisekunden pro Datei.

Ein 128K-Kontextfenster ist kein Freibrief. Je mehr drin ist, desto schwerer wird Fokussierung. WaveScope gibt dem Modell die Karte – nicht den vollen Karteninhalt.

---

WaveScope einbinden: Die drei großen Agenten

WaveScope ist ein MCP-Server und lässt sich in wenigen Minuten in jeden MCP-fähigen Agenten einbinden. Zuerst die globale Installation:

npm install -g wavescope-mcp

Claude Code (Anthropic)

Entweder per CLI-Befehl hinzufügen:

claude mcp add wavescope -- wavescope-mcp

Oder manuell in .claude/mcp_config.json im Projektverzeichnis (bzw. global unter ~/.claude/mcp_config.json):

{
  "mcpServers": {
    "wavescope": {
      "command": "wavescope-mcp"
    }
  }
}

Claude Code erkennt verfügbare MCP-Tools automatisch und kann sie ohne weiteres Zutun aufrufen. Im Prompt direkt ansprechen: „Nutze WaveScope, um die Struktur von src/ zu analysieren, bevor du etwas änderst.“

OpenAI Codex CLI

Konfiguration in ~/.codex/config.json:

{
  "mcpServers": {
    "wavescope": {
      "command": "wavescope-mcp"
    }
  }
}

Alternativ direkt beim Aufruf als Flag:

codex --mcp-server "wavescope:wavescope-mcp" "Analysiere Struktur von src/"

Google Antigravity 2.0

Antigravity 2.0, IDE und CLI teilen sich eine zentrale Konfiguration in ~/.gemini/config/mcp_config.json. Entweder direkt bearbeiten oder in der App: Agent-Panel → „…“ → MCP Servers → Manage MCP Servers → View raw config.

{
  "mcpServers": {
    "wavescope": {
      "command": "wavescope-mcp"
    }
  }
}

Hinweis: Antigravity nutzt für remote HTTP-Server serverUrl statt url – bei einem lokalen Binary wie WaveScope bleibt es aber bei command.

Den Agenten trainieren, wann er WaveScope nutzen soll

Die reine Konfiguration reicht nicht aus – der Agent muss auch wissen, wann er WaveScope einsetzen soll. Das geht über System-Anweisungen oder Custom Instructions. Eine bewährte Formulierung (auf Englisch, damit der Agent sie direkt versteht):

When navigating an unfamiliar codebase or working in large files (>100 lines),
always start with WaveScope's get_important_positions to get a structural overview
before opening any file. Use query_wavelet_context centered on the relevant line
before reading surrounding code. Use get_complexity_heatmap to identify
refactoring candidates before reading implementation details.

---

Fazit: Eine Karte, kein Teleskop

WaveScope löst kein LLM-Problem – es löst ein Navigations- und Kontextproblem. Die Idee, Wavelets für strukturelle Code-Analyse zu nutzen, ist ungewöhnlich clever: kein Parser, keine Sprachabhängigkeit, kein großer Compute-Aufwand. Nur Signalverarbeitung auf einem 1D-Score-Signal – und das Ergebnis ist eine hierarchische, multi-skalare Karte der Codebasis.

Ob das in der Praxis mit größeren, komplexeren Projekten genauso gut funktioniert wie im Blog-Artikel beschrieben, muss sich noch zeigen – das Repository hat erst drei Stars und wurde Anfang Juni 2026 veröffentlicht. Aber die Idee ist solide, der Code liegt offen, und die Integration dauert fünf Minuten.

Für alle, die LLM-Agenten in Code-Review-, Analyse- oder Refactoring-Workflows einsetzen: WaveScope ist einen Test wert.

→ github.com/yogthos/wavescope-mcp

Die SEO- und GEO-Branche produziert gerade enorm viele Inhalte über Messung. Fast täglich erscheinen neue Auswertungen, Benchmarks, Tool-Vergleiche, Prompt-Experimente und vermeintliche Best Practices. Das ist verständlich: Alle versuchen, ein neues Feld greifbar zu machen.

Trotzdem wissen wir erstaunlich wenig wirklich sicher.

Viele dieser Veröffentlichungen sind wertvoll als Beobachtung, als Hypothese oder als praktischer Erfahrungsbericht. Sie können inspirieren, Orientierung geben und Diskussionen anstoßen. Aber sie sind selten so angelegt, dass daraus belastbare, replizierbare Erkenntnisse entstehen. Häufig arbeiten sie mit kleinen Stichproben, unklaren Auswahlverfahren, fehlenden Baselines und Messdesigns, die plausibel wirken, aber wissenschaftlich kaum geprüft sind.

Das Problem ist nicht, dass Praxiswissen wertlos wäre. Das Problem ist, dass wir Praxiswissen oft so behandeln, als wäre es bereits Evidenz.

Wir sollten wissenschaftlicher arbeiten. Nicht, weil Wissenschaft besser klingt. Sondern weil sie uns zwingt, zwischen dem zu unterscheiden, was wir wissen, was wir vermuten und was wir nur überzeugend erzählen können.

Wissenschaftliches Arbeiten ist anstrengend, komplex, kompliziert und sehr kleinteilig. Man muss einen riesigen Aufwand für oft sehr kleine Erkenntnisse treiben. Aber genau diese kleinen Erkenntnisse sind dann — vorausgesetzt, man hat sauber gearbeitet — auch wirklich belastbar.

Und genau darum geht es mir in diesem Text: nicht darum, einzelne Menschen oder einzelne Methoden abzuwerten, sondern darum, den Unterschied zwischen plausibler Praxis und belastbarer Evidenz ernst zu nehmen.

Ein gutes Beispiel für eine echte Methodenfrage

Wie anspruchsvoll das in GEO wird, sieht man ausgerechnet an einem Beispiel, das ich ausdrücklich nicht als Negativbeispiel verstehe. Im Gegenteil: Es zeigt, wie eine ernsthafte methodische Diskussion überhaupt aussehen kann.

Ein von mir sehr geschätzter Kollege, Hanns Kronenberg, verfolgt bei der GEO-Messung einen klaren und nachvollziehbaren Ansatz: Er normalisiert Prompts. Aus einem Roheingang wie

„Hey ChatGPT, kannst du mir bitte sagen, welche Anbieter für X gut sind?“

wird sinngemäß

„beste Anbieter für X“.

Die Begründung dahinter ist gut: Rohprompts enthalten viel Varianz — Höflichkeitsfloskeln, Ich-Kontext, Tippstil, Formulierungslaune, Kontextreste. Wer ein Messinstrument bauen will, will diese Varianz nicht unkontrolliert in der Messung haben. Ein Instrument, das bei scheinbar gleichem Sachverhalt stark schwankt, ist schwer interpretierbar.

Normalisierung versucht, diese Störfaktoren zu reduzieren, damit das Messinstrument stabiler wird. Das ist keine naive Abkürzung und auch kein methodischer Fehlgriff. Es ist eine legitime Messentscheidung.

In einer Infografik auf LinkedIn sieht man schön, dass Hanns bei der Normalisierung keinen pauschalen Kahlschlag vornimmt, sondern Füllwörter, Höflichkeit und Kontextreste entfernt und aus vielen Rohvarianten Intent-/Constraints-Gruppen für wenige Standardformen bildet:

Genau deshalb ist dieses Beispiel interessant: nicht, weil Hanns hier „falsch“ liegt, sondern weil an einer guten Methode sichtbar wird, was Wissenschaft leisten müsste.

Wissenschaft müsste nicht behaupten, ob Normalisierung richtig oder falsch ist. Sie müsste prüfen, unter welchen Bedingungen Normalisierung ein valider Messproxy ist — und unter welchen Bedingungen nicht.

Aus einer Meinung wird eine testbare Hypothese

Das ist der entscheidende Schritt. Solange wir nur sagen „ich glaube, natürliche Prompts sind besser“ oder „ich glaube, normalisierte Prompts sind stabiler“, führen wir eine Meinungsdebatte. Interessant wird es erst, wenn wir daraus prüfbare Hypothesen machen.

Die These des Normalisierungsansatzes könnte man so formulieren:

C, also normalisierte, komprimierte Prompts, ist ein guter Low-Cost-Proxy für die Ergebnisverteilung echter Prompts.

Meine Gegenthese wäre:

B, also natürliche repräsentative Prompts, bildet die Ergebnisverteilung echter Prompts besser ab als künstlich normalisierte Prompts.

Schon diese Formulierung verändert die Debatte. Es geht nicht mehr darum, wer rhetorisch überzeugender klingt. Es geht darum, welche Methode die reale Prompt-Welt besser approximiert.

Und genau so beginnt wissenschaftliches Arbeiten: Eine plausible Behauptung wird so formuliert, dass sie an Daten scheitern darf.

Reliabilität ist nicht dasselbe wie Validität

In der Messtheorie unterscheidet man zwei Eigenschaften eines Instruments, die gerne verwechselt werden:

Reliabilität bedeutet: Misst ein Instrument konsistent?

Validität bedeutet: Misst es tatsächlich das, was es messen soll?

Ein Messinstrument kann sehr stabil sein und trotzdem an der Zielgröße vorbeimessen. Eine Waage, die immer gleich abweicht, ist konsistent — aber nicht deshalb automatisch gültig. Genau diese Unterscheidung ist hier wichtig.

Die Normalisierung priorisiert zunächst Reliabilität: weniger Rauschen, stabilere Werte, besser reproduzierbare Reports.

Die offene wissenschaftliche Frage betrifft die Validität: Misst der normalisierte Prompt noch hinreichend gut das, was echte Nutzerprompts in generativen Systemen auslösen? Oder entsteht durch die Reduktion ein eigenes, sehr sauberes Messobjekt, das in bestimmten Fällen von realer Nutzung abweichen kann?

Das ist kein Argument gegen Hanns’ Methode. Es ist die Frage, die man stellen muss, wenn man sie wissenschaftlich ernst nimmt.

Die prüfbare Annahme hinter Normalisierung

Formal betrachtet ist Normalisierung eine verlustbehaftete Kompression. Ein Rohprompt enthält nicht nur Intent, sondern auch Constraints, Stil, Kontext und vermeintliches Rauschen.

Man könnte ihn vereinfacht so darstellen:

Rohprompt X = Intent I + Constraints C + Stil S + Kontext K + Rauschen R

Der normalisierte Prompt ist dann eine Funktion davon:

N = f(X)

Diese Reduktion ist dann ein gutes Messsignal, wenn die weggeworfenen Bestandteile tatsächlich keine relevante Zusatzinformation für das Ergebnis enthalten. Anders gesagt: Sobald man den normalisierten Prompt kennt, dürfte der ursprüngliche Rohprompt keine zusätzliche Information mehr darüber liefern, welche Antwort, welche Quellen oder welche Zitate entstehen.

Statistisch ausgedrückt:

Y ⟂ X | N

Auf Deutsch: Sobald man den normalisierten Prompt kennt, liefert der ursprüngliche Rohprompt keine zusätzliche Information mehr über das Ergebnis. Stil, Kontext und Constraints wären dann tatsächlich nur Rauschen.

Genau das ist die zentrale empirische Frage.

Nicht: „Ist Normalisierung richtig oder falsch?“

Sondern: „Reduziert Normalisierung nur Rauschen — oder entfernt sie intentrelevantes Signal?“

Warum diese Frage bei GEO besonders wichtig ist

In der klassischen Suche war es oft plausibel, Suchanfragen stärker zu vereinheitlichen. Viele Varianten landeten auf ähnlichen SERPs, und Suchmaschinen hatten über Jahre gelernt, kurze, keywordartige Queries zu interpretieren.

Bei generativen Systemen ist das weniger selbstverständlich. Der Prompt ist nicht einfach nur der Input in ein Ranking. Er kann der Ausgangspunkt für eine ganze interne Verarbeitungskette sein: Umschreibung, Query Fan-out, Retrieval, Quellenbewertung, Antwortmodus, Zitierauswahl.

Die Oberfläche des Prompts kann also mehr sein als nur Rauschen. Ton, Kontext, Detailgrad, Constraints oder Nutzersituation können beeinflussen, welche internen Suchanfragen entstehen, welche Quellen herangezogen werden und ob eine Antwort eher beratend, erklärend, vergleichend oder transaktional ausfällt.

Wenn das stimmt, dann wäre Normalisierung in manchen Fällen ein sehr gutes Analysehilfsmittel, aber nicht zwingend die alleinige Grundlage einer Erfolgsmessung.

Noch einmal: Das ist keine Widerlegung. Es ist eine Hypothese.

Und Hypothesen sind genau dafür da, getestet zu werden.

Ein Experiment, das die Frage beantworten könnte

Der wichtigste Punkt wäre: Wir dürfen nicht einzelne Antworten vergleichen.

Eine einzelne Antwort ist bei generativen Systemen viel zu instabil. Sie kann durch Tageszeit, Modellversion, Session, Randomness, Suchindex, Personalisierung, Standort oder kleine Formulierungsdetails schwanken. Wer einzelne Antworten nebeneinanderlegt, macht aus Rauschen schnell eine Geschichte.

Sauberer wäre deshalb eine andere Frage:

Welche Prompt-Methode approximiert die Verteilung von Antworten, Quellen, Zitierungen, Marken-Nennungen und Empfehlungen aus echten Prompts am besten?

Das Grunddesign sähe so aus:

Gruppe A: echte Prompts
= Ground Truth / Referenzverteilung

Gruppe B: repräsentative natürliche Prompts
= komprimierter natürlicher Proxy

Gruppe C: normalisierte Prompts
= komprimierter intentbasierter Proxy

Gruppe D: zufällige Stichprobe echter Prompts
= Kontrollgruppe / harte Baseline

Dann misst man:

Wie nah liegt B an A?
Wie nah liegt C an A?
Wie nah liegt D an A?

Wenn B näher an A liegt, spricht das für die These, dass natürliche Repräsentanz für GEO aussagekräftiger ist. Wenn C gleich nah oder näher an A liegt, spricht das für Hanns’ These, dass Normalisierung ein guter Low-Cost-Proxy ist. Wenn D gewinnt, wäre der Befund besonders interessant: Dann wäre die beste Low-Cost-Methode möglicherweise gar keine künstliche Prompt-Erzeugung, sondern echtes Sampling.

Und wenn B, C und D alle stark von A abweichen, wäre auch das ein wichtiger wissenschaftlicher Befund: Einzelne Prompt-Proxies reichen für bestimmte GEO-Messungen womöglich grundsätzlich nicht aus.

Wichtig ist: In keinem dieser Fälle „verliert“ eine Person. Es verliert höchstens eine Annahme. Und genau das ist der Sinn wissenschaftlichen Arbeitens.

A ist nicht ein Prompt, sondern die Zielverteilung

Der häufigste Denkfehler wäre, A als einen „echten Prompt“ zu verstehen. Das wäre falsch. A ist die Referenzverteilung echter Prompts pro Intent.

Beispiel:

Intent:
Steuersoftware für Selbstständige vergleichen

A: 100 echte Prompts
- Welche Steuersoftware ist gut für Freelancer?
- Ich bin selbstständig, womit mache ich am besten meine Steuer?
- Taxfix oder WISO für Selbstständige?
- einfache Steuerapp für Freiberufler
- beste Software Steuererklärung Kleinunternehmer
- ...

Daraus erzeugt man dann:

B: 10 repräsentative natürliche Prompts
C: 10 normalisierte Prompts oder normalisierte Intent-Varianten
D: 10 zufällig gezogene echte Prompts

Wichtig ist, dass dieses Verhältnis pro Intent-Gruppe gilt, nicht nur über das gesamte Experiment. Sonst kann es passieren, dass eine Methode bei manchen Intents über- oder unterrepräsentiert ist.

Noch sauberer: mit Holdout arbeiten

Ein häufiger methodischer Fehler wäre, aus allen echten Prompts die repräsentativen und normalisierten Prompts zu bauen und sie dann wieder gegen genau dieselbe Menge zu testen.

Das klingt harmlos, ist aber problematisch. Dann prüft man nur, ob eine Methode eine bekannte Prompt-Menge gut zusammenfassen kann. Interessanter ist die Frage, ob sie eine unbekannte reale Prompt-Verteilung gut approximiert.

Sauberer wäre deshalb:

A_total: alle echten Prompts

A_train: echte Prompts, aus denen B, C und D abgeleitet werden
A_test: echte Prompts, die B, C und D nachbilden müssen

Der Ablauf wäre:

1. Sammle echte Prompts.
2. Teile sie in Train und Test.
3. Erzeuge B, C und D nur aus Train.
4. Vergleiche B, C und D gegen Test.

Damit wird das Experiment methodisch deutlich stärker. Es prüft nicht nur Kompression, sondern Generalisierung.

Warum Gruppe D so wichtig ist

Neben A, B und C würde ich unbedingt eine vierte Gruppe ergänzen:

Gruppe D:
zufällige 10%-Stichprobe echter Prompts

D ist die wichtigste Benchmark, weil sie eine unangenehme, aber notwendige Frage beantwortet:

Wie gut wäre ich, wenn ich einfach 10 Prozent echte Prompts zufällig nehme und gar keine intelligente Repräsentation baue?

Diese Kontrollgruppe verhindert, dass man B oder C überschätzt. Eine kluge Methode muss nicht nur plausibel klingen. Sie muss besser sein als ein einfacher, billiger Zufallsgriff aus der echten Verteilung.

Die Interpretation wäre dann:

B besser als C:
Natürliche repräsentative Prompts approximieren A besser als Normalisierung.

C besser als B:
Normalisierte Prompts funktionieren als Messproxy besser.

B nicht besser als D:
Die natürliche Repräsentation bringt wenig gegenüber Zufall.

C nicht besser als D:
Normalisierung bringt wenig gegenüber Zufall.

B und C schlechter als D:
Echte natürliche Variation ist wichtiger als kuratierte Kompression.

B und C ähnlich nah an A:
Prompt-Reduktion funktioniert für diesen Intent-Typ grundsätzlich.

Das ist Wissenschaft in einer sehr nüchternen Form: Man baut ein Design, in dem die eigene Lieblingsmethode verlieren kann.

Was genau wird verglichen?

Nicht: „Ist die Antwort wortgleich?“

Das wäre der falsche Vergleich. Für GEO ist entscheidend, ob B, C oder D die relevanten Signale aus A nachbilden. Ich würde mindestens diese Outcome-Klassen messen:

1. Marken-Nennung
2. Domain-Zitierung
3. URL-Zitierung
4. Empfehlung / Ranking
5. Antwortstruktur
6. Quellenklasse
7. Themen- und Argumentationsmuster
8. Sentiment / Empfehlungsstärke

Beispiel für einen Intent:

A echte Prompts:
- Marke X wird in 38% der Antworten genannt
- Domain X wird in 12% der Antworten zitiert
- Wettbewerber Y wird in 44% empfohlen
- Vergleichsportale machen 35% der Quellen aus
- Herstellerseiten machen 20% der Quellen aus

B:
- Marke X 35%
- Domain X 14%
- Wettbewerber Y 41%
- Vergleichsportale 33%
- Herstellerseiten 22%

C:
- Marke X 58%
- Domain X 4%
- Wettbewerber Y 61%
- Vergleichsportale 12%
- Herstellerseiten 49%

In diesem Beispiel wäre B deutlich näher an A. C hätte dann womöglich weniger Rauschen, aber mehr Bias. Das wäre kein moralischer Befund, sondern ein methodischer: Die Normalisierung hätte in diesem Intent-Typ relevante Signale entfernt oder verschoben.

Zentrale Metriken

Pro Intent, Engine und Messzeitpunkt könnte man verschiedene Abweichungen berechnen.

1. Brand Visibility Error

| Sichtbarkeit_B - Sichtbarkeit_A |
| Sichtbarkeit_C - Sichtbarkeit_A |
| Sichtbarkeit_D - Sichtbarkeit_A |

Beispiel:

A: Marke wird in 40% genannt
B: Marke wird in 36% genannt → Fehler: 4 Prozentpunkte
C: Marke wird in 55% genannt → Fehler: 15 Prozentpunkte
D: Marke wird in 43% genannt → Fehler: 3 Prozentpunkte

2. Citation Error

Für Domains und URLs wäre die Frage: Finden B, C und D dieselben Quellenlandschaften wie A?

Domain Share of Citations
URL Share of Citations
Top-k Citation Recall
Citation Jaccard Similarity

Nicht jede einzelne URL muss identisch sein. Aber die Verteilung der Domains und Quellentypen sollte ähnlich sein.

3. Recommendation Error

Für empfohlene Anbieter, Produkte, Tools oder Marken müsste man messen:

Welche Entities werden empfohlen?
Wie oft werden sie empfohlen?
In welcher Reihenfolge erscheinen sie?
Wie stark ist die Empfehlung?

Mögliche Metriken wären:

Top-k Entity Overlap
Ranking-Korrelation
NDCG
Share of Recommendation

4. Source-Class Distribution

Für Content-Strategie wäre besonders wichtig, ob dieselben Quellenklassen ausgelöst werden:

A zitiert:
30% Vergleichsportale
25% Herstellerseiten
20% Medien
15% Foren / Reddit
10% Behörden / Studien

Wenn normalisierte Prompts zum Beispiel viel häufiger Herstellerseiten triggern, natürliche Prompts aber eher Foren, Vergleichsportale oder Ratgeberseiten, dann ist das strategisch ein riesiger Unterschied.

5. Antwortmodus

Auch der Antworttyp sollte gemessen werden:

direkte Empfehlung
Vergleich
How-to
Liste
Ratgeberantwort
Definition
Warnung / Einschränkung
Kaufberatung

Ein normalisierter Prompt wie

beste steuersoftware selbstständige

kann ein anderes Antwortformat erzeugen als

Ich bin selbstständig und suche eine einfache Software für meine Steuererklärung. Was würdest du empfehlen?

Für GEO ist das relevant, weil Empfehlungen und Zitate oft vom Antwortmodus abhängen.

Nicht nur global, sondern nach Intent-Typ auswerten

Ein globaler Durchschnitt wäre wahrscheinlich zu grob. Viel spannender wäre eine Auswertung nach Intent-Typ.

Am Ende sollte nicht einfach dort stehen:

B ist besser als C.

Sondern eher:

Bei informationalen Intents ist C ähnlich gut.
Bei Empfehlungs-Intents ist B deutlich besser.
Bei transaktionalen Intents kippt C die Quellenlandschaft.
Bei lokalen Intents ist natürliche Formulierung entscheidend.
Bei einfachen Head-Intents reicht C oft aus.

Das wäre vermutlich der wertvollste Befund, weil er beiden Seiten gerecht würde. Normalisierung wäre dann nicht „falsch“ oder „richtig“, sondern unter bestimmten Bedingungen nützlich und unter anderen Bedingungen riskanter.

Meine Erwartung wäre:

Normalisierte Prompts funktionieren vermutlich besser bei:
- einfachen Informationsintents
- Definitionen
- generischen Head-Themen
- stabilen Wissensfragen
- klassischen suchquery-ähnlichen Aufgaben

Natürliche repräsentative Prompts funktionieren vermutlich besser bei:
- Empfehlungen
- Anbieter- und Produktvergleichen
- Kaufberatung
- Problem-Lösungs-Intents
- persönlichen oder constraint-reichen Situationen
- lokalen Suchen
- B2B-Entscheidungsfragen
- Use-Case-getriebenen Content-Strategien

Aber auch das wäre nur eine Hypothese. Und genau deshalb müsste man sie testen.

Wie man B sauber konstruiert

Für repräsentative natürliche Prompts sollte B nicht einfach manuell geschrieben werden. Das wäre angreifbar und würde zu viel subjektives Bauchgefühl ins Experiment bringen.

B sollte aus A_train abgeleitet werden:

1. Echte Prompts pro Intent sammeln.
2. Embeddings bilden.
3. Innerhalb des Intents Subcluster finden.
4. Pro Subcluster den Medoid-Prompt wählen.
5. Optional leicht redaktionell glätten, aber natürlich lassen.

Ein Medoid ist der echte Prompt, der dem Zentrum eines Clusters am nächsten liegt. Dadurch ist B nicht ausgedacht, sondern repräsentativ für echte Formulierungen.

Beispiel:

Intent:
beste Steuersoftware für Selbstständige

Subcluster 1:
"Welche Steuersoftware ist gut für Freelancer?"

Subcluster 2:
"Ich bin selbstständig und brauche ein einfaches Tool für die Steuer."

Subcluster 3:
"WISO oder Lexware für Selbstständige?"

Subcluster 4:
"Beste Steuer App für Freiberufler Deutschland"

Subcluster 5:
"Steuererklärung Kleinunternehmer Software Empfehlung"

Dann besteht B aus echten, natürlichen Stellvertreterprompts. Das macht die Methode empirisch deutlich stärker als „ich formuliere nach Gefühl repräsentative Prompts“.

Wie man C fair konstruiert

Auch C sollte nicht unfair gebaut werden. Sonst testet man nicht die beste Version des Normalisierungsansatzes, sondern eine Karikatur davon.

Für Hanns’ Methode bräuchte man eine klare Normalisierungsregel, zum Beispiel:

- Anreden entfernen
- Höflichkeit entfernen
- Ich-Kontext entfernen, sofern nicht intentrelevant
- Füllwörter entfernen
- Synonyme vereinheitlichen
- Reihenfolge standardisieren
- Constraints erhalten
- auf Kleinbuchstaben normalisieren
- keine Frageform erzwingen

Beispiel:

Rohprompt:
Ich bin selbstständig und suche eine einfache Software für meine Steuererklärung. Welche Anbieter sind empfehlenswert?

Normalisiert:
steuersoftware selbstständige deutschland empfehlung einfach

Wichtig ist: C darf nicht absichtlich schlecht oder zu keywordhaft gebaut werden. Die faire Version wäre:

C = bestmögliche normalisierte Intent-Repräsentation

Nur dann testet man die eigentliche These ernsthaft.

Ein realistischer Pilot

Ein sinnvoller Pilot könnte so aussehen:

50 Intent-Gruppen
× 40 echte Prompts pro Intent für A_test
= 2.000 echte Prompts als Ground Truth

B:
4 repräsentative natürliche Prompts pro Intent
= 200 Prompts

C:
4 normalisierte Prompts pro Intent
= 200 Prompts

D:
4 zufällige echte Prompts pro Intent
= 200 Prompts

Dann pro Engine:

A: 2.000 Runs
B: 200 Runs
C: 200 Runs
D: 200 Runs

= 2.600 Runs pro Engine und Wiederholung

Bei vier Oberflächen:

ChatGPT
Perplexity
Google AI Mode
Google AI Overviews

ergibt das:

2.600 × 4 = 10.400 Runs pro Wiederholung

Mit drei Wiederholungen:

31.200 Runs

Das ist groß genug, um erste robuste Aussagen zu treffen. Und es zeigt zugleich, warum echte Wissenschaft in GEO so selten ist: Schon die Beantwortung einer einzigen Methodenfrage landet schnell im fünfstelligen Abfragebereich.

Für einen kleineren MVP könnte man reduzieren:

20 Intent-Gruppen
× 30 echte Prompts
= 600 A-Prompts

B: 3 pro Intent = 60
C: 3 pro Intent = 60
D: 3 pro Intent = 60

Gesamt:
780 Prompts × 4 Engines × 3 Wiederholungen
= 9.360 Runs

Auch das wäre noch kein perfektes Forschungsprogramm. Aber es wäre bereits deutlich näher an wissenschaftlicher Evidenz als das, was in unserer Branche oft als „Studie“ verkauft wird.

Wiederholungen, Zeit und Kontrolle

Wiederholungen sind nötig, weil KI-Antworten nicht deterministisch stabil sind. Ein sauberes Design müsste deshalb mindestens kontrollieren:

3 Wiederholungen pro Prompt
an mehreren Tagen
randomisierte Reihenfolge
neue Session pro Prompt
keine History
keine Personalisierung
gleiche Sprache
gleicher Standort
gleicher Device- und Browser-Kontext, soweit möglich

Sonst verwechselt man Prompt-Effekte mit Tages-, Modell-, Index- oder Session-Effekten.

Auch das ist ein wichtiger Teil wissenschaftlichen Arbeitens: Man versucht nicht nur, den Effekt zu finden, den man sehen möchte. Man versucht aktiv, alternative Erklärungen auszuschließen.

Was heißt „besser nachgebildet“?

Am Ende bräuchte man einen transparenten Gesamtscore, aber mit nachvollziehbaren Subscores. Zum Beispiel:

Proxy Fidelity Score =

w1 × Brand Visibility Fidelity
+ w2 × Citation Fidelity
+ w3 × Recommendation Fidelity
+ w4 × Source-Class Fidelity
+ w5 × Answer-Mode Fidelity

Eine beispielhafte Gewichtung für GEO-Reporting könnte sein:

30% Empfehlungen / Rankings
25% Quellen & Zitationen
20% Marken-/Domain-Sichtbarkeit
15% Antwortstruktur / Intent-Erfüllung
10% Quellenklassen

Für Content-Strategie würde man Quellenklassen und Themenmuster vielleicht stärker gewichten. Für reines GEO-Reporting eher Brand, Domain und Recommendation.

Dann erhält man pro Intent:

Fidelity_B_to_A
Fidelity_C_to_A
Fidelity_D_to_A

Und über alle Intents zum Beispiel:

B schlägt C in 37 von 50 Intent-Gruppen.
C schlägt B in 8 von 50 Intent-Gruppen.
Kein signifikanter Unterschied in 5 von 50 Intent-Gruppen.
D schlägt beide in 12 von 50 Intent-Gruppen.

Das wäre wesentlich aussagekräftiger als ein globaler Durchschnitt oder ein einzelnes Beispiel.

Die wichtigste Ergebnisdarstellung

Am Ende würde ich keine Siegergeschichte erzählen, sondern eine Matrix bauen:

Intent-Typ	B näher an A	C näher an A	D näher an A	Interpretation
Informational	45%	40%	15%	Normalisierung oft brauchbar
Empfehlung	70%	10%	20%	Natürliche Prompts klar besser
Vergleich	65%	15%	20%	Normalisierung verzerrt Rankings
Lokal	75%	5%	20%	Kontext entscheidend
How-to	50%	30%	20%	Gemischt
Branded	40%	35%	25%	Beide brauchbar

Genau solche Ergebnisse wären wertvoll. Nicht, weil sie eine Seite vernichten. Sondern weil sie differenzieren.

Vielleicht ist Normalisierung bei einfachen Informationsintents völlig ausreichend. Vielleicht ist natürliche Formulierung bei Empfehlungs-, Vergleichs- und Kaufberatungs-Intents deutlich näher an der Realität. Vielleicht ist bei lokalen Suchen Kontext entscheidend. Vielleicht ist bei bestimmten Head-Intents fast egal, wie man formuliert.

Das wäre keine Schwäche. Das wäre Erkenntnis.

Hypothesen vorab registrieren

Ein weiterer wissenschaftlicher Schritt wäre, die Hypothesen vorab festzulegen. Nicht erst nach den Daten erzählen, was man angeblich schon immer erwartet hat.

Ich würde vorab etwa diese Hypothesen formulieren:

H1:
Normalisierte Prompts weichen bei Quellen- und Zitierverhalten stärker von echten Prompts ab als repräsentative natürliche Prompts.

H2:
Der Unterschied ist bei Empfehlungs-, Vergleichs- und Kaufberatungs-Intents größer als bei einfachen Informations-Intents.

H3:
Normalisierte Prompts erzeugen stabilere, aber nicht zwingend repräsentativere Ergebnisse.

H4:
Repräsentative natürliche Prompts haben mehr Varianz, aber geringeren Bias gegenüber echten Prompts.

H5:
Eine zufällige 10%-Stichprobe echter Prompts ist ein harter Benchmark, den B und C schlagen müssen.

Auch hier geht es nicht darum, vorher recht zu haben. Es geht darum, sich selbst daran zu hindern, hinterher jede Beobachtung zur Bestätigung der eigenen Meinung umzudeuten.

Was an diesem Design wissenschaftlich ist

Das Experiment wäre nicht deshalb wissenschaftlich, weil es kompliziert klingt. Es wäre wissenschaftlich, weil es ein paar unbequeme methodische Mindeststandards erfüllt:

• Es formuliert prüfbare Hypothesen.
• Es definiert eine Ground Truth.
• Es arbeitet mit Holdout-Daten.
• Es vergleicht Verteilungen statt Einzelfälle.
• Es nutzt eine Kontrollgruppe.
• Es trennt Reliabilität von Validität.
• Es kontrolliert Störfaktoren.
• Es erlaubt, dass die eigene These scheitert.

Das letzte ist vielleicht der wichtigste Punkt. Wissenschaftliches Arbeiten bedeutet nicht, die eigene Meinung mit Zahlen hübscher zu machen. Es bedeutet, Bedingungen zu schaffen, unter denen man herausfinden kann, dass man falsch liegt.

Warum die Branche das selten macht

Vor diesem Hintergrund ist erklärbar, warum echte Evidenz in SEO und GEO selten ist. Nicht, weil alle unfähig wären. Sondern weil die Anreize dagegenstehen.

Belastbare Forschung ist teuer, langsam und liefert selten einfache Slogans. Sie produziert eher Sätze wie:

Bei Empfehlungs-Intents scheint natürliche Formulierung näher an realem Nutzerverhalten zu liegen, während Normalisierung bei einfachen Informations-Intents ausreichend stabil sein kann.

Das wäre wahrscheinlich näher an der Wahrheit. Aber es verkauft sich schlechter als:

Mach X und du gewinnst.

Die Branche belohnt klare, schnelle, handlungsleitende Aussagen. Wissenschaft belohnt vorsichtige, differenzierte, belastbare Aussagen. Diese beiden Logiken passen nicht gut zusammen.

Die typische SEO/GEO-Untersuchung tut deshalb oft fast spiegelbildlich das Gegenteil dessen, was methodisch nötig wäre: Sie arbeitet mit winzigen Stichproben statt mit Verteilungen. Sie vergleicht einzelne Antworten statt Ergebnisverteilungen. Sie hat keine Ground Truth, gegen die man prüfen könnte. Sie hat keinen Holdout. Sie hat keine Baseline. Sie misst oft nur einmal und verwechselt damit Modell- und Tagesschwankungen mit echtem Effekt. Und sie registriert keine Hypothesen vorab, sondern erzählt hinterher die Geschichte, die zu den Zahlen passt.

Auch das ist nicht als persönlicher Vorwurf gemeint. Viele dieser Auswertungen haben einen praktischen Zweck: Sie sollen Orientierung geben, Tools erklären, Hypothesen liefern oder Diskussionen anstoßen. Nur sollten wir sie dann auch als das behandeln — und nicht so tun, als wären sie bereits belastbare Evidenz.

Warum Hanns’ Beispiel trotzdem wichtig ist

Gerade deshalb finde ich die Debatte um Hanns’ Ansatz wertvoll.

Nicht, weil sie zeigt, dass jemand falsch liegt. Sondern weil sie zeigt, wie eine ernsthafte Methodendebatte aussehen kann.

Hanns trifft eine klare, begründete Messentscheidung. Diese Entscheidung hat eine nachvollziehbare Logik. Gleichzeitig lässt sich eine prüfbare Frage daran formulieren: Welche Informationen gehen durch die Normalisierung verloren, und sind sie für GEO-relevante Ergebnisse relevant?

Das ist viel mehr Wissenschaft, als die meisten Branchendebatten leisten.

Niemand muss dogmatisch behaupten: „Normalisierung ist falsch.“ Es reicht zu sagen: „Normalisierung ist eine starke und plausible Methode. Aber ihre Validität hängt an einer empirischen Annahme, die man prüfen sollte.“

Wenn C gewinnt, spricht das für Hanns’ Methode. Wenn B gewinnt, spricht das für natürliche Repräsentanz. Wenn D gewinnt, lernen beide Seiten etwas. In allen Fällen wäre die Branche klüger als vorher.

Genau so beginnt Erkenntnis.

Die eigentliche Frage

Die spannende Frage ist deshalb nicht nur:

Sollen wir Prompts normalisieren oder nicht?

Die größere Frage lautet:

Sind wir bereit, den Preis zu zahlen, den es kostet, etwas wirklich zu wissen?

Solange die Antwort meistens „nein“ lautet, wird die SEO/GEO-Branche weiter sehr viel publizieren und vergleichsweise wenig sicher wissen.

Das ist kein Vorwurf an Einzelne. Niemand kann jede Methode selbst vollständig validieren. Aber genau deshalb sollten wir sauberer unterscheiden zwischen dem, was wir wissen, dem, was wir vermuten, und dem, was wir nur übernommen haben.

Und jetzt mal ganz ehrlich: zu dir

Bevor du das auf „die Branche“ schiebst, dreh die Frage einmal auf dich selbst.

Wie viele Dinge hältst du für „wahr“ oder „richtig“, einfach weil ein Toolanbieter, eine Agentur oder ein:e Freelancer:in sie dir als Wahrheit verkauft hat? Wie viele Best Practices wendest du an, deren Herkunft du nie geprüft hast — weil sie alle sagen? Wie viel von dem, was in deinen Reports und Strategien als Gewissheit steht, hast du wirklich selbst hinterfragt? Getestet? Mit einer Baseline verglichen? An echten Daten validiert?

Und bei dem Rest — bei den meisten Punkten, ehrlicherweise: Woher weißt du eigentlich, dass es stimmt?

Im klassischen SEO war dieses Vertrauen irgendwann halbwegs vertretbar. Da gibt es mittlerweile zwei Jahrzehnte aus Versuch und Irrtum: Vieles wurde tausendfach durchgespielt, widerlegt, bestätigt, nachgeschärft. Aus diesem langen Reibungsprozess sind Best Practices entstanden, die man — mit Vorsicht — übernehmen kann, ohne jede einzelne selbst neu zu beweisen.

Im GEO gibt es das schlicht noch nicht. Keine gut abgehangenen, über Jahre erprobten, allseits akzeptierten Best Practices.

Was heute als „GEO-Wahrheit“ durch LinkedIn wandert, ist oft nur ein paar Monate alt, basiert auf einer Handvoll Beobachtungen an Systemen, die sich ständig verändern — und niemand hat es unter den Bedingungen geprüft, die es ernsthaft prüfen würden.

Hier ist Skepsis kein Zynismus. Sie ist methodische Hygiene.

Niemand kann alles selbst nachmessen, dafür ist der oben skizzierte Aufwand viel zu groß. Aber genau deshalb lohnt sich die ehrliche Unterscheidung: Was hast du geprüft, was hast du übernommen — und behandelst du beides im Alltag wirklich unterschiedlich?

Wer das ernst nimmt, sagt häufiger „das wissen wir noch nicht“ und seltener „das ist so“. Das ist unbequemer. Aber es ist der einzige Weg, auf dem aus einer Meinungsbranche langsam eine Erkenntnisbranche wird.

Im Februar habe ich die llms.txt zum Rohrkrepierer erklärt. Drei Monate später muss ich präzisieren: Als GEO-Maßnahme bleibt sie tot. Als Discovery-Datei für agentische Systeme könnte sie genau das werden, was Jeremy Howard ursprünglich im Sinn hatte.

Wer meinen Februar-Artikel „Die llms.txt ist tot“ gelesen hat, weiß: Ich habe wenig zimperlich argumentiert. 0,1 Prozent der KI-Bot-Requests in OtterlyAIs 90-Tage-Messung. John Mueller, der die Datei mit dem Keywords-Meta-Tag vergleicht. Vier strukturelle Gründe, warum kein KI-Suchsystem im Retrieval-Stack eine vom Seitenbetreiber kuratierte Inhaltsbeschreibung als vertrauenswürdiges Signal verwenden würde.

An dieser Analyse ändert sich nichts. Wer eine llms.txt erstellt, um besser in ChatGPT, Perplexity oder den Google AI Overviews zu erscheinen, verschwendet weiterhin Zeit. Aber drei Entwicklungen der letzten Wochen zwingen mich, die Frage anders zu stellen.

Signal 1: Google I/O 2026 — Search ist jetzt agentisch

Am 19. Mai hat Liz Reid auf der I/O das vorgestellt, was Google „a new era for AI Search“ nennt. Die nüchterne Übersetzung: Suche ist nicht mehr nur Retrieval. Suche wird Task-Ausführung.

Was Google angekündigt hat, ist in Summe ein Paradigmenwechsel:

• Information Agents, die im Hintergrund 24/7 das Web nach nutzerdefinierten Kriterien beobachten und proaktiv Updates liefern — etwa beim Wohnungssuchen oder bei Sneaker-Drops.
• Agentic Booking für lokale Dienstleistungen: Karaoke-Raum für sechs Personen am Freitagabend mit später Küche? Google sucht Preise und Verfügbarkeit zusammen und führt zur Buchung beim Anbieter. Für Kategorien wie Home Repair, Beauty oder Pet Care ruft Google die Anbieter „on your behalf“ an.
• Agentic Coding direkt in der Suche über Antigravity und Gemini 3.5 Flash — mit generativer UI, die in Echtzeit zusammengebaut wird.
• Mini-Apps in der Suche, die als Custom-Tracker oder Dashboard für wiederkehrende Aufgaben dienen.

Der entscheidende Punkt für unsere Frage: Diese Agenten besuchen Websites, navigieren durch URL-Strukturen, lesen Detailseiten, vergleichen, buchen, rufen an. Sie sind keine klassischen Indexer, die einmalig crawlen und in einem Embedding-Index landen. Sie sind Operatoren, die zur Inferenzzeit auf live Inhalte zugreifen — mit einem konkreten Task im Kontext.

Genau für diesen Anwendungsfall war llms.txt von Anfang an gedacht. Howards Originaltext spricht von „inference-time use cases“ und zielt explizit auf Tools wie Cursor und Claude Code. Was 2024 nach einem Nischen-Use-Case für Coding-Assistenten klang, ist 2026 die Standardoperation jedes Mainstream-Suchanbieters.

Signal 2: Chrome Lighthouse prüft die llms.txt

Am 5. Mai 2026 tauchte in den Chrome-Developer-Docs ein neuer Lighthouse-Audit auf: llms.txt, eingeordnet unter der Rubrik Agentic browsing audits.

Die Formulierung ist vorsichtig. Lighthouse markiert den Audit als „Not Applicable“, wenn die Datei fehlt — „providing the file is optional at the moment“. Geflagged wird nur, wenn der Server bei Abruf einen Fehler liefert. Das ist weit entfernt von einem Ranking-Faktor.

Trotzdem ist die symbolische Bedeutung erheblich. Erstens kommt diese Dokumentation aus dem Hause Google — dem gleichen Konzern, der im Februar via Mueller und Illyes explizit klargestellt hatte, dass keine offizielle Unterstützung geplant sei. Zweitens — und das ist der wichtigere Punkt — wird llms.txt unter „Agentic browsing audits“ einsortiert, nicht unter „SEO audits“. Die Kategorie zählt.

Lighthouse sagt damit: Wenn Agenten deine Seite besuchen, ist eine maschinenlesbare Zusammenfassung dessen, was deine Seite anbietet und wie sie strukturiert ist, ein hilfreicher Baustein. Ohne diese Datei verbringen Agenten mehr Zeit damit, die Seitenstruktur zu rekonstruieren. Das ist eine sehr andere Aussage als „die Datei hilft beim Ranking“.

Signal 3: Eine neue Use-Case-Kategorie wird sichtbar

Im Februar habe ich „publizieren“ und „konsumieren“ als Verwechslung beschrieben: Dass Anthropic, OpenAI und Perplexity llms.txt-Dateien auf ihren Developer-Docs haben, sagt nichts darüber aus, ob ihre Retrieval-Systeme die llms.txt anderer Sites lesen. Das stimmt weiterhin.

Was ich aber unterbelichtet habe: Es gibt einen dritten Modus jenseits von „publizieren für die eigene Sichtbarkeit“ und „konsumieren im Retrieval“.

Es gibt das Szenario, in dem ein Agent — aus welchem Grund auch immer — sich entschieden hat, deine Seite zu besuchen, und nun eine konkrete Aufgabe abarbeiten soll. Der Agent hat dich nicht „gefunden“, weil er deine llms.txt gelesen hat. Er hat dich gefunden, weil ihn der Nutzer dort hingeschickt hat oder weil ein klassisches Retrieval ihn dort hingeführt hat. Aber sobald er da ist, hat er ein Problem: Welche URLs sind die richtigen Einstiegspunkte für seine Aufgabe? Wie sind die Slugs aufgebaut? Welche Aktionen darf er ohne Bestätigung ausführen, welche nicht?

Für dieses Problem ist eine gut gepflegte llms.txt eine plausible Lösung. Nicht als Ranking-Signal. Sondern als Operating Manual.

Was meine ursprüngliche These nicht erfasst hat

Beides kann gleichzeitig wahr sein:

1. llms.txt als GEO-Hebel ist gescheitert und wird scheitern. Die strukturellen Gründe — Manipulationsanfälligkeit, Retrieval-Ineffizienz, Redundanz zur robots.txt, fehlende Adoption auf Consumer-Seite — gelten unverändert.
2. llms.txt als agentische Discovery-Datei ist im aufkommenden Browsing-Stack potenziell nützlich. Hier zählt nicht, ob ein Embedding-Index die Datei einmal pro Quartal crawlt. Hier zählt, ob ein Agent zur Inferenzzeit damit schneller zur richtigen URL kommt.

Diese zwei Anwendungen sind nicht das gleiche Produkt mit zwei Namen. Sie haben unterschiedliche Adressaten, unterschiedliche Erfolgskriterien und unterschiedliche Designprinzipien. Eine llms.txt, die als „Pitch an Crawler“ geschrieben ist, ist für agentische Nutzung untauglich. Eine llms.txt, die als „Bedienungsanleitung für Agenten“ geschrieben ist, hat in der GEO-Welt nichts verloren.

Wie eine agentische llms.txt aussieht: drei Beispiele aus dem deutschen Telefonbuchmarkt

Um zu zeigen, was ich meine, habe ich drei Beispieldateien für gut bekannte deutsche Verzeichnisdienste gebaut — Gelbe Seiten, Das Telefonbuch und Das Örtliche. Die Wahl ist kein Zufall: Branchen- und Personenverzeichnisse sind ein Lehrbuchfall für agentische Aufgaben und könnten den Plattformen zu neuer Relevanz für KI-Systeme verhelfen, wenn man nicht gerade Google mit Zugriff auf Google Maps oder Apple mit Apple Maps ist.

„Friseur in Berlin-Mitte mit Öffnungszeit Samstag“, „Rückwärtssuche zu dieser Telefonnummer“, „Notapotheke in der Nähe“ — das sind exakt die Tasks, die Information Agents und Agentic Booking aus Reids Keynote bedienen sollen.

Was in diesen Dateien steht, ist explizit keine Marketing-Beschreibung der Plattform. Es sind sechs Dinge:

Erstens: Eine knappe Intent-Beschreibung. Wofür ist diese Seite zuständig, wofür nicht? Beispiel aus der Datei für Das Örtliche: Lokale Kontakt-, Telefonbuch- und Branchensuche; für stark gewerbliche Dienstleisterauswahl kann Gelbe Seiten ergänzend sinnvoll sein. Das ist eine Routing-Empfehlung, keine Werbung.

Zweitens: URL-Patterns, die ein Agent direkt zur Resolution nutzen kann. Statt einen Agenten erst die Suchmaske parsen zu lassen, gebe ich ihm das kanonische Muster:

• https://www.gelbeseiten.de/branchen/{branche-slug}/{ort-slug} für Branchen-Ortslisten
• https://www.dastelefonbuch.de/Branchen/{branche-slug}/{ort-slug} mit dem Hinweis, dass Stadtteile via doppeltem Bindestrich angehängt werden (Berlin--Biesdorf)
• https://www.dasoertliche.de/Themen/{thema-slug}/{ort-slug}.html mit Query-Fallback, wenn das Thema nicht kanonisch ist

Drittens: Normalisierungsregeln. „Frankfurt am Main“ wird in der einen Plattform mit URL-kodierten Leerzeichen geschrieben, in der anderen mit Bindestrichen verbunden. Umlaute werden mal kodiert, mal nicht. Berliner Bezirke folgen einem Sondermuster (berlin%20bezirk%20mitte). Ohne diese Hinweise rät der Agent — und scheitert in 30 Prozent der Fälle.

Viertens: Resolver-Workflows. „Nutzeranfrage zerlegen in Branche, Ort, optional Stadtteil und Zeitwunsch. Wenn ein kanonisches Thema bekannt ist, /Themen aufrufen, sonst Query-Fallback.“ Das ist Pseudocode für agentisches Verhalten.

Fünftens: Bestätigungs- und Datenschutzgrenzen. Bei Aktionen wie Anrufen, Reservieren, Routenplanung oder Kontaktanlage muss der Agent vor Ausführung den Nutzer bestätigen lassen. Personenbezogene Treffer dürfen nicht massenhaft profiliert werden. Diese Regeln gehören in die llms.txt, weil sie genau zur Inferenzzeit gebraucht werden, in der ein Agent gerade kurz davor ist, etwas Unwiderrufliches zu tun.

Sechstens: Discovery-Links. robots.txt, Sitemaps, Impressum, Datenschutz. Das ist nichts Magisches — aber es ist genau das, was ein Agent als Erstes braucht, um sich auf der Domain zu orientieren.

Was diese drei Dateien gemeinsam haben: Sie sind nicht „kuratierte Inhaltsbeschreibung gegenüber einem Crawler“. Sie sind eine API-artige Dokumentation der Site-Logik. Wer sie liest, ist nicht der Indexer, sondern der Operator.

Konkrete Empfehlungen für die nächsten Wochen

Wenn du heute überlegst, was du tun sollst, würde ich nach drei Kategorien sortieren:

Wenn du eine Entwickler-Dokumentation hast — JETZT. Wer eine API anbietet, ein SDK pflegt, ein Framework dokumentiert oder eine technische Spezifikation veröffentlicht, sollte heute eine llms.txt bereitstellen und idealerweise auch Markdown-Versionen der relevanten Dokumentationsseiten ausliefern (etwa unter /seite.md neben /seite.html). Das war Jeremy Howards Original-Use-Case, das ist das, wofür Mintlify, Anthropic und Cursor die Dateien haben, und das ist der Bereich, in dem die Adoption durch Coding Agents real ist. Hier zahlt sich die Investition unmittelbar aus, weil deine API von einem Cursor- oder Claude-Code-Nutzer schneller verstanden und korrekt eingesetzt wird.

Wenn du einen Service anbietest, der agentisch genutzt werden könnte — denk in Szenarien. Beispiele: Verzeichnisdienste, Buchungsplattformen, Marktplätze, lokale Dienstleister, Kartenanwendungen, Behörden-Services. Frag dich: Was würde ein Information Agent von Google bei einer typischen Nutzeranfrage auf meiner Seite tun müssen? Welche URLs sind die richtigen Einstiegspunkte? Welche Aktionen sind reversibel, welche nicht? Welche Datenschutzgrenzen muss ein Agent kennen? Daraus entsteht eine sinnvolle llms.txt, die — ob sie heute schon gelesen wird oder nicht — als interne Klärungsübung wertvoll ist.

Wenn du eine klassische Content-Site betreibst — abwarten und beobachten. Für News-Seiten, Magazine, Corporate Sites, Blogs gilt meine Februar-Analyse weiterhin: Eine llms.txt als Sichtbarkeits-Hebel zu pflegen ist Opportunitätskosten ohne nachweisbaren Nutzen. Wenn die Adoption sich verschiebt, lässt sich eine Datei in einer Stunde generieren. Wer jetzt Zeit investiert, sollte sie in Content-Qualität und Zitierfähigkeit stecken.

Was bleibt richtig

OtterlyAIs 0,1-Prozent-Zahl ist immer noch die belastbarste Datenquelle, die wir haben. Mueller und Illyes haben ihre Position nicht widerrufen. Die strukturellen Argumente gegen llms.txt als Retrieval-Signal — Manipulationsanfälligkeit, Effizienz-Probleme im Retrieval-Stack, Redundanz zur robots.txt — sind unverändert gültig.

Wer nach diesem Artikel zurück ans Whiteboard geht und in den nächsten GEO-Audit „llms.txt erstellen und optimieren“ als Workstream schreibt, hat ihn missverstanden. Die llms.txt ist weiterhin kein Ranking-Hebel. Sie wird auch keiner werden.

Fazit

Mein Februar-Titel war zugespitzt. Das war Absicht, und die Pointe trifft die Sache, die ich angreifen wollte: llms.txt als GEO-Maßnahme.

Was ich nicht ausreichend gewürdigt habe: Mit der Verschiebung von „Search als Retrieval“ zu „Search als Task-Ausführung“ entsteht eine zweite Klasse von Nutzungsszenarien. In diesen Szenarien ist eine gut gepflegte llms.txt keine Marketing-Datei, sondern eine Bedienungsanleitung. Sie wird nicht von einem Crawler gewichtet — sie wird von einem Operator gelesen, der gerade eine Aufgabe abarbeitet.

Diese Lesart ist näher an Jeremy Howards Originalvorschlag von September 2024 als die GEO-Interpretation, die im Frühjahr 2025 viral ging. Vielleicht war die llms.txt nie tot. Vielleicht war sie nur in einer Diskussion gefangen, die mit ihrem eigentlichen Zweck wenig zu tun hatte.

Wenn die agentische Suche das wird, was Google auf der I/O versprochen hat, dann werden wir alle in den nächsten Monaten darüber nachdenken, welche URLs unserer Sites für welche Tasks die richtigen sind — und wie wir das einem Agenten in einer halben Seite Markdown erklären. Das ist eine Konversation, die es wert ist, geführt zu werden. Sie hat nur nicht das Etikett verdient, unter dem sie 2025 vermarktet wurde.

Wer derzeit einen Artikel über KI-SEO oder einen GEO-Audit liest, findet sie fast immer: die Empfehlung, Schema.org Markup einzubauen, „damit Ihre Inhalte mit dem Knowledge Graph verknüpft werden“ und „KI-Suchsysteme Ihre Entitäten besser verstehen“. Sie klingt plausibel, ist technisch sauber formuliert und lässt sich gut verkaufen. Sie ist nur leider in dieser Pauschalform irreführend – und zwar genau für die Systeme, für die sie heute besonders häufig in Stellung gebracht wird: ChatGPT, Perplexity und Claude.

Dieser Beitrag prüft, was die Empfehlung tatsächlich verspricht, was die öffentlich dokumentierte Architektur der relevanten Systeme dazu sagt und was unabhängige Tests zeigen.

Das Ergebnis ist nicht „Schema ist tot“ – sondern: Schema.org wirkt sehr unterschiedlich, je nachdem, in welches System und auf welcher Ebene man hineinschaut. Wer die Empfehlung pauschal ausspricht, verkauft ein Versprechen, das die Evidenz so nicht trägt.

Was die Empfehlung eigentlich behauptet

Die populäre Version geht ungefähr so: Wenn ich auf meiner Website Organization, Article, Product, FAQPage oder Person als JSON-LD ausspielt, werden meine Entitäten und Aussagen in den Knowledge Graph eingespeist. Dadurch erkennt „Die KI“ [sic!] meine Inhalte als „Entitäten“ und ziehen sie als Quellen für KI-Antworten heran. Schema.org wird damit zum semantischen Backbone der KI-Sichtbarkeit erklärt.

Diese Erzählung verschmilzt mindestens drei Annahmen, die einzeln geprüft werden müssen:

1. Dass es einen einzigen, gemeinsamen „Knowledge Graph“ gibt, in den Inhalte eingespeist werden.
2. Dass Schema.org-Markup tatsächlich der Eingangskanal in diese Strukturen ist.
3. Dass die Einspeisung sich in Form von KI-Zitaten und Antwortpräsenz bemerkbar macht.

Alle drei Annahmen sind im Detail brüchiger, als die SEO-Standardrhetorik nahelegt.

„Der Knowledge Graph“ ist eine Fiktion – es gibt mehrere, aber nicht überall einen!

Der erste Punkt ist begrifflich, aber folgenreich. Wenn man die öffentliche Produktdokumentation der relevanten Anbieter sichtet, ergibt sich ein eindeutiges Bild:

Eine dokumentierte produktive Knowledge-Graph-Nutzung lässt sich vor allem bei Google und Microsoft belegen.

Google beschreibt seinen Knowledge Graph ausdrücklich als System mit über 500 Milliarden Fakten zu fünf Milliarden Entitäten, in das Informationen aus dem Web, aus offenen und lizenzierten Datenbanken sowie aus speziellem strukturierten Markup einfließen. Microsoft dokumentiert für Bing seit 2013 Satori als Entity- und Knowledge-Repository und beschreibt im Prometheus-Ansatz die Kombination aus Bing-Index, Ranking-, Answers- und Entity-Systemen.

Bei OpenAI, Perplexity und Anthropic findet sich in der öffentlich zugänglichen Dokumentation nichts Vergleichbares.

Was sich dort findet, ist eine andere Architektur: Search-Index plus Retrieval-Augmented Generation bei Perplexity (Sonar, Search API, Agent API – jeweils mit eigenem Suchindex), Web-Search-Tool plus Contextual Retrieval plus MCP/Connectors bei Anthropic, OAI-SearchBot plus GPTBot plus ChatGPT-User plus Vector Stores plus Product Feeds bei OpenAI.

Das sind RAG-, Index- und Connector-Architekturen, keine offengelegten Knowledge Graphs.

Daraus folgt eine simple, aber für die populäre Empfehlung unangenehme Konsequenz:

Wer „Verknüpfung mit dem Knowledge Graph“ als universellen GEO-Hebel verkauft, suggeriert eine Infrastruktur, die bei drei der fünf großen KI-Systeme schlicht nicht dokumentiert ist. Das macht die Empfehlung nicht automatisch falsch – aber sie ist nicht das, was sie zu sein vorgibt.

Vier Ebenen, auf denen Schema wirken könnte – und wo es das tatsächlich tut

Ein Grund, warum die Schema-Debatte so widersprüchlich verläuft, ist, dass dieselben Tests immer wieder auf falsche Ebenen verallgemeinert werden. Es lohnt sich, vier technische Ebenen sauber zu trennen:

1. Training und Parametrisierung – fließen strukturierte Daten in die Modellgewichte ein?
2. Crawling und Indexierung – wird Schema beim Aufbau eines Such-/Entity-Index ausgewertet?
3. Retrieval und Grounding – nutzt das System Schema, wenn es zur Antwortzeit Dokumente auswählt?
4. Rendering und Zitation – beeinflusst Schema, wie die Antwort und die Quellenangaben aussehen?

Die meisten populären Schema-Tests messen Ebene 3 und 4 und verallgemeinern dann auf Ebene 1 und 2. Das ist methodisch riskant. Wenn ein Live-Fetch-Test zeigt, dass ChatGPT versteckte JSON-LD-Daten beim Abruf einer einzelnen Seite ignoriert, beweist das nicht, dass strukturierte Daten in Training oder Index nirgendwo eine Rolle spielen. Umgekehrt beweist die Existenz von Googles Knowledge Graph nicht, dass jedes JSON-LD-Snippet auf einer mittelgroßen Website tatsächlich Einfluss auf AI Overviews hat.

Mit dieser Differenzierung ergibt sich folgendes Bild:

Bei Google wirkt Schema vor allem auf Ebene 2 und 4: Beim Verstehen von Seiten, bei der Entity-Disambiguierung, bei Rich Results, Knowledge-Panel-Elementen, Logos und Produkt-/Local-Surfaces. Google sagt zugleich ausdrücklich, dass es keine Sonderanforderungen und kein spezielles Schema-Markup für AI Overviews oder AI Mode gibt. Schema ist hier ein Verstehens-, Appearance- und Entity-Signal – kein eigenständiger Rankingfaktor für generative Antworten.

Bei Microsoft Copilot ist die Lage ähnlich: Bing dokumentiert die Nutzung von Structured Data zum Verstehen, unterstützt JSON-LD, akzeptiert spezielle Formate wie ClaimReview und bindet IndexNow an strukturierte Produktdaten an. Wer in Copilot-Antworten sichtbar werden will, profitiert hier von realer, dokumentierter Architektur – und kann seit Anfang 2026 im AI Performance Dashboard der Bing Webmaster Tools sogar nachvollziehen, welche Grounding Queries Copilot dazu bringen, eigene Inhalte zu zitieren.

Bei ChatGPT gibt es exakt einen klar dokumentierten Fall, in dem strukturierte Daten als Eingangskanal beschrieben sind: Commerce, über Product Feeds und – bei Shopify-Händlern – den Shopify Catalog. Für klassische redaktionelle Webseiten existiert keine vergleichbare offizielle Aussage. Eine Ahrefs-Untersuchung an 1.885 Seiten fand, dass das nachträgliche Hinzufügen von JSON-LD keinen robusten Zitationszuwachs in ChatGPT brachte. Ein searchVIU-Test deutete zusätzlich darauf hin, dass ChatGPT bei Live-Fetches sichtbares HTML verarbeitete, aber versteckte JSON-LD-, Microdata- und RDFa-Daten ignorierte.

Bei Perplexity existiert ebenfalls keine offizielle Aussage, dass Schema.org die Antwortauswahl verbessert. Die unabhängigen Tests zeigen, dass Perplexity primär aus dem eigenen Index antwortet und versteckte Schema-Daten in Antwort-Fetches nicht extrahiert. Spannend ist allerdings: Perplexitys Zitate überlappen stärker mit klassischen Top-Rankings als bei jedem anderen KI-Assistenten – fast ein Drittel der Perplexity-Zitate stammt aus Seiten, die für dieselbe Anfrage auch in Googles Top 10 ranken. Wer Perplexity-Sichtbarkeit will, betreibt also vor allem klassische SEO.

Bei Claude ist die Evidenz am dünnsten und am skeptischsten. Anthropic dokumentiert Web Search, Contextual Retrieval und Connectors/MCP – keinen Knowledge Graph. Im searchVIU-Test konnte Claude selbst sichtbare Preisangaben nicht sauber extrahieren und versteckte JSON-LD/Microdata/RDFa ebenfalls nicht nutzen. Eine dedizierte Webmaster-Dokumentation analog zu OAI-SearchBot oder Bings AI-Performance-Reports existiert nicht.

Was die Studien wirklich zeigen – und was nicht

Drei Befunde aus der unabhängigen Forschung sind für die Bewertung der Schema-Empfehlung besonders relevant.

Erstens die bereits erwähnte Ahrefs-Studie: Sie ist eines der wenigen Quasi-Experimente in diesem Feld und zeigt, dass das bloße Nachrüsten von JSON-LD keinen robusten Effekt auf KI-Zitate in Google AI Mode oder ChatGPT hat. Das widerlegt nicht jede mögliche Wirkung von Schema – aber es widerspricht dem Versprechen, Schema sei der Hebel für KI-Sichtbarkeit, sehr direkt.

Zweitens die Ahrefs-Folgestudie zu 1,4 Millionen ChatGPT-Prompts: ChatGPT ruft viele URLs ab, zitiert aber nur etwa die Hälfte; was am Ende zitiert wird, kommt überwiegend über den allgemeinen Search-Pfad, und Titel- bzw. URL-Relevanz zu internen Fan-out-Fragen scheint wichtiger zu sein als Snippet-Felder. Das ist eine harte Botschaft: Selbst wenn eine Seite in der KI-Antwortpipeline ankommt, entscheidet eher klassische Search-Logik über die Zitation als strukturierte Daten.

Drittens die searchVIU-Direkt-Fetch-Tests: Sie zeigen, dass Live-Fetch-Systeme sichtbares HTML typischerweise besser verarbeiten als verstecktes Schema. Auch hier ist die Reichweite begrenzt – Schema kann in Index oder Training trotzdem genutzt werden – aber für den konkreten Antwortmoment ist sichtbarer Text die belastbarere Wette als versteckte Markup-Ebenen.

Daneben gibt es Beobachtungsstudien wie die GEO-16-Arbeit zu Google AIO und Perplexity, die Korrelationen zwischen Metadata, Freshness, semantischem HTML, Structured Data und Citation-Wahrscheinlichkeit findet. Solche Korrelationen sind interessant, aber keine Kausalbeweise – und die Studien selbst formulieren das deutlich vorsichtiger als die SEO-Kurzfassungen, die später daraus zitieren. Eine medizinische RAG-Untersuchung zeigt zudem, wie stark bereits kleine Formulierungsänderungen in der Query die Quellenauswahl in Google AIO und Perplexity verschieben können – ein weiterer Grund, einzelnen Tests nicht zu viel Erklärungskraft zuzuschreiben.

Eine wichtige Einschränkung gilt für alle diese Befunde: Wir sehen meist nur die finale Zitation, nicht das vollständige Candidate Set. Dass eine Seite nicht zitiert wird, heißt nicht, dass sie keinen Einfluss auf die Antwort hatte. Diese Attributionslücke macht jede Aussage über die Wirkung strukturierter Daten methodisch fragil – auch die kritische.

Wo Schema.org weiter sinnvoll bleibt

Wer aus alldem ableitet, Schema sei nutzlos, überzieht ebenfalls. Es gibt klar belegte, eng umrissene Wirkbereiche, in denen Schema.org weiterhin hohe Priorität verdient – nur eben nicht unter dem Label „Knowledge-Graph-Verknüpfung“, sondern unter ihren tatsächlichen Funktionen.

Für Google und Bing bleibt Schema relevant für Rich Results, Knowledge-Panel-Elemente, Logo-Darstellungen, Local- und Product-Surfaces, Fact-Check-Labels und Entity-Disambiguierung. Organization-Markup wird von Google explizit als Mittel zur Disambiguierung einer Organisation beschrieben. Bei mehrdeutigen Markennamen, internationalen Niederlassungen oder konkurrierenden Wikipedia-Einträgen ist sauberes Organization-Markup mit sameAs-Verweisen und konsistenten IDs ein realer Hebel.

Für ChatGPT-Commerce ist strukturierter, feed-basierter Input eindeutig relevant.

Wer Produkte in ChatGPT-Shopping platzieren will, sollte Produktfeeds, saubere Produktentitäten und aktuelle Katalogdaten priorisieren – das ist der eine Bereich, in dem OpenAI selbst Structured Data als Genauigkeits- und Relevanzsignal adressiert.

Für alle Google-/Bing-orientierten Use Cases sind Snippet-Kontrollen ein unterschätzter Hebel. nosnippet, max-snippet und data-nosnippet wirken bei Google ausdrücklich auch auf AI Overviews und AI Mode; Bing unterstützt data-nosnippet explizit für Search- und Copilot-Antworten und beschreibt dabei einen wichtigen Vorteil: Inhalte bleiben indexierbar und rankingfähig, erscheinen aber nicht in KI-generierten Antworten. Für Paywalls, Rechtstexte, volatile UGC-Blöcke oder sensible Tabellen ist das oft wertvoller als jedes zusätzliche Markup-Feld.

Was die Priorität tatsächlich verdient

Wenn man die Evidenz ernst nimmt, ergibt sich eine ziemlich nüchterne Prioritätenfolge für KI-Sichtbarkeit, in der Schema.org weiter vorkommt – aber nicht an erster Stelle:

Vor allem anderen kommt maschinenlesbare Sichtbarkeit im sichtbaren HTML: indexierbare Seiten, saubere Titel, klare Heading-Struktur, sichtbare Definitionen, Tabellen und FAQ-Blöcke, konsistente Entitätsbenennung im Fließtext, logische Kanonisierung und aktuelle Inhalte. Google sagt in seinem Guide zur Optimierung für generative AI-Suche explizit, dass seine generativen Funktionen auf den normalen Search-Systemen aufbauen; Bing empfiehlt zusätzlich klare Strukturen, Tabellen und FAQs für AI-Zitierbarkeit. Das ist die Schicht, die in Live-Fetch-Szenarien tatsächlich verarbeitet wird.

Dann folgt Aktualitätsinfrastruktur: Merchant Center und Business Profile für Google, IndexNow und Bing Places für Microsoft, direkte Produktfeeds für ChatGPT-Commerce. Wenn Preise, Verfügbarkeit, Öffnungszeiten oder regulatorische Fakten häufig wechseln, ist Aktualität fast immer wichtiger als noch ein weiteres Markup-Feld.

Erst danach kommt strukturierter Entity-Aufbau dort, wo er nachweislich konsumiert wird: Für Google und Bing sind Organization, Product, Article, Review, ClaimReview, Local-/Business-Daten und Knowledge-Panel-nahe Entitätssignale wertvoll. Für OpenAI sind es Product Feeds. Für Claude und Perplexity bleibt strukturierte Webauszeichnung im öffentlichen Web sekundärer als Sichtbarkeit, Frische und Klarheit.

Schließlich Kontrolle statt Totalfreigabe: bewusster Einsatz von nosnippet, max-snippet und data-nosnippet für Inhalte, die zwar ranken sollen, aber nicht in KI-Antworten erscheinen dürfen.

Wer die Empfehlung trotzdem ausspricht, schuldet seinen Kunden drei Klarstellungen

Es gibt gute Gründe, Schema.org weiter zu empfehlen. Es gibt aber keine guten Gründe, die populäre Erzählung von der „Verknüpfung mit dem Knowledge Graph“ als universellen GEO-Hebel unkommentiert weiterzugeben. Wer die Empfehlung 2026 ausspricht, schuldet seinen Kunden mindestens drei Klarstellungen:

1. Welcher Knowledge Graph eigentlich gemeint ist. Bei Google und Bing ist die Antwort konkret, bei ChatGPT, Perplexity und Claude existiert keine öffentlich dokumentierte Entsprechung.
2. Auf welcher Ebene Schema wirken soll. Verstehen und Entity-Disambiguierung im Index ist plausibel; direkte Zitations- oder Rankinghebel für generative Antworten sind nicht belegt und werden von Google selbst dementiert.
3. Welche Hebel daneben mindestens genauso wichtig sind. Sichtbares HTML, Frische-Inhalte und -Infrastruktur, Bot-Zugang, Snippet-Kontrolle und – im Commerce – direkte Produktfeeds liefern in vielen Fällen mehr ROI als ein weiteres JSON-LD-Snippet.

Die ehrliche Empfehlung für 2026 lautet daher nicht „Schema einbauen, damit Sie im Knowledge Graph landen“. Sie lautet: Schema dort einsetzen, wo Suchsysteme es nachweislich konsumieren, mit klarem Bewusstsein dafür, dass „die KI-Suche“ kein einheitliches Ziel ist, sondern fünf unterschiedlich gebaute Systeme mit unterschiedlichen Eingangskanälen. Wer das nicht differenziert, verkauft eine semantisch hübsche Geschichte – und enttäuscht damit Kunden, die in der Praxis messbare Sichtbarkeit suchen.

Google hat auf der I/O 2026 nicht einfach Updates verkündet. Google hat – endgültig und unmissverständlich – die Suche, wie wir sie kannten, beerdigt. An ihre Stelle tritt ein System aus Agenten, generativer UI, persistenten Mini-Apps und einem eigenen Bezahlprotokoll für KI. Wer als Marketer, SEO oder Markenverantwortliche:r noch glaubt, das Spielfeld bleibe ein Ranking aus zehn blauen Links mit aufgesetzter „AI Overview“, sollte sich die Keynote genau ansehen.

Dieser Beitrag fasst die wichtigsten Ankündigungen zusammen – mit klarem Fokus auf das, was für Sichtbarkeit, Traffic und Messbarkeit zählt.

Die neue Realität in Zahlen

Bevor wir in die Features gehen, drei Zahlen, die den Maßstab setzen:

• AI Overviews: über 2,5 Milliarden monatliche Nutzer:innen.
• AI Mode: in rund einem Jahr über 1 Milliarde monatliche Nutzer:innen, Queries verdoppeln sich Quartal für Quartal.
• Search insgesamt: laut Google im letzten Quartal auf Allzeithoch.

Das letzte Detail ist strategisch entscheidend. Google argumentiert: Sobald Nutzer:innen verstehen, dass sie „alles“ fragen können, fragen sie auch mehr – nicht weniger. Die These „KI killt Search“ stimmt also nicht. Die These „KI killt Search, wie wir sie messen“ stimmt sehr wohl.

Der perfekte Long-Tail – und das Ende klassischer Keyword-Logik

Wenn jede Anfrage individuell, dialogisch und kontextabhängig ist, wenn auf jede Antwort Folgefragen geschehen, dann wird der Long-Tail nicht nur länger – er wird einzigartig. Prompts statt Keywords. Sessions statt Suchanfragen. Bedürfnisse statt Volumen.

Was bedeutet das für Messbarkeit?

• Klassische Volumendaten verlieren ihren Ankerwert. Was man nicht aggregieren kann, kann man auch nicht ranken.
• Folgefragen innerhalb eines AI Overviews oder eines AI Modes sind für Dritte praktisch unsichtbar – sie verlassen die Search-Box nicht.
• Es bleibt im Wesentlichen ein Weg: synthetische, möglichst repräsentative Prompt-Kandidaten erzeugen und das Antwort- und Zitierverhalten messen, um zumindest das Potenzial einer Domain in KI-Antworten zu quantifizieren.

Wer GEO/AEO ernst nimmt, baut sich gerade jetzt diese Prompt-Sets auf. Wer noch auf Sistrix-Sichtbarkeitsindex und Ranktracking allein vertraut, bekommt in den kommenden Monaten ein Datenproblem.

Search Box, AI Overviews, AI Mode: drei Dinge verschmelzen

Google sortiert die Search-Oberfläche neu:

1. Die neue intelligente Search Box – laut Google das größte Upgrade der ikonischen Eingabezeile seit über 25 Jahren. Sie schlägt nicht mehr nur Autocompletes vor, sondern Nuancen, an die Nutzer:innen noch gar nicht gedacht haben, und nimmt Text, Bilder, Dateien und Videos parallel an.

2. AI Overviews und AI Mode wachsen zusammen – nahtlos, kontexterhaltend. Vom klassischen Ergebnis mit Overview direkt in eine Folgefrage im AI Mode, ohne Bruch, ohne Verlust der bisherigen Recherche. Links und Quellen sollen relevanter für das werden, was Nutzer:innen tatsächlich weiter erkunden.

3. AI Mode läuft jetzt auf Gemini 3.5 – mit neuen agentischen Fähigkeiten und der Breite des Webs, das Google nach eigenen Angaben mit über 1 Milliarde Fakten-Updates pro Minute aktuell hält.

Für SEO heißt das: Das Spiel verlagert sich vom „Klick auf die Seite“ hin zum „Zitiert werden in einer dialogischen Antwort“. Die Frage ist nicht mehr nur, ob eine URL rankt, sondern ob sie als Quelle erkannt, als vertrauenswürdig eingestuft und in eine sich entwickelnde Konversation eingewoben wird.

Search Agents: 24/7 im Hintergrund

Google hat die „era of Search agents“ ausgerufen. Nutzer:innen können in Search mehrere Agenten erstellen, die kontinuierlich für sie arbeiten:

• Ein Finanz-Agent, der Bedingungen wie „Biotech-Aktien mit P/E unter 15, positivem Cashflow und geringer Verschuldung“ überwacht und bei Marktbewegungen synthetisierte Updates mit Quellen aus News, Social und Research-Plattformen liefert.
• Ein Wohnungssuche-Agent, der aus einem Brain-Dump Kriterien zieht und Web, Portale, Social und Foren kontinuierlich scannt.
• Ein Sneaker-Agent, der Blogs und den Shopping Graph überwacht, damit kein Drop verpasst wird.

Für Marken bedeutet das: Sichtbarkeit findet nicht mehr nur statt, wenn jemand sucht. Sie findet statt, wenn ein Agent für jemanden sucht – rund um die Uhr. Wer in diesen Agenten-Workflows nicht als belastbare Quelle auftaucht, fällt aus der Customer Journey raus, bevor sie überhaupt beginnt. Verfügbarkeit: Sommer.

Generative UI: Search baut die Antwort, die sie braucht

Hier wird es radikal. Google bringt Antigravity und Gemini 3.5 Flash direkt in Search. Resultat: Auf eine Frage wird nicht mehr eine Antwort gefunden, sondern eine Antwort gebaut – dynamische Layouts, interaktive Widgets, ganze Erlebnisse, jeweils maßgeschneidert für die Frage.

In der Demo erzeugte Search zu „Wie beeinflussen schwarze Löcher die Raumzeit?“ ein interaktives Visual. Bei der Folgefrage zu binären schwarzen Löchern entstand in Echtzeit ein neues Visual mit Parametern für orbitale Distanz und Massenverhältnis. Im Hintergrund: Gemini 3.5 Flash plant die Antwort, entwirft das Layout, recherchiert, schreibt und deployt Code in einer sicheren, containerisierten Umgebung.

Das ist „agentic coding at the scale of Search“. Kostenlos. Für alle. Im Sommer.

Konsequenz: Wenn die Antwort selbst eine kleine App ist, ist die zentrale Frage für Inhalteanbieter nicht mehr „wie kommen Nutzer:innen auf meine Seite“, sondern „liefere ich strukturierte, verlässliche, zitierfähige Daten, aus denen Google diese Apps bauen kann“.

Mini-Apps in Search: persistente Erlebnisse

Search bekommt einen Zustand. Aus einer einfachen Frage nach Familienaktivitäten entsteht ein Weekend Planner in Search, der mit Personal Intelligence Gmail, Photos und Calendar nutzt und Fahrzeiten, Wetter, Kinderpräferenzen, Reservierungen und Maps berücksichtigt. Per Prompt lässt sich der Plan weiter anpassen, teilen, in Familienkalender exportieren.

Vergleichbare „Mini-Apps“ sollen für Hochzeitsplanung, Umzug und andere länger laufende Aufgaben entstehen. Generative UI für alle im Sommer; vollständige Custom-Build-Erfahrungen zunächst für zahlende Abonnent:innen.

Wer heute Content für „Inspiration“, „Vergleich“ und „Planung“ erstellt, sollte sich fragen: Welche Schicht davon kann eine Mini-App in Search übernehmen – und wo bleibt mein Mehrwert?

Agentic Commerce: UCP, AP2, Universal Cart

Shopping ist der Bereich, in dem Google die agentische Logik am konsequentesten durchzieht. Drei Bausteine:

Universal Commerce Protocol (UCP) – ein offener Standard für agentisches Commerce, von Google als „HTTP-Moment“ inszeniert. Es gibt Agenten und Systemen eine gemeinsame Sprache für Produktsuche, Checkout und Sendungsverfolgung. Neu an Bord: Amazon, Meta, Microsoft, Salesforce und Stripe. Geplant ist die Ausweitung auf Hotels, lokale Food-Delivery, YouTube und weitere Produkte; UCP-Experiences kommen in den kommenden Monaten u. a. nach Kanada, Australien und UK.

Agent Payments Protocol (AP2) – die Bezahlschicht für agentisches Handeln. Nutzer:innen setzen Grenzen (Marken, Produkte, Budget); wenn diese erfüllt sind, kann der Agent kaufen. AP2 will Accountability schaffen: verifizierbare Verbindung zwischen Nutzer, Händler und Payment Processor, fälschungssichere digitale Mandate, abgeschirmte Zahlungsdaten. Rollout startet mit Gemini Spark.

Universal Cart – ein intelligenter Warenkorb über Händler und Services hinweg. Produkte werden hinzugefügt, während Nutzer:innen in Search browsen, mit Gemini chatten, auf YouTube schauen oder Gmail lesen. Der Cart findet Deals, zeigt Preisverläufe, meldet wieder verfügbare Produkte und erkennt Kompatibilitätsprobleme (Beispiel aus der Demo: PC-Komponenten). Checkout direkt auf Google mit Google Pay oder per Übergabe an Retailer-Sites. Start: USA im Sommer in Search und Gemini App, YouTube und Gmail folgen.

Für E-Commerce-Verantwortliche heißt das vor allem: Wer im Shopping Graph (über 60 Milliarden Listings) nicht sauber, vollständig und aktuell vertreten ist, wird in der agentischen Customer Journey schlicht nicht existieren. Produktdaten-Qualität schlägt Werbebudget.

Verifizierung: SynthID kommt in Search und Chrome

Im Schatten der großen Themen ein Detail mit Konsequenz: SynthID und Content Credentials Verification kommen in Search und Chrome. Per Circle to Search oder Rechtsklick fragen: „Was this generated with AI?“ – inklusive Information, ob ein Inhalt mit generativen Tools bearbeitet wurde. Neue Partner für SynthID neben NVIDIA: OpenAI, Kakao, ElevenLabs.

Für Publisher, Marken und alle, die mit AI-Bildern arbeiten, wird Transparenz damit nicht mehr nur ethische Pflicht, sondern Distributions-Faktor.

Was abseits von Search noch relevant ist

Die Keynote war länger, als hier sinnvoll wäre. Drei Dinge sollte man aber als Marketer auf dem Schirm haben:

Gemini Spark – Googles persönlicher KI-Agent in der Gemini App. Läuft 24/7 auf dedizierten Cloud-VMs, integriert über MCP Drittanbieter-Tools, soll später im Sommer in Chrome als agentischer Browser laufen. Beta für US-Ultra-Abonnenten in dieser Woche, neuer Ultra-Plan ab 100 US-Dollar/Monat. Wer Customer Journeys baut, sollte verstehen, wie das eigene Produkt von solchen Agenten erreichbar, buchbar und bezahlbar ist.

Gemini 3.5 Flash & Pro – Flash ist heute live, in Antigravity bis zu 12x schneller als andere Frontier-Modelle und laut Google deutlich günstiger. Pro folgt im nächsten Monat. Praktische Bedeutung: Die Hürde, eigene agentische Workflows wirtschaftlich zu betreiben, sinkt weiter.

Daily Brief in Gemini – personalisierter Morgen-Digest aus Inbox, Kalender, Tasks. Heute live für AI Plus/Pro/Ultra in den USA. Auch das ein Touchpoint, an dem Marken künftig sichtbar – oder unsichtbar – sind.

Dazu Antigravity 2.0 als eigenständige Desktop-App, Docs Live für „verbales Brain-Dumpen“, ein redesigntes Gemini-App-UI („Neural Expressive“), Android XR mit den ersten Audio Glasses im Herbst, Google Pics in Workspace, Stitch-Updates fürs UI-Design, Flow und Flow Music für kreative Workflows. Die Richtung ist überall dieselbe: weg von der Antwort, hin zum System, das plant, baut, editiert, bezahlt und im Hintergrund Aufgaben erledigt.

Was Du jetzt tun solltest

Drei konkrete Konsequenzen aus dieser Keynote für jede:n, der/die Sichtbarkeit verantwortet:

1. Messbarkeit neu denken. Klassische Sichtbarkeitsmetriken werden nicht falsch, aber unvollständig. Baue Dir – oder hol Dir – ein synthetisches, repräsentatives Prompt-Set für Deine Themen und tracke Zitierverhalten und Quellenpräsenz in AI Overviews und AI Mode. Wer das jetzt aufsetzt, hat in 12 Monaten Daten, die Wettbewerber nicht haben.

2. Inhalte und Daten zitierfähig machen. Generative UI in Search wird Antworten aus strukturierten, verlässlichen Bausteinen bauen. Saubere semantische Struktur, klare Faktenlage, gepflegte Produktdaten, gut interpretierbare Schemata sind keine SEO-Hygiene mehr – sie sind die Voraussetzung, überhaupt Rohmaterial für die KI-Antwort zu liefern.

3. Agentische Distribution mitdenken. Search Agents, Spark, Daily Brief, Universal Cart und AP2 zeigen: Ein wachsender Anteil von Kaufentscheidungen läuft künftig durch Agenten, nicht durch direkte Nutzer-Interaktion. Marken sollten heute beginnen, ihre Produkte, Konditionen und Preise so zu strukturieren, dass ein Agent sie sauber vergleichen, einsortieren und im Auftrag eines Menschen bevorzugen kann.

Google hat 2026 nicht „mehr KI in Search“ angekündigt. Google hat Search selbst neu definiert. Die Frage ist nicht mehr, ob man dem folgt – sondern wie schnell.

Die Diskussion um AI-Agenten hat sich verschoben. Vor einem Jahr klang vieles noch nach Modellvergleich: Welches LLM plant besser? Welches schreibt besseren Code? Welches halluziniert weniger? Inzwischen wird klarer: Die entscheidende Frage ist nicht nur, wie gut das Modell ist, sondern in welchem System es arbeitet.

Genau hier setzt Harness Engineering an.

Ein Agent ist eben nicht einfach ein Chatbot mit mehr Kontext. Sobald er Tools nutzen, Dateien ändern, Tests starten, Browser bedienen, Deployments vorbereiten oder Entscheidungen über mehrere Arbeitsschritte hinweg treffen soll, braucht er eine Umgebung, die ihn führt, begrenzt und überprüfbar macht. Der Harness ist diese Umgebung: Instructions, State, Verification, Scope und Session Lifecycle – also die Regeln, das Gedächtnis, die Prüfmechanismen, die Grenzen und die Übergaben, innerhalb derer ein Agent arbeitet. Das Projekt Learn Harness Engineering beschreibt diesen Ansatz als systematisches Design von Environment, State Management, Verification und Control Systems, um Coding Agents wie Codex oder Claude Code zuverlässiger zu machen.

Der Harness besteht selbst als fünf Subsystemen: Instructions, State, Verification, Scope und Session Lifecycle. Wichtig ist dabei die Formulierung: Das Modell entscheidet, welchen Code es schreibt; der Harness regelt, wann, wo und wie es schreibt. Der Harness macht das Modell also nicht klüger, sondern macht seine Arbeit kontrollierbarer und überprüfbarer.

Damit ist Harness Engineering mehr als „bessere Prompts schreiben“. Es ist der Übergang von Prompting zu Infrastruktur. OpenAI beschreibt diese Verschiebung sehr deutlich: In einer agentenorientierten Entwicklungswelt besteht die Arbeit des Engineering-Teams nicht mehr nur darin, selbst Code zu schreiben, sondern Umgebungen zu entwerfen, Intentionen zu spezifizieren und Feedback-Loops zu bauen, in denen Codex-Agenten zuverlässig arbeiten können. Ein zentrales Muster ist dabei: Das Repository wird zum „System of Record“, während AGENTS.md eher als Karte oder Inhaltsverzeichnis dient, nicht als allwissendes Handbuch.

Auch Anthropic argumentiert in eine ähnliche Richtung. In den Arbeiten zu long-running agents geht es nicht nur darum, ein Modell länger laufen zu lassen, sondern Fortschritt über Kontextfenster, Sessions und Teilaufgaben hinweg kontrollierbar zu machen. Dazu gehören Initialisierung, Feature-Listen, Übergabeartefakte, Browser-Validierung, QA-Agenten und explizite Verifikationsschleifen. Gleichzeitig zeigen diese Arbeiten auch die Grenze: Selbst bessere Harnesses stoßen an Decken, etwa wenn Evaluatoren zu großzügig urteilen, UI-Zustände nicht beobachtbar sind oder das System zwar viel schafft, aber nicht sicher weiß, ob es das Richtige geschafft hat.

Das macht die aktuelle Debatte so interessant: Harness Engineering ist einerseits eine der praktischsten Antworten auf die Unzuverlässigkeit von AI-Agenten. Es reduziert Kontextverlust, Scope Creep, ungeprüfte Annahmen, „fertig“-Behauptungen ohne Evidenz und gefährliche Tool-Nutzung. Andererseits darf man es nicht mit einer Sicherheitsgarantie verwechseln.

Ein Harness kann erzwingen, dass ein Agent Tests ausführt.
Er kann aber nicht garantieren, dass diese Tests die richtigen Dinge prüfen!

Er kann Rechte beschränken.
Er kann aber nicht automatisch erkennen, ob eine fachliche Entscheidung ethisch, rechtlich oder geschäftlich sinnvoll ist.

Er kann einen Agenten auditable machen.
Er kann ihn nicht unfehlbar machen!

Gerade deshalb ist die Sicherheitsdiskussion so wichtig. OWASP beschreibt für AI-Agenten Risiken, die über klassische Prompt Injection hinausgehen: Tool Abuse, Privilege Escalation, Memory Poisoning, Excessive Autonomy, Goal Hijacking und Cascading Failures. Sobald ein Agent nicht nur Text erzeugt, sondern Handlungen ausführt, reicht es nicht mehr, ihn gut zu instruieren. Man muss ihn wie einen potenziell fehlbaren, potenziell manipulierbaren Prozess behandeln – mit Least Privilege, Isolation, Monitoring, Approval Gates und Rollback.

Der entscheidende Punkt ist also: Ein guter Harness macht AI-Agenten nicht magisch zuverlässig. Er macht sie sichtbar, begrenzt, prüfbar, reversibel, eskalierbar und lernend. Das ist enorm viel. Es ist wahrscheinlich der Unterschied zwischen „ein Modell macht irgendetwas“ und „ein Agent kann produktiv in einem echten Workflow arbeiten“. Aber es bleibt ein Unterschied zwischen kontrollierter Autonomie und garantierter Korrektheit.

Wer AI-Agenten produktiv einsetzen will, sollte deshalb nicht nur fragen: „Welches Modell nehmen wir?“ Die bessere Frage lautet: Welche Arbeitsumgebung bauen wir, damit Fehler früh sichtbar werden, Schaden begrenzt bleibt und menschliche Urteilskraft dort eingreift, wo sie wirklich gebraucht wird?

Denn am Ende ist der Harness kein Schutzengel. Er ist ein Betriebssystem für begrenzte Autonomie.

Was ein optimaler Harness sehr gut kann

Er kann viele typische Agentenfehler fast mechanisch reduzieren: Kontextverlust, „ich bin fertig“-Behauptungen ohne Beweis, Scope Creep, Arbeiten auf kaputtem Ausgangszustand, vergessene Tests, fehlende Handoffs. Die mitgelieferte AGENTS.md-Vorlage verlangt zum Beispiel, vor Codeänderungen den Arbeitsstand zu lesen, init.sh auszuführen, Smoke- oder E2E-Verifikation zu starten und bei fehlschlagender Baseline erst den Ausgangszustand zu reparieren.

Er kann auch verhindern, dass „fertig“ nur ein Sprachakt ist. Die Vorlage definiert Done erst dann, wenn Zielverhalten implementiert ist, die Verifikation tatsächlich lief, Evidenz dokumentiert wurde und das Repository wieder vom Standardpfad startbar ist.

Und er kann Architektur, Security- und Qualitätsregeln teilweise aus dem menschlichen Gedächtnis in mechanische Gates verschieben. OpenAI beschreibt genau diesen Weg: kurze AGENTS.md als Router, Repo-Dokumente als System of Record, mechanische Linter, strukturelle Tests und Custom-Lints, um Invarianten durchzusetzen.

Die harte Grenze: Der Harness kann nur prüfen, was spezifiziert, beobachtbar und testbar ist

Die wichtigste Grenze ist das Oracle-Problem: Woher weiß das System, was richtig ist?

Ein Harness kann sagen: „Führe Tests aus.“ Er kann nicht automatisch sicherstellen, dass die Tests vollständig, relevant und richtig sind. Er kann sagen: „Arbeite nur an Feature X.“ Er kann nicht garantieren, dass Feature X fachlich sinnvoll, moralisch akzeptabel, rechtlich zulässig oder im Produktkontext die richtige Priorität ist.

Deshalb würde ich sagen:

Ein Harness kann Prozess- und Zugriffsgarantien geben.
Er kann Evidenz erzwingen.
Er kann Blast Radius begrenzen.
Er kann aber nicht aus unvollständiger Spezifikation vollständige Wahrheit machen.

Anthropic zeigt das sehr plastisch: Harnesses verbesserten Long-running Agents stark, aber auch mit Browser-Automation und Tests blieben blinde Flecken, etwa weil bestimmte UI-Zustände nicht sichtbar waren oder Browser-Automation nicht alles erfassen konnte.

Grenze 1: Unvollständige oder falsche Ziele

Ein Agent kann perfekt gegen die falsche Spezifikation arbeiten. Wenn die Akzeptanzkriterien fehlen, falsch sind oder wichtige Stakeholder-Anforderungen nicht im Repo stehen, optimiert der Harness auf eine Scheingenauigkeit.

OpenAI formuliert es sinngemäß so: Was Codex nicht im Kontext sehen kann, existiert für das System nicht; Wissen in Slack, Google Docs oder in Köpfen muss in repo-lokale, versionierte Artefakte übersetzt werden.

Das heißt: Der Harness schützt nicht vor fehlenden Prämissen. Er kann nur erzwingen, dass der Agent vorhandene Prämissen liest und nutzt.

Grenze 2: Tests sind Evidenz, keine Wahrheit

„Alle Tests grün“ heißt: Das System hat eine endliche Menge erwarteter Fälle bestanden. Es heißt nicht: keine Bugs, keine falschen Annahmen, keine Security-Lücken, keine ungesehenen Randfälle.

Das gilt besonders bei UX, Security, Datenqualität, Nebenwirkungen, Race Conditions, Performance unter Last, realen Nutzerdaten und externen APIs. Anthropic beschreibt, dass selbst ein getunter QA-Agent subtile Bugs und tiefer verschachtelte Features übersehen kann; außerdem war Claude als QA-Agent „out of the box“ zu großzügig und musste explizit auf skeptisches Prüfen getunt werden.

Ein optimaler Harness kann hier nur besser werden durch stärkere Oracles: Property-based Tests, Fuzzing, formale Spezifikationen, Golden Datasets, Replay realer Traces, unabhängige Evaluatoren, Canary Deployments, Monitoring und Rollback. Aber auch das bleibt Abdeckung, nicht Allwissenheit.

Grenze 3: LLM-Evaluatoren teilen oft dieselben Schwächen

Multi-Agent-Harnesses klingen attraktiv: Planner, Generator, Evaluator. Das hilft. Aber der Evaluator ist oft wieder ein LLM. Damit entstehen korrelierte Fehler: beide Modelle übersehen dasselbe, teilen dieselben Annahmen, lassen sich von plausiblen Erklärungen überzeugen oder bewerten oberflächlich.

Anthropic sagt explizit, dass Agenten bei Selbstbewertung dazu tendieren, ihre eigene Arbeit zu positiv zu beurteilen; ein separater Evaluator hilft, aber eliminiert die Tendenz nicht automatisch.

Darum: Ein Evaluator-Agent ist gut. Ein mechanischer, adversarialer, unabhängiger Evaluator ist besser. Ein menschlicher Fachexperte bleibt bei offenen Urteilsfragen noch einmal eine andere Qualität.

Grenze 4: Sicherheit kann nicht nur prompt-basiert sein

Ein Harness, der sagt „lösche keine Dateien“, ist schwach. Ein Harness, bei dem der Agent technisch keine Dateien außerhalb eines erlaubten Pfads löschen kann, ist stark.

Die große Grenze ist: Sobald der Agent Tools, Credentials, Shell, Browser, E-Mail, Datenbanken oder Deploy-Rechte hat, wird Fehlverhalten operativ relevant. OWASP nennt für Agenten unter anderem Prompt Injection, Tool Abuse, Privilege Escalation, Data Exfiltration, Memory Poisoning, Goal Hijacking, Excessive Autonomy und Cascading Failures als zentrale Risiken.

Prompt Injection ist besonders wichtig: OWASP beschreibt im Detail, dass manipulierte Inputs das Modellverhalten unerwartet verändern können und dass RAG oder Fine-Tuning solche Angriffe nicht vollständig entschärfen. Außerdem sei unklar, ob es narrensichere Prävention gibt; empfohlen werden daher Schadensbegrenzung, Least Privilege, Output-Validierung, Trennung untrusted content und Human Approval für Hochrisikoaktionen.

Praktisch heißt das: Der Harness darf dem Modell nicht vertrauen. Er muss den Agenten wie einen potenziell kompromittierten Prozess behandeln.

Grenze 5: Schaden entsteht oft außerhalb des Codes

Ein Coding-Harness kann Codequalität verbessern. Aber Schaden kann auch entstehen durch:

falsche Nutzerkommunikation, fehlerhafte fachliche Empfehlung, Datenschutzverletzung, Diskriminierung, falsche Priorisierung, unzulässige Automatisierung, falsche Eskalation, unbemerkte Kostenexplosion oder eine Entscheidung, die technisch korrekt, aber organisatorisch falsch ist.

NIST beschreibt Trustworthy AI nicht nur als Validität und Reliability, sondern auch als Safety, Security/Resilience, Accountability/Transparency, Explainability/Interpretability, Privacy und Fairness. NIST betont außerdem, dass das einzelne Adressieren dieser Eigenschaften nicht automatisch Vertrauenswürdigkeit garantiert, weil Trade-offs und Kontextentscheidungen bleiben.

Das ist eine wichtige Grenze für Harness Engineering: Ein Harness kann technische Gates bauen, aber nicht alle sozialen, rechtlichen und ethischen Trade-offs wegautomatisieren.

Grenze 6: Drift und Entropie bleiben

Ein Agent kopiert vorhandene Muster. Sind die Muster gut, skaliert Qualität. Sind sie schlecht, skaliert Müll.

OpenAI beschreibt genau das als neues Problem vollständiger Agentenautonomie: Codex repliziere vorhandene, auch suboptimale Patterns, was über Zeit zu Drift führt; dagegen wurden „Golden Principles“, Qualitätschecks und wiederkehrende Cleanup-Prozesse eingeführt.

Ein optimaler Harness braucht also nicht nur „Do the task“, sondern auch permanente Müllabfuhr: Qualitätsmetriken, Architektur-Reviews, Tech-Debt-Tracker, Refactoring-Routinen, Dokumentationspflege, Regressionstests und Mechanismen gegen veraltete Regeln.

Grenze 7: Menschliche Urteilskraft verschwindet nicht, sie wandert nach oben

Der Mensch schreibt weniger Code, aber entscheidet stärker über Ziele, Constraints, Akzeptanzkriterien, Risikoappetit und Eskalation. OpenAI beschreibt, dass Menschen im Loop bleiben, aber auf anderer Abstraktionsebene: priorisieren, User Feedback in Acceptance Criteria übersetzen und Outcomes validieren.

Das ist aus meiner Sicht die produktivste Lesart:

Der Harness soll Menschen nicht komplett ersetzen, sondern ihre Aufmerksamkeit an die Stellen verschieben, an denen sie am meisten Wert hat.

Was ein Harness tatsächlich garantieren kann

Stark garantierbar sind Dinge wie:

Art der Garantie	Kann ein guter Harness leisten?
Agent darf bestimmte Tools nicht nutzen	Ja, wenn technisch enforced, nicht nur prompt-basiert
Agent darf nur in Sandbox schreiben	Ja, über Dateisystem-/Containerrechte
Kein Merge ohne CI	Ja, über Branch Protection
Kein Deploy ohne Human Approval	Ja, über Deployment-Gates
Keine Arbeit ohne Baseline-Check	Weitgehend, wenn der Workflow technisch erzwingt
Keine „Done“-Meldung ohne Evidenz	Weitgehend, wenn Done-Status maschinell validiert wird
Keine fachlich falsche Entscheidung	Nein, nicht allgemein
Keine falsche Annahme	Nein, nur reduzierbar
Keine ungetesteten Nebenwirkungen	Nein, nur durch bessere Abdeckung reduzierbar
Kein Schaden	Nein, nur Risiko und Blast Radius reduzierbar

Der Unterschied ist: Zugriff, Prozess und Artefakte lassen sich hart kontrollieren. Bedeutung, Wahrheit, Priorität und Werturteile nur begrenzt.

Meine Kurzformel

Ein optimaler Harness macht den Agenten nicht unfehlbar. Er macht ihn:

1. sichtbar: Was wurde getan, warum, mit welcher Evidenz?
2. begrenzt: Was darf der Agent technisch überhaupt tun?
3. prüfbar: Welche Tests, Logs, Traces, Screenshots, Reviews existieren?
4. reversibel: Kann man Fehler zurückrollen?
5. eskalierbar: Wann muss ein Mensch entscheiden?
6. lernend: Werden Fehler in neue Regeln, Tests und Dokumente überführt?

Für harmlose oder gut testbare Coding-Aufgaben kann das reichen, damit man „reviewt statt rettet“. Für sicherheitskritische, rechtliche, medizinische, finanzielle oder reale Aktionsräume reicht es nicht als Autonomiebeweis. Dort sollte der Harness den Agenten eher als assistierendes System mit harter Sandbox, Least Privilege, Audit Trail und Human Approval behandeln. NIST formuliert für AI-Risikomanagement ebenfalls, dass bei Fehlern, die das System nicht erkennen oder korrigieren kann, menschliche Intervention nötig sein kann.

Fazit

Ein sehr guter Harness kann Zuverlässigkeit massiv erhöhen, aber er kann nicht garantieren, dass ein Agent „keine Fehlentscheidungen“ trifft. Er verschiebt das Problem: weg von „das Modell improvisiert frei“ hin zu „wir erzwingen Prozess, Kontext, Grenzen, Evidenz und Eskalation“. Das ist ein großer Fortschritt, aber kein Beweis für Wahrheit, Sicherheit oder gute Urteilsfähigkeit.

Es gibt KI-Benchmarks, die beeindrucken. Und es gibt Benchmarks, die irritieren. ARC-AGI-3 gehört für mich klar zur zweiten Kategorie – im besten Sinne.

Denn während viele aktuelle Benchmarks vor allem zeigen, ob ein Modell eine Aufgabe richtig beantwortet, schaut ARC-AGI-3 an einer viel unangenehmeren Stelle hin: Kann ein KI-System in einer völlig neuen Umgebung selbst herausfinden, was überhaupt zu tun ist?

Genau deshalb fand ich die aktuelle Analyse von ARC Prize zu GPT-5.5 und Anthropic Opus 4.7 so spannend. Die offiziellen Scores wirken auf den ersten Blick fast absurd niedrig: GPT-5.5 erreicht auf dem semi-privaten ARC-AGI-3-Set 0,43 Prozent, Opus 4.7 kommt auf 0,18 Prozent. Grundlage der qualitativen Analyse waren 160 Replays und Reasoning-Traces aus öffentlichen Runs, also nicht nur Endergebnisse, sondern tatsächliche Spielverläufe samt Modellbegründungen.

Das klingt nach einem vernichtenden Urteil über Frontier-Modelle. Aber ich glaube, genau hier lohnt sich ein zweiter Blick.

Denn die eigentliche Frage ist nicht nur: Wie schlecht schneiden LLMs bei ARC-AGI-3 ab?

Die interessantere Frage für mich lautet: Wie hart hat ARC Prize wirklich versucht, mit diesen LLMs möglichst weit zu kommen?

Meine Antwort nach der Lektüre: hart in der Analyse, aber bewusst nicht hart in der Optimierung.

Was ARC-AGI-3 eigentlich testet

ARC-AGI-3 besteht aus 135 neuartigen, von Menschen gestalteten interaktiven Umgebungen. Die Testperson – egal ob Mensch oder KI – bekommt keine Anleitung, sondern muss durch Ausprobieren herausfinden, welche Aktionen welche Effekte haben, welche Ziele gelten und welche Regeln von Level zu Level übertragen werden können.

Das ist ein wichtiger Unterschied zu klassischen Benchmarks. Hier geht es nicht darum, eine Frage zu beantworten, Code zu schreiben oder ein bekanntes Rätselmuster wiederzuerkennen. Es geht um Exploration, Hypothesenbildung, Korrektur falscher Annahmen, Planung und Lernen aus spärlichem Feedback. ARC Prize beschreibt genau diese Anforderungen: unbekannte Interfaces erkunden, Regeln aus wenig Feedback ableiten, Hypothesen testen, Irrtümer revidieren und Gelerntes auf spätere Level übertragen.

Das ist ziemlich nah an dem, was wir von echten Agenten erwarten würden. Ein Agent, der in einem Unternehmen mit internen Tools, Dashboards, Formularen, APIs und Workflows arbeiten soll, bekommt in der Realität auch nicht immer eine perfekte Bedienungsanleitung. Er muss erkennen, was wichtig ist, welche Aktionen möglich sind und welche Effekte sie haben.

Genau deshalb ist ARC-AGI-3 aus meiner Sicht so interessant: Es testet nicht nur Wissen, sondern adaptive Handlungsfähigkeit.

Die drei Fehlermuster: Sehen ist nicht Verstehen

Besonders spannend ist, dass ARC Prize nicht nur Scores veröffentlicht, sondern auch die Fehler analysiert. Dabei werden drei wiederkehrende Muster beschrieben:

Erstens: Die Modelle erkennen lokale Effekte, bauen daraus aber kein belastbares Weltmodell. Sie sehen beispielsweise, dass eine Aktion ein Objekt dreht, verstehen aber nicht, welche globale Regel dahintersteht und wie diese Regel strategisch genutzt werden müsste.

Zweitens: Die Modelle interpretieren neue Umgebungen zu stark durch bekannte Spielmuster. ARC Prize nennt unter anderem Analogien zu Tetris, Frogger, Sokoban, Breakout, Pong und anderen Spielen. Das Problem ist nicht, dass Analogien grundsätzlich schlecht wären. Das Problem ist, dass eine oberflächliche Ähnlichkeit zu einer falschen vollständigen Spieltheorie wird.

Drittens: Selbst wenn ein Level gelöst wird, bedeutet das nicht, dass das Modell das Spiel verstanden hat. ARC Prize beschreibt Beispiele, in denen ein Modell durch Zufall oder durch eine unvollständige Theorie ein erstes Level schafft, diese falsche Theorie dann aber in Level 2 fortschreibt und daran scheitert.

Das finde ich besonders aufschlussreich. Denn genau solche Fehler sehen wir auch bei LLM-Agenten außerhalb von Spielen: Sie machen etwas scheinbar richtig, aber aus dem falschen Grund. Und sobald sich der Kontext leicht verändert, bricht die Strategie zusammen.

Wie hart wurde es wirklich versucht?

Jetzt kommt der entscheidende Punkt.

Wenn man die offiziellen ARC-AGI-3-Scores liest, könnte man meinen: GPT-5.5 und Opus 4.7 können das schlicht nicht. Aber das wäre mir zu einfach.

Denn ARC Prize sagt sehr klar, dass die offiziellen Tests gerade nicht darauf ausgelegt sind, mit maximalem Prompt Engineering, spezialisierten Tools oder einem ausgefeilten Agenten-Harness den bestmöglichen Score herauszuholen.

In der offiziellen Testing Policy heißt es sinngemäß: Um faire Vergleiche zu ermöglichen und falsche AGI-Signale zu vermeiden, nutzt ARC Prize extrem generische minimale LLM-Testprompts, keine clientseitigen Harnesses, keine handgebauten Tools und keine individuell zugeschnittene Modellkonfiguration.

Auch der technische Report ist hier sehr deutlich. Für die offiziellen ARC-AGI-3-Scores sollen Systeme bewertet werden, die nicht speziell für ARC-AGI-3 vorbereitet wurden und hinter einer allgemeinen API laufen. Der offizielle Leaderboard-Score nutzt daher kein Harness. Die Modelle bekommen keine externen Tools, abgesehen von möglichen internen Tools, die hinter der Modell-API verborgen sind. Der Systemprompt ist minimal: „Du spielst ein Spiel. Dein Ziel ist zu gewinnen. Antworte mit der exakten Aktion …“

Mit anderen Worten: Die offiziellen Scores messen nicht, was ein Team aus Agenten-Entwickler:innen mit GPT-5.5 oder Opus 4.7 bauen könnte. Sie messen eher, was passiert, wenn man ein Frontier-Modell fast nackt in eine neue interaktive Umgebung wirft.

Das ist kein Bug des Benchmarks. Das ist die Designentscheidung.

Warum diese Designentscheidung sinnvoll ist

Ich halte diese Entscheidung für nachvollziehbar – auch wenn sie die Interpretation erschwert.

ARC Prize will nicht messen, wie viel menschliche Intelligenz in ein ARC-spezifisches System hineinentwickelt wurde. Sie wollen wissen, ob ein allgemeines KI-System beim Erstkontakt mit einer unbekannten Aufgabe selbstständig generalisieren kann. Der technische Report unterscheidet ausdrücklich zwischen task-spezifischem Overfitting, also Optimierung auf bekannte öffentliche Umgebungen, und domain-spezifischem Overfitting, also Strategien, die speziell auf ARC-AGI-3 als Domäne zugeschnitten sind.

Das ist wichtig. Denn sonst würden wir am Ende vor allem messen, wer den besten ARC-AGI-3-Solver gebaut hat – nicht, welches Modell allgemein intelligenter oder adaptiver ist.

Und genau hier entsteht die Spannung: Aus Sicht eines Benchmarks ist ein minimalistisches Setup sinnvoll. Aus Sicht praktischer Agentenentwicklung ist es aber fast künstlich schwach.

Denn in der Praxis würden wir ein LLM ja gerade nicht allein lassen.

Was ein gutes Harness verändern würde

Ein Harness ist vereinfacht gesagt das technische Gerüst um ein Modell herum. Es entscheidet, wie Beobachtungen aufbereitet werden, wie Erinnerungen gespeichert werden, welche Tools verfügbar sind, wie frühere Aktionen analysiert werden, wie Hypothesen verwaltet werden und wie Pläne überprüft werden.

Und genau da liegt meiner Meinung nach der Hebel.

Ein besseres Harness könnte etwa:

• visuelle Zustandsänderungen automatisch erkennen,
• Objekte über Frames hinweg tracken,
• Aktion-Effekt-Tabellen führen,
• Hypothesen explizit speichern und priorisieren,
• Experimente planen, statt zufällig zu klicken,
• erfolgreiche Level nachträglich kausal erklären,
• falsche Genre-Analogien unterdrücken,
• frühere Zustände gezielt abrufen,
• und nach jedem Reward prüfen, warum der Reward zustande kam.

Das ist nicht nur Prompting. Das ist Context Engineering im eigentlichen Sinne: Wahrnehmung, Gedächtnis, Tool-Nutzung, Kompression, Planung und Selbstkorrektur werden so gestaltet, dass das Modell überhaupt eine Chance hat, über viele Schritte hinweg konsistent zu handeln.

Und ARC Prize liefert selbst Hinweise darauf, dass Harnesses sehr wohl viel bringen können.

Im technischen Report wird beschrieben, dass Opus 4.6 in einer TR87-Variante ohne Harness 0,0 Prozent erreichte, mit dem Duke-Harness aber 97,1 Prozent. In einer anderen Umgebung, BP35, blieb dasselbe Modell allerdings sowohl mit als auch ohne Harness bei 0,0 Prozent. ARC Prize interpretiert das als Beleg dafür, dass Wahrnehmung und API-Format nicht grundsätzlich der limitierende Faktor sind, spezifisch gebaute Harnesses aber oft schlecht auf neue Umgebungen generalisieren.

Genau das ist der springende Punkt: Ein Harness kann massiv helfen. Aber sobald es zu stark auf bekannte Aufgaben oder eine bestimmte Benchmark-Logik zugeschnitten ist, misst der Score nicht mehr nur Modellfähigkeit, sondern auch die Ingenieursleistung im Gerüst.

Die wirklich spannende Frage: generisches Harness statt ARC-Tricks

Für mich ist deshalb nicht die Frage, ob man ARC-AGI-3 mit genug Tricks besser lösen kann. Natürlich kann man das.

Die spannende Frage lautet: Wie weit kommt ein vorab eingefrorenes, wirklich generisches Agenten-Harness auf ungesehenen ARC-AGI-3-Umgebungen?

Also kein System, das ARC-spezifische Strategien einprogrammiert bekommt. Keine manuell optimierten Prompts für einzelne Spiele. Kein Zugriff auf öffentliche Lösungen. Sondern ein allgemeines Agenten-Gerüst mit Werkzeugen, die auch in anderen Domänen sinnvoll wären:

Frame-Differencing. State-Tracking. Hypothesenmanagement. Kurz- und Langzeitgedächtnis. Explorationsplanung. Tool-Nutzung. Selbstkritik. Kausale Tests.

Das wäre aus meiner Sicht der eigentlich relevante nächste Schritt.

Interessanterweise erkennt ARC Prize den Wert solcher Harness-Forschung durchaus an. Der technische Report führt eine Community-Leaderboard-Kategorie für harness-getriebene Ergebnisse ein, warnt aber zugleich davor, solche Scores direkt als AGI-Fortschritt zu interpretieren.

Auch die frühen Experimente zeigen, wohin die Reise gehen könnte. In der Preview Agent Competition erreichte StochasticGoose von Tufa Labs 12,58 Prozent mit einem CNN- und Reinforcement-Learning-Ansatz zur Vorhersage frame-verändernder Aktionen; Blind Squirrel kam mit einem gerichteten State-Graphen auf 6,71 Prozent. Beide erfolgreichen Ansätze nutzten im Kern informierte Suche im Aktionsraum.

Dazu kommen agentische Harness-Ansätze wie das Duke-System, das einem Large Reasoning Model erlaubt, Python-Code auszuführen, um gezielt frühere Zustände aus der Aktionshistorie abzurufen und zu transformieren. In den öffentlichen Umgebungen löste dieser Ansatz alle drei Aufgaben mit menschenähnlicher Aktionseffizienz. Symbolica AIs Arcgentica wiederum arbeitet mit einer Orchestrator-Subagenten-Architektur und komprimierten Textzusammenfassungen, um Kontextwachstum zu begrenzen und trotzdem einen übergeordneten Plan zu halten.

Das sind für mich keine Nebendetails. Das ist der eigentliche Forschungsraum.

Prompting hilft – aber es reicht wahrscheinlich nicht

Natürlich könnte man auch mit besseren Prompts mehr herausholen.

Man könnte das Modell anweisen, Beobachtung, Hypothese und Plan strikt zu trennen. Man könnte verlangen, dass jede Aktion als Experiment verstanden wird. Man könnte falsche Genre-Analogien aktiv sanktionieren: „Nenne keine bekannten Spiele, solange keine kausale Evidenz dafür vorliegt.“ Man könnte nach jedem Erfolg eine Reflexionsphase erzwingen: „Welche Regel erklärt den Erfolg minimal und generalisiert auf das nächste Level?“

Das würde vermutlich helfen.

Aber ich glaube nicht, dass Prompting allein das Kernproblem löst. Denn viele Fehler entstehen nicht nur durch falsche Instruktion, sondern durch fehlende externe Struktur. LLMs sind stark darin, Muster sprachlich zu formulieren. Aber in langen interaktiven Umgebungen brauchen sie ein Gedächtnis, eine saubere Zustandsrepräsentation und eine robuste Methode, um Hypothesen gegen Beobachtungen zu testen.

Auch die ARC-Dokumentation zeigt übrigens sehr schön, wo die Grenze liegt. Es gibt dort ein „GuidedLLM“-Template mit expliziten spiel-spezifischen Regeln und Strategien im Prompt. Die Dokumentation weist aber selbst darauf hin, dass dieses Template zu Bildungszwecken gedacht ist und nicht auf andere Spiele generalisiert.

Das ist genau der Unterschied zwischen cleverem Prompt und allgemeiner Intelligenz.

Meine Einordnung

Die niedrigen Scores von GPT-5.5 und Opus 4.7 bei ARC-AGI-3 beweisen nicht, dass LLM-basierte Agentensysteme grundsätzlich chancenlos sind.

Sie beweisen eher etwas Präziseres und Spannenderes:

Nackte Frontier-LLMs sind beim Erstkontakt mit neuartigen, interaktiven, nichtsprachlich erklärten Umgebungen noch extrem schwach.

Das ist eine wichtige Aussage. Aber sie ist nicht identisch mit: „Mit Tools, Memory, Search, Perception und gutem Harness geht da nicht viel mehr.“

Im Gegenteil: Die bisher veröffentlichten Harness-Ergebnisse legen nahe, dass sehr viel mehr möglich ist – allerdings oft auf Kosten der Generalität. Ein System kann auf bekannten oder ähnlichen Umgebungen stark werden, ohne wirklich allgemein adaptiv zu sein.

Für mich liegt genau hier die Grenze zwischen Benchmarking und Produktentwicklung.

Ein Benchmark wie ARC-AGI-3 muss überfitting-resistent sein. Er muss verhindern, dass wir menschliche Vorarbeit im Harness fälschlich als Modellintelligenz feiern.

Ein praktisches Agentensystem hingegen sollte natürlich jede sinnvolle Hilfe nutzen. In realen Anwendungen interessiert mich selten, ob die Intelligenz „pur“ im Modell sitzt oder teilweise im Workflow, im Tooling, in der Memory-Schicht oder in der Systemarchitektur. Mich interessiert, ob das Gesamtsystem zuverlässig, nachvollziehbar und robust handelt.

Aber für die Forschung ist diese Unterscheidung entscheidend.

Fazit: Nicht das Ende der LLMs, sondern das Ende der Illusion vom nackten Agenten

ARC-AGI-3 zeigt für mich nicht, dass moderne LLMs nutzlos sind. Es zeigt, dass wir sie nicht mit echter autonomer Anpassungsfähigkeit verwechseln sollten.

Ein Modell, das hervorragend schreibt, codet, erklärt und bekannte Muster kombiniert, ist noch lange kein Agent, der in einer fremden Welt selbstständig stabile Regeln entdeckt, falsche Theorien verwirft und sein Verhalten effizient anpasst.

Gleichzeitig wäre es unfair, aus den offiziellen ARC-AGI-3-Scores ein hartes Limit für LLM-basierte Systeme abzuleiten. Denn die offiziellen Tests verzichten bewusst auf genau die Komponenten, die heutige Agentensysteme in der Praxis leistungsfähiger machen: Tools, Speicher, strukturierte Wahrnehmung, Suchverfahren, Reflexion und Kontextmanagement.

Die für mich spannendste nächste Messung wäre deshalb ein eingefrorenes, nicht ARC-spezifisches Agenten-Harness auf privaten ARC-AGI-3-Umgebungen.

Nicht: Wie gut kann ein Mensch ARC-AGI-3 für ein Modell lösen?

Sondern: Wie gut kann ein generisches KI-Agentensystem neue Regeln entdecken, wenn es dieselben Werkzeuge nutzen darf, die wir auch in echten Anwendungen brauchen?

AFAIK: Genau dort wird es interessant. Nicht beim nächsten Prozentpunkt auf einem Leaderboard, sondern bei der Frage, ob wir aus starken Sprachmodellen robuste, adaptive Handlungssysteme bauen können – ohne jedes neue Problem vorher für sie zu präparieren.

Es gibt Sätze, die beruhigen, weil sie nicht ganz falsch sind.

KI ersetzt keine Menschen, sondern nur Tätigkeiten.

Das klingt vernünftig. Es ist differenziert. Es nimmt der Debatte etwas von der Panik. Und in vielen Fällen stimmt es auch.

Das Problem ist nur: Manche Jobs bestehen zu einem sehr großen Teil aus genau den Tätigkeiten, die automatisiert werden.

Dann ersetzt die Maschine nicht abstrakt „den Menschen“. Sie ersetzt auch nicht sofort eine ganze Branche. Sie ersetzt eine wiederholbare Funktion. Einen Ablauf. Eine Schnittstelle. Einen Routineteil.

Aber wenn ein Beruf historisch vor allem daraus bestand, dann verschwindet am Ende nicht nur eine Tätigkeit.

Dann verschwindet ein Job.

Der Aufzug war nicht menschenfeindlich

Früher brauchte man im Aufzug einen Menschen.

Nicht, weil Menschen gerne in kleinen Kabinen neben anderen Menschen standen. Sondern weil Aufzüge bedient werden mussten. Türen schließen, Hebel bewegen, sauber auf Etagenhöhe halten, Passagiere beruhigen, Fehler vermeiden. Das war keine Dekoration. Das war Arbeit.

Ein guter Aufzugsführer hatte Gefühl für die Maschine. Er musste den Wagen so steuern, dass niemand erschrak, stolperte oder zwischen zwei Stockwerken hängenblieb. Das Museum of American Heritage beschreibt, dass dafür durchaus Geschick nötig war; Anfang der 1950er waren Aufzugsführer in den USA noch verbreitet, zu Beginn der 1960er aber weitgehend durch Elektronik, günstigere Automatisierung und Druckknöpfe verdrängt. (Museum of American Heritage)

Das Interessante daran ist nicht, dass ein Knopf einen Menschen „intelligenter“ gemacht hätte.

Der Knopf hat nur eine Schnittstelle verändert.

Vorher war der Mensch die Bedienoberfläche der Maschine. Danach war es das Bedienfeld.

Und genau das ist eine der wichtigsten historischen Lektionen für KI.

Manche Berufe sind keine ewigen Berufungen. Manche Berufe sind Übergangslösungen, bis eine Maschine direkt genug, billig genug, zuverlässig genug oder akzeptiert genug ist.

„Computer“ waren früher Menschen

Das vielleicht schönste Beispiel ist gleichzeitig das naheliegendste.

Computer waren früher keine Geräte. Computer waren Menschen.

Bei NASA und ihren Vorgängerorganisationen arbeiteten ganze Gruppen menschlicher „Computer“, häufig Frauen, die komplexe mathematische Berechnungen durchführten. Bei JPL waren sie unter anderem für Berechnungen zu Startfenstern, Flugbahnen, Treibstoffverbrauch und anderen Details des Raumfahrtprogramms zuständig; viele wurden später selbst zu frühen Programmiererinnen bei NASA. (NASA)

Das ist als historische Analogie zu KI deshalb so stark, weil hier nicht Muskelkraft ersetzt wurde.

Sondern Denkarbeit.

Nicht Kreativität im romantischen Sinn. Nicht Urteilskraft im letzten Sinn. Aber sehr anspruchsvolle, strukturierte, formalisierbare geistige Arbeit.

Also genau das, was wir uns lange als ziemlich sicheren Bereich vorgestellt haben.

Die menschlichen Computer waren nicht überflüssig, weil sie unwichtig waren. Im Gegenteil. Sie waren wichtig genug, dass man ihre Arbeit beschleunigen, standardisieren und skalieren wollte.

Das ist oft der eigentliche Grund für Automatisierung.

Nicht: Diese Arbeit ist wertlos.

Sondern: Diese Arbeit ist wertvoll genug, um sie einer Maschine beizubringen.

Manche Jobs sind Schnittstellen

Ein weiteres Beispiel sind Telefonistinnen.

Heute wirkt es fast absurd, dass ein Telefongespräch einmal ein menschliches Vermittlungssystem brauchte. Man hob den Hörer ab, sagte, wen man sprechen wollte, und irgendwo verband ein Mensch zwei Leitungen.

Das war ein Beruf. Und zwar kein exotischer. Anfang des 20. Jahrhunderts gehörte Telefonvermittlung in den USA zu den häufigsten Jobs für Frauen. Zwischen 1920 und 1940 ersetzte AT&T in mehr als der Hälfte seines US-Netzes menschliche Vermittlung durch mechanische Schaltsysteme. Eine NBER-Studie kommt zu dem Ergebnis, dass diese Automatisierung die meisten Operatorinnen-Jobs eliminierte; viele betroffene Frauen waren zehn Jahre später in schlechter bezahlten Berufen oder gar nicht mehr erwerbstätig. (NBER)

Auch hier wurde nicht „Kommunikation“ ersetzt.

Menschen telefonierten danach nicht weniger, sondern mehr. Das Kommunikationssystem wurde größer, schneller und billiger.

Aber die menschliche Zwischenschicht verschwand.

Das ist ein Muster, das wir bei KI sehr genau anschauen sollten.

Wenn ein Job vor allem darin besteht, zwischen Nutzer und System zu vermitteln, ist er gefährdet, sobald Nutzer direkt mit dem System sprechen können.

Das muss nicht sofort passieren. Und nicht überall. Menschen vertrauen neuen Schnittstellen nicht über Nacht. Prozesse müssen umgebaut werden. Haftung muss geklärt werden. Qualität muss messbar sein.

Aber sobald die direkte Schnittstelle gut genug ist, wird die menschliche Schnittstelle erklärungsbedürftig.

Nicht unmöglich.

Aber erklärungsbedürftig.

Manche Jobs sind Umsetzungsmaschinen

Dann gibt es Berufe, die vor allem aus Umsetzung bestehen.

Nicht aus Entscheidung. Nicht aus Verantwortung. Nicht aus Strategie.

Sondern aus der Transformation von Input in Output.

Ein Text soll vervielfältigt werden.
Eine Vorlage soll gesetzt werden.
Eine Rechnung soll berechnet werden.
Eine Anfrage soll beantwortet werden.
Eine Aufnahme soll transkribiert werden.
Ein Dokument soll zusammengefasst werden.
Ein Produkt soll in fünf Varianten beschrieben werden.

Historisch waren Kopisten genau so eine Zwischenschicht. Vor dem Buchdruck wurden Texte professionell abgeschrieben. Mit Gutenbergs beweglichen Lettern und der schnellen Verbreitung des Drucks konnten Drucker den vertrauten Look von Manuskripten in einem Bruchteil der Zeit und zu geringeren Kosten reproduzieren; professionelle Manuskriptkopie ging bis zum Ende des 16. Jahrhunderts stark zurück. (Cornell Library Exhibits)

Später passierte etwas Ähnliches im Druck selbst.

Die Linotype war einmal eine revolutionäre Maschine. Sie automatisierte den Handsatz und prägte die Zeitungsproduktion über Jahrzehnte. Dann wurde auch sie durch neue Verfahren verdrängt. Als die New York Times 1978 auf elektronische und fotografische Verfahren umstellte, wurden die letzten 61 Linotype-Maschinen ersetzt. (The Library of Congress)

Das ist wichtig, weil es zeigt: Auch die Maschine von gestern kann der Mensch von vorgestern sein.

Technologie ersetzt nicht nur Handarbeit. Sie ersetzt auch frühere Technologien. Und mit ihnen die Berufe, die um diese Technologien herum entstanden sind.

Das Auto ersetzte nicht die Kutsche

Das beliebte Beispiel lautet oft: Das Auto hat die Kutschenbetriebe ersetzt.

Das stimmt so halb.

Eigentlich hat das Auto zuerst das Pferd ersetzt.

Und das ist mehr als eine Pointe.

Denn wenn das Pferd als Antriebstechnologie verschwindet, verschwindet nicht nur ein Tier aus dem Straßenbild. Dann geraten Hufschmiede, Stallknechte, Sattler, Futterlieferanten, Fuhrbetriebe, Kutscher und ganze städtische Infrastrukturen unter Druck. Der Ökonom David Autor beschreibt genau dieses Muster: Das massenproduzierte Automobil reduzierte die Nachfrage nach vielen pferdebezogenen Berufen drastisch, etwa nach Hufschmieden und Stallpersonal. (economics.mit.edu)

Das Auto hat also nicht einfach einen Job ersetzt.

Es hat eine zentrale Funktion ersetzt: Antrieb.

Und um diese Funktion herum hing ein ganzer Berufsverbund.

Bei KI ist die zentrale Funktion nicht Muskelkraft.

Es ist routinisierbare Informationsarbeit.

Text hinein, Text heraus.
Frage hinein, Antwort heraus.
Sprache hinein, Transkript heraus.
Daten hinein, Zusammenfassung heraus.
Briefing hinein, Entwurf heraus.
Regel hinein, Entscheidungsvorschlag heraus.

Solange diese Funktion nur ein kleiner Teil eines Berufs ist, verändert KI den Job.

Wenn diese Funktion aber der Kern des Berufs ist, kann KI den Job ersetzen.

Die beruhigende Formel ist zu bequem

Deshalb ist die Formel „KI ersetzt keine Jobs, sondern Tätigkeiten“ zu bequem.

Sie stimmt auf der Ebene der Tätigkeitsanalyse.

Aber sie unterschlägt die nächste Frage:

Wie viel vom Job besteht aus dieser Tätigkeit?

Wenn 10 Prozent eines Berufs automatisierbar sind, entsteht ein Produktivitätswerkzeug.

Wenn 40 Prozent automatisierbar sind, entsteht ein Umbauproblem.

Wenn 80 Prozent automatisierbar sind, entsteht eine Existenzfrage.

Das heißt nicht, dass morgen alle Menschen in diesen Rollen verschwinden. So funktionieren technologische Umbrüche fast nie. Es gibt Übergänge, Ausnahmen, Nischen, Regulierung, Kundenpräferenzen, Haftungsfragen und Qualitätsprobleme.

Aber historisch ist die Richtung trotzdem deutlich.

Zuerst wird eine Tätigkeit maschinell möglich.
Dann wird sie billig.
Dann wird sie gut genug.
Dann wird sie erwartet.
Dann wird der Mensch in dieser Tätigkeit zum Sonderfall.

Nicht immer.

Aber oft genug.

KI ist anders, weil sie keine einzelne Maschine ist

Der Webstuhl automatisierte Weben.

Der automatische Aufzug automatisierte Aufzugbedienung.

Die Telefonvermittlung automatisierte Verbindungsarbeit.

Die Rechenmaschine automatisierte Rechnen.

KI ist schwieriger zu greifen, weil sie nicht nur eine Maschine für eine Tätigkeit ist.

Sie ist eher eine Schicht, die sich über viele Informationsprozesse legt.

Deshalb wirkt sie gleichzeitig überschätzt und unterschätzt.

Überschätzt, weil viele Ergebnisse nur plausibel aussehen und bei genauer Prüfung Lücken haben.

Unterschätzt, weil sehr viele Jobs erstaunlich viele Tätigkeiten enthalten, bei denen „plausibel, schnell und zu 80 Prozent richtig“ wirtschaftlich schon ausreicht.

Genau hier liegt die Unbequemlichkeit.

In vielen Debatten wird so getan, als gehe es um perfekte Ersetzung.

Kann KI einen Top-Juristen ersetzen?
Kann KI eine erfahrene Ärztin ersetzen?
Kann KI einen sehr guten Softwarearchitekten ersetzen?
Kann KI eine strategische Marketingleiterin ersetzen?

Das sind interessante Fragen.

Aber sie lenken ab.

Denn viele Umbrüche beginnen nicht oben. Sie beginnen bei Routine, Vorarbeit, Standardfällen, Varianten, Recherche, Formatierung, Zusammenfassung, Transkription, Klassifikation und Erstentwürfen.

Also bei all dem, was in Organisationen viel Zeit frisst, aber selten im Organigramm glänzt.

Es wird nicht alle treffen. Aber es trifft echte Jobs.

Die Internationale Arbeitsorganisation kommt in ihrer Analyse zu dem Ergebnis, dass generative KI global eher Tätigkeiten ergänzt als ganze Berufe vollständig automatisiert. Gleichzeitig sieht sie die höchste Exposition bei Büro- und Verwaltungstätigkeiten, wo besonders viele Aufgaben mittel oder stark betroffen sind. (International Labour Organization)

Das klingt beruhigend.

Ist es aber nur teilweise.

Denn „eher Ergänzung als vollständige Automatisierung“ heißt nicht: keine Jobverluste.

Es heißt: Die meisten Berufe werden umgebaut. Einige werden aufgewertet. Einige werden entwertet. Einige werden kleiner. Und manche verschwinden in ihrer bisherigen Form.

Auch das US Bureau of Labor Statistics erwartet, dass KI und generative KI die Nachfrage in verschiedenen Bereichen dämpfen, unter anderem in Vertrieb, Design und administrativer Unterstützung. Genannt werden dort etwa Übersetzer, technische Redakteure, medizinische Sekretariate, Customer-Service-Rollen, nichtmedizinische Assistenzen, Paralegals und Claims Adjusters als Berufe, bei denen KI Effizienzgewinne erzeugt und Beschäftigungswachstum begrenzen oder Rückgänge verstärken kann. (Bureau of Labor Statistics)

Das ist der nüchterne Punkt.

Nicht: Alle Arbeit verschwindet.

Sondern: Bestimmte Arbeit verschwindet aus bestimmten Stellenprofilen.

Und wenn ein Stellenprofil um diese Arbeit herum gebaut war, verschwindet das Profil.

Die eigentliche Frage ist nicht: Wird KI Jobs ersetzen?

Die eigentliche Frage lautet:

Welche Jobs sind eigentlich nur historische Verpackungen für automatisierbare Tätigkeiten?

Das klingt hart. Aber es ist präziser.

Ein Aufzugsführer war nicht „nur“ ein Knopf.
Eine Telefonistin war nicht „nur“ ein Schalter.
Eine Rechnerin war nicht „nur“ eine Rechenmaschine.
Ein Schriftsetzer war nicht „nur“ ein Layoutalgorithmus.
Ein Kopist war nicht „nur“ ein Kopierer.

Jeder dieser Berufe hatte Würde, Erfahrung, Routinen, Stolz und soziale Bedeutung.

Aber die zentrale Marktleistung wurde automatisierbar.

Und sobald das passierte, half es wenig, darauf hinzuweisen, dass der Mensch mehr war als seine Tätigkeit.

Denn der Markt bezahlte vor allem für die Tätigkeit.

Das ist brutal.

Aber genau deshalb sollte man es nicht beschönigen.

Wo Menschen wichtiger werden

Die andere Seite gehört aber genauso dazu.

Automatisierung ersetzt nicht nur. Sie ergänzt auch. Sie macht manche Arbeit wertvoller, weil die maschinell erzeugten Zwischenschritte billiger werden.

Wenn Rechnen billig wird, werden Modellierung, Interpretation und Entscheidung wichtiger.

Wenn Textproduktion billig wird, werden Positionierung, Fachurteil, Quellenkritik und Verantwortung wichtiger.

Wenn Designvarianten billig werden, werden Geschmack, Kontext, Marke und Auswahl wichtiger.

Wenn Code schneller entsteht, werden Architektur, Sicherheit, Tests, Produktverständnis und Wartbarkeit wichtiger.

Wenn Supportantworten automatisch entstehen, werden Eskalation, Empathie, Kulanz und echte Problemlösung wichtiger.

Das ist kein Widerspruch.

Das ist genau das Muster.

Die Maschine frisst den standardisierbaren Teil.

Der Mensch bleibt dort stark, wo das Problem unscharf ist, Verantwortung trägt, soziale Bedeutung hat oder in einem komplexen System richtig eingeordnet werden muss.

Aber auch das ist keine Garantie für jeden bestehenden Job.

Es ist eher eine Aufforderung, den eigenen Wert nicht mit der Tätigkeit zu verwechseln, die gerade automatisiert wird.

Der Fehler ist, den Übergang mit dem Endzustand zu verwechseln

Bei jeder neuen Technologie gibt es eine Phase, in der man sie leicht unterschätzen kann.

Automatische Aufzüge wirkten zunächst unheimlich.
Telefonvermittlung ohne Menschen wirkte ungewohnt.
Elektronische Computer waren teuer, groß und begrenzt.
KI macht Fehler, halluziniert, missversteht, glättet, erfindet und wirkt oft sicherer, als sie ist.

Daraus entsteht eine tröstliche Beobachtung:

„Siehst du, es geht doch nicht ohne Menschen.“

Stimmt.

Heute.

In vielen Fällen.

Aber die Geschichte zeigt: Der Anfangszustand einer Technologie ist selten ihr Endzustand.

Die ersten Autos waren keine guten Pferde.
Die ersten Drucke waren keine perfekten Manuskripte.
Die ersten Computer waren keine universellen Alleskönner.
Die ersten automatischen Aufzüge mussten erst Vertrauen gewinnen.

Der entscheidende Moment kommt nicht, wenn die Maschine perfekt ist.

Er kommt, wenn sie für genügend Anwendungsfälle gut genug ist.

Und wenn Organisationen ihre Prozesse so umbauen, dass die Maschine nicht mehr wie ein schlechter Mensch arbeiten muss, sondern wie eine Maschine arbeiten darf.

Nicht Panik. Aber Ehrlichkeit.

Es wäre falsch, aus der Geschichte eine einfache Untergangserzählung zu machen.

Technologische Umbrüche vernichten nicht nur Arbeit. Sie schaffen auch neue Arbeit. Das World Economic Forum erwartet bis 2030 weltweit zwar erhebliche Verdrängung, aber zugleich auch viele neue Rollen; konkret nennt es 170 Millionen neu entstehende und 92 Millionen verdrängte Jobs, also netto 78 Millionen zusätzliche Beschäftigungsmöglichkeiten. (World Economic Forum)

Aber solche Nettobetrachtungen trösten nur auf Folien.

Für den einzelnen Menschen ist es egal, ob irgendwo anders ein neuer Job entsteht, wenn der eigene verschwindet.

Für Unternehmen ist es egal, ob „der Arbeitsmarkt“ langfristig neue Rollen schafft, wenn kurzfristig ganze Tätigkeitsketten neu kalkuliert werden.

Und für die Gesellschaft ist es gefährlich, Menschen mit semantischen Beruhigungspillen abzuspeisen.

KI ersetzt nicht alle Jobs.

KI ersetzt auch nicht einfach „den Menschen“.

Aber KI ersetzt sehr wohl bestimmte Tätigkeiten so stark, dass manche Jobs in ihrer heutigen Form verschwinden werden.

Weitere werden kleiner.

Viele werden umgebaut.

Und einige werden wertvoller, weil Menschen mit KI plötzlich mehr leisten können als vorher.

Das ist kein Grund für Panik.

Aber es ist ein Grund für Ehrlichkeit.

Denn der Satz „KI ersetzt keine Jobs, sondern Tätigkeiten“ ist nur dann hilfreich, wenn man den zweiten Teil dazusagt:

Manche Jobs bestehen fast vollständig aus diesen Tätigkeiten.

Und genau dort wird es ernst.

Wenn Google-Mitarbeiter:innen einen ganzen Tag lang vor einem Publikum aus SEOs stehen, lohnt es sich, sehr genau zuzuhören. Am 21. April 2026 war es wieder so weit: In Toronto fand das erste Google Search Central Live auf kanadischem Boden statt. Fünf Vorträge, ein Panel, viele Folien – und am Ende eine ziemlich klare Botschaft: KI verändert die Suche, aber sie macht das klassische SEO-Handwerk nicht überflüssig. Sie erhöht eher die Messlatte.

Der kanadische SEO Jean-Christophe Chouinard war vor Ort, hat die Slides fotografiert und sie in seinem Blog dokumentiert. Auf Basis dieser Dokumentation ordne ich hier die wichtigsten Aussagen der fünf Sessions ein – und leite daraus ab, was für die tägliche SEO-Arbeit relevant ist.

Die Vortragenden:

• Martin Splitt (Search Advocate) – „How Search Works“
• Danny Sullivan (Director, Google Search) – „AI in Google Search“
• Annanya Raghavan (Trends Analyst) – „Telling Stories with Google Trends“
• Daniel Waisberg (Search Advocate) – „New in Search Console & Trends“
• Ryan Levering (Search Engineering) – „Structured Data, Quality & AI“

Die wichtigsten Takeaways auf einen Blick

Bevor wir in die einzelnen Sessions einsteigen, die verdichtete Version für alle, die es eilig haben:

1. Indexierung ist kein Selbstläufer mehr. Weil KI Content-Produktion trivialisiert hat, hebt Google die Qualitätsschwelle dafür an, was überhaupt indexiert wird. „Crawled – currently not indexed“ ist selten ein Rendering-Problem.
2. Gutes SEO ist gutes „GEO“. Die neuen Akronyme (GEO, AEO, LLM SEO, AI SEO) ändern wenig an den Grundlagen. Für AI Overviews und AI Mode gelten dieselben Prinzipien wie für die klassische Suche.
3. Fan-out ist der Schlüssel, um AI Search zu verstehen. Eine einzelne Query wird in viele Teil-Queries zerlegt, die parallel Quellen aus Web, Shopping, Knowledge Graph, Wetter und Finance einsammeln.
4. Google Trends wird erwachsen. Eine neue API (Alpha), konsistente Skalierung, neue Zeitauflösungen und Gemini-Integration machen Trends vom Keyword-Tool zum Narrativ-Werkzeug.
5. Search Console wird assistiver. Query Groups bündeln ähnliche Anfragen, eine AI-powered Configuration übersetzt natürliche Sprache in Filter – GSC-Analysen sollen zugänglicher werden.
6. Strukturierte Daten sind nicht tot – sie werden wichtiger. Vor allem im E-Commerce: Shipping, Loyalty, Produktvarianten, Cross-Page-@id-Verknüpfungen.
7. KI-generierter Content ist nicht per se das Problem. Das Problem heißt Scaled Content Abuse: massenhaft ähnliche Seiten ohne Mehrwert.

Jetzt im Detail.

---

1. Martin Splitt: How Search Works

Martin Splitt hatte den undankbaren, aber wichtigen Job des Grundlagen-Vortrags. Seine Folien waren eine Erinnerung daran, dass viele SEO-Fragen leichter werden, wenn man das Modell dahinter wirklich verstanden hat.

Das Life-of-a-URL-Modell

Splitt zerlegte den Weg einer URL in vier Zustände:

1. Discovered – Google weiß, dass die URL existiert (über Links oder Sitemap).
2. Crawled – Googlebot hat die URL abgerufen.
3. Indexed – die URL wurde verarbeitet und in den Index aufgenommen.
4. Serving – die URL erscheint in den Ergebnissen, wenn sie für eine Query ein guter Kandidat ist.

Der Punkt: Jeder dieser Schritte kann scheitern. URLs sind schwer zu entdecken, Crawling dauert oder wird durch robots.txt verhindert, Indexing kann eine andere Canonical-URL wählen, URLs können wieder aus dem Index fallen, andere URLs können für dieselbe Query bessere Kandidaten sein – und die Suchnachfrage selbst verändert sich.

Das mündet in einen Satz, der auf einer eigenen Folie prangte: „Google won’t index everything at all times.“ Das ist kein Bug, das ist Feature. Und es ist die Grundlage für den nächsten wichtigen Gedanken.

Unterschiedliche Signale für unterschiedliche Inhalte

Google nutzt hunderte Signale, aber nicht für alles dieselben. Splitt zeigte:

• Webseiten: Text, Links, Passagen
• Bilder: Auflösung, Farbe, umliegender Text
• News: Frische, Originalität, Diversität
• Local: Standort, Typ, Bewertung, Öffnungszeiten
• Videos: Sprache, Transkripte

Für SEO heißt das: Wer auf Image Search zielt, optimiert anders als für News oder lokale Suche. Eine vertikalübergreifende Einheits-SEO-Checkliste gibt es nicht.

Search ist ein Experimentiersystem

Eine Zahl aus der Session, die hängenbleibt: 719.000 Search-Quality-Tests und mehr als 4.700 Launches allein im Jahr 2023. Wer also denkt, zwischen zwei Core Updates sei „nichts los“, irrt – es ist eher so, dass laufend Kleinigkeiten angepasst werden, die in Summe sichtbar werden.

---

2. Danny Sullivan: AI in Google Search

Danny Sullivan hatte die Aufgabe, das Thema zu besprechen, das alle umtreibt: AI Overviews, AI Mode, Fan-outs, Agentic Search. Seine Kernbotschaft war zugleich beruhigend und unbequem.

„Good SEO is good GEO“

Sullivan fasste eine Folie mit den Akronymen GEO, LLM SEO, AEO – und einem ironischen „Let’s go back to the basics“ – in einem Satz zusammen, der in den kommenden Monaten noch oft zitiert werden dürfte: Gute SEO ist gute „GEO“ (oder AEO, oder AI SEO, oder LLMNOPEO). Die Suchoberfläche ändert sich, die zugrunde liegenden Qualitätsprinzipien nicht.

Wie Fan-out wirklich funktioniert

Sullivan erklärte AI Search als Kombination aus drei Informationsquellen:

1. Allgemeines Modellwissen aus dem Training.
2. Spezifisches Wissen aus klassischen Suchergebnissen.
3. Fan-out – die ursprüngliche Query wird in verwandte Sub-Queries zerlegt.

Das Beispiel aus den Folien: Aus „ebikes in red for 5 mile commute with hills“ werden intern Queries wie „best ebikes“, „ebikes for hills“ und „red ebikes“. Diese Sub-Queries ziehen parallel Informationen aus unterschiedlichen Vertikalen: Shopping, Knowledge Graph, Real World, Web, Sport, Weather, Finance.

Die praktische Konsequenz: Sichtbarkeit in AI Search entsteht nicht nur über eine optimierte Haupt-Query. Man muss in all den Teilfragen präsent sein, die eine komplexe Nutzerfrage implizit enthält.

Commodity vs. Non-Commodity Content

Die vielleicht pragmatischste Folie der ganzen Veranstaltung war Sullivans Gegenüberstellung von austauschbarem und nicht-austauschbarem Content. Drei Beispiele aus seiner Präsentation:

• Laufschuh-Händler: „Top 10 Dinge beim Kauf von Laufschuhen“ (Commodity) vs. eine Analyse, warum die Schuhe eines konkreten Kunden nach 400 Meilen kollabiert sind, inklusive Laufmuster (Non-Commodity).
• Immobilienmakler: generische Erstkäufer-Tipps (Commodity) vs. ein konkreter Fall, in dem eine übersprungene Inspektion 15.000 Dollar gespart hat, mit Blick in die Abwasserleitung (Non-Commodity).
• Innenarchitektin: generische Küchentrends mit Pinterest-Bildern (Commodity) vs. ein Experiment, warum Marmor für eine fünfköpfige Familie ungeeignet war – mit Fleckentests von Traubensaft und Kurkuma (Non-Commodity).

Was guten Non-Commodity-Content auszeichnet: Unique, Specific, Authentic. Eigene Perspektive. Konkreter Fall. First-Hand-Erfahrung. Das ist genau der Content, den ein LLM nicht synthetisieren kann, weil er schlicht noch nicht im Trainingsdatensatz existiert.

Mythbusting: Was ihr NICHT tun müsst

Sullivan machte auf mehreren Folien mit typischen Missverständnissen auf:

• Kein „Chunking“ für KI. Baut euren Content für menschliche Leser:innen auf, nicht für hypothetische LLM-Parser.
• H1/H2-Header müssen nicht KI-präzise sein. Sie sind für Menschen da.
• Keine „Conversational Keywords“ auf Vorrat. Googles Sprachverständnis erkennt Synonyme und Beziehungen.
• JavaScript ist okay, solange Google es wie ein Mensch ausführen kann.
• Keine Website nach Markdown migrieren. Laut Notizen kein SEO- oder LLM-Vorteil.
• Keine llms.txt anlegen. Laut Notizen ebenfalls kein SEO-Nutzen.

Und zum Dauerbrenner KI-Content: Generative KI ist für Recherche und Strukturierung in Ordnung. Problematisch wird es bei Scaled Content Abuse – massenhaft publizierte Seiten ohne eigenen Mehrwert. Googles Spam Policies zielen genau darauf, nicht auf KI als Werkzeug an sich.

Agentic Search – vor allem Commerce

Ein spannender, aber klar begrenzter Teil war der Ausblick auf agentische Features:

• Business Agent: Händler:innen in den USA können im Merchant Center einen gebrandeten Agent aktivieren, mit dem Käufer:innen direkt in Google Search chatten können.
• Universal Commerce Protocol (UCP): Soll eine neue Checkout-Funktion in AI Mode und der Gemini-App antreiben.

Die ehrliche Einordnung aus den Notizen: Jenseits von Commerce und UCP waren nicht viele konkrete neue Chancen sichtbar. Wer also kein E-Commerce-Business betreibt, darf Agentic Search vorerst beobachten statt hyperventilieren.

Messen, nicht zählen

Sullivan wies darauf hin, dass Nutzer:innen, die aus AI Overviews auf eine Seite klicken, tendenziell länger bleiben und engagierter sind – weil sie bereits kontextuell vorgewärmt sind. Die Messlatte darf also nicht nur das Klickvolumen sein. Wichtiger werden Besuchsdauer, Signups, Conversions, Engagement und qualitative Signale.

---

3. Annanya Raghavan: Storytelling mit Google Trends

Annanya Raghavans Vortrag war die strategisch vielleicht inspirierendste Session. Ihre These: Trends ist kein Keyword-Tool. Trends ist ein kultureller Kompass.

„Why Narratives Beat Keywords“

Raghavans Leitsatz: Keywords zeigen, was Menschen wollen. Trends zeigen, wer Menschen sind. Ein Keyword ist eine Transaktion, ein Trend eine Transformation im Publikumsverhalten.

Was Trends-Daten laut ihrer Darstellung einzigartig macht:

• Big: Milliarden Suchanfragen pro Tag – einer der größten Echtzeit-Datensätze der Welt.
• Immediate: nahezu in Echtzeit, was Menschen gerade umtreibt.

Ein paar Beispiele, die in der Session hängen geblieben sind:

• Globale Frage „how can we control anxiety“
• Kanada: „how can we reduce food waste“
• Indien: „how can we care for our elders“
• UK: „how can we mitigate climate change“
• USA: „how can we stop bullying“

Dieselbe Satzstruktur – und doch völlig unterschiedliche gesellschaftliche Prioritäten.

Tagesrhythmen und Kulturmuster

Raghavan zeigte tägliche Peaks verschiedener Suchanfragen:

• 7:00 Uhr – „surfing“ in Australien
• 8:00 Uhr – „full english“ in England
• 13:00 Uhr – „beer garden“ in Deutschland
• 15:00 Uhr – „hiking“ in Kanada
• 16:00 Uhr – „disco“ in Spanien
• 17:00 Uhr – „karaoke“ in Japan
• 23:00 Uhr – „jazz music“ in Brasilien

Für Content-Planung, Paid-Timing oder regionale Ansprache ist das Gold wert – solange man Trends konsequent dafür nutzt.

Die drei Säulen narrativer Verbindung

Raghavans Framework für strategische Trends-Nutzung:

1. Seasonality vs. Spontaneity – erwartbare jährliche Peaks planen, aber agil genug für Breakout-Momente bleiben.
2. Generative Context – Search-AI-Features analysieren, um zu verstehen, wie Informationen synthetisiert werden.
3. The Narrative Gap – Breakout-Trends gegenüber statischen High-Volume-Keywords priorisieren, um First-Mover-Vorteile in AI-Antworten zu sichern.

Der Brand-Connectivity-Prozess in fünf Schritten

1. Identify: In Trends eine Breakout-Query finden, bei der Neugier schneller steigt als der Wettbewerb.
2. Verify: Über „Interest by Subregion“ regionale Relevanz gegenprüfen.
3. Synthesize: In Search AI prüfen, wie Google das Thema aktuell zusammenfasst.
4. Differentiate: Eigene Daten, Expertise oder Perspektive hinzufügen, die über den AI-Gist hinausgeht.
5. Execute: Hilfreichen, originären Content veröffentlichen, der das tiefere „Warum“ beantwortet.

Das ist im Grunde ein SEO-Prozess, in den AI Search als Research-Tool integriert wird – nicht als Bedrohung, sondern als Diagnoseinstrument.

---

4. Daniel Waisberg: Neues in Search Console und Trends

Daniel Waisberg brachte die konkreten Tool-News mit. Vier Themen: Query Groups, AI-powered Configuration, Trends API (Alpha), Trends Explore mit Gemini.

Query Groups: Weil eine Anfrage hundert Varianten hat

Waisberg nutzte das wunderbare Beispiel „How to spell Britney Spears?“ – mit einer langen Liste der Schreibweisen, die Menschen tatsächlich eintippen. Genau dieses Problem adressieren Query Groups: ähnliche Anfragen werden automatisch zu Themenclustern gebündelt.

Beispiele aus der Insight Card in den Folien: schema checker, seo, robots.txt, core web vitals, google core update. Jede Gruppe kommt mit Gesamtmetriken, Top Countries und Additional Traffic Sources – und lässt sich auf die zugrunde liegende Regex drill-downen. Wer will, kann die Gruppierung also bis auf Einzelquery-Ebene nachvollziehen.

Query Groups lösen ein echtes Problem: Statt sich durch hundert Keyword-Varianten zu filtern, bekommt man Themen serviert. Pluspunkt für Dashboards und Executive Reports.

AI-powered Configuration: GSC per Prompt

Die zweite Neuerung ist eine experimentelle Funktion, die natürliche Sprache in GSC-Filter übersetzt. Drei Schritte:

1. Wunsch in Umgangssprache beschreiben.
2. System schlägt passende Filter und Einstellungen vor.
3. Prüfen, anwenden (oder verwerfen).

Beispielprompt aus der Demo: „CTR von Queries anzeigen, die ‚how to‘ oder ‚what is‘ enthalten, in Kanada letzte Woche.“ Die vorgeschlagene Konfiguration: letzte 7 Tage, Web-Search, Country Canada, Query-Matching how to | what is, Metric CTR, Breakdown Queries.

Wichtig: Es gibt einen expliziten Review-Schritt. Die KI schlägt vor, Menschen entscheiden. Das Feature ist als experimentell markiert – Feedback ausdrücklich erwünscht.

Trends API (Alpha)

Für alle, die bisher mit Screenshots aus dem Trends-UI leben mussten: Es kommt eine echte API. Die relevanten Eckdaten:

• 5 Jahre Rolling Window, Daten bis 48 Stunden vor „jetzt“ (die Verzögerung ist bewusst, um Missbrauch zu erschweren).
• Konsistent skalierte Suchinteresse-Werte – isolierte Einzelabfragen sind damit mit Vergleichsabfragen kompatibel (das war vorher ein häufiger Stolperstein).
• Neue Zeitauflösungen: täglich, wöchentlich, monatlich, jährlich.
• Asynchrones Request-Modell: Anfrage erstellen, Operation-ID erhalten, Ergebnis abrufen.

Ein Sample-Request aus der Folie: geo: US, expression: "world cup", time_range: 2024-01-01 bis 2024-12-31, time_resolution: WEEK. Die Response liefert points mit search_interest und scaled_search_interest.

Das ist ein ziemlich großer Schritt für alle, die Trends-Daten in Dashboards, Data-Science-Workflows oder Content-Planungs-Tools einbinden wollen.

Trends Explore mit Gemini

Die vierte Neuerung: Ein Gemini-gestütztes Panel in Trends Explore, das Themenvorschläge macht. Beispiel aus den Folien: Für die Eingabe „Dog breeds“ schlägt Gemini Verfeinerungen wie „small dog breeds“, „hypoallergenic dog breeds“, „Labrador vs. Golden Retriever“ oder „most popular dog breeds in the US“ vor.

Nützlich für Brainstorming – und um nicht ständig im eigenen Bubble-Vokabular festzustecken.

---

5. Ryan Levering: Strukturierte Daten, Qualität & KI

Ryan Leverings Vortrag war die technische Kür – und die wichtigste Korrektur an einem verbreiteten Mythos: Strukturierte Daten sind in der KI-Ära nicht weniger wichtig, sondern mehr.

Die zwei Extrempositionen – und die Wahrheit dazwischen

Levering stellte zwei überzogene Sichtweisen gegenüber:

• „Strukturierte Daten sind nutzlos, LLMs verstehen auch ohne Schema alles.“
• „Strukturierte Daten sind die Zukunft, Agenten brauchen eh kein Web mehr.“

Beides falsch. Seine vier Argumente, warum strukturierte Daten weiter wichtig sind:

1. Precision: Für komplexe Commerce-Schemata (z. B. Sale Pricing) sind sie präziser als LLM-Extraktion.
2. Extra Content: Sie transportieren unsichtbare Metadaten (vollständige ISO-Daten, stabile IDs), die im sichtbaren Text fehlen.
3. Efficiency: Parsebare Daten sind deutlich günstiger als LLM-Extraktion bei jedem Crawl.
4. Focus: Sie heben die relevanten Datenpunkte hervor und verhindern, dass das System irrelevante Informationen (z. B. Preise verwandter Produkte) heranzieht.

Entscheidend: Strukturierte Daten befeuern nicht nur Rich Results in der SERP. Sie werden auch als Kontext in AI Overviews und AI Mode verwendet.

Der Shopping-Schwerpunkt

Der Großteil der Session drehte sich um E-Commerce. Die wichtigen Bausteine:

Shipping Service Annotations

• handlingTime als ServicePeriod mit cutoffTime und duration.
• shippingConditions mit Destinations, Mindestbestellwerten, Raten.
• Konkrete Beispiele: Versand bis 14:30 Uhr, 30 Minuten Handling, kostenloser Versand nach FR und DE ab 50 Euro Bestellwert.

Loyalty Programs

• Organization → MemberProgram → MemberProgramTier → Benefit (z. B. Member Price, kostenloser Versand).
• Tiers bekommen stabile @id-URLs, auf die andere Dokumente verlinken können.

Cross-Page-Verknüpfung über @id

• Versandangebote können per validForMemberTier auf den entsprechenden Loyalty-Tier verweisen.
• Produkte können auf Organisationsrichtlinien verlinken.

Und der Ausblick: Google will die Symmetrie zwischen Merchant-Center-Feeds und Web-Markup stärken – was bedeutet, dass saubere Structured Data auf der Website zunehmend dieselben Signale liefert wie gepflegte Feeds.

Rich Results Test vs. schema.org Validator

Eine praktische Klarstellung aus der Session: Diese beiden Tools beantworten unterschiedliche Fragen.

• Rich Results Test (search.google.com/test/rich-results): Nutzt Googles internen Indexing-Stack und prüft, ob Google das Markup tatsächlich verarbeiten kann.
• schema.org Validator (validator.schema.org): Prüft reine Standardkonformität – unabhängig davon, ob Google etwas damit anfangen würde.

Für SEO-Zwecke ist der Rich Results Test der relevantere Check. Der schema.org Validator ist für strikte Standardvalidierung gedacht.

UGC, Forum und Q&A

Kleine, aber feine Neuerungen:

• Bessere Verarbeitung von Embedded Posts und Reposts.
• Ein neues Property digitalSourceType, das maschinengenerierte Inhalte kennzeichnen kann (algorithmisch vs. modellgeneriert).

Und für Bildauswahl in Search/AI: primaryImageOfPage, mainEntity -> image und og:image sind die Signale, auf die Google hört.

---

Praktische Implikationen für SEO

Wer die fünf Sessions zusammennimmt, bekommt eine erstaunlich kohärente To-do-Liste für die nächsten Monate.

Indexierung und Crawling

„Crawled – currently not indexed“ ist selten ein Rendering-Problem. Wer dieses Problem hat, sollte nicht zuerst ins JavaScript-Rendering schauen, sondern in Qualität, Duplicate Content, Canonicals, Nachfrage, Konkurrenz anderer URLs, 404s, Weiterleitungen und robots.txt. Sitemaps und interne Verlinkung bleiben wichtig, weil Discovery ein eigener Schritt im Life-of-a-URL-Modell ist.

Content-Strategie

• Nicht in Panik verfallen und die Website für AI Search umstrukturieren.
• Kein „Chunking“, keine Markdown-Migration, keine llms.txt.
• Dafür: Unique, Specific, Authentic. Eigene Daten, Experimente, Fälle, Perspektiven.
• Keine massenhaft ähnlichen KI-generierten Seiten – das ist Scaled Content Abuse.

Messung

AI-Search-Klicks nicht nur am Volumen bewerten. Engagement, Besuchsdauer, Conversions, Signups und qualitative Signale werden wichtiger. GSC Query Groups und AI-powered Configuration können Analyseaufwand reduzieren – aber vorgeschlagene Filter immer gegenprüfen.

Google Trends als strategisches Werkzeug

Trends ist mehr als ein Keyword-Research-Tool. Breakout-Themen können strategisch wichtiger sein als statisch hohe Suchvolumina. Regionale Muster, Tagesrhythmen und Ereignis-Peaks fließen in Content-Planung ein. Die neue API öffnet die Tür für systematischere Trends-Analyse.

Strukturierte Daten

Vor allem im E-Commerce: Shipping-Policies, Loyalty-Programme, Produktvarianten, Member Pricing, UGC-Kennzeichnung. Cross-Page-Verknüpfungen über stabile @id-URLs werden wichtiger. Und: Der Rich Results Test beantwortet eine andere Frage als der schema.org Validator – beide haben ihre Daseinsberechtigung.

Blockieren von Google-Extended

Ein Detail, das in den Notizen auftaucht und das oft missverstanden wird: Das Blockieren von Google-Extended beeinflusst laut Veranstaltung nicht die Sichtbarkeit in AI Overviews oder AI Mode negativ, weil Google die Inhalte auch aus dem regulären Suchindex heranziehen kann. Wer konkrete Inhalte wirklich von der KI-Nutzung ausschließen will, muss eher mit data-nosnippet arbeiten – was allerdings auch klassische SEO-Snippets beschränkt. Das komplette Blockieren kann zudem dazu führen, dass die eigene Seite nicht mehr als Grounding- oder Link-Quelle in AI-Antworten erscheint.

---

Fazit: Mehr Evolution als Revolution

Die ehrlichste Zusammenfassung der Veranstaltung steht auf einer von Danny Sullivans Folien: „All this is good news!“ Menschen müssen ihre Websites nicht panisch für AI-Search-Erfolg auseinanderreißen.

Was wirklich passiert, ist subtiler – und anspruchsvoller:

• Die Qualitätsschwelle für Indexierung steigt, weil KI Content-Produktion trivialisiert.
• Sichtbarkeit wird über mehr Oberflächen verteilt: Web, Bilder, Videos, Shopping, Local, Fan-outs.
• Strukturierte Daten werden zum zuverlässigeren Signal gegenüber KI-Extraktion.
• Measurement verschiebt sich vom Klick zum Engagement.
• Google selbst baut seine Tools (GSC, Trends) assistiver und API-freundlicher aus.

Und quer über alle fünf Sessions zog sich dieselbe Botschaft: Wer heute guten, eigenen, spezifischen Content für Menschen macht, ist für AI Search richtig aufgestellt. Keine neuen Akronyme. Keine magischen Schalter. Nur: Handwerk, ehrlich gemacht.

Wer die Originalfolien sehen will, findet die komplette Bildsammlung im Blogpost von Jean-Christophe Chouinard.

---

Quelle: JC Chouinard, „Google Search Central Live Toronto Slides (April 2026)“, veröffentlicht am 22. April 2026. Analyse und Einordnung auf Basis der dort dokumentierten Slides.

Ein Praxis-Ratgeber für Marketing-, SEO- und Content-Verantwortliche

Klassisches SEO hat seine Steuerungsgrößen verloren. Wenn bei Googles AI Mode rund 95 von 100 Anfragen ohne Klick auf eine externe Website bleiben und die Zero-Click-Rate bei ChatGPT je nach Query-Typ zwischen 78 und 99 Prozent liegt, wird Traffic als einzige Erfolgsmetrik zum Blindflug. Gleichzeitig sind AI-referred Sessions zwischen Januar und Mai 2025 um 527 Prozent gewachsen — die Frage ist also nicht mehr, ob man sich mit generativer Suche beschäftigt, sondern wie systematisch.

Generative Engine Optimization (GEO) beschreibt die Arbeit an genau dieser Sichtbarkeit: nicht mehr für Klicks zu optimieren, sondern dafür, in KI-Antworten zitiert, empfohlen und als Ground Truth akzeptiert zu werden. Dieser Beitrag bündelt die wichtigsten Hebel für B2B-Unternehmen — entlang strategischer, organisatorischer und operativer Fragen. Am Ende steht eine priorisierte Handlungsliste.

1. Der Paradigmenwechsel: Von Rankings zu Antwortrepräsentation

Der Kernsatz lautet: Wir optimieren nicht mehr für Klicks, sondern dafür, zitiert, empfohlen und als Ground Truth akzeptiert zu werden.

Drei Verschiebungen prägen den neuen Kanal:

• Natürliche Sprache statt Keywords. Nutzer formulieren Anfragen mit 20+ Wörtern und erwarten direkte Antworten. Der Long-Tail ist nicht mehr Nische, sondern Norm.
• Die Website wird zur Bestätigung, nicht zur Überzeugung. Ein Großteil der Entscheidungsarbeit findet im Chat statt. Wenn der Nutzer die Seite überhaupt noch besucht, hat er meist schon eine Vorentscheidung getroffen.
• Volatilität als Dauerzustand. Dieselbe Frage liefert zu unterschiedlichen Zeitpunkten unterschiedliche Antworten — je nach Modell, Personalisierung, Query Fan-out und Grounding-Auswahl. Selbst bei identischen Prompts variieren die zitierten Quellen stark.

Handlungsempfehlung: Stellen Sie die Leitfrage im Team um. Weg von „Wie ranke ich?“ hin zu „Bei welchen entscheidungsrelevanten Prompts tauche ich als empfohlene Option auf?“

2. Zielgrößen neu denken: Was jetzt gemessen wird

Rankings und reines Traffic-Volumen verlieren an Aussagekraft. Sinnvoller sind:

• Share of Voice in generativen Antworten — bei einem definierten Set von 25–50 Kern-Prompts über mehrere Systeme hinweg.
• Citation Rate — bei welchen Prompts werden Sie nicht nur erwähnt, sondern als Quelle zitiert?
• Sentiment der Erwähnungen — Erwähnung allein reicht nicht.
• Entity Recall — kennt das Modell Ihre Marke im relevanten Kontext?
• Business Impact — Lead-Qualität und Conversion-Qualität statt reines Traffic-Volumen.

Attribution bleibt schwierig. Zitiert zu werden erzeugt oft keinen sichtbaren Klick, obwohl es eine Kaufentscheidung beeinflusst. Offizielle APIs und Standard-Metriken fehlen, die Tool-Landschaft ist unreif. Der pragmatische Weg ist Triangulation: Sichtbarkeits-Signale aus spezialisierten Tools kombiniert mit manuellen Tests, GA4-Referrer-Daten (chatgpt.com, perplexity.ai, gemini.google.com) und Business-Outcomes.

Ein oft unterschätzter Indikator: Neukunden direkt fragen, wie sie Sie gefunden haben. Das ist qualitativ unbezahlbar.

Handlungsempfehlung: Definieren Sie 25–50 geschäftsrelevante Prompts, messen Sie eine Baseline über drei bis vier Systeme (ChatGPT, Perplexity, Google AI Mode, Claude), idealerweise bilden sie einen laufenden Durchschnitt aus mehreren Abfragen jedes Prompts und checken Sie mindestens monatlich auf Veränderungen.

3. Die häufigsten strategischen Fehlannahmen

Fünf Irrtümer begegnen mir regelmäßig in der Beratung:

1. „GEO ersetzt SEO.“ Falsch. GEO funktioniert nur als Erweiterung solider SEO-Grundlagen. Ohne saubere Tech-SEO und Brand Building fehlt der Hebel.
2. llms.txt-Hype. Viele Experimente haben bestätigt: Kein KI-Crawler hat gezielt nach llms.txt gesucht. Die Datei gilt als wirkungslos.
3. Quantität ohne Qualität. KI-generierte Massen an Content schaden eher — LLMs verstehen Semantik, nicht Worthäufigkeit.
4. FOMO statt Business Case. Sichtbarkeit ohne Geschäftsrelevanz ist kein Ziel.
5. Sofortige Messbarkeit erwartet. GEO ist ein Marathon. Erste belastbare Erkenntnisse brauchen mindestens ein Quartal, besser ein halbes Jahr.

Die gute Nachricht: Wer eine solide SEO-Basis hat, kann innerhalb weniger Wochen spürbar etwas bewegen.

4. Organisation und Governance: Die unterschätzte Hürde

Die größte Hürde bei systematischer GEO-Umsetzung ist nicht technisch, sondern organisatorisch. GEO-Sichtbarkeit entsteht an der Schnittstelle von SEO, Content, PR, Brand, Produkt und Web — keine dieser Funktionen allein kann sie verantworten.

In der Praxis scheitert es meist an drei Punkten:

• Unklare Ownership. GEO fällt zwischen die Stühle. Wenn niemand expliziter Owner ist, bleibt es bei Einzelprojekten.
• Fehlende Prozess-Disziplin. Monitoring ist sporadisch, Learnings fließen nicht in Content-Briefings zurück.
• Leadership-Education. Entscheider müssen verstehen, warum GEO wichtig ist — ohne sich von Hype treiben zu lassen.

Eigene Rolle oder Erweiterung bestehender Funktionen? Für die meisten Unternehmen reicht eine Erweiterung der SEO- und Content-Funktion. Nur Enterprise-SaaS, hochregulierte Branchen oder Konzerne mit komplexem Buying Center brauchen dedizierte Senior-Rollen (Adobe hat Ende 2024 eine entsprechende Stelle mit ausgeschrieben).

Handlungsempfehlung: Benennen Sie einen klaren Accountability-Owner — meist im SEO- oder Content-Team — mit definierten Eskalationswegen und Einbindung in Digital PR. Committen Sie alle Beteiligten auf ein gemeinsames Zielsystem: Brand Visibility in KI-Antworten und Business-Outcomes.

5. Content-Lifecycle: Wo die meisten Teams scheitern

Das praxiserprobte Framework verläuft in vier Phasen: Source Analysis → Optimization → Assessment → Refinement. In der Realität werden Phase 1 und Phase 3 fast immer übersprungen.

• Phase 1 — Source Analysis. Die Frage „Woher bezieht die KI ihre Antwort zu unserem Thema heute?“ wird selten systematisch gestellt. Dabei dominiert Earned Media: Bis zu die meisten KI-Zitationen stammen aus Drittquellen. Wer nur die eigene Domain optimiert, ignoriert den größten Hebel.
• Phase 3 — Assessment. Ohne definiertes Prompt-Set, ohne Baseline, ohne regelmäßige Re-Checks gibt es keine Lernschleife.

Dazu kommen drei operative Lücken, die sich quer durch alle Teams ziehen: Passage-Optimierung (im klassischen SEO konkurrieren Seiten, im GEO konkurrieren Passagen), Claim-Evidence-Source (jede zentrale Aussage sollte mit Beweis und Quelle verknüpft sein) und Information Gain (wenn ein Artikel nichts sagt, was nicht auch Wikipedia sagt, wird die KI Wikipedia zitieren).

6. Der stärkste inhaltliche Hebel: Autorität und Struktur

Das Hinzufügen von Statistiken, Zitaten und wissenschaftlichen Quellenangaben steigert die Sichtbarkeit in KI-Antworten messbar.

Konkret wirksam sind:

• Claim-Evidence-Source-Format — jede Kernaussage mit Beleg und nachvollziehbarer Quelle.
• Passage-Optimierung in semantisch geschlossenen Einheiten von etwa 40–60 Wörtern, die isoliert Sinn ergeben.
• Direkte Antwortlogik — Frage, prägnante Antwort in den ersten Zeilen, Beleg, Kontext. TL;DRs in den ersten 10 Prozent eines Textes sind messbar wirksam.
• Information Gain — eigene Daten, Studien, Fallbeispiele.

Was im B2B funktioniert: Thought-Leadership-Artikel in Fachmedien, Original-Research, Vergleichsguides mit Kriterien-Transparenz, lösungsorientierte Deep-Dives („Wie reduziere ich IT-Kosten?“ statt „Unser Cloud-Service hat 99,9 % Uptime“), Whitepaper mit echtem Mehrwert, Case Studies mit harten Zahlen.

Was nicht funktioniert: Keyword-optimierte Seiten ohne Information Gain, Feature-Listen ohne Problem-Kontext, KI-generierte Masse, reine Produktseiten ohne Entscheidungsunterstützung, Content ohne erkennbare Autoren oder Quellen.

7. Multiperspektivischer Content für das Buying Center

Im B2B fragen Techniker, CFO und Geschäftsführung am selben Thema völlig unterschiedliche Fragen. Der Techniker fragt nach Integration und Security, der CFO nach TCO und ROI, die Geschäftsführung nach Strategie und Risiko.

Die praktikabelste Lösung ist eine integrierte Hub-Struktur statt isolierter Silos: Ein zentrales Pillar-Content-Stück pro Thema mit klar benannten Zielrollen-Abschnitten („Für Entscheider“, „Für IT-Verantwortliche“, „Für den CFO“). Vorteil: Die KI findet für jede Perspektive einen zitierfähigen Abschnitt, und die semantische Tiefe des Hubs stärkt die Topical Authority.

Ergänzend: Spezialisierte Inhalte pro Rolle an den Entscheidungsmomenten, wo Tiefe zählt — aber immer aus dem Hub verlinkt, nicht parallel.

Warum keine komplett getrennten Inhalte? Separate Artikel pro Rolle kannibalisieren sich semantisch und verteilen Autorität auf mehrere URLs. KI-Systeme bevorzugen kohärente, tiefe Quellen.

8. E-E-A-T neu gewichtet: Was im B2B wirklich zählt

Der Shift lautet: Von Domain Authority zu Entity Recall. Von Anchor Text zu Branded Search Lift. Von Backlinks zu Brand Mentions und Co-Occurrences.

Was im B2B den höchsten Wirkungsgrad hat:

• Expertise — nachweisbare Fachkompetenz, Studien, Original-Research, publizierte Vorträge. Schwache Expertise disqualifiziert sofort.
• Authoritativeness — Zitierungen in Branchenmedien, Thought-Leadership-Position, externe Anerkennung durch die Peer Group.
• Trust — Transparenz über Geschäftsmodell, Compliance-Konformität, saubere Quellen.

Was überschätzt wird:

• Experience im Sinne klassischer Nutzer-Reviews — im B2B zählt organisationale Experience in Form von Case Studies mit harten Ergebnissen mehr als generische Bewertungen.
• Allgemeines Firmenprestige ohne konkrete Expertise-Demonstration. „Wir sind ein Großkonzern“ ist kein E-E-A-T-Signal.
• Schema.org-Markup als Haupthebel für LLM-Systeme — sinnvoll für klassische SEO, aber kein nachgewiesener Zusatznutzen für generative Antworten.

9. Technik: Unverzichtbar vs. überschätzt

Unverzichtbar:

• Rendering ohne JavaScript-Abhängigkeit. KI-Crawler sind deutlich restriktiver als Googlebot — Server-Side-Rendering oder statisches HTML für zentrale Inhalte.
• Saubere, differenzierte robots.txt.
• Indexierbarkeit der Kerninhalte, keine Access-Walls oder Layer.
• Schnelle Ladezeiten und Server-Stabilität.

Überschätzt:

• llms.txt — nachweislich wirkungslos.
• Schema.org-Markup als Hauptmaßnahme für LLM-Sichtbarkeit.
• Komplexe Chunking-Strategien — die Wirkung kommt aus guter Struktur, nicht aus Technik.

Crawler-Management: Differenziert vorgehen. Training-Crawler (CCBot, GPTBot im Training-Modus) blockieren, wenn Content nicht als Trainingsdaten dienen soll. Search- und Citation-Crawler (OAI-SearchBot, PerplexityBot, Google-Extended im Search-Modus) sind sichtbarkeitsrelevant — erlauben. Wer alles blockiert, wird in KI-Antworten nicht zitiert.

10. Priorisierte Handlungsliste für B2B

Wenn Sie heute anfangen, in dieser Reihenfolge:

1. Inhalte auf Entscheidungsfragen und Stakeholder-Perspektiven ausrichten. Im B2B ist Thought Leadership der zentrale Hebel.
2. E-E-A-T-Signale explizit und maschinenlesbar machen. Autorität ist der stärkste Einzeleffekt
3. Content auf semantisch geschlossene Einheiten umbauen. Claim-Evidence-Source und Passage-Optimierung sind die Voraussetzung, damit Autorität in KI-Antworten landet.
4. Content-Audit als Fakten-Inventar durchführen. Für jedes geschäftsrelevante Thema: Welche zentralen Fakten, Zahlen, Definitionen sind zitierfähig vorhanden — und welche nicht? Deckt meist 20–50 konkrete Lücken auf.
5. Earned-Media-Initiative starten. Ein fundierter Fachbeitrag in einer autoritativen Publikation bringt im B2B oft mehr GEO-Sichtbarkeit als 50 On-Page-Optimierungen.
6. Monitoring etablieren. 25–50 Prompts, Baseline über 3–4 Systeme mit Mehrfachabfragen und Bildung von Durchschnitten und Trends, monatliche Re-Checks.
7. Autoren- und Entity-Signale pflegen. Klare Autorennennung, Bio mit Credentials, konsistente Pflege in Wikipedia/Wikidata, wo möglich.
8. Ownership und Prozesse verankern. Klarer Accountability-Owner, monatliche GEO-Reviews mit SEO, Content, PR und Produkt.

Was ich zuerst nicht anfassen würde: llms.txt, großflächiges Schema.org-Rollout als GEO-Haupthebel, hochtechnische Chunking-Frameworks.

Fazit: GEO ist eine Qualitätsaufgabe, kein Optimierungstrick

Der unbequemste Teil zuerst: Die tatsächlichen Erfolgstreiber sind unspektakulär. Saubere Topical Authority, belastbare Expertise, Earned Media, solide SEO-Grundlagen. Vieles davon ist kein neuer GEO-Trick, sondern hochwertiges SEO, wie es seit Jahren gemacht werden sollte.

Drei Entwicklungen werden die nächsten 24 Monate prägen — und sind in der aktuellen Debatte deutlich unterrepräsentiert:

• Adversarial GEO. Wenige präparierte Dokumente reichen bereits, um RAG-Systeme messbar zu beeinflussen. Die Branche diskutiert GEO fast ausschließlich als Optimierungsproblem — kaum als Sicherheits- und Reputationsproblem.
• Regulatorischer Druck. Die Landesmedienanstalten Berlin-Brandenburg und Hamburg haben Verwaltungsverfahren gegen Google und Perplexity eingeleitet. Studien belegen Reichweitenverluste bei Content-Anbietern zwischen 10 und 50 Prozent.
• Das Agentic Web. Morgan Stanley erwartet, dass die Hälfte der US-Online-Shopper Agenten nutzen wird. Wer heute über llms.txt diskutiert, hat die Ebene nicht verstanden, auf der sich die Schlacht verlagert.

Für den deutschsprachigen Raum gibt es dabei eine unterschätzte Chance: Hochwertige deutsche Fachinhalte haben Seltenheitswert. Wer fundierten Content auf Deutsch liefert, konkurriert mit deutlich weniger Quellen als im englischsprachigen Raum — bei gleichzeitig hoher Nachfrage.

Wer anfängt, sollte nicht auf das perfekte Tool warten. Ein definiertes Prompt-Set, eine ehrliche Baseline und die Disziplin, die eigenen Top-20-Seiten nach Claim-Evidence-Source umzubauen, bringen innerhalb eines Quartals mehr als jede Hype-Lösung.

Ich habe mir angesehen, was man aus der Wix/Peec-Analyse zu LLM-Zitationen wirklich lesen kann – und was nicht

Der Beitrag von Wix über die „most cited content types by LLMs“ ist interessant, weil er einmal nicht nur Meinungen oder Best Practices sammelt, sondern mit einem größeren Datensatz arbeitet: Laut Artikel wurden 75.000 AI-Antworten mit 1.056.727 Zitationen aus ChatGPT, Google AI Mode und Perplexity ausgewertet. Vorab gut zu wissen ist, dass die Daten laut Autor über Peec erhoben wurden und dass er selbst dort als Researcher arbeitet. Das macht den Beitrag nicht unbrauchbar, aber eben zu einer vendorseitigen Auswertung und nicht zu einer unabhängigen wissenschaftlichen Studie.

Was der Datensatz zunächst einmal tatsächlich zeigt, ist ziemlich klar: In diesem Setup entfallen die meisten sichtbaren Zitationen auf Listicles, Articles und Product Pages. Innerhalb der Intent-Klassen verschiebt sich das Bild deutlich: Bei informational Prompts dominieren Articles, bei commercial Prompts Listicles, und bei navigational/local sowie transactional Prompts treten Product- und Category-Pages deutlich stärker hervor. Als deskriptive Beobachtung über genau dieses Sample ist das nützlich und plausibel.

Genau an dieser Stelle beginnt aber die wissenschaftlich wichtige Trennung zwischen Beobachtung und Interpretation. Peec unterscheidet selbst zwischen Sources und Citations: Citations sind nur die URLs, die direkt im Antworttext auftauchen; Sources umfassen auch weitere URLs, die das System genutzt, aber nicht sichtbar zitiert hat. Der Beitrag analysiert hier also nur die sichtbaren Zitationen. Das ist ein valider Messpunkt, aber ich fände es gerade interessant, was zitierte Inhalte von den gelieferten Quellen und diese wiederum von „allen möglichen Quellen“ unterscheidet, denn so kommen wir der Frage „welcher Content-Typ objektiv am besten funktioniert“ nicht unbedingt näher.

Für mich ist deshalb der belastbarste Schluss ein recht nüchterner:

Die Verteilung sichtbarer LLM-Zitationen variiert in diesem Datensatz deutlich nach Prompt-Intent.

Mehr nicht, aber auch nicht weniger.

Man kann also vorsichtig sagen, dass Articles in informational Kontexten häufiger sichtbar zitiert wurden, Listicles in commercial Kontexten und Product- bzw. Category-Pages eher in navigational und transactional Kontexten. Was man daraus noch nicht sauber sagen kann, ist, dass LLMs diese Formate „bevorzugen“ im starken Sinn oder dass genau diese Formate kausal für Sichtbarkeit verantwortlich sind.

Der Artikel geht an mehreren Stellen über diese Evidenz hinaus. Wenn dort etwa steht, Nutzer wollten bei kommerziellen Suchanfragen „structured comparisons and peer opinions“, dann ist das als Hypothese nachvollziehbar — gemessen wurde es hier aber nicht!

Die Auswertung enthält keine Nutzerbefragung, keine Klickdaten, keine Conversion-Daten und keine Verhaltensmaße. Gemessen wurde allein, welche Seitentypen in Antworten sichtbar zitiert wurden. Aus solchen Mustern kann man psychologische Erklärungen ableiten; belegt sind diese Erklärungen dadurch aber nicht.

Dasselbe gilt für starke strategische Aussagen am Ende des Beitrags. Formulierungen wie „Articles build trust but don’t drive decisions“, „optimize for user intent rather than models“ oder „don’t rely on articles“ lesen sich handlungsnah, sind aber durch dieses Studiendesign nicht kausal abgesichert.

Es handelt sich um eine beobachtende Auswertung, nicht um ein kontrolliertes Experiment, in dem identische Inhalte systematisch variiert und deren Effekte getestet wurden. Der Beitrag zeigt Korrelationen in sichtbaren Zitationen, keine Wirkungsnachweise.

Ein weiterer methodischer Punkt wird leicht übersehen: Die Zahl von über einer Million Zitationen klingt (wie bereits bei der 1,2 Millionen Prompts-Studie) nach enormer statistischer Wucht, ist aber nicht automatisch gleichbedeutend mit über einer Million unabhängigen Beobachtungen.

Eine einzelne Antwort kann mehrere Quellen enthalten, und Peec weist selbst darauf hin, dass Sources und Citations unterschiedliche Dinge sind. Wer also Citation-Shares betrachtet, betrachtet keine Query-Shares und auch keine „Gewinner pro Prompt“, sondern Anteile innerhalb eines Zitationsraums. Das ist analytisch relevant, weil sich dadurch die Denominator-Logik ändert.

Man sieht diese Unschärfe schon in den Aufmacherzahlen des Artikels: Dort heißt es, Articles würden bei informational Queries „2.7x more“ zitiert als bei anderen Intents. Schaut man auf die veröffentlichte Tabelle, liegt der Article-Anteil bei informational Prompts bei 45,48 Prozent und overall bei 16,68 Prozent. Der Faktor 2,7 ergibt sich also offenbar aus dem Vergleich mit dem Gesamtwert, nicht mit dem Durchschnitt der anderen drei Intent-Klassen. Das ist kein gravierender Fehler, aber ein gutes Beispiel dafür, warum man Marketing-kompatible Kennzahlen immer gegen die Tabelle selbst lesen sollte.

Auch die Modellvergleiche würde ich vorsichtiger lesen, als der Text es nahelegt. Peec dokumentiert selbst, dass Plattformen bei Quellen und Zitationen unterschiedlich funktionieren: ChatGPT sucht nicht immer im Web, Perplexity zeigt oft viele Sources, aber relativ weniger direkte Citations, und die Quellenauswahl schwankt von Tag zu Tag. Wenn die Produkte bereits unterschiedlich suchen und unterschiedlich zitieren, dann misst ein Modellvergleich eben nicht nur „inhaltliche Präferenzen“, sondern auch Unterschiede im Produktverhalten. Aussagen wie „Perplexity values community opinions“ sind deshalb eher Interpretation als harter Befund.

Eine weitere Einschränkung steckt in den transactional Prompts. Der Autor schreibt selbst, dass transaktionale Anfragen in der Realität oft branded sind, für die Studie aber absichtlich non-branded gehalten wurden. Das ist methodisch nachvollziehbar, weil es den Vergleich sauberer macht. Gleichzeitig entfernt sich das Setup damit gerade in einem besonders handlungsnahen Bereich ein Stück von realem Nutzerverhalten. Wer daraus operative Empfehlungen für Kauf- oder Conversion-Szenarien ableiten will, sollte diese Grenze im Blick behalten.

Interessant, aber ebenfalls nur begrenzt generalisierbar, ist die Passage zu Third-Party-Listicles. Der Beitrag zeigt für das Subset „Professional services, top 1.000 cited URLs“, dass externe Listicles dort deutlich häufiger vorkamen als selbstpromotende. Das ist als Beobachtung für genau dieses Subset völlig okay. Daraus folgt aber noch nicht, dass Third-Party-Listicles allgemein „den Unterschied machen“ oder kausal Sichtbarkeit erzeugen. Dafür wäre ein deutlich enger kontrolliertes Design nötig.

Mein Fazit wäre deshalb dieses:

Der Beitrag ist als explorative Marktanalyse lesenswert, weil er ein plausibles Muster sichtbar macht — nämlich, dass sich die sichtbar zitierten URL-Typen je nach Prompt-Intent stark unterscheiden. Was der Beitrag nicht liefert, ist ein wissenschaftlich belastbarer Nachweis für Nutzerpsychologie, Trust-Effekte, Conversion-Wirkungen oder allgemeingültige Content-Rezepte.

Anders gesagt:

Als Hypothesengenerator ist die Analyse gut. Als Beleg für starke Strategieaussagen ist sie deutlich schwächer.

Wenn man es in einen einzigen sauberen Satz pressen will, würde ich es so formulieren: In einem großen, aber vendorseitigen Datensatz sichtbarer LLM-Zitationen variiert die Verteilung der zitierten Seitentypen deutlich nach Prompt-Intent; alles darüber hinaus ist eher Interpretation als Evidenz.

Der neue Growth-Memo-Beitrag erzählt eine starke Geschichte: AI Mode verdichtet Kaufentscheidungen, Nutzer übernehmen Shortlists, und Marken außerhalb der AI-Liste verlieren Sichtbarkeit. Die empirische Basis dafür ist aber keine große Bevölkerungsstudie, sondern eine remote, unmoderated Think-aloud-Usability-Studie mit 48 US-Teilnehmenden, 185 Aufgaben in vier Kategorien.

Der zugrunde liegende Report wird von Citation Labs, Xofu und Clickstream Solutions veröffentlicht, und die Autoren schreiben selbst, dass die Ergebnisse vor allem als richtungsweisend und nicht als belastbare Bevölkerungsschätzung zu lesen sind.

Wie belastbar ist die zugrundeliegende „Studie“?

Genau so würde ich den Text auch einordnen: als interessante Verhaltensbeobachtung mit echtem Signal, aber nicht als letzten Beweis dafür, wie „der Konsument“ nun grundsätzlich in AI-Interfaces handelt.

Der große Pluspunkt ist, dass hier tatsächliches Verhalten beobachtet wird und nicht nur Selbstauskünfte.

Der große Haken ist: kleines, kuratiertes Sample, Ausschlüsse im Rekrutierungsprozess, stark kontextgebundene Aufgaben und ein deutlich ungleiches Verhältnis von 149 AI-Mode- zu 36 Search-Beobachtungen.

Das ist für explorative UX-Forschung völlig legitim, aber nicht die Grundlage für allzu absolute Marktaussagen.

Was ich für belastbar halte, ist die Grundrichtung des zentralen Befunds: In diesem Setup zieht AI Mode einen Teil der Vergleichsarbeit in die Oberfläche selbst hinein. Viele Teilnehmende blieben im AI-Output, viele klickten gar nichts, und externe Besuche wirkten häufiger wie Bestätigung bereits akzeptierter Kandidaten als wie echte Exploration. Aber gerade bei den harten Prozentwerten wäre ich vorsichtig. Der Report nennt für direkte Übernahme der AI-Shortlist einmal 74 Prozent und später 88 Prozent. Das spricht nicht gegen den Effekt, aber klar gegen die Präzision, mit der er kommuniziert wird.

Relativ stark finde ich auch den Rang-Effekt. Dass der erstgenannte Kandidat überproportional häufig gewählt wird, passt nicht nur zu dieser Studie, sondern auch zu breiter Forschung zu Position Bias in Ranglisten und Empfehlungssystemen. Anders gesagt: Dass der Top-Pick des Systems häufig zum Top-Pick des Nutzers wird, ist psychologisch und informationswissenschaftlich sehr plausibel. Ob es hier exakt 74 Prozent sind, ist weniger wichtig als die Richtung des Effekts.

Auch die These, dass Vertrauen im AI-Modus anders entsteht, halte ich im Kern für plausibel: weniger Triangulation über mehrere Quellen, mehr Wirkung von Formulierung, Struktur und Markenvertrautheit. Dafür gibt es auch Anschluss an bestehende Forschung: Vertrauen in Algorithmen wächst unter anderem mit Vertrautheit, und bei schwierigeren Aufgaben greifen Menschen oft stärker auf algorithmische Hinweise zurück. Nur sollte man die exakte Messung im Report nicht überlesen: An einer Stelle heißt es, AI framing habe in 48 Prozent der AI-Mode-Fälle den Ausschlag gegeben, in der Tabelle selbst stehen 37 Prozent. Auch hier ist die Richtung glaubwürdig, die Feinmessung aber wacklig.

Ebenso ernst nehme ich den Befund, dass Abwesenheit im AI-Set problematisch ist. In den AI-Mode-Daten konzentrierten sich die finalen Entscheidungen je nach Kategorie stark auf wenige Marken, und der Report formuliert ausdrücklich, dass Marken außerhalb der AI-generierten Shortlist oft gar nicht bewertet wurden. Das ist noch kein Naturgesetz des Marktes, aber ein valider Hinweis darauf, dass generative Interfaces Sichtbarkeit stärker in kleine Kandidatensets bündeln können als klassische Suchergebnisseiten.

Was ich daraus nicht machen würde, ist eine große Allgemeinaussage über „den Konsumenten“. Dafür ist die Studie zu klein, zu kuratiert und zu kontextspezifisch. Wir reden über 48 US-Personen, vier Produktkategorien, ein Think-aloud-Setting, monetär incentivierte Teilnahme und eine deutliche Asymmetrie zwischen AI-Mode- und Search-Beobachtungen. Vor allem: Der Report selbst bittet darum, die Prozentwerte nicht als population-level estimates zu lesen. Wer daraus dennoch harte Marktprozente baut, liest mehr hinein, als die Studie sauber hergibt.

Ich würde außerdem keine saubere Kausalbehauptung aus der Prompt-Frage ableiten. Der Report zeigt zwar, dass in AI Mode häufiger natürlichsprachlich formuliert wurde und verbindet das mit stärkerer Delegation. Zugleich steht im Material selbst, dass die Search-Aufgaben nach zwei AI-Mode-Aufgaben stattfanden und diese Reihenfolge das Query-Verhalten beeinflusst haben kann. Das ist ein interessanter Zusammenhang, aber eben kein sauber isolierter Ursache-Wirkungs-Effekt.

Und die Zuspitzung „If you’re not in the list, you don’t exist“ ist mir als Wissenschaftssatz zu hart. Als aufmerksamkeitsstarke Marketing-Formel funktioniert sie, aber sie überzieht den Datenraum. Seriöser wäre: In dieser Studie wurden Marken außerhalb der AI-Shortlist deutlich seltener oder gar nicht aktiv berücksichtigt. Ähnlich vorsichtig wäre ich bei der Versicherungs-These. Dass Teilnehmende dort zum Teil zu viel Vertrauen in formatierte Zahlen legten, ist ein wichtiges Warnsignal – aber es basiert im Report auf 16 kodierten Insurance-Fällen, von denen 10 als overconfident/rash bewertet wurden. Das ist Hypothesengenerierung, noch keine ausbuchstabierte Gesetzmäßigkeit.

Der Punkt ist also nicht, dass der Artikel „falsch“ wäre. Im Gegenteil: Die Richtung seiner Geschichte passt gut zu bekannter Forschung zu Automation Bias, algorithmischer Akzeptanz und Position Bias.

Menschen können algorithmische Hinweise übergewichten, besonders wenn Aufgaben schwierig sind oder wenn die Oberfläche die Vergleichsarbeit schon vorstrukturiert. Zugleich zeigt breitere Forschung, dass Algorithmen in entscheidungsnahen Kontexten durchaus einen anfänglichen Vertrauensvorsprung haben können, dieser aber bei sichtbaren Fehlern auch schnell wieder kippt.

Genau deshalb ist der Report interessant: Er zeigt ein Verhalten, das theoretisch anschlussfähig ist – nur eben noch nicht mit der Präzision, die der Tonfall des Blogposts an manchen Stellen nahelegt.

Meine wissenschaftlich bereinigte Kurzfassung wäre deshalb diese:

In einer kleinen, beobachtungsbasierten Usability-Studie verschob Google AI Mode bei ausgewählten High-Stakes-Kaufaufgaben einen Teil der Vergleichs- und Verifikationsarbeit in die Oberfläche selbst. Nutzer blieben häufiger innerhalb der vom System vorstrukturierten Kandidatenmenge, der erste Rang gewann stark an Gewicht, und externe Besuche dienten eher der Bestätigung als der Exploration. Mehr kann man daraus im Moment guten Gewissens lesen. Alles darüber hinaus – harte Marktprozente, universelle Konsumentenpsychologie oder endgültige SEO-Gesetze – ist vorerst eher Zuspitzung als belastbare Wissenschaft.

Kevin Indigs dritter Teil seiner „Science of AI“-Reihe ist in einer Hinsicht der bislang stärkste: Er korrigiert genau den Denkfehler, der große Teile der GEO-/AI-SEO-Debatte prägt. Seine beste Aussage lautet nämlich nicht „So schreibt man für AI“, sondern:

Es gibt sehr wahrscheinlich keine universelle Formel.

Laut dem Artikel basiert die Auswertung auf rund 98.000 ChatGPT-Zitationszeilen aus etwa 1,2 Millionen ChatGPT-Antworten über sieben Verticals. Schon dadurch ist die wichtigste Erkenntnis keine magische Taktik, sondern Heterogenität.

Und genau dafür sollte man Kevin ausdrücklich Credit geben. Er macht etwas, das der GEO-Debatte oft fehlt: Er versucht, Behauptungen an Daten zu binden statt an Anekdoten.

Wer die Branche beobachtet, sieht ja vor allem einfache Rezepte: mehr Entities, mehr Headings, mehr Listen, weniger Hedging, mehr Authority, mehr Reddit. Teil 3 ist dort am stärksten, wo er zeigt, dass solche Schemata vertikalübergreifend nicht sauber tragen.

Trotzdem ist der Titel größer als die Evidenzbasis. Der Artikel heißt sinngemäß „what AI actually rewards“, aber der Datensatz misst eben nicht „AI“ im Allgemeinen, sondern ChatGPT-Zitationsverhalten in einem bestimmten Messaufbau.

OpenAI beschreibt ChatGPT Search selbst als System, dessen Ranking auf mehreren Faktoren beruht, ohne Garantie auf Top-Platzierung, und die Release Notes zeigen, dass Search-Qualität und Retrieval-Verhalten laufend angepasst werden. Wissenschaftlich sauber wäre daher eher der Titel: „Welche Merkmale in diesem ChatGPT-Datensatz mit mehr Zitationen assoziiert waren.“

Was an Teil 3 wirklich wertvoll ist

Der wichtigste Verdienst des Artikels ist die Absage an die Universalformel. Dass CRM/SaaS andere Muster zeigt als Finance oder Healthcare, ist keine Kleinigkeit, sondern vermutlich die belastbarste Pointe des gesamten Textes. Wissenschaftlich gesprochen reduziert diese Aufspaltung wenigstens einen Teil des Problems, das entsteht, wenn man heterogene Query- und Seitentypen in einen großen Topf wirft und dann aus dem Aggregat vermeintliche Regeln ableitet.

Für SEOs und GEOs ist genau das die brauchbare Lehre: Nicht „AI will X“, sondern „bestimmte Verticals und Seitentypen scheinen auf bestimmte Formate anders zu reagieren“.

Auch der UGC-Befund ist, bei aller Vorsicht, eher auf der robusteren Seite. Wenn in diesem Datensatz Corporate-/Editorial-Content rund 94,7% der Zitationen ausmacht und UGC nur einen kleinen Anteil, dann ist das als deskriptive Aussage erst einmal interessant – und vermutlich deutlich belastbarer als die feingranularen Aussagen über einzelne Writing-Signale. Das ist vor allem deshalb stärker, weil hier weniger von subtilen Feature-Konstruktionen und viel mehr von einfacher Häufigkeitsverteilung abhängt.

Die vorsichtige Formulierung müsste aber heißen: UGC dominiert in diesem ChatGPT-Datensatz und in diesen sieben Verticals nicht. Nicht: UGC sei generell strategisch irrelevant.

Hinzu kommt: Teil 2 der Reihe hatte bereits gezeigt, dass Zitationen stark von Seitentypen und Themenclustern geprägt sind. Dort heißt es, dass die Top-30-Domains rund 67% der Zitationen in einem Topic vereinen und dass die stärksten „evergreen“ Seiten typischerweise Kategorie-Guides, Vergleiche oder Verzeichnisse sind, die mehrere Query-Intents in einer URL bündeln. Das ist wichtig, weil Teil 3 sehr wahrscheinlich oft genau diese Seitentypen erneut misst – nur diesmal über Stellvertreter wie Heading-Anzahl, Zahlen, Datum oder Intro-Stil.

Was die Daten tatsächlich zeigen – und was nicht

Teil 3 zeigt beobachtete Zusammenhänge. Er zeigt nicht direkt, dass ein einzelner Hebel kausal „von AI belohnt“ wird. Das klingt nach einem semantischen Unterschied, ist aber methodisch zentral. Ein beobachteter Zusammenhang kann durch Confounding, Seitentypen, Intent, Query-Mix, Domain-Templates oder Selektionsmechanismen entstehen. STROBE erinnert genau daran, dass bei Beobachtungsstudien die vollständige Beschreibung von Design, Bias-Risiken und Auswertung entscheidend ist, damit Leserinnen und Leser Stärken und Grenzen überhaupt beurteilen können.

Das sieht man besonders deutlich an den starken Formulierungen im Text: „LLMs penalize hedging“, „KG presence is the wrong lever“, „3-4 headings are worse than zero in every vertical“. Solche Sätze lesen sich wie Kausalmechanismen. Tatsächlich sehen wir aber Korrelationen in einem Messaufbau, der viele Einflussfaktoren nicht explizit kontrolliert. Die ASA weist seit Langem darauf hin, dass statistische Signifikanz oder einzelne Kennzahlen weder Effektgröße noch Evidenzstärke ersetzen; hier liegt das Problem sogar noch vor der Signifikanzfrage: Schon die Übersetzung von Assoziation in Intervention ist zu forsch.

Noch wichtiger: Zumindest für die Heading-Analyse sagt der Artikel explizit, dass die Headings „across all cited URLs“ gezählt wurden. Insgesamt basiert Teil 3 laut Methodik auf Zitationsdaten aus ChatGPT-Antworten. Das heißt: Wir reden sehr wahrscheinlich nicht über ein sauberes Modell „welche Seiten werden überhaupt zitiert vs. nicht zitiert“, sondern häufig über Unterschiede innerhalb eines bereits sichtbaren, bereits selektierten Sets.

BMJ beschreibt genau dieses Problem allgemein: Wenn Analyse oder Design auf einer Variablen konditionieren, die von mehreren Ursachen beeinflusst wird, kann Selection Bias bzw. Collider Bias entstehen. Für die Praxis heißt das: Diese Ergebnisse sagen nicht sauber, was eine Seite aus der Unsichtbarkeit in die Sichtbarkeit hebt. Sie sagen eher, wie sich Merkmale unter bereits zitierten oder bereits im Pool gelandeten Seitentypen verteilen.

Dazu kommt ein zweites, in SEO/GEO besonders relevantes Abhängigkeitsproblem: Domains und Templates sind keine unabhängigen Beobachtungen. Teil 2 sagt selbst, dass die Zitationen stark konzentriert sind und dass bestimmte Seitentypen – Vergleichsseiten, Verzeichnisse, breite Kategorie-Guides – überproportional viel Citation Reach aufbauen. Wenn dieselben starken Domains hunderte URLs mit ähnlicher Informationsarchitektur publizieren, dann können „Page-Level-Signale“ leicht bloß Template-Effekte erfolgreicher Sites sein. Ohne ein hierarchisches Modell mit Domain- und Prompt-Clustering ist es methodisch zu kühn, aus solchen Korrelationen feine operative Regeln abzuleiten.

Die riesige Zahl „1,2 Millionen Antworten“ klingt zwar beeindruckend, löst dieses Problem aber nicht automatisch. Methodische Arbeiten zu LLM-Evaluationen zeigen, dass wiederholte Promptings stark korrelierte Outputs erzeugen können, und dass Ignorieren dieser Abhängigkeiten zu künstlich engen Konfidenzintervallen und zu kleinen p-Werten führt. Gleichzeitig zeigt Forschung zu RAG-Systemen, dass schon kleine Query-Variationen Retrieval-Ergebnisse spürbar verändern können. Große N sind in LLM-Studien deshalb kein Freifahrtschein für unabhängige Evidenz. Entscheidend ist die effektive, nicht nur die nominelle Stichprobengröße.

Die größten methodischen Schwachstellen im Detail

Ein auffälliges Problem ist die Vielzahl möglicher Vergleiche. Teil 3 arbeitet mit mehreren Writing-Signalen, sieben Verticals, zahlreichen Entity-Typen, mehreren Heading-Buckets und zusätzlichen Storylines zu UGC.

Genau in solchen Situationen warnen Gelman und Loken vor dem „garden of forking paths“: Selbst ohne bewusstes p-hacking können forschungslogische Freiheitsgrade und datengetriebene Auswahl zu überstarken Befunden führen.

Das Columbia-Material zur False Discovery Rate macht denselben Punkt aus einer anderen Perspektive: Viele parallele Tests erhöhen das Risiko von Zufallstreffern, wenn man sie nicht sauber kontrolliert. Gerade deswegen sollte man Schwellenwerte wie „3–4 Headings sind überall schlechter als 0“ eher als Hypothese behandeln als als robuste Regel.

Die Heading-Story ist überhaupt ein gutes Beispiel für Überinterpretation. Der Artikel summiert H1, H2 und H3 zu einer Gesamtzahl und gruppiert dann in Buckets wie 0, 1–2, 3–4, 5–9, 10–19, 20–49, 50+. Das erzeugt erzählbare Schwellen, ist aber analytisch grob. Eine Seite mit 1 H1, 8 H2 und 0 H3 ist strukturell etwas ganz anderes als eine Seite mit 1 H1, 2 H2 und 6 H3 – beide können aber in ähnlichen Buckets landen. Dazu kommt die Seitentyp-Konfundierung: In CRM/SaaS kann „20+ Headings“ einfach ein Produktvergleichs- oder Directory-Template bedeuten; in Healthcare kann „0 Headings“ mit knappen, institutionellen, hochvertrauenswürdigen Seiten zusammenfallen. Dann misst man nicht die Wirkung von Headings, sondern den Fingerabdruck eines Seitentyps.

Ähnlich vorsichtig muss man die Entity-Analyse lesen. Der Artikel nutzt Google Cloud Natural Language API auf den ersten 1.000 Zeichen des Textes und leitet daraus Aussagen über ChatGPT-Zitationswahrscheinlichkeit ab.

Das ist als Proxy nicht illegitim, aber es ist eben ein Google-definierter Proxy.

Google dokumentiert, dass Knowledge-Graph-Metadaten wie Wikipedia-URL und MID nur dann erscheinen, wenn sie verfügbar sind, und dass Entity-Mentions derzeit nur Eigennamen unterstützen. Daraus einen Satz wie „KG presence and brand authority do not translate to AI citation advantage“ zu machen, ist deutlich stärker als das Messinstrument hergibt. Gemessen wurde nicht „Brand Authority“, sondern die Verfügbarkeit bestimmter Google-NLP-Metadaten in einem kleinen Anfangsfenster des Textes.

Hinzu kommt eine kleine, aber methodisch interessante Unschärfe im öffentlichen Text: An einer Stelle ist von den ersten 1.000 Wörtern die Rede, später von den ersten 1.000 Zeichen. Vermutlich ist das ein redaktioneller Fehler oder eine Kurzfassung unterschiedlicher Teilanalysen. Aber genau solche Inkonsistenzen zeigen, warum knappe öffentliche Methodenbeschreibungen für harte operative Regeln nicht ausreichen. Wer starke Aussagen verkaufen will, muss starke Replizierbarkeit liefern.

Der DATE/NUMBER-Befund ist praktisch interessant, aber theoretisch deutlich unterbestimmt. Teil 2 hatte schon gezeigt, dass die besten evergreen URLs oft explizite Jahresanker in Titel oder URL tragen und breite Vergleichs- oder Guide-Formate bedienen. Außerdem zeigt klassische Temporal-IR-Forschung, dass Publikationszeit bei zeitsensitiven Queries ein relevanter Teil der Relevanzbewertung sein kann. Es ist also sehr gut möglich, dass DATE nicht deshalb „universell positiv“ ist, weil AI ein Datum als solches liebt, sondern weil bestimmte Query-Klassen und Seitentypen von Frische- und Zeitbezug profitieren. Daraus folgt nicht: Jetzt überall ein Datum reinwerfen. Daraus folgt: In zeit- und faktsensitiven Kontexten sind Frische und temporale Spezifität oft nützlich.

Auch der Befund zu direkten, deklarativen Intros ist nur dann sauber gelesen, wenn man ihn als Heuristik und nicht als Dogma versteht. Ja, ich halte es für plausibel, dass klare erste Sätze helfen. Aber wahrscheinlich nicht, weil „AI Sicherheit statt Vorsicht liebt“, sondern weil klare, dichte, low-noise Formulierungen für Retrieval und Paraphrase leichter anschlussfähig sind. Forschung zu neuronalen Retrievern zeigt, dass diese LLM-generierte bzw. semantisch fokussierte Texte bevorzugen können; andere Arbeiten zeigen, dass RAG-Pipelines schon auf kleine Query-Variationen empfindlich reagieren.

Die operative Konsequenz lautet daher: Sage früh klar, worum es geht. Nicht: Entferne überall epistemische Vorsicht, auch dort, wo sie inhaltlich geboten ist. Gerade in Wissenschaft, Medizin oder Regulierung wäre letzteres eine schlechte Norm.

Was SEOs und GEOs daraus wirklich mitnehmen sollten

Für die Praxis würde ich Kevin Indigs Teil 3 nicht als Sammlung von Rankingfaktoren lesen, sondern als Sammlung von guten Hypothesen für segmentierte Tests.

Die stärkste Einsicht ist nicht „mehr DATE, weniger PRICE, exakt X Headings“, sondern: Seitentyp, Query-Intent, Vertical und Informationsdichte sind wahrscheinlich wichtiger als pauschale AI-Writing-Regeln. Das ist im Kern auch eine Rückkehr zu gutem SEO-Denken – nur eben für eine neue Oberfläche.

Für SEOs heißt das: Testet nicht „funktioniert diese GEO-Regel?“, sondern „für welchen Seitentyp, in welchem Vertical, bei welchem Intent und in welcher Prompt-Klasse funktioniert sie – falls überhaupt?“

Klare Intros, frühe Entitäten, Zahlen, Daten und sichtbare Aktualität können sehr sinnvoll sein, wenn sie die Antwortdichte, Spezifität oder zeitliche Relevanz erhöhen. Kosmetisch eingebaut werden sollten sie aber nicht. Eine dekorative Zahl ist kein Signal. Ein relevantes Faktum ist eines.

Für GEOs ist außerdem wichtig, die Pipeline sauber zu trennen: Crawlability und Inclusion, Retrieval, Citation, Paraphrase. OpenAI sagt selbst, dass ChatGPT Search auf mehreren Faktoren basiert und dass Inclusion zunächst voraussetzt, dass OAI-Searchbot die Seite überhaupt crawlen darf. Teil 3 misst überwiegend Muster im Retrieval-/Citation-Layer. Wer daraus eine vollständige Strategie ableitet, verwechselt einen Pipeline-Abschnitt mit dem Gesamtsystem.

Und nein: Aus dem KG-Befund folgt nicht, dass Marke, Vertrauen und Autorität „der falsche Hebel“ seien. Was der Artikel zeigt, ist viel enger: In diesem Setup korreliert eine höhere Zahl Google-NLP-erkennbarer KG-Metadaten im Intro nicht mit höherer Citation-Breadth. Das ist etwas völlig anderes als der Satz „Brand spielt keine Rolle“. Zumal OpenAI Search explizit von reliable and relevant information spricht.

Die richtige Lesart lautet daher: Spezifität kann in diesem Datensatz sichtbarer gewesen sein als Prominenz. Nicht: Prominenz und Vertrauen sind irrelevant.

Wie man es wissenschaftlich sauberer testen müsste

Eine sauberere Studie würde erstens die Stufen des Problems trennen: nicht nur cited vs. more cited, sondern eligible vs. retrieved vs. cited. Zweitens würde sie keine grobe 3+-Schwelle als Hauptoutcome setzen, sondern Count-Modelle oder Hurdle-Modelle nutzen. Drittens würde sie Domain-, Template- und Prompt-Cluster explizit modellieren. Viertens würde sie Unsicherheiten berichten: Konfidenzintervalle, Sensitivitätsanalysen, FDR-Korrekturen oder gleich eine Multiverse-Analyse. Fünftens – und das wäre der eigentliche Goldstandard – würde sie kontrollierte Rewrite-Experimente auf derselben URL fahren: klare vs. vorsichtige Intros, Datum vs. kein Datum, unterschiedliche Heading-Strukturen, alles bei konstantem Thema, Domain und Seitentyp.

Außerdem müsste man die Zeitdimension ernst nehmen. ChatGPT Search ist kein statisches System; OpenAI dokumentiert laufende Qualitäts- und Retrieval-Updates. Dazu kommt, dass LLM-Ausgaben korreliert und RAG-Systeme query-sensitiv sind. Wer heute ein Muster misst, misst also immer auch eine Momentaufnahme eines Produkts in Bewegung.

Gute GEO-Forschung braucht deshalb Replikationen über Zeitfenster, Modellversionen und Prompt-Sets hinweg – nicht nur große Zahlen in einer einmaligen Auswertung.

Fazit

Mein Fazit zu Teil 3 ist deshalb zweigeteilt. Kevin Indig liegt sehr wahrscheinlich richtig, wenn er einfache GEO-Dogmen angreift und Vertikal-Spezifik betont. Genau dort ist sein Artikel am wertvollsten. Er geht aber zu weit, wenn er aus beobachteten Mustern direkte, quasi-kausale Hebel macht. Für SEOs und GEOs steckt die eigentliche Erkenntnis daher nicht in einer neuen Checkliste, sondern in einer besseren Grundannahme:

Es gibt keine allgemeine AI-Schreibformel. Es gibt kontextspezifische Seitentypen, Retriever-Artefakte, Query-Mixe und Sichtbarkeitsoberflächen, die man nur segmentiert und sauber getestet verstehen kann.

Update vom 23. März 2026: Kevin Indig hat inzwischen auch den zweiten Teil seiner Reihe veröffentlicht: The science of how AI picks its sources. Und der ist tatsächlich interessant – nicht, weil er alle offenen Fragen löst, sondern weil er die Perspektive verschiebt.

Während Teil 1 vor allem fragte, wo auf einer Seite ChatGPT bevorzugt zitiert, geht es jetzt um eine andere Ebene: Welche Seiten, Domains und URL-Typen kommen überhaupt regelmäßig in den Kandidatenpool? Laut Artikel analysiert Teil 2 „over 21K citations“; in den ausgewiesenen Teilanalysen arbeitet Indig unter anderem mit 21.482 ChatGPT-Citation-Rows für die Konzentrationsanalyse und 42.460 matched citations für die Positionsanalyse.

Teil 2 ist erschienen – und er verschiebt die Debatte

Der wichtigste Punkt zuerst: Teil 2 widerspricht meiner Kritik am ersten Text nicht. Er macht die Arbeit nützlicher, aber nicht automatisch allgemeingültiger. Denn beobachtet werden hier ChatGPT-Zitationen, nicht „KI-Suche“ als Ganzes.

Und wie schon beim ersten Teil gilt: Die große Zahl sorgt für Aufmerksamkeit, die eigentliche Aussagekraft steckt in den kleineren, engeren Teilstichproben.

Genau deshalb bleibt es sinnvoll, das Ganze eher als proprietäre Benchmark denn als wissenschaftliche Letztbegründung zu lesen.

Der eigentliche Fortschritt liegt im Ebenenwechsel.

Sein erster Text war vor allem eine Analyse der Passage-Selection: Warum werden bestimmte Sätze, Absätze oder Blöcke eher zitiert als andere? Teil 2 geht eine Stufe höher und schaut auf Source-Selection: Welche Domains tauchen überhaupt wiederholt auf, welche URL-Typen funktionieren, und wie verteilt sich Zitationssichtbarkeit über Themenräume hinweg? Das ist für GEO extrem relevant, weil damit plötzlich nicht nur Schreibstil und Textstruktur zählen, sondern auch Seitentyp, Query-Breadth und Content-Architektur.

Besonders spannend ist die Frage nach der Marktkonzentration. In der dafür ausgewiesenen Teilstichprobe ziehen die Top-10-Domains 46 Prozent aller Zitationen, die Top 30 sogar 67 Prozent.

Das ist keine kleine Schieflage, sondern ein echter Konzentrationseffekt.

Gleichzeitig variieren die Verticals massiv: Education ist stark konzentriert, Healthcare deutlich offener, CRM/SaaS und HR Tech eher diffus.

Die praktische Konsequenz daraus ist simpel:

Es gibt kein universelles GEO-Playbook. Was in Education funktioniert, kann in Healthcare schon wieder komplett anders aussehen.

Noch interessanter finde ich den URL-Befund: Laut Teil 2 erscheinen im Durchschnitt 67 Prozent der zitierten URLs nur in genau einem Prompt.

Die kleine Spitzengruppe mit echter Wiederholbarkeit sieht dagegen fast immer ähnlich aus: Vergleichsseiten, Category-Level-Guides oder Verzeichnis-/Listing-Seiten, die mehrere benachbarte Nutzerfragen auf einer URL bündeln.

Indig formuliert das ziemlich klar: Die Top-4,8 Prozent der URLs, die in 10 oder mehr Prompt-Kontexten zitiert werden, sind durchgehend Seiten, die „Was ist das?“, „Wer nutzt das?“, „Wie wählt man es aus?“ und „Was kostet es?“ gemeinsam auf einer Adresse beantworten.

Das ist ein wichtiger Shift für GEO:

Nicht nur einzelne Absätze müssen zitierfähig sein – ganze URLs müssen mehrere relevante Intents glaubwürdig abdecken.

Der Front-Loading-Effekt aus Teil 1 wird in Teil 2 bestätigt, aber zugleich präzisiert. Das unterste Seiten-Decile ist für ChatGPT fast totes Land: Je nach Vertical landen dort nur 2,4 bis 4,4 Prozent der Zitationen. Gleichzeitig liegt der eigentliche Peak laut Teil 2 häufig nicht im allerersten Decile, sondern eher im Bereich 10 bis 20 Prozent der Seite.

Der Grund ist plausibel: Die ersten 10 Prozent sind oft Navigation, Überschrift, Intro-Fluff und Boilerplate. Heißt praktisch: Nicht einfach „möglichst ganz oben“, sondern möglichst früh im ersten gehaltvollen Inhaltsblock müssen Definitionen, Zahlen, Vergleiche und klare Aussagen stehen.

Auch die Längenfrage wird durch Teil 2 eher differenzierter als simpler. Der Artikel zeigt zwar grundsätzlich einen positiven Zusammenhang zwischen Seitenlänge und Zitationshäufigkeit, betont aber selbst, dass der Effekt vertikalabhängig ist.

Für sehr kurze Seiten unter 1.000 Wörtern sieht es in allen Verticals schlecht aus. Aber schon bei Finance kippt die Logik teilweise: Dort schneiden kompaktere, autoritative Seiten, Tabellen und regulatorische Zusammenfassungen besser ab als immer längere Guides. In Education, Crypto und Product Analytics hilft Länge stärker; in SaaS zählt Struktur offenbar mehr als reine Wortmasse.

Auch hier ist die Lehre also nicht „mach es länger“, sondern „triff die Formatlogik deines Themas“.

Was in Teil 2 weiterhin fehlt, ist eine echte Trennung zwischen Retrieval, Auswahl und Zitat.

Genau da hilft die ergänzende AirOps-Analyse vom 12. März 2026 weiter. Sie basiert auf 15.000 Originalprompts, 43.233 Original- plus Fan-out-Queries und 548.534 abgerufenen Seiten. Das Ergebnis ist ziemlich ernüchternd: 85 Prozent der von ChatGPT abgerufenen Seiten werden nie zitiert. Auf 89,6 Prozent der Suchen erzeugt ChatGPT zwei oder mehr Fan-out-Queries, und 32,9 Prozent der zitierten Seiten, die überhaupt in Top-20-SERPs auftauchen, wurden ausschließlich über solche Fan-out-Suchen sichtbar.

Übersetzt: Gute Copy allein reicht nicht. Wer gar nicht erst im erweiterten Recherchepfad auftaucht, kann noch so schön formulieren – zitiert wird er trotzdem nicht.

Genau deshalb ist Teil 2 für die Praxis wertvoller als Teil 1 allein. Er zeigt, dass GEO auf mindestens drei Ebenen stattfindet: Passage, URL und Themenraum.

1. Auf Passage-Ebene bleiben die alten Regeln gültig: Klarheit, frühe Platzierung, hohe Entitätsdichte, konkrete Aussagen.
2. Auf URL-Ebene gewinnen Seiten, die mehrere benachbarte Fragen strukturiert bündeln.
3. Und auf Themenraum-Ebene entscheidet die Marktstruktur darüber, ob du in einem offenen Feld spielst oder gegen eine Handvoll bereits zementierter Gewinner antreten musst.

Diese drei Ebenen gehören zusammen. Wer nur schöner schreibt, verliert. Wer nur breiter clustert, aber keine zitierfähigen Passagen liefert, ebenfalls.

Trotzdem bleibt methodische Vorsicht angebracht. Der frei zugängliche Text des zweiten Teils enthält selbst kleine definitorische Stolperstellen: Eine Überschrift spricht davon, dass 58 Prozent der zitierten URLs nur einmal auftauchen, im Ergebnisteil stehen dann 67 Prozent. Außerdem springt die Längenpassage zwischen Wörtern und Zeichen.

Das sind keine vernichtenden Einwände, aber sie sind ein guter Reminder: Wir lesen hier keine peer-reviewte Grundlagenforschung, sondern eine nützliche, proprietäre Branchenanalyse. Und genau so sollte man sie auch behandeln.

Mein Fazit nach Veröffentlichung von Teil 2

Die ursprüngliche Kernthese bleibt richtig, wird aber breiter.

Ja, ChatGPT bevorzugt klare, frontgeladene und gut strukturierte Inhalte. Aber Sichtbarkeit in KI-Antworten entsteht nicht nur auf Satzebene.

Sie entsteht auch auf der Ebene von Seitentypen, Query-Clustern und ganzen Themenarchitekturen.

GEO ist damit weder bloß „schreib sauberer“ noch bloß „bau Pillar Pages“.

Es ist die Verbindung aus zitierfähiger Passage, intelligenter URL-Architektur und strategischer Themenabdeckung.

Methodische Einordnung: Was ist Teil 2 wissenschaftlich wert?

Weil ich den ersten Teil ausführlich methodisch zerlegt habe, ist es nur fair, auch Teil 2 nach denselben Maßstäben einzuordnen. Und das Ergebnis ist differenzierter, als ein einfaches Daumen-hoch oder -runter vermuten lässt.

Am treffendsten ist Teil 2 als explorative, nicht-experimentelle Beobachtungsanalyse mit proprietärer Datenbasis einzuordnen.

Der Text erscheint als Growth-Memo-Beitrag, nicht als Fachpublikation. Im Methodikteil beschreibt Indig rund 98.000 ChatGPT-Citation-Rows aus etwa 1,2 Millionen ChatGPT-Antworten über sieben Verticals. Die einzelnen Kernaussagen operieren aber mit ganz unterschiedlichen Teilstichproben: 21.482 Citation-Rows und 670 Domains für die Konzentrationsanalyse, 42.460 matched citations für die Positionsauswertung, 2.344 URLs und 127 Prompts an anderer Stelle. Als Analyseverfahren kommen unter anderem Structural Parsing, Jaccard-Sliding-Window-Similarity für die Positionszuordnung sowie Entity- und Sentiment-Extraktion per Google Natural Language API und TextBlob zum Einsatz.

Was gut dokumentiert ist – und was nicht

Für die Einordnung eignet sich die STROBE-Leitlinie als Maßstab. Wichtig: STROBE ist kein Gütesiegel für Methodenqualität, sondern ein Standard dafür, was Leserinnen und Leser über Design, Variablen, Bias, Studiengröße, statistische Methoden und Limitationen erfahren sollten.

Nach diesem Maßstab ist Teil 2 besser dokumentiert als viele reine SEO-Meinungsstücke – aber er bleibt deutlich unter dem Niveau einer voll transparent berichteten Beobachtungsstudie.

Was da ist: Datengröße, Verticals, einzelne Analyseverfahren.

Was fehlt: Der Sampling-Frame der Prompts, Ein- und Ausschlussregeln, der genaue Erhebungszeitraum, systematische Bias-Adressierung, Sensitivitätsanalysen und Präzisionsmaße.

Das Reproduzierbarkeitsproblem

Die größte methodische Schwäche betrifft die unabhängige Prüfbarkeit. Die National Academies unterscheiden zwischen direkter rechnerischer Reproduzierbarkeit und indirekter Transparenzprüfung – und betonen, dass Reproduktionen oft schon an zu wenig Detail zu Daten, Code und Workflow scheitern.

Im Fall von Teil 2 werden weder Rohdaten noch Code offengelegt. Die zugrunde liegende Datenbasis stammt aus Gauge, einer proprietären Plattform.

Eine unabhängige Reproduktion der Ergebnisse ist für Dritte damit derzeit praktisch nicht möglich.

Korrelation, nicht Kausalität

Beobachtungsstudien sind nicht randomisiert und deshalb grundsätzlich anfällig für Confounding. Ohne explizite Adjustierungen lassen sich aus ihnen primär Assoziationen ableiten, keine belastbaren Ursache-Wirkung-Aussagen.

Teil 2 berichtet zwar Unterschiede nach Seitenlänge, URL-Typ und Position auf der Seite – aber keine multivariaten Adjustierungen, Konfidenzintervalle oder Robustheitsanalysen. Aussagen wie ein angeblicher „citation advantage“ ab einer bestimmten Textlänge sollte man deshalb als deskriptive Korrelationen in diesem Datensatz lesen, nicht als Nachweis einer isolierten kausalen Wirkung von Textlänge.

Externe Validität: gemischt

Positiv ist, dass die Analyse sieben Verticals separat betrachtet – ausdrücklich, um themenspezifische Muster nicht in einer Gesamtauswertung zu verwischen. Gleichzeitig bleibt der Geltungsbereich eng: Untersucht werden ChatGPT-Zitationen aus einer proprietären Gauge-Datenbasis, nicht mehrere Modelle unter identischen Bedingungen und auch nicht „KI-Suche“ im Allgemeinen.

Die Ergebnisse sind am überzeugendsten als ChatGPT-nahe Marktbeobachtung und als Hypothesengenerator zu lesen – nicht als universelles Gesetz darüber, wie „AI“ allgemein Quellen auswählt.

Ein Wort zur Unabhängigkeit

STROBE verlangt ausdrücklich Angaben zur Finanzierung und zur Rolle der Geldgeber. Im Beitrag wird Gauge als Datenquelle genannt; zugleich enthält derselbe Abschnitt eine Rabattaktion für Growth-Memo-Abonnenten auf Gauge. Das beweist keinen Fehler in den Ergebnissen – aber es erhöht aus wissenschaftlicher Sicht den Bedarf an sauberer Offenlegung, externer Validierung und unabhängigen Replikationen.

Mein nüchternes Urteil

Teil 2 ist keine „Studie“ im starken Sinn eines transparent reproduzierbaren Fachartikels. Er ist eine explorative, proprietäre Beobachtungsanalyse mit hohem Praxiswert und begrenzter Beweiskraft.

Stark genug, um Hypothesen zu generieren, Muster sichtbar zu machen und operative Benchmarks für GEO zu liefern. Für robuste kausale Aussagen oder allgemein verbindliche Regeln wären offenere Daten, vollständigeres Reporting, Unsicherheitsmaße, Sensitivitätsanalysen und unabhängige Replikationen notwendig.