Die Website funktioniert im Browser, der Server meldet keinen Fehler, und Google kann die betroffene Seite trotzdem nicht abrufen. Eine mögliche Ursache sitzt vor der Anwendung: Die Web Application Firewall des CDN stuft den Crawler als unerwünschten Bot ein und liefert eine Sperre oder Sicherheitsabfrage aus.
Um das nachzuweisen, reichen weder ein grüner Servercheck noch die Zeichenfolge Googlebot im Zugriffsprotokoll. Du brauchst einen konkreten Abruf, dessen Identität und Antwort sich nachvollziehen lassen. Erst dann lohnt es sich, eine Firewall-Regel zu ändern.
Google beschreibt sowohl harte Blockaden als auch vorgeschaltete Bot-Abfragen in seinem Beitrag über CDNs und Crawling. Besonders irreführend sind Fehlerseiten mit HTTP 200. Der Status meldet Erfolg, obwohl der eigentliche Inhalt nicht ausgeliefert wurde. Deshalb prüfst du neben dem Status immer auch die Antwort selbst.
Vier Fragen, die den Fehler eingrenzen
Beginne mit einer einzelnen betroffenen URL und einem überschaubaren Zeitraum. Notiere, wann der Fehler beobachtet wurde und welcher Abruf ihn gezeigt hat. Die Meldung „Googlebot wird blockiert“ ist noch zu ungenau, um ein Infrastrukturteam gezielt suchen zu lassen.
Trenne dann vier Fragen: Hat die Anfrage das CDN erreicht? Hat das CDN sie zum Origin weitergeleitet? Welche Antwort bekam der Client? Und stammt die Anfrage tatsächlich von dem Google-Crawler, den du untersuchen willst?
Das sind unterschiedliche Nachweise. Ein fehlender Eintrag im Origin-Log kann bedeuten, dass die WAF vorher blockiert hat. Er kann aber auch entstehen, wenn das CDN eine gültige Antwort aus seinem Cache geliefert hat. Ohne Edge-Ereignis lässt sich zwischen diesen Fällen nicht sicher wählen.
Auch Crawling und spätere Indexierung bleiben getrennte Vorgänge. Dieses Verfahren prüft, ob ein bestimmter Abruf den vorgesehenen Inhalt erreichen konnte. Es erklärt nicht automatisch jeden Sichtbarkeitsverlust derselben Website.
Ein fiktiver Fall: Die Ländersperre trifft den Crawler
Das folgende Beispiel ist erfunden. Ein Shop unter example.com schützt öffentliche Produktseiten mit einer Länderregel. Nach einer Konfigurationsänderung bekommen bestimmte Anfragen eine Browser-Challenge. Mitarbeiter testen von ihrem üblichen Standort und sehen weiterhin die Produktseite.
Im Fehlerzeitraum meldet die URL-Prüfung hingegen eine Sicherheitsabfrage. Das CDN protokolliert für die betroffene Anfrage eine Challenge-Aktion mit einer Regel-ID. Im Origin-Log fehlt diese Anfrage, weil sie dort nicht ankam. Die Anwendung selbst musste dabei keinen Fehler erzeugen.
Die Arbeitshypothese lautet nun: Diese Edge-Regel verhindert den betreffenden Abruf. Das ist enger und hilfreicher als „das CDN ist SEO-schädlich“. Andere URLs oder andere Anfragen können weiterhin problemlos funktionieren. Ein ähnlicher Test gehört nach einem Website-Relaunch oder Infrastrukturwechsel zu den Prüfungen am öffentlichen Auslieferungspfad.
Bevor du eine Ausnahme baust, klärst du jedoch die Identität. Ein automatisiertes Werkzeug, das die URL im Auftrag eines Nutzers prüft, muss nicht dieselbe Herkunft oder Kategorie haben wie ein regulärer Indexierungs-Crawler. Diese Unterscheidung wird für die spätere Abnahme wichtig.
Googlebot überprüfen, ohne dem Namen zu vertrauen
Der HTTP-User-Agent ist eine frei gesetzte Angabe des Clients. Ein fremder Bot kann darin Googlebot schreiben. Eine Freigabe, die ausschließlich auf diesem Text beruht, würde deshalb auch anderen Clients offenstehen.
Google dokumentiert zwei Wege zur Verifikation von Crawler-Anfragen: den Abgleich der Quell-IP mit den veröffentlichten, zur Crawler-Kategorie passenden IP-Bereichen oder eine rückwärts und anschließend vorwärts bestätigte DNS-Auflösung. Die Dokumentation unterscheidet reguläre Crawler, Sonderfälle und nutzerinitiierte Abrufe.
Für einen einzelnen Logeintrag ist die DNS-Prüfung gut nachvollziehbar. Du löst zunächst die Quell-IP rückwärts auf. Dann prüfst du den erhaltenen Hostnamen gegen die für diese Kategorie dokumentierte Domain. Schließlich löst du diesen Hostnamen vorwärts auf und kontrollierst, ob die ursprüngliche IP enthalten ist. Nur nach einem Namen zu suchen, der irgendwo google enthält, genügt nicht.
Mit nslookup kannst du die beiden Abfragen durchführen:
textnslookup IP-AUS-DEM-EDGE-LOG
nslookup HOSTNAME-AUS-DER-ERSTEN-ANTWORT
Ersetze die Platzhalter durch den konkreten Wert aus dem untersuchten Ereignis. Nutze für laufende Auswertungen die aktuelle offizielle Bereichsliste und dokumentiere deren Abrufdatum. Eine vor Monaten kopierte Liste ist keine verlässliche Grundlage für eine dauerhafte Regel.
Wichtig ist außerdem, welche IP du prüfst. Hinter einem Proxy kann das Anwendungslog die CDN-Adresse zeigen. Die ursprüngliche Client-IP muss aus einer vertrauenswürdigen Proxy-Kette stammen. Ein beliebiger vom Besucher mitgeschickter Header ist kein Identitätsbeleg. Für die Untersuchung ist deshalb das passende Edge-Ereignis oft der sauberste Ausgangspunkt.
Die öffentliche Antwort speichern
Rufe die betroffene öffentliche URL mit einem HTTP-Client ab und speichere Header sowie Body. Für eine erste, nicht automatisch weitergeleitete Anfrage eignet sich:
bashcurl -sS -D edge-headers.txt -o edge-body.html "https://example.com/produkte/wanderschuh"
Unter Windows PowerShell verwendest du gegebenenfalls curl.exe. Prüfe anschließend Status, Weiterleitungsziel, Inhaltstyp und den tatsächlichen Body. Enthält er Produktname und Produktinformation oder nur eine Sicherheitsabfrage? Eine leere Seite mit HTTP 200 ist genauso wenig ein erfolgreicher Inhaltsabruf wie eine schön gestaltete Challenge-Seite.
Dieser Test stammt von deinem Rechner. Er zeigt die Antwort für genau diese Anfrage und ersetzt keinen belegten Googlebot-Abruf. Ein geänderter User-Agent kann dabei helfen, eine textbasierte Regel einzugrenzen. Er macht deinen Rechner aber nicht zu Googlebot und sagt nichts darüber aus, wie die WAF eine verifizierte Google-IP behandelt.
Wiederhole lokale Abfragen nicht in hoher Frequenz. Sonst erzeugst du durch den Test möglicherweise erst ein Rate Limit und vermischst den ursprünglichen Fehler mit einem neuen. Eine kleine Zahl dokumentierter Abrufe ist für die erste Eingrenzung meist aussagekräftiger als ein unkontrollierter Belastungstest.
Edge, Origin und gerenderte Seite zusammenlesen
Suche nun im CDN-Protokoll nach dem Zeitpunkt, Pfad und gegebenenfalls der Request-ID. Halte die auslösende Regel, ihre Aktion und die verifizierte Bot-Kategorie fest, soweit der Anbieter diese Informationen liefert. Fehlt ein Feld im gewählten Tarif oder Export, bleibt es eine Datenlücke.
Vergleiche das Ereignis mit dem Origin-Zugriff. Eine am Edge abgewiesene Anfrage kann dort fehlen. Eine weitergeleitete Anfrage kann dagegen einen Anwendungsfehler auslösen. Wenn beide Schichten HTTP 200 melden, prüfst du weiterhin, ob die ausgelieferte Seite den beabsichtigten Inhalt enthält.
Bringe die Zeitangaben auf dieselbe Grundlage. Ein Dashboard kann Ortszeit anzeigen, während der Server UTC protokolliert. Suche zusätzlich nach Pfad und Request-ID, damit zwei ähnliche Anfragen nicht versehentlich als dieselbe behandelt werden. Enthält ein Export nur eine Stichprobe, beweist ein fehlender Treffer keine fehlende Anfrage. Dokumentiere dann die Abdeckung des Exports und den verfügbaren Zeitraum.
Kannst du den angeblichen Googlebot-Abruf weder verifizieren noch einem Edge-Ereignis zuordnen, bleibt die WAF-Hypothese offen. Eine auffällige Regel oder ein gleichzeitiger Sichtbarkeitsverlust ersetzt diese Verbindung nicht. Bereite stattdessen einen überprüfbaren Fall mit URL, Zeitfenster, beobachteter Antwort und den fehlenden Logfeldern vor. Damit kann der zuständige Betreiber gezielter nachsehen. Ändere nicht mehrere Schutzmechanismen gleichzeitig, nur um irgendeinen grünen Test zu erhalten. Sonst ist später unklar, welche Änderung geholfen hat und welche unbeabsichtigten Wirkungen sie mitgebracht hat.
Bei JavaScript-Seiten kommt die Ressourcenebene hinzu. Das Hauptdokument kann verfügbar sein, während ein notwendiges Skript oder eine Inhalts-API blockiert wird. Dann zeigt die gerenderte Seite möglicherweise nur eine Hülle. Solche Rendering- und Edge-Probleme erfordern einen Blick auf die fehlgeschlagenen Ressourcen, nicht nur auf die Haupt-URL.
Die folgende Matrix macht die Grenzen der einzelnen Nachweise sichtbar:
| Beobachtung | Was sie belegt | Was offenbleibt |
|---|---|---|
| Lokaler Browser zeigt das Produkt | Dieser Browser konnte den Inhalt laden | Antwort für verifizierte Crawler |
| HTTP-Client erhält 200 | Diese Anfrage erhielt einen Erfolgsstatus | Ob der Body der Produktseite entspricht |
| Verifizierte Anfrage im Edge-Log blockiert | Eine konkrete Regel traf diesen Abruf | Ob andere Crawler-Kategorien betroffen sind |
| Kein Origin-Eintrag | Am Origin wurde kein passender Abruf gefunden | Blockade oder erfolgreiche Cache-Antwort |
| Hauptdokument lädt, Skript scheitert | Der Auslieferungspfad ist nur teilweise verfügbar | Vollständiger gerenderter Inhalt |
| Live-Prüfung zeigt die Seite korrekt | Dieser Prüfabruf konnte sie darstellen | Regulärer Crawlverlauf und Indexverarbeitung |
Die Google Search Console ergänzt die Protokolle mit einer Sicht auf Googles Abruf und Darstellung. Notiere auch dort den Zeitpunkt und die Art der Prüfung. Ein alter Indexbefund und eine aktuelle Live-Prüfung können verschiedene Zustände beschreiben.
Die auslösende Regel gezielt korrigieren
Erst wenn der Zusammenhang nachvollziehbar ist, änderst du die Regel. Das Ziel ist, den vorgesehenen öffentlichen Inhalt für die gewünschte verifizierte Crawler-Kategorie erreichbar zu machen. Eine pauschale Abschaltung sämtlicher Schutzfunktionen lässt sich aus einem einzelnen Fehlalarm nicht ableiten.
Cloudflare zeigt beispielsweise eine Länderregel mit Ausnahme für bekannte Bots. Sie verwendet die vom Anbieter ermittelte Bot-Klassifikation statt einer frei gesetzten User-Agent-Zeichenfolge. Das ist ein Beispiel für eine konkrete Regel, keine allgemeine Zusage, dass jeder andere Schutzmechanismus dadurch übersprungen wird.
Prüfe deshalb Regelreihenfolge, betroffene Schutzphase und die tatsächlich verfügbaren Bedingungen deines Anbieters. Eine Ausnahme in einer benutzerdefinierten WAF-Regel kann ein separates Rate Limit oder einen anderen Bot-Schutz unverändert lassen. Dokumentiere genau, welcher Mechanismus angepasst wurde.
Bei vorübergehender Überlastung müssen Serverantworten den Ausfall ehrlich ausdrücken. Googles Dokumentation zu HTTP-Statuscodes erläutert, dass 429 und Serverfehler das Crawling reduzieren können. Solche Antworten sind keine dauerhafte SEO-Reparatur. Eine länger anhaltende Störung kann auch bestehende Indexeinträge gefährden.
Verwechsle diese technische Erreichbarkeit außerdem nicht mit der Erlaubnis in robots.txt. Eine erlaubte URL kann trotzdem an der Firewall scheitern. Die Trennung ist auch bei Such- und KI-Crawlern relevant, deren Zugriffsregeln nach Zweck geprüft werden müssen.
Eine Abnahme, die denselben Weg erneut prüft
Speichere vor der Änderung die betroffene Konfiguration so, dass sie gezielt zurückgenommen werden kann. Nach der Korrektur wiederholst du die dokumentierten Fälle. Dazu gehören die ursprünglich blockierte Abrufkategorie, eine normale öffentliche Anfrage und ein Kontrollfall, den die Schutzregel weiterhin absichtlich abweisen soll.
Ordne die betroffenen Seiten nach Template und Auslieferungspfad. Der Site Audit von Crawl Foundry hilft, technische Befunde mit dem untersuchten URL-Umfang zu verbinden. Die verifizierte Bot-Identität und das konkrete WAF-Ereignis ergänzt du aus den Infrastrukturprotokollen. Ein erfolgreicher Plattform-Crawl allein beweist keinen erfolgreichen Googlebot-Abruf.
Beobachte anschließend eine passende Anzahl realer Ereignisse im Betrieb. Halte Anteil und Art der Fehler sowie die tatsächlich gesehenen Crawler-Kategorien fest. Veränderungen des Crawl Budgets lassen sich nicht seriös aus einem einzelnen gelungenen Abruf ableiten. Dafür brauchst du einen vergleichbaren Zeitraum und eine nachvollziehbare Ausgangslage.
Ein belastbarer Abschluss lautet etwa: Die zuvor auslösende Regel wurde angepasst, die untersuchte verifizierte Anfrage erhält nun die Produktseite und die Kontrollregel greift weiterhin wie vorgesehen. Ob Google danach anders indexiert oder rankt, ist eine weitere Beobachtung. Der behobene Fehler ist zunächst der nachgewiesene Zugriff auf den vorgesehenen Inhalt.