Über Nacht

Um 3 Uhr morgens pazifischer Zeit bedient meine Produktionswebsite mehr Anfragen als zu irgendeinem Zeitpunkt während des Geschäftstages. Nicht für Benutzer. Für Bots.

Googlebot crawlt 21.000 Seiten. Bingbot crawlt 10.000. Mein umfassender Nightcheck arbeitet sich durch 15.000 Blogbeiträge und Unternehmensseiten. Ein Warm Pass befüllt den Cloudflare-Edge-Cache für den Datenverkehr des nächsten Tages. Zusammen berühren die nächtlichen Prozesse mehr Seiten als alle menschlichen Besucher zusammen.

Die Website, die ich tagsüber baue, ist nicht die Website, die am meisten zählt. Die Website, die am meisten zählt, ist diejenige, die die Crawler um 3 Uhr nachts sehen.

Der Crawl-Zensus

Jeden Tag führe ich einen Crawl-Zensus durch, der zählt, was die Bots in den letzten 24 Stunden gesehen haben. Der Zensus nutzt Cloudflares Analytics-API, gefiltert nach User Agent. Die Zahlen erzählen eine Geschichte darüber, was Suchmaschinen wertschätzen:

Google:     21.463  (67%)
Bing:       10.620  (33%)
Gesamt:     32.083

Jobs:       16.111  (50% aller Crawls)
Blog:       298
Locale:     1.233
Programmatisch: 257
Unternehmen: 14

Jobs verbrauchen die Hälfte des Crawl-Budgets. Googlebot crawlt 10.654 Stellenseiten pro Tag. Die Job-Sitemap hat keine Obergrenze. Jede berechtigte Stellenanzeige ist enthalten. Die Verteilung des Crawl-Budgets verrät mir, was Google als den wertvollsten Inhalt der Website betrachtet.

Blogbeiträge erhalten 298 Crawls pro Tag, obwohl sie die qualitativ hochwertigsten Inhalte darstellen. Das Verhältnis der Crawl-Investition (Jobs 50-mal mehr als Blog) entspricht nicht der Inhaltsinvestition (Blog erfordert 100-mal mehr Aufwand pro Seite als Jobs). Suchmaschinen crawlen, was sie im großen Maßstab indexieren können, nicht was am meisten Aufwand in der Erstellung erforderte.

Unternehmensseiten erhalten 14 Crawls pro Tag, obwohl über 7.000 Seiten in der Sitemap vorhanden sind. Dies ist ein Problem der Crawl-Budget-Aushungerung: Die Stellenseiten verbrauchen so viel Budget, dass Unternehmensseiten kaum entdeckt werden. Die nächtlichen Daten haben dieses Problem offenbart. Ohne den Zensus hätte ich nicht gewusst, dass 7.000 Unternehmensseiten für Crawler praktisch unsichtbar sind.

Was 410 verrät

Der Zensus erfasst HTTP-Statuscodes. Der interessanteste Status ist 410: Gone.

Google 410s:  7.614  (35,5% der Crawls)
Bing 410s:    4.494  (42,3% der Crawls)

Über ein Drittel aller Crawler-Anfragen treffen auf abgelaufene Stellenseiten, die 410 zurückgeben. Dies sind Jobs, die existierten, als der Crawler sie erstmals entdeckte, indexiert wurden und seitdem entfernt worden sind. Der 410-Code teilt dem Crawler mit: „Diese Seite existierte, ist aber dauerhaft verschwunden – hör auf, sie anzufragen.”

Die 410-Rate sinkt. Letzte Woche lag sie bei 8.858 für Google. Diese Woche sind es 7.614. Die Crawler lernen. Jeden Tag sinkt die Anzahl der Geisteranfragen, während die Suchmaschinen ihre Indizes aktualisieren. Allerdings verläuft das Lernen langsam. Bings 410-Rate (42,3 %) ist höher als die von Google (35,5 %), weil Bing Entfernungssignale langsamer verarbeitet.

