AI State of the Internet
Deutschland 2026

Wie reichweitenstarke Websites im DACH-Raum auf KI-Systeme reagieren: zwischen Öffnung, Kontrolle und Schutz.

Analyse von … dokumentierten Web-Crawlern und rund … sichtbaren Domains im DACH-Raum. Darunter … klassifizierte KI-Crawler und AI-Agents.

Warum das relevant ist

KI-Systeme verändern derzeit, wie Inhalte gefunden, verarbeitet und genutzt werden. Darauf reagieren Websites sehr unterschiedlich: von aktiver Öffnung für KI-Systeme bis hin zu stärkerem Schutz und Kontrolle der eigenen Inhalte. Dieser Monitor macht sichtbar, welche Strategien besonders sichtbare Domains im DACH-Raum im Umgang mit KI-Systemen verfolgen. Die Grundlage bilden rund 19.000 Domains aus Deutschland, Österreich und der Schweiz. Berücksichtigt werden pro Land die jeweils sichtbarsten Domains im offenen Web. Durch Überschneidungen zwischen den Ländern entsteht ein konsolidiertes DACH-Set.

Ländervergleich D-A-CH

Kern-KPIs pro Land · Tap auf eine Karte für die Detailansicht

Datenbasis

Internationale Plattformen und globale Services können separat betrachtet werden.

Je größer die Website, desto häufiger werden KI-Systeme blockiert

Vor allem große Plattformen und Publisher setzen zunehmend auf Kontrolle über KI-Zugriffe, Inhalte und Infrastruktur. KI-Zugriff wird zur Verhandlungs- und Machtfrage.

Reichweiten-Tiers basieren auf Google-Sichtbarkeit deutscher Domains.

Anteil mit aktiver KI-Blockierung

Erfasst werden Domains, die bekannte KI-Crawler (z. B. GPTBot, ClaudeBot, Google-Extended, PerplexityBot) per robots.txt vollständig oder selektiv sperren. Identische Definition zur "KI-Blockierungsrate" im Zeitreihen-Block oben.

Strategische Lesart

Was hier sichtbar wird, ist keine technische Randnotiz: Mit wachsender Marktmacht steigt die Kontrolle über KI-Zugriffe. Große Plattformen behandeln KI-Zugriff zunehmend als strategische Infrastrukturfrage — ähnlich der Aggregator-Konflikte der 2000er, der Paywall-Strategien und der Medienlizenz-Verhandlungen. Der Markt verschiebt die Machtverhältnisse zwischen KI-Systemen und Content-Anbietern.

Entwicklung seit Beobachtungsbeginn

Die Plattform dokumentiert nicht nur den aktuellen Zustand der AI-Infrastruktur, sondern auch deren laufende Veränderung im offenen Web. Kerngrößen und die KI-Blockierungsrate pro Reichweiten-Tier werden täglich erfasst — und machen sichtbar, wie sich Reaktionen, Standards und Bot-Ökologie über die Zeit entwickeln.

Beobachtungsbeginn wird mit dem zweiten Datenstand sichtbar.

Signale freiwilliger KI-Öffnung

Anteil der Domains pro Reichweiten-Tier mit freiwilligen Freigaben für bekannte KI-Crawler oder einer validen llms.txt.

Reichweiten-Tiers basieren auf Google-Sichtbarkeit deutscher Domains.

Anteil mit aktiver KI-Freigabe

Erfasst werden Domains mit expliziten Freigaben für bekannte KI-Bots oder einer validen llms.txt. Der praktische Nutzen dieser Signale ist bislang nicht eindeutig belegt. Sie zeigen jedoch, welche Websites aktiv Offenheit gegenüber KI-Systemen signalisieren.

Beobachtung

Reichweitenschwächere Domains experimentieren häufiger mit freiwilligen KI-Freigaben und neuen Infrastruktur-Signalen.

Am häufigsten blockierte KI-Crawler

Anteil der auditierten Domains mit vollständiger Sperrung dieses KI-Crawlers.

Vollständiges Crawler-Ranking →

Branchen mit den höchsten KI-Sperren

Anteil der Domains einer Branche mit mindestens einer vollständigen KI-Sperre.

Vollständige Branchen-Übersicht →

Domains mit den meisten KI-Sperren

Domains mit der höchsten Zahl vollständig blockierter KI-Crawler in der robots.txt.

Vollständiger Domain-Index →

WebMCP-Pioniere

Domains, die strukturierte Agenten-Schnittstellen nach WebMCP-Spezifikation auf ihrer Homepage bereitstellen.

WebMCP befindet sich noch in einer frühen Phase. Sichtbare Signale sind derzeit selten und technisch noch nicht standardisiert.

Crawler Governance Explorer

Interaktive Detailanalyse: wechseln Sie zwischen Region und Reichweiten-Tier, um Governance-Muster pro Bot-Kategorie zu untersuchen. Die Heatmap oben zeigt den Vergleich, dieser Block den Drilldown.

