Sichtbarkeit & KI-Suche1. September 2026 

Technisches SEO für KI-Sichtbarkeit: was belegt ist, was abgeschrieben wird, und was am 15. September passiert

Veröffentlicht
Lesedauer
min
Aktualität
aktuell
Technisches SEO für KI-Sichtbarkeit: was belegt ist, was abgeschrieben wird, und was am 15. September passiert

Das Wichtigste in Kuerze

Die gängigen Empfehlungen zur KI-Sichtbarkeit sind technisch richtig, aber ihr Belegstand ist schlechter als ihr Ton. Die zentrale Behauptung, KI-Crawler führten kein JavaScript aus, stützt sich auf eine einzige Messung vom Dezember 2024. Die verbreitete Zahl, sie brächen nach ein bis fünf Sekunden ab, hat keine Herstellerquelle. Gleichzeitig steht am 15. September 2026 eine Änderung an, die konkreter ist als jede Checkliste: Cloudflare stellt die Standardeinstellung für KI-Crawler um, und wer dabei Trainings-Bots blockiert, sperrt laut Cloudflare auch Googlebot aus.

Der Termin, der vor allen Checklisten kommt

Am 15. September 2026 ändert Cloudflare die Voreinstellung für KI-Crawler. Laut Cloudflare, 1. Juli 2026 teilt der Anbieter sie in drei Kategorien: Search, Agent und Training. Für neu bei Cloudflare aufgeschaltete Domains gilt dann: Training und Agent sind auf werbeführenden Seiten standardmäßig blockiert, Search bleibt erlaubt.

Das klingt nach einer Entscheidung für Publisher. Der eigentlich kritische Satz steht an anderer Stelle im selben Beitrag. Cloudflare schreibt, dass „multi-purpose crawlers such as Googlebot, Applebot, and BingBot“ blockiert werden, wenn ein Kunde sich für das Blockieren von Trainings-Bots entscheidet.

Diese Bots haben mehrere Aufgaben zugleich. Googlebot crawlt für die klassische Suche und speist zugleich die KI-Funktionen von Google. Eine Einstellung, die als Schutz vor Trainingsdatennutzung gemeint ist, kann damit die normale Indexierung mit abschalten. Wer im CDN einen Haken setzt, um sein Material aus KI-Modellen herauszuhalten, kann versehentlich seine Google-Sichtbarkeit beenden.

Das ist kein hypothetisches Risiko und keine Frage der Strategie. Es ist ein Schalter, dessen Nebenwirkung im Text des Anbieters steht.

Was wir dazu ausdrücklich nicht behaupten: Cloudflare nennt dort als Geltungsbereich „all new domains onboarding to Cloudflare“. Verschiedene Fachbeiträge lesen die Umstellung weiter, etwa dass sie auch für neu hinzugefügte Sites von Bestandskunden und für unveränderte Konten im kostenlosen Tarif greife. Diese weitergehende Lesart konnten wir am Originaltext nicht bestätigen. Wer betroffen sein könnte, prüft seine eigenen Einstellungen, statt sich auf eine Zusammenfassung zu verlassen.

Unsere eigenen Zahlen, und warum sie unbequem sind

Bevor wir Empfehlungen sortieren, legen wir unsere eigene Ausgangslage offen. Sonst steht dieser Text auf demselben Fundament wie die Ratgeber, die er prüft.

waterproof.agency erfüllt praktisch jede gängige technische Anforderung. Die Site läuft auf TYPO3 und rendert serverseitig, kein Inhalt hängt an JavaScript. Die HTML-Struktur ist sauber. Die XML-Sitemap ist eingereicht. In unserer robots.txt ist kein einziger KI-Bot blockiert, alle laufen über User-agent: * und sind erlaubt. Statuscodes und Canonicals stimmen.

Und das ist das Ergebnis, gemessen am 1. September 2026 über die Search-Console-API für den Zeitraum 2. bis 29. August:

SeiteKlicksImpressionenPosition
/101806,2
/cms/typo30445,5
/en/0342,6

