Cloudflare 5-Sekunden-Schild: 3 Konfigurationstipps für SEO und UX

Einleitung

Server-CPU bei 100 %, Traffic zehnfach – typischer CC-Angriff. Im Cloudflare-Dashboard „I’m Under Attack” aktivieren, 30 Sekunden später sinkt die Serverlast.

Am nächsten Tag Google Search Console: Index von über 1.200 auf unter 800 – minus 30 %. Ursache: Der 5-Sekunden-Schild blockiert auch Suchmaschinen-Crawler.

Ohne Schild hält man den Angriff nicht aus, mit Schild leiden SEO und UX. Dieser Artikel zeigt, wie Cloudflares 5-Sekunden-Schild Angriffe abwehrt und SEO sowie Nutzererlebnis möglichst schont.

Kapitel 1: Was ist der 5-Sekunden-Schild (Under-Attack-Modus)?

Funktionsweise: Was in den 5 Sekunden passiert

Kurz gesagt legt Cloudflare zwischen Website und Besucher eine Prüfbarriere. Statt direktem Zugriff erscheint eine Übergangsseite – etwa 5 Sekunden Wartezeit.

In dieser Zeit passiert Folgendes:

Schritt 1: Der Browser sendet automatisch die erste Anfrage. Cloudflare setzt das __cfduid-Cookie – ein temporärer Pass.

Schritt 2: Der Browser sendet eine zweite Anfrage mit verschlüsselten Parametern. Nach Prüfung setzt Cloudflare das cf_clearance-Cookie – der echte Pass, Standard-Gültigkeit 30 Minuten.

Schritt 3: Mit beiden Cookies fordert der Browser die Startseite an. Cloudflare prüft und lässt durch – erst dann lädt der Seiteninhalt.

Zusätzlich im Hintergrund:

• JavaScript-Prüfung: Obfuskiertes JS prüft, ob der Browser JavaScript ausführt. Normale Browser bestehen, einfache Crawler und Angriffsskripte scheitern oft.
• Browser-Fingerprinting: Auflösung, Plugins, Systemschriften usw. bilden einen einzigartigen Fingerabdruck – erkennt Tools, die sich als Browser tarnen.
• Verhaltensanalyse: Request-Frequenz, User-Agent, Mausbewegungen – Mensch oder Bot?

Unterschied zu anderen Security Levels

Cloudflare bietet mehrere Stufen – nicht nur den 5-Sekunden-Schild:

Im Alltag reicht Medium. Nur bei echtem Angriff temporär auf I’m Under Attack – nicht dauerhaft wie eine Gasmaske im Alltag.

Wogegen der Schild schützt

Netzwerkangriffe folgen dem OSI-Modell – je höher die Schicht, desto näher an der Anwendung.

Der Schild schützt vorwiegend vor Layer-7-Angriffen – CC-Angriffe (Challenge Collapsar): simulierte normale Besucher in großer Menge, Serverressourcen erschöpft.

Gegen volumetrische DDoS (UDP Flood, SYN Flood) wirkt er begrenzt – Cloudflare nutzt andere Mechanismen. Offiziell: „zusätzliche Sicherheitsprüfungen zur Minderung von Layer-7-DDoS” – Minderung, nicht vollständige Blockade. Bei sehr großem DDoS braucht es weitere Maßnahmen.

Kapitel 2: Reale Auswirkungen auf SEO und Nutzererlebnis

Kommen Suchmaschinen-Crawler durch?

Es kommt darauf an.

Googlebot führt JavaScript aus und kann theoretisch bestehen. Crawler-Zeit ist knapp – statt 5 Sekunden zu warten, crawlt Google erst andere Sites und kommt später zurück.

Beobachtungen in der Search Console nach Aktivierung:

1. Crawl-Frequenz sinkt: von ~1.200/Tag auf 400–600.
2. Mehr Crawl-Fehler: Timeouts, Serverfehler.
3. Langsamere Indexierung: neue Artikel von 1–2 auf 4–5 Tage.

Baidu-Crawler: schwaches JavaScript – Crawling scheitert meist. Ein Bekannter mit chinesischer Site: 3 Tage Schild, Index von 2.000+ auf ~1.000.