Der 410-Trend ist das klarste nächtliche Signal. Er zeigt mir die Geschwindigkeit, mit der die Suchmaschinen sich dem aktuellen Zustand der Website annähern. Eine steigende 410-Rate bedeutet, dass ich Inhalte schneller entferne, als die Crawler sich anpassen können. Eine sinkende 410-Rate bedeutet, dass der Index aufholt. Das Gleichgewicht liegt bei null 410s – was bedeutet, dass jede vom Crawler angeforderte Seite noch existiert.

Das 524-Problem

Cloudflare gibt 524 zurück, wenn der Origin-Server nicht innerhalb des Timeout-Fensters antwortet. An einem Tag mit vielen Deployments (87 Commits) zeigte der Zensus:

Google 524s:  68  (0,3%)
Bing 524s:    0

Achtundsechzig Origin-Timeouts in 24 Stunden. Jeder einzelne bedeutet, dass Googlebot eine Seite anforderte, Cloudflare die Anfrage an Railway weiterleitete und Railway nicht rechtzeitig antwortete. Die wahrscheinlichste Ursache waren Worker-Neustarts bei Railway während häufiger Deployments. Jedes Deployment startet die Anwendung neu und erzeugt ein kurzes Zeitfenster, in dem Anfragen ablaufen.

Bei 0,3 % der Crawls sah Google eine defekte Website. Die 524-Fehler tauchten in keinem Anwendungslog auf, weil die Anwendung zum Zeitpunkt ihres Auftretens nicht lief. Der Fehler existierte nur im Zwischenraum zwischen Cloudflare und Railway, sichtbar ausschließlich durch den Crawl-Zensus.

Am nächsten Morgen sank die 524-Anzahl auf null. Die Deployments hatten aufgehört. Die Worker waren stabil. Die nächtlichen Daten bestätigten, dass das Problem vorübergehende Deployment-Turbulenz war, kein strukturelles Problem.

Der Warm Pass

Bevor die Crawler eintreffen, läuft der Warm Pass. Er ruft jeden Blogbeitrag, jede Locale-Variante und 50 Unternehmensseiten über Cloudflares Edge-Cache ab. Das Ziel ist sicherzustellen, dass Googlebot beim Aufruf einer Seite eine gecachte Antwort erhält, statt auf ein Origin-Rendering zu warten.

Der Unterschied ist erheblich. Ein gecachter Blogbeitrag antwortet in 80 ms. Ein nicht gecachter Blogbeitrag benötigt 1,5 Sekunden vom Origin. Googlebot hat ein Crawl-Rate-Budget, gemessen in Anfragen pro Sekunde. Schnellere Antworten bedeuten mehr gecrawlte Seiten im selben Zeitfenster. Ein warmer Cache verdoppelt die effektive Crawl-Abdeckung.

Der Warm Pass ist für Benutzer unsichtbar. Kein menschlicher Besucher profitiert von einem um 2 Uhr nachts gecachten Blogbeitrag. Doch der Warm Pass bestimmt, ob Googlebot in seinem nächtlichen Zeitfenster 300 oder 600 Blogbeiträge entdeckt. Die SEO-Auswirkung ist real, auch wenn kein Mensch den Mechanismus sieht.

Was die Nacht offenbart

Jeden Morgen lese ich die nächtlichen Logs. Das Muster ist immer dasselbe: größtenteils grün, ein paar Anomalien, ein oder zwei Dinge, die eine Untersuchung wert sind. Der Rhythmus ist langweilig. Der Wert liegt im langweiligen Rhythmus.

Eine langweilige Nacht bedeutet, dass die Deployments nichts kaputt gemacht haben, die Crawler fanden, was sie erwarteten, der Cache funktioniert und die Website für den Datenverkehr des nächsten Tages bereit ist. Eine interessante Nacht bedeutet, dass sich etwas geändert hat: ein neues Fehlermuster, eine Cache-Regel, die nicht mehr funktioniert, eine Crawl-Budget-Verschiebung, die auf eine Änderung des Ranking-Signals hindeutet.