Drei URLs. Bei knapp zweihundert Seiten in der Sitemap. Kein einziger Blogartikel ist darunter.

Der Grund ist kein technischer Defekt, sondern ein Domainumzug: Die Inhalte sind unter der alten Adresse weiterhin indexiert und ranken dort, während Google die neue Domain crawlt und noch nicht indexiert. Das ist ein Vorgang von Wochen bis Monaten, und er läuft.

Für dieses Thema ist der Befund trotzdem der entscheidende. Technisches SEO für KI-Sichtbarkeit setzt Indexierung voraus. Google schreibt selbst, dass eine Seite indexiert sein muss, um überhaupt als unterstützender Link in KI-Antworten in Frage zu kommen. Wer nicht im Index steht, kann seine Überschriften-Hierarchie beliebig verfeinern und seine Ladezeit halbieren, ohne dass sich etwas bewegt.

Vier Modelle, zehn Fragen, ein klares Muster

Am 25. August haben wir zehn kaufnahe Fragen an vier Modelle gestellt und gezählt, wie oft wir genannt wurden.

ModellNennungen
perplexity/sonar6 von 10
openai/gpt-4.1-mini2 von 10
anthropic/claude-haiku-4.50 von 10
google/gemini-2.5-flash0 von 10

Die Trennlinie verläuft nicht zwischen Anbietern, sondern zwischen suchen und nicht suchen. Modelle, die zur Antwortzeit im Web nachschlagen, nennen uns. Modelle, die aus dem Gedächtnis antworten, nennen uns nicht.

Das hat eine Folge, die in der Crawler-Diskussion selten ausgesprochen wird: Der ganze Werkzeugkasten aus robots.txt, Rendering und strukturierten Daten wirkt nur auf den suchenden Teil. Für den nicht suchenden Teil entscheidet, ob eine Marke im Trainingsmaterial und in fremden Quellen vorkommt, und dafür ist keine technische Einstellung zuständig.

Wir halten das für die wichtigere Unterscheidung als die zwischen Trainings- und Suchcrawlern, weil sie sich direkt darauf auswirkt, worauf Aufwand sinnvoll ist.

Die sieben üblichen Hebel und ihr tatsächlicher Belegstand

Der Fachbeitrag von Seokratie vom 14. August 2026 fasst den Stand der Branche gut zusammen: Crawlbarkeit, JavaScript, Seitenarchitektur, Ladezeit, strukturierte Daten, HTML-Grundlagen, llms.txt. Wir teilen die Stoßrichtung. Uns interessiert etwas anderes, nämlich woher die einzelnen Aussagen ihre Sicherheit nehmen.

EmpfehlungBelegstand
KI-Bots in robots.txt nicht blockierenBelegt. Die Crawler-Namen und ihre Steuerung stehen in der Dokumentation von OpenAI, Anthropic und Perplexity.
Inhalte gehören ins initiale HTMLBelegt, aber der Beleg ist vom 17.12.2024.
KI-Crawler brechen nach ein bis fünf Sekunden abNicht belegt. Keine Herstellerquelle auffindbar.
Saubere Überschriften-Hierarchie, eigenständige AbsätzePlausibel, aber kein Anbieter dokumentiert, wie er Text zerlegt.
FAQPage-Markup einsetzenTeilweise überholt. Google liefert das Feature nicht mehr aus.
llms.txt anlegenUnbelegt, von allen Beteiligten als Experiment bezeichnet.
Sitemap einreichen, Canonicals und Statuscodes prüfenBelegt und unstrittig. Das ist klassisches SEO.

Diese Tabelle ist keine Widerlegung. Sie ist eine Sortierung. Der Unterschied zwischen „dokumentiert“ und „plausibel“ entscheidet, wie viel Aufwand eine Maßnahme verdient.

Der JavaScript-Befund und sein Datum

Die Aussage, dass KI-Crawler kein JavaScript ausführen, trägt einen großen Teil der aktuellen Fachliteratur. Sie stammt in nahezu allen Fällen aus derselben Quelle: einer Analyse von Vercel vom 17. Dezember 2024 mit dem Titel „The rise of the AI crawler“.