Crawler Governance

Wo Websites aktiv steuern — Anteil mit Einschränkung

Teilweise Einschränkung Vollständige Sperre

Anteil aktiv steuernder Domains in der gewählten Reichweite. Basis: technisch auswertbare Domains. Domains ohne robots.txt gelten als nicht eingeschränkt und werden nicht abgebildet.
„Alle Bots" misst Wildcard-Direktiven (User-agent: *). Diese gelten für jeden Crawler, sofern keine bot-spezifischere Sektion existiert. Googlebot, Bingbot, AI Bots und SEO Bots zählen nur Domains, die den jeweiligen User-Agent explizit per Name ansprechen. AI Bots umfasst alle 149 als KI-/Training-/Retrieval-Crawler klassifizierten User-Agents, SEO Bots die 49 SEO-Tools — identisch zur „KI gesamt"- und „SEO-Tools"-Filterung auf dem Crawler-Ranking. Für DACH wird bevölkerungsgewichtet über DE (85 Mio), AT (9 Mio) und CH (9 Mio) gemittelt.

Governance nach Reichweite

Einschränkungsquote pro Reichweiten-Tier und Bot-Kategorie. Direkter Vergleich.

Werte = Einschränkungsquote (vollständig + teilweise) in Prozent. Farbsättigung steigt mit dem Wert. Zeilen disjunkt: Top 100 (Rang 1–100), Top 1.000 (101–1.000), Top 5.000 (1.001–5.000), Long Tail (5.001+). „Alle Bots" misst Wildcard-Direktiven (User-agent: *); die anderen Spalten zählen nur Domains, die den Bot explizit per Name ansprechen. Seit der Parser-Korrektur am 27.05.2026 19:14 UTC zählen die Werte ausschließlich Domains, die nach diesem Zeitpunkt re-auditiert wurden — Zellen mit kleinem Sample (n<20) sind dezent markiert.

Meist blockierte Crawler

Analyse der am häufigsten regulierten KI-, Such- und SEO-Crawler im DACH-Web.

Erfasst werden vollständige Sperren, Teilblockierungen und explizite Freigaben in robots.txt-Dateien.

…

Branchenvergleich

Welche Branchen KI-Crawler besonders häufig blockieren, freigeben oder experimentelle Standards nutzen.

Vergleich nach Sperranteil, KI-Freigaben und llms.txt-Nutzung.

30 Branchen-Segmente

DACH-Top-Domains klassifiziert

Domain-Monitor

Überblick der beobachteten Domains und ihrer KI- und Crawler-Regeln.

Die Detailansicht zeigt Sperren, Freigaben, Standards und Infrastruktur-Signale pro Domain.

…

DACH-Top-Domains

Ereignisse

…

Live-Feed relevanter AI-Governance-Änderungen im DACH-Web: KI-Sperren, Freigaben, WebMCP-Signale, kritische Googlebot-Sperren und ausgewählte llms.txt-Änderungen. Sortiert nach Relevanz und Aktualität.

Beobachtete Googlebot-Sperren

Domains, bei denen unsere robots.txt-Messung eine vollständige Googlebot-Sperre beobachtet hat.

robots.txt wird heute oft dynamisch ausgeliefert. Unterschiedliche IPs, Regionen oder User-Agents können unterschiedliche Versionen erhalten. Deshalb prüfen wir jede Beobachtung aus mehreren unabhängigen Messpunkten.

Aktuell beobachtet

Domains mit aktuell beobachteter Googlebot-Sperre. Der Status rechts beschreibt die Konsistenz der Auslieferung über unsere Messpunkte.

Historisch aufgelöst

Frühere Sperren, die in einem späteren Audit nicht mehr beobachtet wurden.

Methodik: Jede beobachtete Sperre wird aus drei unabhängigen Messpunkten geprüft:

Eigener Crawler — eigene IP-Range, Standard-User-Agent
Crawler mit Googlebot-User-Agent — deckt UA-basiertes Cloaking auf
Externer Crawler — anderer Egress, andere IP-Region

Diese drei Punkte sehen oft unterschiedliche Antworten, weil robots.txt heute häufig dynamisch ausgeliefert wird — je nach IP, Region, User-Agent, CDN-Edge oder WAF-Regel. Was der reale Googlebot sieht, können wir nicht messen, weil wir nicht Googlebot sind. Die Statusanzeige beschreibt daher die Konsistenz der beobachteten Auslieferung über unsere Messpunkte, nicht die absolute Wahrheit darüber, was der reale Googlebot bekommt.