Der Crawl-Zensus zeigte mir, dass 7.000 Unternehmensseiten für Google unsichtbar sind. Keine Tagesmetrik hätte dies offenbart. Benutzeranalysen zeigen null Traffic auf Unternehmensseiten, was ich geringer Nachfrage zuschrieb. Der Zensus zeigte null Crawls auf Unternehmensseiten, was bedeutet, dass Google die Seiten noch nicht einmal bewertet hat. Das Problem ist nicht die Nachfrage. Das Problem ist die Auffindbarkeit.

Die 524-Analyse zeigte mir, dass Railway-Deployments Origin-Timeout-Fenster erzeugen, die Googlebot trifft. Kein Anwendungsmonitoring hätte dies offenbart, weil die Anwendung während des Timeouts nicht läuft. Das Problem existiert in der Infrastrukturlücke zwischen Deployment und Verfügbarkeit.

Der 410-Trend zeigte mir, dass Bing Entfernungssignale 20 % langsamer verarbeitet als Google. Dies ist für SEO relevant: Abgelaufene Stellenseiten verbleiben länger in Bings Index und liefern potenziell veraltete Ergebnisse an Benutzer, die über Bing-betriebene Oberflächen suchen (DuckDuckGo, Yahoo).

Jede dieser Erkenntnisse stammte aus den nächtlichen Daten. Der Tag verrät, was Benutzer tun. Die Nacht verrät, was die Infrastruktur tut, wenn niemand zusieht. Beides ist wichtig. Für SEO ist die Nacht wichtiger.

FAQ

Wie führen Sie den Crawl-Zensus durch?

Der Zensus nutzt Cloudflares GraphQL-Analytics-API (httpRequestsAdaptiveGroups), gefiltert nach User-Agent-Mustern (%Googlebot% und %bingbot%). Er kategorisiert Seiten nach URL-Pfad-Präfix und aggregiert Statuscodes. Das Skript läuft in 30 Sekunden und erzeugt einen Seite-an-Seite-Vergleich des Crawl-Verhaltens von Google und Bing.

Warum nicht Google Search Console für Crawl-Daten verwenden?

Google Search Console meldet Crawl-Statistiken mit einer Verzögerung von 2–3 Tagen und begrenzter Granularität. Der Cloudflare-Zensus ist nahezu in Echtzeit (letzte 24 Stunden) und enthält Statuscodes, Inhaltskategorien und Cache-Status, die GSC nicht meldet. GSC eignet sich für Trends. Der Zensus eignet sich für operative Entscheidungen.

Erhöht der Warm Pass die Cloudflare-Kosten?

Nein. Cloudflare-Caches werden durch jede Anfrage befüllt, unabhängig von der Quelle. Der Warm Pass verwendet Standard-HTTP-Anfragen, die gegen das normale Anfragenkontingent zählen. Im kostenlosen Tarif gibt es kein Anfragenlimit für gecachte Antworten. Die Origin-Anfragen während des Warm Pass zählen gegen Railways Bandbreite, aber bei 15.000 Seiten mit durchschnittlich 50 KB beträgt das Gesamtvolumen etwa 750 MB pro Warm Pass.

Was passiert, wenn Crawler ihr Verhalten ändern?

Der Zensus erfasst, was auch immer die Crawler tun, unabhängig von Änderungen. Eine Verschiebung im Crawl-Muster (mehr Stellenseiten, weniger Blogseiten) erscheint sofort im nächsten Zensus. Die Trenddaten über mehrere Tage hinweg zeigen, ob die Verschiebung eine einmalige Anomalie oder eine dauerhafte Veränderung ist.

Quellen

Dieser Artikel basiert auf täglichen Crawl-Zensus-Daten, die seit März 2026 über die Cloudflare GraphQL API erhoben werden. Zensus-Tool: ~/Projects/Utility/crawl_census.py. Nightcheck-Tool: ~/.claude/skills/nightcheck/.