Dort steht wörtlich: „none of the major AI crawlers currently render JavaScript“. Untersucht wurden die Bots von OpenAI, Anthropic, Meta, ByteDance und Perplexity, auf Basis der Beobachtung von nextjs.org und des Vercel-Netzwerks sowie zweier Stellenportale.

Drei Dinge daran werden beim Weiterreichen regelmäßig verloren.

Erstens das Datum. Der Beitrag ist vom 17. Dezember 2024. Er ist damit über zwanzig Monate alt. In einem Feld, in dem Anbieter im Quartalstakt Crawler umbauen, ist das kein aktueller Messwert, sondern ein historischer. Eine Wiederholungsmessung mit vergleichbarer Datenbasis haben wir nicht gefunden. Falls es sie gibt, nehmen wir den Hinweis gern auf.

Zweitens die Präzisierung. Vercel unterscheidet sauberer als seine Nachnutzer: „ChatGPT and Claude crawlers do fetch JavaScript files... they don't execute them“. Die Dateien werden also geladen, nur nicht ausgeführt. Für die Praxis läuft das aufs Gleiche hinaus, für die Diagnose nicht: Wer im Server-Log sieht, dass ein KI-Bot .js-Dateien abruft, darf daraus nicht schließen, dass er sie auch rendert.

Drittens die Ausnahmen. Im selben Text steht, dass Gemini über die Infrastruktur von Googlebot läuft und damit vollständig rendert, und dass AppleBot ebenfalls rendert. Die pauschale Formel „KI-Crawler rendern nicht“ ist also schon in ihrer eigenen Quelle falsch.

Und ein Interessenhinweis, den man mitdenken sollte: Vercel verkauft serverseitiges Rendering. Das macht die Messung nicht falsch. Es ist ein Grund mehr, sie nicht als einzige Grundlage stehen zu lassen.

Praktisch bleibt die Empfehlung dieselbe. Inhalte, die nur nach JavaScript-Ausführung erscheinen, sind für einen Teil der Systeme unsichtbar. Wer TYPO3, WordPress oder ein anderes serverseitig gerendertes System betreibt, hat dieses Problem ohnehin nicht. Es trifft Single-Page-Anwendungen und nachgeladene Inhaltsbereiche.

Die Timeout-Zahl, die niemand belegt

„KI-Crawler warten nur ein bis fünf Sekunden“ ist eine der meistzitierten Zahlen des Themas. Wir haben nach einer Primärquelle gesucht und keine gefunden.

OpenAI, Anthropic und Perplexity dokumentieren ihre Crawler, ihre User-Agent-Namen und teilweise ihre IP-Bereiche. Ein Timeout nennen sie nicht. Die Vercel-Analyse, die sonst als Beleg herhalten muss, erwähnt Timeouts mit keinem Wort. Auffindbar sind nur Fachblogs, die sich gegenseitig zitieren.

Das heißt nicht, dass die Zahl falsch ist. Crawler haben Zeitgrenzen, das ist technisch selbstverständlich. Es heißt, dass die konkrete Spanne bislang eine Behauptung ist und keine Messung. Wer sein Budget nach dieser Zahl ausrichtet, richtet es nach einer Vermutung aus.

Der brauchbare Kern bleibt: Eine langsame Seite ist für jeden abrufenden Dienst ein Risiko. Dafür braucht es keine erfundene Sekundenzahl.

Was Google im Mai und im Sommer geändert hat

Zwei Änderungen betreffen das Thema direkt, und beide werden häufig verkürzt wiedergegeben.

FAQPage. Google hat die Dokumentation zum FAQ-Rich-Result entfernt, weil das Feature in den Suchergebnissen nicht mehr ausgeliefert wird. Wer FAQPage-Markup pflegt, um erweiterte Suchergebnisse zu bekommen, tut das seither ohne Wirkung.