konsistente Auslieferung: ≥2 Messpunkte sehen dieselbe Sperre.
Andere Messpunkte nicht erreichbar: Ein Punkt bestätigt die Sperre, die anderen lieferten Fehler oder Timeouts. Keine Verifikation möglich.
Unterschiedliche Versionen je Messpunkt: Die Messpunkte sahen unterschiedliche robots.txt-Versionen — aktiv beobachtetes Cloaking-Signal.
nicht reproduzierbar: Messung derzeit technisch nicht stabil reproduzierbar.

Doktrin: No single vantage point is authoritative.

Domain-Endungen im Vergleich

Wie unterschiedlich Domains je nach Endung mit KI-Systemen und Crawlern umgehen.

Verglichen werden KI-Sperren, Freigaben, llms.txt-Nutzung und technische Erreichbarkeit.

Vergleich von 13 Domain-Endungen

… technisch auswertbare Domains

Zentrale Befunde

Die Statistik verdichtet die wichtigsten Beobachtungen aus dem aktuellen Infrastruktur-Audit.

Analysiert werden robots.txt-Verfügbarkeit, KI-Sperren, Freigaben, llms.txt, WebMCP und technische Hindernisse.

Aktueller Infrastruktur-Stand

… Domains analysiert

Snapshot lädt …

Marktanalyse

Die Spieltheorie der KI-Blockierung

Warum große Plattformen stärker blockieren — und kleinere Websites häufiger kooperieren.

Spieltheorie untersucht, wie sich Strategien verändern, wenn viele Akteure gegenseitig aufeinander reagieren.

Die Daten deuten darauf hin, dass sich im offenen Web unterschiedliche Strategien gegenüber KI-Systemen entwickeln. Während große Plattformen häufiger auf Kontrolle und Sperrung setzen, öffnen sich kleinere Websites deutlich öfter für KI-Crawler und Antwortsysteme.

KI-Systeme profitieren bereits dann, wenn ein Teil des offenen Webs weiterhin kooperiert.

Kleine Websites

Kooperation als Chance

Viele kleinere Websites verfügen nur über begrenzte Markenbindung, geringe direkte Reichweite und hohe Abhängigkeit von Plattformen wie Google.

Für sie kann zusätzliche Sichtbarkeit in KI-Systemen eine Chance darstellen — selbst wenn der langfristige Nutzen noch unklar ist.

Spieltheoretisch entsteht dadurch ein starker Anreiz zur Kooperation.

Große Plattformen

Kontrolle als Schutzstrategie

Große Plattformen, Publisher und Medienmarken verfügen häufiger über direkte Nutzerbeziehungen, starke Marken und exklusive Inhalte.

KI-Systeme können dort als Wertabschöpfer wahrgenommen werden — etwa wenn Inhalte zusammengefasst werden, ohne dass direkte Besuche entstehen.

Mit wachsender Marktmacht steigt das Bedürfnis nach Kontrolle über KI-Zugriffe.

Strategische Positionierung

Zwei Strategien, zwei Logiken

	Kleine Websites	Große Plattformen
Motivation	Hoffnung auf Sichtbarkeit	Schutz bestehender Reichweite
Risiko	Verlust an Verhandlungsmacht	Reichweitenverlust durch zu strikte Sperre
Typisches Verhalten	Öffnung & Kooperation	Sperrung & Kontrolle

Das eigentliche Problem

Warum Sperren alleine nicht reichen

Selbst wenn große Plattformen KI-Systeme blockieren, reichen oft bereits viele kleinere und mittlere Websites aus, damit KI-Systeme weiterhin auf große Teile des offenen Webs zugreifen können.

Individuell kann Kooperation rational erscheinen — kollektiv kann sie die Verhandlungsmacht der Content-Anbieter schwächen.

Mögliche Marktfolge

Warum KI-Systeme trotzdem weiterlernen können

Je fragmentierter die Strategien der Websites bleiben, desto stärker profitieren die Betreiber großer KI- und Antwortsysteme. Auch konsequente Sperren auf einzelnen Plattformen ändern wenig, solange der Rest des Webs offen bleibt.

Realitätscheck

Wie wirksam ist all das überhaupt?

Selbst die konsequentesten Sperrer bleiben im Symbolischen — die strukturelle Asymmetrie zwischen Verteidiger und Angreifer ist mit einem freiwilligen Protokoll wie robots.txt nicht zu schließen.

…

lädt

Was hier sichtbar wird, ist symbolische Kontrolle:

Wer den Namen eines Bots nicht kennt, kann ihn nicht gezielt ausschließen — und es existiert kein vollständiges öffentliches Register aller KI-Crawler. robots.txt bleibt damit ein freiwilliges Protokoll ohne zentrale Kontrolle oder technische Durchsetzung.

Diese Interpretation ist eine analytische Lesart der erhobenen Daten — keine Bewertung einzelner Strategien. Schutz, Kontrolle, Öffnung und Kooperation sind im aktuellen Marktumfeld jeweils nachvollziehbare Positionierungen.

robots.txt Generator für KI-Crawler