Bing: zwischen Google und Baidu – langsamer, Index −15–20 %.

Reale Nutzerdaten

Ein A/B-Test vor und nach Aktivierung:

Absprungrate explodiert:

• Vorher: 35 %
• Nachher: 62 %
• Anstieg: 77 %

Fast 6 von 10 neuen Besuchern schließen nach der 5-Sekunden-Seite. Mobil bis 75 %.

Verweildauer:

• Vorher: 3:15
• Nachher: 1:48
• Rückgang: 45 %

Conversion halbiert:
Bei Registrierung oder Kauf rechnen Sie mit etwa halber Conversion. Nutzer klicken motiviert – warten 5 Sekunden – Stimmung kippt.

Ein E-Commerce-Bekannter: Angriff, Schild aktiv, Bestellungen von 60 auf 22 – Angriff abgewehrt, Umsatz auch.

Verzerrte Analytics-Daten

Cloudflare-Dokumentation: „Da JavaScript für die Übergangsseite nötig ist, ist Störung von JavaScript-basierten Analytics-Tools erwartbar.”

Google Analytics zeigt weniger:

• Auf der Warte-Seite kein GA-Tracking
• Abspringende Nutzer fehlen in den Statistiken
• Sichtbar nur „bestandene” Besucher – tatsächlicher Traffic höher

Heatmaps unbrauchbar:
Hotjar, Crazy Egg erfassen kein Verhalten auf der Warte-Seite. Die Hälfte scheint gar nicht anzukommen.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Ad-Tracking blind:
Google Ads, Facebook Pixel laden auf der Challenge-Seite nicht – Budget verbraucht, Conversions unsichtbar.

Katastrophe für APIs und Drittanbieter

Für Webseiten erträglich, für APIs verheerend.

Problem 1: API-Anfragen scheitern
Programm-zu-Programm – kein JavaScript, keine 5 Sekunden Wartezeit, sofort Fehler.

Extremfall: Mobile App mit Cloudflare-geschützter API, versehentlich site-weiter Schild – 50.000+ aktive Nutzer, App tot, Support überlastet.

Problem 2: Drittanbieter-Integrationen brechen ab

• Payment-Callbacks (PayPal, Stripe)
• Webhooks (GitHub, Slack)
• RSS
• Monitoring (Uptime Robot)

Keine Challenge-Prüfung – alles blockiert. Payment-Callback-Fehler: Nutzer zahlt, Shop erhält keinen Status – Support-Chaos.

Problem 3: Mobile Apps nicht erreichbar
iOS/Android über Web-API: Schild = App permanent „Loading”, dann Netzwerkfehler.

Fazit: Bei API, Mobile App oder wichtigen Integrationen niemals site-weit den Schild aktivieren. Page Rules zum Ausschließen – Kapitel 3 im Detail.

Kapitel 3: Schild nur für bestimmte Pfade (Page Rules)

Was sind Page Rules?

Bedingte Regeln: pro URL-Pfad unterschiedliche Security Level, Cache-Strategien usw.

Beispiel:

• example.com/api/* → Security Level Low
• example.com/admin/* → I’m Under Attack
• Rest → Medium

Gezilter Schutz – nur wo nötig.

Hinweis: Cloudflare kündigte im Juni 2024 an, Page Rules schrittweise durch Configuration Rules, Cache Rules usw. zu ersetzen. Bestehende Page Rules bleiben nutzbar, Migration übernimmt Cloudflare.

Free: 3 Page Rules – für viele persönliche Sites ausreichend. Pro: 20, Business: 50.

URL-Matching: Wildcard *

Grundregeln:

• * matcht beliebige Zeichenketten (auch leer)
• Überall in der URL
• Mehrere * möglich

Typische Muster:

example.com/api/*
→ matcht example.com/api/users
→ matcht example.com/api/posts/123
→ matcht nicht example.com/apiv2/users (api braucht Schrägstrich)

example.com/*.jpg
→ matcht example.com/logo.jpg
→ matcht example.com/images/banner.jpg
→ matcht nicht example.com/logo.png

example.com/*admin*
→ matcht example.com/wp-admin
→ matcht example.com/admin/users
→ matcht example.com/myadmin

Priorität (sehr wichtig):
Ausführung von oben nach unten – erste passende Regel gewinnt.

1. Spezifische Regeln oben, Wildcards unten
2. Falsche Reihenfolge: Wildcard frisst alles

Falsch:

Regel 1: example.com/* → I'm Under Attack
Regel 2: example.com/api/* → Low

Regel 2 greift nie.

Richtig:

Regel 1: example.com/api/* → Low
Regel 2: example.com/* → I'm Under Attack

Szenario 1: Login und Admin schützen

Häufigstes Szenario – Angreifer zielen auf Login-Bruteforce.

WordPress-Beispiel:

Regel 1: wp-admin

• URL: example.com/wp-admin*
• Security Level → I’m Under Attack

Regel 2: Login

• URL: example.com/wp-login.php
• Security Level → I’m Under Attack

Regel 3: Rest

• URL: example.com/*
• Security Level → Medium

Nur Admin und Login triggern den Schild – normale Artikel-Leser und SEO unberührt.

Szenario 2: API ausschließen

API darf nicht blockiert werden:

Regel 1: API niedrig

• URL: example.com/api/*
• Security Level → Low

Regel 2: Mobile-API-Subdomain

• URL: api.example.com/*
• Security Level → Low

Regel 3: Rest hoch

• URL: example.com/*
• Security Level → I’m Under Attack

API-Regeln zuerst.

Mehrere API-Versionen:

example.com/api/v1/*
example.com/api/v2/*

Verbraucht Regeln. Kompakter:

example.com/api*

Szenario 3: Dynamische Seiten schützen, statische Assets durchlassen

Bilder, CSS, JS brauchen keinen Schild – Blockierung lädt Seiten unvollständig.

Regel 1: Bilder

• URL: example.com/*.jpg
• Security Level → Low, Cache Level → Cache Everything

Weitere Endungen einzeln – verbraucht Regeln. Besser: CDN-Subdomain:

• cdn.example.com/* → Low

Regel 2: Dynamische Seiten

• URL: example.com/*
• Security Level → I’m Under Attack

HTML geschützt, Assets laden normal – besseres UX.

Vollständige Konfiguration

Schritt 1: Cloudflare Dashboard, Domain wählen.

Schritt 2: Rules → Page Rules (ggf. Page Rules (Legacy)).

Schritt 3: Create Page Rule, URL z. B.:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

example.com/api/*

+ Add a Setting → Security Level → Low → Save and Deploy.

Schritt 4: Weitere Regeln – Reihenfolge beachten.

Schritt 5: Priorität per Drag – spezifisch oben, Wildcard unten.

Schritt 6: Inkognito testen:

• API ohne Schild ✓
• Normale Seite mit Schild ✓
• Statische Assets laden ✓

Free-Tier: 3 Regeln optimal nutzen

Regel 1: Wichtigster Eingang

example.com/wp-admin*
Security Level: I'm Under Attack

Regel 2: API und statische Assets

example.com/api*
Security Level: Low

Regel 3: Rest mittel

example.com/*
Security Level: Medium

Kritische Bereiche geschützt, Alltag ungestört. Ohne Angriff nicht auf I’m Under Attack wechseln.

Kapitel 4: Challenge Passage – Best Practices

Was ist Challenge Passage?

Nach bestandener Prüfung speichert Cloudflare cf_clearance – temporärer Pass. Challenge Passage = Gültigkeitsdauer.

Standard: 30 Minuten – danach erneute Prüfung beim nächsten Besuch.

Technische Details:

Clock-Skew-Puffer: Zusätzliche Minuten gegen Client-Server-Zeitabweichung.

XMLHttpRequest: Ajax erhält bis zu 1 Stunde Extra – verhindert häufiges Ablaufen bei SPAs mit kurzem Cache.

Security-Level-Vererbung: Interactive Challenge bestanden → Cookie gilt für alle Stufen. Nur niedrige Stufe bestanden → bei hoher Stufe erneut prüfen.

Einstellung

Cloudflare Dashboard:
Security → Settings → Challenge Passage

Bearbeiten, Minuten eingeben – empfohlen 15–45 Minuten. Global für die Domain, nicht pro Pfad.

Empfehlungen nach Szenario

Hohe Sicherheit (Finanzen, Zahlung): 15–20 Min.

• Online-Banking, Payment, OA
• Sicherheit vor UX, kurze Sessions

Ausgewogen (E-Commerce, SaaS): 30 Min.

• Meiste Business-Sites
• Einkauf oder Browsing in 30 Min. abgeschlossen

UX-Priorität (Content, Blog, Medien): 40–45 Min.

• News, Tech-Blogs, Video
• Lange Sessions, mehrere Artikel

Eigener Tech-Blog: 40 Min. – Leser lesen oft mehrere Artikel hintereinander.

Drei typische Irrtümer

Irrtum 1: Kürzer = sicherer
5 Minuten klingt sicherer – Trugschluss. Kern ist Mensch/Bot-Trennung, nicht Schutz vor Wiederholungsbesuchen desselben Menschen. Echter Angriff scheitert beim ersten Mal oder umgeht die Prüfung – 5 vs. 30 Min. egal.

Irrtum 2: Stundenlang für bessere UX
2 Stunden klingt bequem – aber: Nutzer in Café mit öffentlichem WLAN bestand Prüfung, Cookie bleibt – andere im selben Netz oder Angreifer könnten es nutzen. Obergrenze 45 Min. ist bewusst gesetzt.

Irrtum 3: Gilt für alle Regeltypen
Challenge Passage gilt nicht für Rate Limiting Rules. Rate Limit getriggert → erneute Prüfung, unabhängig von Challenge Passage.

Passende Einstellung erkennen

1. Nutzerbeschwerden
„Immer wieder 5 Sekunden warten” → evtl. zu kurz. Typisches Surfverhalten prüfen.

2. Security Events
Viele wiederholte Challenges derselben IP in kurzer Zeit → evtl. zu kurz.

3. Absprung und Verweildauer
Plötzlicher Absprung-Anstieg, kürzere Verweildauer → evtl. Zweit-Challenge während des Surfens.

Eine Woche beobachten, dann feinjustieren – keine Extremwerte von Anfang an.

Kombination mit WAF

Oft reicht WAF + gezielter Schild statt site-weit + kurzer Passage:

1. WAF filtert offensichtlichen Schadtraffic

   • Bekannte böse IP-Ranges
   • Verdächtige User-Agents
   • Request-Limits

2. Schild nur auf kritischen Pfaden

   • Page Rules: Login, Registrierung, Payment
   • Rest Medium/High

3. Challenge Passage sinnvoll

   • 30 Min. für die meisten Sites

~90 % Angriff via WAF, ~10 % via Schild – sicher und nutzerfreundlich.

Kapitel 5: 7 Best Practices

Praxis 1: Nicht dauerhaft site-weit

Häufigster Anfängerfehler: Panik bei Angriff, Schild an – Monate später noch aktiv.

Richtig:

• Nur bei klarem Angriff temporär
• Nach 1–3 Tagen auf Medium/High
• Monitoring (UptimeRobot)
• Wöchentliche Erinnerung Security Level prüfen

Eigene Regel: Nach Aktivierung 48-Stunden-Alarm – neu bewerten.

Praxis 2: Page Rules für gezielten Schutz

Site-weiter Schild = alle Türen verschweißen. Besser: nur wichtige Türen abschließen.

Schützen:

1. Login (/login, /wp-login.php)
2. Registrierung (/register, /signup)
3. Admin (/admin, /wp-admin)
4. Payment (/checkout, /payment)
5. Formulare (/contact, /comment)

Ausschließen:

1. API (/api/*, /rest/*)
2. Statische Assets (/*.jpg, /*.css, /*.js)
3. RSS (/feed, /rss.xml)
4. robots.txt, sitemap.xml
5. Health (/health, /status)

Tech-Blog-Ideal:

Regel 1: example.com/wp-admin* → I'm Under Attack
Regel 2: example.com/xmlrpc.php → I'm Under Attack
Regel 3: example.com/* → Medium

Praxis 3: Custom Challenge Page (Paid)

Standard-Seite ist Englisch – Paid-Pläne erlauben Anpassung.

Custom Pages → 5-Second Shield, eigenes HTML.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Empfohlene Elemente:

• Logo und Site-Name
• Erklärung: „Browser-Sicherheit wird geprüft, bitte warten …”
• Countdown-Animation
• Kurzer Grund: Schutz vor Angriffen
• Kontakt bei Problemen

Bestes Beispiel: Mini-Spiel während der Wartezeit – deutlich besseres Gefühl.

Praxis 4: WAF-Regeln

Schild ist letzte Linie – WAF entlastet vorher.

Empfohlene WAF-Regeln:

Regel 1: Böse IP-Ranges

(ip.geoip.country in {"CN"} and cf.threat_score > 30)
→ Action: Block

(Nur Beispiel – an Zielgruppe anpassen)

Regel 2: Verdächtige User-Agents

(http.user_agent contains "curl" or http.user_agent contains "python")
→ Action: Challenge

Regel 3: API-Rate-Limit

(http.request.uri.path contains "/api/" and rate > 100/1m)
→ Action: Block for 1h

Regel 4: Login schützen

(http.request.uri.path eq "/wp-login.php" and rate > 5/5m)
→ Action: Challenge

Mit WAF: ~90 % Angriff vorab blockiert.

Praxis 5: Crawler-Whitelist

Verbessert SEO deutlich – Google kann zwar bestehen, reibungsloses Crawling ist besser.

Methode 1: WAF User-Agent

(http.user_agent contains "Googlebot" or
 http.user_agent contains "Bingbot" or
 http.user_agent contains "Baiduspider")
→ Skip: Security Level for this request

Methode 2: Crawler-IP-Whitelist
Google, Bing veröffentlichen Crawler-IP-Ranges – IP Access Rules.

Google-Referenz:
https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot

Hinweis: User-Agent-Spoofing möglich – IP + User-Agent oder DNS-Reverse-Lookup sicherer.

Praxis 6: Monitoring und Anpassung

Konfiguration ist kein Einmal-Job.

Wöchentliche Checkliste:

1. Security Events (Security → Events)

   • Blockierungen, Regeln, IP-Verteilung
   • False Positives?

2. Analytics

   • Traffic, Absprung, Verweildauer

3. Google Search Console

   • Crawl-Frequenz, Index, Fehler

4. Nutzerfeedback

   • Support, Social Media

Eigene Routine: Montag 10 Uhr, 15 Minuten, Excel-Protokoll – bei Anomalie sofort anpassen.

Praxis 7: Eigene Domain für Mobile Apps

Bei iOS/Android-Apps: separate Subdomain für API.

Architektur:

• www.example.com – Frontend, Schild möglich
• api.example.com – API, kein Schild
• admin.example.com – Admin, Schild + Extra-Auth

Sicherheit:

• API Key oder JWT
• WAF Rate Limits
• IP-Whitelist für App-Egress

Vorteile:

1. App unberührt
2. Frontend kann Schild nutzen
3. Entkopplung, einfachere Wartung
4. Pro Domain eigene CDN-Strategie

Kundenbeispiel: häufige Angriffe auf Website, 200.000 DAU in der App – eigene API-Domain, Schild auf www, App läuft weiter.

Fazit

Drei Kernpunkte:

1. Notfallwaffe, kein Dauerschild
Wie Notbremse – im Ernstfall lebensrettend, nicht dauerhaft treten. Alltag: Medium + WAF. Angriff: temporär I’m Under Attack.

2. Page Rules für Präzision
Nicht site-weit – nur Login, Registrierung, Payment. Free: 3 Regeln reichen bei sorgfältiger Planung.

3. Sicherheit und UX ausbalancieren
Keine ewige Konfiguration. Site-Typ, Nutzerverhalten, Angriffs-Lage beobachten. 30 Min. Challenge Passage als Startpunkt – Daten entscheiden.

Aktionsliste:

• Jetzt prüfen: Welches Security Level? I’m Under Attack ohne Angriff → bewerten.
• Page Rules: Mindestens 2 Regeln nach Kapitel 3.
• Challenge Passage: 15–45 Min. passend zum Site-Typ.
• Testen: Inkognito, verschiedene Pfade.
• Monitoring: Wöchentlich Security Events und Analytics.

Wenn der Artikel geholfen hat – teilen Sie ihn mit anderen, die gegen DDoS kämpfen. Erfahrungen und Fragen gerne in die Kommentare.