UA- und WAF-basierte Zugriffsbeschränkungen
UA- und WAF-basierte Zugriffsbeschränkungen sind technische Regeln oder Schutzmechanismen, die Requests abhängig vom User Agent oder von einer Web Application Firewall beziehungsweise einem Bot-Management-System erlauben, blockieren, challengen oder begrenzen.
Solche Regeln können gezielt bestimmte Crawler betreffen, aber auch automatisierten Traffic allgemein oder, in Fehlkonfigurationen, sogar Suchmaschinen und reale Nutzer beeinträchtigen.
Was bedeutet UA?
UA = User Agent. Der User Agent ist eine Kennung, die ein Client bei einem HTTP-Request mitsendet. Beispiele:
- Browser
- Googlebot
- GPTBot
- ClaudeBot
- CCBot
Der User Agent ist eine Selbstauskunft des Clients und kann technisch leicht verändert werden.
Was bedeutet WAF?
WAF = Web Application Firewall. Eine WAF sitzt typischerweise vor der Webanwendung und bewertet eingehende Requests. Sie kann unter anderem:
- erlauben
- blockieren
- challengen
- drosseln
- loggen
Nicht jede WAF arbeitet identisch. Regelwerk, Signale und Standardverhalten unterscheiden sich je nach System und Konfiguration.
Wie funktioniert UA-basiertes Blocking?
Ein einfaches Beispiel: Wenn User Agent CCBot, dann 403. Das ist eine relativ einfache Regel.
Sie kann an unterschiedlichen Stellen umgesetzt werden, am Webserver, im CDN, in der WAF oder in einem Reverse Proxy.
Wie funktioniert WAF-basiertes Blocking?
WAF-Systeme können mehr Signale berücksichtigen als nur den User Agent, je nach System beispielsweise:
- IP-Adresse
- Netzwerk
- Bot-Verifizierung
- Request-Muster
- Request-Rate
- Browser-Verhalten
- Cookies
- JavaScript-Ausführung
- Reputation
- bekannte Bot-Signaturen
Bewusst immer „kann berücksichtigen“, nicht „berücksichtigt immer“. Welche Signale konkret wirken, hängt vom jeweiligen System und seiner Konfiguration ab.
Warum reicht ein User-Agent-Test nicht aus?
Ein Request mit Googlebot als User Agent ist kein echter Googlebot. Ebenso ist ein Request mit CCBot als User Agent nicht zwingend repräsentativ für einen echten Common-Crawl-Request.
Weil WAFs weitere Signale verwenden können, kann ein Testserver beispielsweise Folgendes liefern:
…während der echte Googlebot aufgrund verifizierter Bot-Erkennung anders behandelt wird. Der Test misst nur die Reaktion auf die gemeldete Kennung, nicht den echten Crawler.
Challenge ist nicht dasselbe wie Block
Beispiel Cloudflare: Der Response-Header cf-mitigated: challenge signalisiert eine Challenge-Response, keine dauerhafte Deny-Regel.
Ein echter Browser kann eine solche Prüfung gegebenenfalls bestehen. Ein einfacher HTTP-Client nicht. Deshalb kann ein 403 technisch eine Challenge sein und nicht zwingend eine dauerhafte Blockade.
CCBot (Common Crawl) prüft robots.txt, nutzt HTTP GET und folgt Redirects, führt aber kein JavaScript aus und nutzt keine Cookies. Ein Schutzmechanismus, der JavaScript- oder Cookie-Unterstützung voraussetzt, kann CCBot deshalb praktisch ausschließen, selbst wenn die robots.txt ihn erlaubt.
Wie eine Schutzschicht intern jeden Fingerprint berechnet, ist von außen nicht bestimmbar. Verlasse dich nur auf dokumentierte Signale wie Statuscode und Response-Header, nicht auf Vermutungen über interne Bewertungslogik.
Welche Statuscodes sind relevant?
Der Statuscode allein reicht häufig nicht zur Ursachenbestimmung. Header, Response-Inhalt, Historie und Logs ergänzen das Bild.
Können auch echte Nutzer betroffen sein?
Ja. Aggressive Bot-Schutzsysteme können auch reale Nutzer challengen oder blockieren. Mögliche Faktoren:
- VPN
- ungewöhnliche IP
- bestimmte Regionen
- Privacy-Tools
- deaktiviertes JavaScript
- ungewöhnliches Browser-Verhalten
- hohe Request-Frequenz
Können Suchmaschinen betroffen sein?
Ja, insbesondere bei Fehlkonfigurationen, allerdings vorsichtig zu formulieren. Googlebot kann durch verifizierte Bot-Mechanismen anders behandelt werden als ein beliebiger Client mit Googlebot-Kennung.
Ein externer Googlebot-UA-Test ist deshalb kein Beweis. Belastbarer sind:
- Google Search Console
- echte Serverlogs
- verifizierte IP- bzw. DNS-Signale
- WAF-Logs
Warum ist das für Generative Engine Optimization (GEO) relevant?
Generative Engine Optimization (GEO) berücksichtigt auch die technische Zugänglichkeit. Der Zugriff eines einzelnen Crawlers ist dabei aber nur ein Teil der Gesamtbetrachtung: AI-Systeme können Inhalte über verschiedene Quellen und Retrieval-Wege erhalten.
WAF-Blocking eines einzelnen Crawlers bedeutet nicht automatisch keine AI-Sichtbarkeit.
Wie erkennt man UA- oder WAF-basierte Zugriffsbeschränkungen?
1. Response vergleichen
Requests mit Browser- und Crawler-User-Agents vergleichen (beides bleibt derselbe Testclient gegenüber derselben Infrastruktur).
2. Statuscodes prüfen
Auf 403, 429 und weitere achten.
3. Response-Header prüfen
Beispielsweise server, Cloudflare-spezifische Header oder Challenge-Signale.
4. Response-Inhalt prüfen
Auf Human-Verification, Challenge-Seiten oder „Access Denied“-Inhalte achten.
5. Historische Crawl-Daten prüfen
Hat Common Crawl früher erfolgreich zugegriffen?
6. Owner-Daten prüfen
WAF-/CDN-Logs, Google Search Console und Serverlogs heranziehen.
Beispiele
Beispiel 1 – UA-basiert
Hinweis auf eine UA-abhängige Zugriffsbeschränkung. Daraus folgt nicht automatisch, dass der echte CCBot identisch behandelt wird.
Beispiel 2 – WAF-/Challenge-basiert
cf-mitigated: challengeDie Einschränkung ist offenbar nicht allein vom User Agent abhängig. Die Response weist auf eine vorgelagerte Challenge hin.
Beispiel 3 – historische Veränderung
Hinweis auf eine veränderte technische Zugänglichkeit für Common Crawl, keine Kausalität ohne weitere Evidenz.
Einordnung in Crawler Accessibility
UA- und WAF-basierte Regeln sind nur ein Teil der übergeordneten Crawler Accessibility. Dazu gehören auch robots.txt, Rate Limits, Authentifizierung, technische Fehler und weitere Zugriffsebenen.
Praktische Analyse
Der Common Crawl Decoder zeigt, wie sich der tatsächliche Zugriff von Common Crawl historisch entwickelt hat. Dadurch lassen sich beispielsweise Veränderungen bei erfolgreichen Abrufen, 403-Antworten oder anderen HTTP-Statuscodes untersuchen.
Common Crawl Decoder öffnen →Der Decoder misst Common-Crawl-Signale. Er misst nicht direkt Googlebot, GPTBot, ClaudeBot oder andere Crawler.
Typische Fehlinterpretationen
- „Alle 403 bedeuten Bot-Blocking.“
- Falsch. Ein 403 kann eine Challenge, eine Fehlkonfiguration oder eine allgemeine Schutzregel sein.
- „Mit einem Chrome-User-Agent simuliere ich einen echten Browser.“
- Nicht vollständig. Eine WAF kann viele weitere Signale prüfen, die ein reiner UA-String nicht abbildet.
- „Mit Googlebot-UA teste ich Google.“
- Falsch. Getestet wird nur die Reaktion auf die Kennung, nicht der echte, verifizierte Googlebot.
- „Browser 200 bedeutet, dass Googlebot ebenfalls 200 erhält.“
- Nicht zwingend. Browser und Crawler können unterschiedlich behandelt werden.
- „CCBot 403 bedeutet automatisch, dass ChatGPT die Seite nicht kennt.“
- Falsch. Common Crawl ist nur eine mögliche Quelle; AI-Systeme können Inhalte über andere Wege erhalten.
Quellen und weiterführende Dokumentation
- Google Search Central. Google-Crawler-Zugriffe verifizieren
- Cloudflare Docs. Challenge-Response erkennen (cf-mitigated)
- Cloudflare Docs. Web Application Firewall (WAF)
- Cloudflare Docs. Verified Bots
- AWS WAF. Developer Guide
- MDN. HTTP-Header User-Agent
- MDN. HTTP-Statuscodes
- Common Crawl. FAQ (CCBot: robots.txt, kein JavaScript, keine Cookies)
Zuletzt geprüft: 7. August 2026