Bemerkenswert ist, was Google nicht sagt: Eine Aufforderung, das Markup zu entfernen, gibt es nicht. Die Auszeichnung bleibt gültiges strukturiertes Datenmaterial. Ob KI-Systeme sie auswerten, ist eine offene Frage, zu der kein Anbieter etwas dokumentiert. Unsere Empfehlung lautet deshalb: bestehendes Markup stehen lassen, aber keine Arbeitszeit mehr in neues FAQ-Markup investieren, das allein auf die Suchdarstellung zielt.

Der Generative-AI-Bericht in der Search Console. Google hat einen Bericht ergänzt, der Impressionen in generativen KI-Funktionen ausweist. Die Hilfeseite definiert eine Impression als „wie oft Links zu Ihrer Website einer Nutzerin oder einem Nutzer in einer generativen KI-Funktion in der Google Suche präsentiert wurden“. Als Dimensionen nennt sie Seiten, Länder, Zeitraum und Geräte.

Zwei Einordnungen dazu, die in der Fachdiskussion untergehen.

Der Bericht weist keine Klicks aus, nur Impressionen. Wer daraus einen Wirkungsnachweis bauen will, hat die halbe Kette. Und die Definition ist enger, als sie oft wiedergegeben wird: Es geht um präsentierte Links, nicht um jede Form der inhaltlichen Verwertung. Ein Modell kann Inhalte einer Website in seine Antwort einarbeiten, ohne dass ein Link erscheint. Dieser Fall taucht im Bericht nicht auf.

Zum Verbreitungsstand halten wir uns zurück. In der Branche kursiert, der Bericht sei seit Ende August weltweit verfügbar und die Daten begännen am 18. Mai 2026 ohne Rückrechnung. Googles eigene Hilfeseite beschreibt den Zugang weiterhin als auf eine Teilmenge der Websites beschränkt und nennt weder ein Startdatum noch einen fehlenden Backfill. Wir geben deshalb nur wieder, was dokumentiert ist. Wer den Bericht in seinem Konto sieht, hat ihn. Wer nicht, hat ihn noch nicht.

Was wir nicht wissen

Dieser Abschnitt gehört dazu, weil ein Text über Belegstände sonst mit zweierlei Maß misst.

Wir wissen nicht, ob die Rendering-Aussage von Ende 2024 heute noch zutrifft. Wir wissen nicht, wie die Anbieter Text intern zerlegen, und damit auch nicht, ob die Empfehlung zu eigenständigen Absätzen mehr ist als eine gut begründete Vermutung. Wir wissen nicht, ob strukturierte Daten für KI-Zitate etwas bewirken. Wir wissen nicht, wie oft welcher Bot unsere eigenen Seiten abruft, weil unser Hoster keine Server-Logs im Dateisystem vorhält.

Was wir wissen, steht in diesem Text mit Quelle daneben.

Was auf dem Spiel steht

Ein falsch gesetzter Schalter am 15. September legt keine Website lahm. Die Seiten bleiben erreichbar, sie laden normal, und in der Statistik sieht zunächst alles unverändert aus. Eine Fehlermeldung gibt es nicht, weil aus Sicht des Servers nichts kaputt ist.

Die Folge zeigt sich verzögert: Neue Seiten werden nicht mehr aufgenommen, geänderte Seiten nicht mehr aktualisiert, und der Bestand veraltet still. Wer keine Messreihe führt, bemerkt das oft erst, wenn der Rückgang groß genug ist, um in den Anfragen aufzufallen. Dann liegt die Ursache Monate zurück und ist nur noch schwer zuzuordnen.

Der umgekehrte Fall ist unspektakulär, und genau das ist der Punkt. Wer die Einstellung vor dem Termin einmal ansieht, hat danach nichts weiter zu tun.

Die Reihenfolge, die wir empfehlen