Erstelle eine kommentierte robots.txt-Konfiguration für bekannte KI-Crawler, AI-Suche und Agenten-Systeme.

Die Auswahl beeinflusst Sichtbarkeit, Datennutzung und Zugänglichkeit für KI-Systeme.

Bots ausgewählt

0 Kategorien aktiv

Die Bot-Liste basiert auf täglich beobachteten robots.txt-Dateien und laufender Analyse realer Web-Infrastruktur. Status-Labels („häufig beobachtet", „selten beobachtet" usw.) stammen aus dem aktuellen DACH-Top-10.000-Audit.

KI-Crawler prüfen

Validiert AI-Crawler-Regeln gegen dokumentierte User-Agents und reale Schreibvarianten.

Analyse gegen dokumentierte KI-Crawler und reale Schreibvarianten.

Die Prüfung basiert auf dokumentierten KI-Crawlernamen und real beobachteten Schreibvarianten.
Viele Regeln scheitern an kleinen Tippfehlern oder nicht existierenden User-Agents.

Hall of Fame der robots.txt-Kultur

Kuratierte Beispiele aus dem offenen Web: ungewöhnliche Kommentare, ASCII-Art, KI-Botschaften und menschliche Spuren in robots.txt-Dateien.

Kuratierte Fundstücke aus periodischen Audits des offenen Webs.

Kuratiert aus rund 19.500 robots.txt-Dateien im DACH-Web. Eine kleine Sammlung menschlicher Spuren im offenen Web — kein Ranking, kein Archiv im technischen Sinne.

Methodik

Domain-Basis

Der Monitor trackt die SISTRIX-Top-10.000-Listen für Deutschland, Österreich und die Schweiz, insgesamt ~19.500 unterschiedliche Domains (rund 50 % Überschneidung zwischen den Ländern). Datenstand der Ranking-Listen: 26. Mai 2026, gespiegelt aus der eingefrorenen Studie gpt-insights.de/ai-overview-analyse/ (DE-Liste) und SISTRIX-Direktexport (AT- und CH-Listen). Adult- und NSFW-Domains werden serverseitig maskiert und nicht in die Audits einbezogen.

Country-Editionen

Vier Ansichten desselben Datenbestands — jede Domain wird genau einmal auditiert, die Tier-Zuordnung wechselt aber je nach Country:

D-A-CH (Default) — gewichteter Sichtbarkeits-Score: DE_rank × 0,82 + AT_rank × 0,09 + CH_rank × 0,09 (Bevölkerungsanteil). Fehlende Länder erhalten Penalty-Rang 10.001.
🇩🇪 Deutschland — nur Domains, die in der DE-Top-10.000 stehen.
🇦🇹 Österreich — nur AT-Top-10.000.
🇨🇭 Schweiz — nur CH-Top-10.000.

Berechnungslogik der Block-Raten

Jede aggregierte Prozentangabe auf dieser Plattform folgt einer expliziten Governance-Regel. Sie schließt drei methodische Standardfehler aus, die viele AI-Infrastruktur-Studien produzieren.

Regel 1 — Ausgangsmenge. Die Analyse startet mit der definierten Top-Liste eines Country- oder DACH-Sets (DE-Top-10.000, AT-Top-10.000, CH-Top-10.000 oder die DACH-Union).

Regel 2 — Technisch nicht bewertbar wird ausgeschlossen. Domains, bei denen die robots.txt technisch nicht abrufbar ist — Timeout, DNS-Fehler, Connection-Failure, SSL-Error, WAF-Block (Cloudflare/Akamai 403), 5xx-Server-Fehler beim robots.txt-Abruf — fließen nicht in die Berechnungsgrundlage ein. Für diese Domains kann keine belastbare Aussage über das Vorhandensein einer Blockierung getroffen werden. Sie gelten als nicht bewertbar, nicht als nicht blockierend. Konkret: audit_success verlangt (a) HTTP 200–399 auf der Homepage, (b) last_block_status ∈ {NULL, 'ok'} und (c) last_robots_status ∈ {200, 404, 410} — also entweder eine erfolgreich gelesene robots.txt oder ein sauberes „nicht vorhanden".

Regel 3 — Domains ohne robots.txt bleiben in der Analyse. Ein 404 oder das schlichte Fehlen einer robots.txt ist selbst eine Aussage: Es existiert keine robots-basierte Zugriffsbeschränkung. Diese Domains werden als nicht blockierend gewertet und bleiben Teil des Nenners.

Regel 4 — Block-Definition. Eine Domain gilt als blockierend, sobald sie mindestens einen KI-Crawler einschränkt — entweder vollständig (Disallow: /) oder teilweise (selektive Pfad-Sperre). Für aggregierte Raten werden beide Fälle gemeinsam gezählt: auch partielle Sperren haben reale Auswirkungen auf Retrieval und Grounding.

Warum diese Regeln greifen:

Fehler 1 — Nicht abrufbare robots.txt implizit als „nicht blockierend" zu zählen, senkt die Block-Rate künstlich. Wir schließen sie aus dem Nenner aus.
Fehler 2 — Fehlende robots.txt als „fehlende Daten" zu behandeln, ist methodisch falsch: das Fehlen selbst ist Information. Wir lassen sie im Nenner.
Fehler 3 — Teilblockierungen zu ignorieren, unterschätzt reale Zugriffsbeschränkungen moderner AI-Crawler erheblich. Wir zählen sie mit.

DACH-Aggregation

Für die D-A-CH-Sicht wird jede KPI als bevölkerungsgewichteter Mittelwert über die drei Country-Block-Raten gebildet: (85·DE + 9·AT + 9·CH) / 103. Lesart: „Durchschnittliche Block-Rate, der ein DACH-Bürger beim Besuch von Top-Domains begegnet". Eine reine Union-Aggregation (Domain 1×) wäre methodisch sauber, produziert aber ein Simpson-Paradox: internationale Top-Domains blockieren häufiger und werden in jeder Country-Liste 3× gewichtet, in der DACH-Union nur 1×. Die Domain-Tabelle bleibt Union (jede Domain genau einmal sichtbar); aggregierte KPIs verwenden den bevölkerungsgewichteten Mittel.

Drei-Layer-Architektur der Bot-Identifikation

Die Plattform kombiniert reale robots.txt-Beobachtungen mit externen Infrastruktur-Signalen und eigener heuristischer Analyse. Kein Layer ist allein zuverlässig — erst die Kreuzung aller drei Layer macht die Bot-Identifikation belastbar.

Layer	Was es sieht	Quelle
Layer 1 — eigene Beobachtung	Welche User-Agents tatsächlich in den robots.txt der DACH-Top-10.000 stehen — inkl. Schreibvarianten, Fantasie-Namen, Copy-Paste-Diffusion	~19.500 robots.txt + Server-Logs auf groundingpage.com und gpt-insights.de
Layer 2 — externe Verifikation	Welche Bots dokumentiert existieren, mit Operator + Funktion + respect-Status	ai-robots-txt Community-Liste (~150 kuratierte AI-Crawler)
Layer 3 — eigene Heuristik	Levenshtein-Distanz, AI-Hint-Tokens, Syntax-Prüfung, Typo-Erkennung	`botNameQuality()` — kanonische Liste + heuristische Regeln

Status-Aggregation: Jeder Bot erhält einen abgeleiteten Infrastruktur-Status — VERIFIED, OBSERVED, HEURISTIC, TYPO oder UNKNOWN. Dabei gilt die Doktrin: Namensqualität hat Vorrang vor Beobachtungs-Verbreitung. Ein massenhaft beobachteter Name kann trotzdem ein Fantasie-Name sein.

Status	Bedeutung	Beispiele
Verifiziert	Extern publiziert UND in der DACH-Top-10.000 real beobachtet — Konsens beider Layer	`GPTBot`, `ClaudeBot`, `PerplexityBot`
Real beobachtet	Kanonisch geschrieben und in robots.txt geblockt, aber (noch) nicht in externer Liste verifiziert	`aibot` (17×), `molokaibot` (15×), `80bot` (5×)
Heuristisch	Enthält AI-Bezug im Namen, ist aber kein offizieller User-Agent — Fantasie-Namen, experimentelle Varianten	`gemini-deep-research` (77×), `grokbot` (32×), `mistralai` (12×)
Schreibvariante	Eine Edit-Distance zu einem kanonischen Bot — Tippfehler, kein eigenständiger Crawler	`claude-bot` → `claudebot`, `perplexityuser` → `Perplexity-User`
Unbekannt	Nicht eindeutig klassifizierbar — Custom-Crawler ohne AI-Indizien	z.B. `digitaloceangenaicrawler`, `cloudflare-ai-search`

Externe Quellen werden bewusst als Enrichment-Layer behandelt, nicht als alleinige Wahrheit. Cloudflare, Fastly oder ai-robots-txt sehen anderes als wir — sie fokussieren Netzwerktraffic, Fingerprints und WAF-Signale, während unser Audit das real publizierte Governance-Verhalten der Domain-Betreiber misst. Beide Perspektiven ergänzen sich.

Vier Infrastruktur-Dimensionen

Der Monitor dokumentiert vier eigenständige Signale. Jede Strategie ist legitim und folgt unterschiedlichen wirtschaftlichen, redaktionellen oder rechtlichen Überlegungen — der Monitor bewertet nicht, sondern macht sichtbar.

