Ein SEO-Spezialist startet ein technisches Audit einer großen Website – und nach 10 Minuten beginnt Screaming Frog, nur noch 403 Forbidden oder 429 Too Many Requests auszugeben. Der Schutzserver hat den Crawler als angreifenden Bot identifiziert und die IP-Adresse blockiert. Das Ergebnis – das Audit muss neu gestartet werden, und dem Kunden muss erklärt werden, warum der Bericht verspätet ist. Das Problem lässt sich durch eine ordnungsgemäße Konfiguration des Proxys für den Crawler lösen – wir werden untersuchen, wie genau.
Warum Websites Screaming Frog beim Audit blockieren
Screaming Frog, Sitebulb, JetOctopus und Netpeak Spider funktionieren technisch ähnlich wie Suchmaschinen-Bots: Sie durchlaufen schnell Tausende von URLs nacheinander, laden HTML, CSS, JS und Bilder herunter, überprüfen Weiterleitungen und Statuscodes. Aus Sicht des Website-Schutzes (Cloudflare, Qrator, DDoS-Guard, integrierte WAF des Hostings) sieht das nach verdächtiger Aktivität aus – zu viele Anfragen von einer IP in kurzer Zeit.
Blockierungen treten besonders häufig beim Audit auf:
- großer Online-Shops auf einer Wildberries-ähnlichen Infrastruktur mit eigenem Schutz vor Parsing;
- Websites hinter Cloudflare mit aktiviertem "Under Attack"-Modus oder hohem Sicherheitslevel;
- Portalen mit dynamischen Inhalten, bei denen jede Anfrage eine Last auf dem Server erzeugt (Suche, Filter, Produktlisten);
- Websites von Wettbewerbern, die Sie nicht von Ihrer Domain aus analysieren – sie haben keinen Grund, Ihrer IP zu vertrauen.
Eine zusätzliche Schwierigkeit: Wenn eine Agentur eine statische Büroadresse hat und die Audits regelmäßig durchgeführt werden (mehrere Kunden pro Tag), wird diese IP schnell auf schwarze Listen der Schutzsysteme gesetzt. Danach werden nicht nur aktuelle, sondern auch zukünftige Audits von derselben Adresse blockiert – selbst für Websites, die zuvor problemlos geöffnet wurden.
Wie man Blockierungen anhand von Antwortcodes erkennt
Bevor Sie die Proxy-Einstellungen ändern, ist es wichtig zu verstehen, was genau passiert. Screaming Frog zeigt den Antwortcode in der Spalte Statuscode an – daran lässt sich leicht erkennen, warum das Crawlen gestoppt wurde.
| Antwortcode | Was bedeutet das | Was tun |
|---|---|---|
| 403 Forbidden | IP wurde vom Schutz der Website blockiert | IP wechseln, Crawling-Geschwindigkeit reduzieren |
| 429 Too Many Requests | Anfragenlimit pro Zeiteinheit überschritten | Anzahl der Threads reduzieren, Verzögerung hinzufügen |
| 503 Service Unavailable | Server überlastet oder Bot-Schutz aktiviert | User-Agent wechseln, Residential IP verwenden |
| Keine Antwort / Timeout | IP auf schwarzer Liste, Anfragen erreichen nicht | Vollständiger Austausch des Proxy-Pools |
Wenn im Bericht massenhaft derselbe Code auf Tausenden von URLs erscheint – ist das fast immer eine IP-Blockierung und kein echtes Problem der Website. Die Hypothese lässt sich einfach überprüfen: Öffnen Sie die problematische URL in einem normalen Browser von derselben IP. Wenn die Seite normal geöffnet wird, während Screaming Frog 403 erhält – liegt das am Crawler und nicht an der Website.
Welche Proxys für SEO-Crawling geeignet sind
Die Wahl des Proxytyps hängt von der Aufgabe ab: einmaliges Audit der eigenen Website, regelmäßige Überwachung von Wettbewerbern oder Scannen eines geschützten Marktplatzes. Lassen Sie uns drei Haupttypen und deren Anwendbarkeit für Crawler untersuchen.
| Proxytyp | Geschwindigkeit | Blockierungsrisiko | Wann verwenden |
|---|---|---|---|
| Data Center Proxys | Hoch | Mittel-hoch auf geschützten Websites | Audit der eigenen Website ohne strengen Schutz |
| Residential Proxys | Mittel | Niedrig | Audit von Wettbewerbern, Websites hinter Cloudflare, Marktplätze |
| Mobile Proxys | Mittel-niedrig | Minimal | Für die aggressivsten Schutzmaßnahmen, seltene punktuelle Audits |
Für die meisten regelmäßigen technischen Audits bieten Residential Proxys das optimale Gleichgewicht – sie verwenden echte IP-Adressen von Anbietern, sodass der Schutz der Website die Anfragen des Crawlers als Traffic eines normalen Benutzers wahrnimmt. Dies ist besonders wichtig, wenn Sie nicht Ihre eigene Domain, sondern die Website eines Wettbewerbers oder einen Marktplatz mit einem strengen Anti-Bot-System analysieren.
Data Center Proxys bleiben eine gute Option, wenn Sie Ihre eigene Website auditieren und die IP-Bereiche im Voraus auf der WAF- oder Cloudflare-Ebene auf die Whitelist setzen können – dann wird die Scangeschwindigkeit maximal sein, ohne Risiko von Blockierungen.
Schritt-für-Schritt-Anleitung zur Proxy-Einrichtung in Screaming Frog
Screaming Frog unterstützt Proxys "out of the box", die Einrichtung dauert ein paar Minuten:
- Öffnen Sie das Programm und gehen Sie zu Configuration → System → Proxy.
- Setzen Sie ein Häkchen bei Use Proxy Server for All Traffic.
- Geben Sie die Adresse und den Port des Proxy-Servers ein, die Sie vom Anbieter erhalten haben.
- Wenn der Proxy eine Authentifizierung mit Benutzername und Passwort erfordert – geben Sie diese im Popup-Fenster bei der ersten Anfrage an.
- Klicken Sie auf OK und starten Sie das Crawling neu, um die Einstellungen anzuwenden.
Ein wichtiger Hinweis: Screaming Frog kann in der kostenlosen und kostenpflichtigen Version nur mit einem Proxy-Server gleichzeitig über die integrierte Schnittstelle arbeiten. Wenn eine IP-Rotation in Echtzeit erforderlich ist (relevant beim Scannen von 50.000 Seiten oder mehr), verwenden Sie Proxys mit automatischer IP-Wechsel auf der Anbieterseite – dies wird nicht im Crawler selbst, sondern im persönlichen Bereich des Proxy-Dienstes konfiguriert, wo das Intervall für den IP-Wechsel festgelegt wird (z. B. alle 10 Minuten oder bei jeder neuen Anfrage).
Dieses Schema entlastet eine einzelne Adresse: Der Crawler arbeitet weiterhin mit einem Port, während die IP automatisch wechselt, und die Website sieht keine anormal hohe Anfragefrequenz von einer bestimmten Adresse.
Geschwindigkeits- und Thread-Einstellungen für große Websites
Selbst mit einem funktionierenden Proxy können zu aggressive Crawling-Geschwindigkeitseinstellungen zu Blockierungen führen. In Screaming Frog ist dafür der Abschnitt Configuration → Speed verantwortlich. Empfohlene Werte für Websites mit mehr als 100.000 Seiten:
- Max Threads: 2–5 für geschützte Websites, 10–15 für Websites ohne strengen Schutz;
- Max URI/s: zu Beginn auf 2–3 Anfragen pro Sekunde beschränken, allmählich erhöhen und die Antwortcodes beobachten;
- Custom User-Agent: im Abschnitt Configuration → HTTP Header verwenden Sie den User-Agent eines echten Browsers anstelle des Standard "Screaming Frog SEO Spider", wenn die Website Crawler anhand des Headers blockiert;
- Respect robots.txt / crawl-delay: Berücksichtigen Sie die Crawl-delay-Direktive, wenn sie angegeben ist – das Ignorieren führt häufig zu einer Sperre auf Serverebene.
Für Websites mit aggressivem Bot-Schutz ist es auch nützlich, den JavaScript Rendering-Modus nur dort zu aktivieren, wo es wirklich notwendig ist (SPA-Websites auf React/Vue) – das Rendern von JS erhöht die Serverlast erheblich und erhöht die Wahrscheinlichkeit einer Blockierung beim Crawlen über eine IP.
IP-Rotation beim Scannen von 100.000+ Seiten
Je größer die Website, desto wichtiger ist es, die Last zwischen IP-Adressen richtig zu verteilen. Für Audits dieser Größenordnung gibt es zwei Schemen:
Zeitbasierte Rotation. Die IP wechselt automatisch alle 5–15 Minuten, unabhängig von der Anzahl der Anfragen. Geeignet für gleichmäßiges, langanhaltendes Crawling, wenn das Scannen über mehrere Stunden verteilt ist.
Anfragebasierte Rotation. Jede neue HTTP-Anfrage erfolgt von einer neuen IP aus dem Pool. Dieser Modus bietet maximalen Schutz vor Blockierungen, kann jedoch die ordnungsgemäße Funktion mit cookie-basierter Authentifizierung oder Sitzungsparametern der Website beeinträchtigen – für ein reines technisches Audit (Sammlung von Statuscodes, Weiterleitungen, Metatags) ist das nicht kritisch.
Für Agenturen, die parallele Audits mehrerer Kunden-Websites durchführen, ist es sinnvoll, die IP-Pools nach Projekten zu trennen – dies verhindert, dass eine Blockierung auf einer Domain "versehentlich" auf die Reputation der IP bei der Arbeit mit einer anderen Website übergreift.
Praktischer Tipp: Führen Sie vor einem großen Audit ein Test-Crawling von 500–1000 URLs mit den aktuellen Geschwindigkeits- und Proxy-Einstellungen durch. Wenn in dieser Zeit keine 403/429-Fehler aufgetreten sind, können Sie das Scannen auf die gesamte Website sicher ausweiten.
Checkliste vor dem Start des Audits
- ✅ Proxy ist verbunden und auf Erreichbarkeit getestet (Überprüfung über curl oder einen separaten Browser);
- ✅ Max Threads und Max URI/s sind konservativ für den ersten Durchlauf eingestellt;
- ✅ User-Agent ist korrekt konfiguriert, weckt keine Verdachtsmomente beim WAF;
- ✅ Respect robots.txt ist aktiviert, wenn die Website ausdrücklich um Beachtung des Crawl-delay bittet;
- ✅ JavaScript Rendering ist nur bei tatsächlichem Bedarf aktiviert;
- ✅ IP-Rotation ist bei einem Website-Volumen von 20.000–30.000 Seiten eingerichtet;
- ✅ Fortschritt des Crawlings ist aktiviert (Configuration → Save Crawl) für den Fall eines Sitzungsabbruchs;
- ✅ Für das Audit von Marktplätzen und geschützten Portalen wurden Residential oder Mobile Proxys anstelle von Data Center Proxys ausgewählt.
Häufige Fehler beim Crawlen über Proxys
Zu hohe Geschwindigkeit zu Beginn. Spezialisten setzen oft sofort die maximale Anzahl an Threads, in der Hoffnung, das Audit zu beschleunigen. Infolgedessen reagiert der Schutz der Website blitzschnell, und schon nach ein paar Minuten landet der gesamte Proxy-Pool auf der schwarzen Liste.
Eine statische IP für alle Kundenprojekte. Wenn eine Agentur denselben Data Center Proxy für Dutzende von Audits pro Monat verwendet, sinkt die Reputation dieser IP schnell – die Schutzsysteme verschiedener Websites tauschen Informationen über verdächtige Adressen über gemeinsame Datenbanken aus (z. B. Cloudflare IP Reputation).
Ignorieren von Geo-Targeting. Wenn die audierte Website auf eine bestimmte Region eingestellt ist (z. B. ein russischer Online-Shop mit Geo-Blockierung für ausländischen Traffic), wird die Verwendung von Proxys mit IPs aus einem anderen Land selbst eine Zugangsbeschränkung auslösen – selbst ohne aggressives Crawling.
Fehlende Überwachung während des Prozesses. Wenn das Crawling über mehrere Stunden läuft, überprüfen Spezialisten oft nicht die Zwischenantwortcodes. Infolgedessen entdecken sie das Problem erst nach Abschluss, wenn die Hälfte des Berichts aus Blockierungsfehlern und nicht aus tatsächlichen Daten zur Website besteht.
Fazit
Blockierungen während eines technischen Audits in Screaming Frog lassen sich fast immer durch eine Kombination aus drei Faktoren lösen: der richtige Proxytyp, eine angemessene Crawling-Geschwindigkeit und eine durchdachte IP-Rotation. Für eigene Websites ohne strengen Schutz sind Data Center Proxys mit Whitelisting ausreichend. Für Audits von Wettbewerbern, Marktplätzen und Websites hinter Cloudflare sind IPs erforderlich, die wie normaler Benutzertraffic aussehen.
Wenn Sie regelmäßig fremde Domains oder geschützte Plattformen auditieren, empfehlen wir, mit Residential Proxys zu beginnen – sie verringern das Risiko von Blockierungen bei den aggressivsten Anti-Bot-Systemen. Für punktuelle Aufgaben auf maximal geschützten Ressourcen sollten Sie mobile Proxys in Betracht ziehen, während Data Center Proxys für großangelegte Audits der eigenen Infrastruktur eine gute und schnelle Lösung bleiben.