Die sieben Hebel sind keine Liste zum Abhaken. Sie sind eine Kette, in der jeder Schritt den vorigen voraussetzt. Die üblichen Checklisten stellen alle sieben nebeneinander, als lägen sie gleichzeitig an. In der Praxis gibt es fast immer einen bindenden Engpass, und der Rest ist Feinschliff daneben. Bei uns ist es die Indexierung. Bei einer Single-Page-Anwendung ist es das Rendering. Bei einer Site hinter einem falsch eingestellten CDN ist es der Zugang.

1. Zugang. Kommt der Bot überhaupt an? robots.txt prüfen, aber vor allem die Einstellungen im CDN und in der Firewall. Wegen des Cloudflare-Termins am 15. September ist das gerade der wichtigste Punkt der Liste. Welche Crawler es überhaupt gibt, worin sich Trainings-, Such- und Agent-Bots unterscheiden und was das Blocken einzelner Bots wirklich bewirkt, haben wir in KI-Crawler blocken oder zulassen auseinandergenommen. Dieser Beitrag hier setzt darauf auf und fragt nach dem Belegstand.

2. Auslieferung. Bekommt der Bot brauchbares HTML oder eine Weiterleitungskette, einen Fehlercode oder eine leere Hülle? Das ist eine Statuscode-Frage, keine Strategiefrage.

3. Indexierung. Steht die Seite bei Google im Index? Wenn nicht, ist alles Weitere verfrüht.

4. Struktur. Sauberes HTML, klare Überschriften, Absätze, die für sich stehen. Das nützt Lesern und Maschinen gleichermaßen und kostet wenig.

5. Belege. Eigene Zahlen, nachprüfbare Aussagen, genannte Quellen. Was inhaltlich nichts hergibt, wird auch nicht zitiert.

6. Strukturierte Daten. Sinnvoll, aber unter Praktikern offen strittig, was sie für KI-Zitate tatsächlich bewirken. Wir behandeln sie als Hygiene, nicht als Hebel.

7. llms.txt. Ein Experiment ohne Wirkungsnachweis. Anlegen kostet zehn Minuten, mehr Aufwand ist derzeit nicht zu rechtfertigen.

Prüfschritte für die nächsten zwei Wochen

Alles Folgende kostet zusammen weniger als eine Stunde.

Prüfe deine CDN-Einstellungen vor dem 15. September. Wenn du Cloudflare nutzt, sieh dir die Bot-Einstellungen an, bevor die neue Voreinstellung greift. Achte besonders auf die Option zum Blockieren von Trainings-Crawlern, weil sie laut Cloudflare Googlebot einschließt.

Ruf deine robots.txt auf. Steht dort ein KI-Bot mit Disallow, war das eine Entscheidung. Falls du dich nicht daran erinnerst, sie getroffen zu haben, ist sie einen zweiten Blick wert.

Deaktiviere JavaScript im Browser und lade deine wichtigste Seite. Was jetzt fehlt, sehen die meisten KI-Crawler nicht. Bei serverseitig gerenderten Systemen ändert sich nichts, und das ist das erwartete Ergebnis.

Sieh in der Search Console nach, wie viele deiner Seiten indexiert sind. Nicht wie viele in der Sitemap stehen. Die Lücke zwischen beiden Zahlen ist oft die eigentliche Aufgabe.

Prüfe, ob du den Generative-AI-Bericht in deinem Konto siehst. Falls ja, hast du ab dem Startzeitpunkt eine Zeitreihe. Falls nein, ist das kein Fehler deiner Website.

Fällt bei einem dieser Schritte etwas auf und du bist nicht sicher, wie es einzuordnen ist: Crawler-Setup abgleichen. Wir sehen uns deine Konfiguration an und sagen dir, welcher der sieben Punkte bei dir der bindende ist. Ohne Eingriff in laufende Systeme.

Zur Person

Ich bin Dennis Hüttner und arbeite seit 2007 mit TYPO3 und WordPress. Die Zahlen zur eigenen Indexierung in diesem Text stammen aus unserer laufenden Messreihe und sind nicht geschönt. Ich veröffentliche sie, weil ein Beitrag über technische Voraussetzungen wenig wert ist, wenn der Autor die eigene Ausgangslage verschweigt.