Crawler-Steuerung — Parse von /robots.txt, Klassifikation pro entdecktem KI-Crawler in vier Klassen: full_block (Disallow: /), partial_block (Disallow auf Teil-Pfaden), allow_explicit (Allow: / oder leeres Disallow), no_directive. Bekannte KI-Crawler sind u. a. GPTBot, ClaudeBot, anthropic-ai, CCBot, PerplexityBot, Google-Extended, Applebot-Extended, Bytespider — die Liste wird laufend aus den realen robots.txt entdeckt und automatisch klassifiziert. Derzeit ~90 KI-Bot-User-Agents im Index, jeder mit LLM-generierter Beschreibung im Bot-Detail-Modal.
Aktive KI-Freigaben — Anteil der Domains mit mindestens einem allow_explicit für einen KI-Bot. Beobachtetes Signal für eine bewusste Öffnungs-Strategie. Die Abwesenheit dieses Signals ist neutral und kein Defizit.
WebMCP-Schnittstelle — HTML-Source-Analyse der Homepage auf deklarative (toolname=, tooldescription=) und imperative (navigator.modelContext, registerTool()) Signale gemäß WebMCP-Spezifikation. Hinweis: Imperative Tools, die per JavaScript erst nach Hydration registriert werden, werden in dieser Phase nicht erfasst.
llms.txt — GET /llms.txt. Validität nach llmstxt.org-Standard: H1-Header, mindestens 100 Bytes, mindestens ein Markdown-Link. Der praktische Nutzen ist heute strittig — kein großer LLM-Anbieter bestätigt offiziell, dass diese Datei als Grounding-Signal genutzt wird.

Vier strategische Grundtypen

Die gemessenen Signale lassen sich in vier strategische Normhaltungen einordnen. Keine davon ist „richtig" oder „falsch" — jede folgt einer eigenen Logik aus Geschäftsmodell, Markenmacht, Google-Abhängigkeit, IP-Schutz, Reichweitenstruktur und Verhandlungsposition. Die Struktur orientiert sich an den Denkmodellen der „Münsteraner Schule" um Heribert Meffert zum Verhalten von Herstellermarken gegenüber Handelsmacht — übertragen auf das Verhältnis von Content-Anbietern zu KI-Plattformen.

Strategie	Haltung	Beobachtbare Signale
Duldung	passiv, geringe Eigensteuerung	keine spezifischen KI-Direktiven, keine Anpassung der Content-Strategie
Schutz	passiv, hohe Eigensteuerung	aktive Blockierung bekannter KI-Crawler, oft umfassende Bot-Listen
Kooperation	aktiv, geringe Eigensteuerung	explizite Allow-Direktiven, llms.txt, WebMCP — Mitgestaltung des KI-Ökosystems
Ausweichung	aktiv, hohe Eigensteuerung	Rückzug aus KI-Sichtbarkeit, Aufbau alternativer Reichweitenkanäle (Push, Newsletter, App, Community)

Der Monitor misst die direkt beobachtbaren Infrastruktur-Signale — Ausweichungs-Strategien werden bewusst nicht erfasst, weil sie sich nicht aus robots.txt oder Homepage-HTML ablesen lassen.

Reichweiten-Tiers

Jede Liste (DACH, DE, AT, CH) wird in vier Reichweiten-Klassen unterteilt — der Rang spiegelt die organische Google-Sichtbarkeit im jeweiligen Land:

Tier 1 — Top 100: Rang 1–100. Die sichtbarsten Domains.
Tier 2 — Top 1.000: Rang 101–1.000. Hohe Sichtbarkeit.
Tier 3 — Top 5.000: Rang 1.001–5.000. Mittlere Sichtbarkeit.
Tier 4 — Long Tail: Rang 5.001+. Bei DE/AT/CH bis ~Rang 10.000, bei DACH durch Dedup bis ~Rang 19.500.

KI-Blockierungsrate — wie wir messen

Die in beiden Tier-Modulen gezeigte „KI-Blockierungsrate" misst Domains mit aktiver Sperr-Direktive gegenüber bekannten KI-Crawlern in der robots.txt — vollständig (Disallow: /) oder selektiv (Disallow: /pfad/). Identische Definition in:

Zeitreihen-Tile „KI-Blockierungsrate" (gesamt, alle Tiers zusammen)
4 Tier-Tiles in der Zeitreihen-Sektion (Top 100 / Top 1.000 / Top 5.000 / Long Tail)
Tier-Balken im Hero-Bereich („Je größer die Website, desto häufiger…")

Basis (Nenner) in allen drei Modulen ist die Zahl der erfolgreich abgefragten Domains — also Domains mit HTTP-2xx-Response ohne Cloudflare/WAF-Block. Eine Domain, deren robots.txt wir nicht lesen konnten, erlaubt keine „blockiert KI"-Aussage und zählt daher nicht in die Basis.

Andere Werte auf der Seite — z.B. „Am häufigsten blockierte KI-Crawler" oder „Top-Sperrer pro Branche" — beziehen sich auf vollständige Sperrungen einzelner Bots; das ist eine andere, engere Metrik.

Audit-Pipeline (rollierend, ohne Reset)

Alle 3 Minuten: 50 Domains werden parallel auditiert (3 Fetches pro Domain: /llms.txt, /robots.txt, /).
Reihenfolge: Domains mit ältestem last_audit_at kommen zuerst dran (NULL = noch nie auditiert hat höchste Priorität). Bei Gleichstand entscheidet der Rang in DACH bzw. DE.
Kein Daily-Reset: Die Crawl-Logik ist selbst-rollierend. Jede Domain wird kontinuierlich aktualisiert, sobald ihr letzter Audit am ältesten ist. Bei aktuell ~19.500 Domains und ca. 50 Audits pro 3 min ergibt das einen vollständigen Turn-around alle ~20 Stunden — die hochsichtbaren DACH-Top-Domains werden tendenziell etwas häufiger erneuert, weil sie nach dem ersten Audit als „älteste mit DACH-Priorität" wieder oben in der Queue stehen.
Live-Status: crawl-monitor.html (Auto-Refresh alle 5 s).

Crawler-Blockierung und WAF-Plattform-Detection

Jeder Audit erkennt aus den Response-Headern automatisch die CDN/WAF-Plattform (Cloudflare, Fastly, Akamai, Imperva, CloudFront, Sucuri, AWS) anhand von cf-ray, x-fastly-*, x-akamai-*, x-iinfo, x-amz-cf-id, x-sucuri-id sowie server. Plus: Block-Detection erkennt aktive WAF-Sperren des Audit-Crawlers (cf_challenge, cf_block, fastly_block, akamai_block, imperva_block, sucuri_block, HTTP 403/406/429/503, Timeout, no_response). Wenn eine Domain blockiert, wird das im Domain-Detail als Banner ausgewiesen — die robots.txt- und WebMCP-Werte spiegeln dann nicht den tatsächlichen Stand wider.

Robustheit

Timeout: 12 Sekunden pro Fetch, mit automatischem Retry (20 Sekunden) für Homepage und robots.txt bei Timeout — fängt langsame Origin-Server und Cloudflare-Challenge-Pages ab.
Atomic-Claim: 50 Domains pro Tick werden in einem Atomic-Update mit einem zufälligen crawling_*-Marker exklusiv reserviert. Verhindert Doppel-Audits bei parallelen Cron-Triggern.
Diff-Tracking: Jeder Audit wird mit dem vorherigen Audit der Domain verglichen. Änderungen (neue Sperre, neue Freigabe, llms.txt erstellt, WebMCP-Signal aufgetaucht) landen in einer changes-Tabelle für späteres Event-Tracking.

Häufige Fehler bei KI-Sperren

Wichtiger Befund

Rund 11 % aller beobachteten KI-Sperren sind technisch unwirksam — etwa durch falsche Bot-Namen, Syntaxfehler oder ungültige robots.txt-Direktiven.

Viele KI-Sperren scheitern nicht an der Absicht, sondern an fehlerhaften oder nicht existierenden User-Agent-Namen. Diese Sektion ist keine Fehlerliste, sondern eine Bestandsaufnahme der technischen Reife von AI-Governance in der frühen Phase: Die Infrastruktur-Politik entwickelt sich schneller als die technische Kompetenz dafür — vergleichbar mit den frühen Tagen von Cookie-Bannern, fehlerhaften hreflang-Implementierungen oder kaputten Canonicals.

OpenAI (ChatGPT / GPT)

Beobachtete Direktive	Wirkung	Standardkonforme Variante
`chatgpt`, `chatgpt-bot`, `chatgpt-nutzer`	unbekannter Bot	`ChatGPT-User` — On-Demand-Fetch beim Klick auf Citation
`openai`, `openai-webcrawler`, `openaibot`, `openai.com`	unbekannter Bot	`GPTBot` — Training-Crawler
`openaisearch`, `chatgpt-search`	unbekannter Bot	`OAI-SearchBot` — ChatGPT-Suche
`chatgpt agent` (mit Leerzeichen)	syntaktisch problematisch, Token bricht ab	`ChatGPT-User` mit Bindestrich

Anthropic (Claude)

Beobachtete Direktive	Wirkung	Standardkonforme Variante
`claude`, `claude-bot` (mit Bindestrich), `anthropicbot`	unbekannter Bot	`ClaudeBot` — Training-Crawler von Anthropic
`anthropiccrawler`, `anthropic`	unbekannter Bot	`anthropic-ai` — Legacy-Crawler (mit Bindestrich!)
`claude-code`	nicht als Crawler beobachtet	Claude Code ist ein CLI-Tool, kein Web-Crawler

Google AI & Perplexity

Beobachtete Direktive	Wirkung	Standardkonforme Variante
`google-ai`, `googleai`, `gemini-bot`	unbekannter Bot	`Google-Extended` — Gemini-Training & Vertex-AI-Grounding
`google-gemini-cli`	nicht als Crawler beobachtet	Gemini CLI ist ein lokales Tool
`perplexity` alleine, `perplexityuser` (ohne Bindestrich)	unbekannter Bot	`PerplexityBot` (crawlt) · `Perplexity-User` (fetcht beim Antwort-Klick)
`perplexity‑user` mit Unicode-Bindestrich U+2011	unbekannter Bot	`Perplexity-User` mit ASCII-Hyphen U+002D — häufig per Copy-Paste eingeschleust

AI-klingende, aber nicht existierende Bots

Ein Teil der beobachteten Direktiven verwendet KI-bezogene Namen, die technisch nicht existieren oder von keinem bekannten Crawler genutzt werden. Diese Direktiven sind kulturell aufschlussreich: Sie zeigen, wie Website-Betreiber versuchen, diffuse KI-Systeme semantisch greifbar zu machen — geschrieben wird oft, was plausibel klingt, nicht was tatsächlich existiert.

Beobachtete Direktive	Vermutete Absicht	Was tatsächlich blockiert würde
`chatgpt agent`	OpenAI-Agent für autonome Aktionen	nichts — Token bricht am Space
`gemini-deep-research`	Geminis Deep-Research-Modus	nichts — kein dokumentierter UA
`google-gemini-cli`	Gemini-CLI als Web-Zugriff	nichts — lokales CLI hat keinen Web-Crawler
`anthropic-claude-research`	Claude-Research-Modus	nichts — kein dokumentierter UA
`openaicontentcrawler`	vermutlich Training-Daten	nichts — OpenAI nutzt GPTBot für diesen Zweck

Syntaktisch nicht standardkonform

Beobachtete Schreibweise	Wirkung gemäß RFC 9309	Standardkonforme Variante
`User-agent: gptbot # https://radar.cloudflare.com/...`	Kommentar verschmilzt mit dem UA-Token — der zusammengesetzte String ist nicht beobachtet	`User-agent: GPTBot` in eigener Zeile, Kommentar separat davor
`User-agent: chatgpt-user*`	Wildcards im UA-Namen sind nach RFC 9309 nicht zulässig — Major-Crawler verwerfen die Direktive	`User-agent: ChatGPT-User` (exakter Token)
`User-agent: chatgpt agent` (mit Space)	Whitespace beendet den Token — Parser registriert nur `chatgpt`	`User-agent: ChatGPT-User` (Bindestrich)
`User-agent: AI-Bots` als Gruppen-Name	robots.txt kennt keine Bot-Gruppen — nur exakte Token-Matches plus `*`	Pro Bot eine eigene `User-agent:`-Zeile mit dem offiziellen Namen
`Disallow: AI-Training` als Themen-Verbot	robots.txt kennt nur `Allow:` und `Disallow:` mit Pfad-Wert — keine Themen-Verbote	`User-agent: GPTBot` `Disallow: /`

Hinweis zur Schreibweise: robots.txt ist nach RFC 9309 case-insensitive im User-Agent. Operatoren publizieren ihre Namen zur Lesbarkeit oft in CamelCase (ClaudeBot), der Audit prüft alles in Lowercase. Was zählt, ist die exakte Token-Form, die der Operator dokumentiert hat.

Bekannte Limits

Single-Page-Audit: WebMCP-Detection läuft nur auf der Homepage. Tools, die nur in Unterseiten registriert werden, werden gemissed.
Kein Browser-Rendering: JavaScript wird nicht ausgeführt. Bei aktueller WebMCP-Verbreitung von praktisch null ist die Verzerrung minimal; bei Anstieg wird Browser-Rendering nachgezogen.
Bot-User-Agent: Der Audit nutzt einen Chrome-Desktop-User-Agent. Sites, die Headless-Anfragen erkennen, könnten 403 zurückgeben.
Cluster-Tags: AT- und CH-only-Domains haben aktuell noch keine Branchen-Zuordnung (DE-Domains: 30 Cluster aus dem ai-overview-analyse-Projekt). LLM-basierte Cluster-Erweiterung folgt.

Stack

Cloudflare Workers + D1 (SQLite) + Cron-Trigger. Frontend statisch via FTP auf nginx (gpt-insights.de). API-Aufrufe per PHP-Reverse-Proxy auf den Worker, damit Frontend und API unter einer Origin laufen. Bot-Beschreibungen werden einmalig per OpenAI GPT-4o-mini generiert und in D1 zwischengespeichert.

Quellen und verwandte Tools

groundingpage.com — Grounding-Check für einzelne Seiten
ai-overview-analyse — Schwesterprojekt: AI-Overview-Exposition deutscher Top-Domains
Lighthouse Agentic Browsing — Methodik-Vorbild der vier Dimensionen
llmstxt.org — llms.txt-Spezifikation
webmachinelearning/webmcp — WebMCP W3C Community Draft