Die CoreDash-Bots: Was sie abrufen und wie du sie erkennst

Wer die CoreDash-Bots betreibt und warum sie Seiten aufrufen

CoreDash ist ein Real-User-Monitoring-Tool für Core Web Vitals. Website-Betreiber sehen damit, wie schnell ihre Seiten bei echten Besuchern laden – mobil und auf dem Desktop. CoreDash sitzt im niederländischen Bergen op Zoom und betreibt beide Bots selbst.

Ein CoreDash-Bot ruft eine Seite nur auf, wenn ein CoreDash-Kunde das anfordert: indem er die Seite zu einem Uptime-Monitor hinzufügt oder ihr Audit öffnet. Die Bots folgen keinen Links und suchen nie von selbst nach Seiten. Nichts von dem, was sie abrufen, landet in einem Suchindex oder trainiert ein KI-Modell. Die Ergebnisse gehen an den Kunden, der sie angefordert hat – und an niemanden sonst.

CoreDash-User-Agents

CoreDash/1.0 (uptime; +https://www.coredash.app/bot)
CoreDash/1.0 (audit; +https://www.coredash.app/bot)

Das Wort in Klammern zeigt, welcher Bot den Request gesendet hat. Der Link führt zu dieser Seite. Jedes CoreDash-Tool sendet einen User-Agent, der mit CoreDash/ beginnt – auch künftige Tools. Eine Suche in den Logs oder eine Firewall-Regel für CoreDash/ findet sie alle. Diesen Namen kann allerdings jeder senden. Gleiche die Quelladresse eines Requests deshalb immer auch mit der ips.json ab.

Der Uptime-Check und das cRUM-Audit

Im Access-Log eines Servers sehen die beiden Bots so aus: der Uptime-Check zur vollen und zur halben Stunde und ein Audit, das eine Seite zusammen mit ihrem CSS und einem Bild lädt.

Das Access-Log von www.example-shop.com.

Der Uptime-Check

Ein Kunde fügt in CoreDash eine URL zu einem Uptime-Monitor hinzu. Ab da ruft der Uptime-Check diese URL alle 30 Minuten ab: ein CoreDash-Server zur vollen Stunde, der andere zur halben Stunde. Das ergibt 48 Checks pro Tag für jeden Monitor.

Jeder Check ist ein GET-Request für das HTML, plus ein weiterer für jeden Redirect – bis zu fünf in Folge. Er liest höchstens die ersten 256 KB der Antwort und lädt keine Bilder, Skripte oder CSS. Hat der Kunde die IP-Adresse des Servers hinterlegt, sendet jeder Check auch einen Request direkt an diesen Server, am CDN vorbei. So sieht CoreDash, ob der Server selbst antwortet. CoreDash speichert den Statuscode und die Timings – und nichts von der Seite selbst.

Das cRUM-Audit

Das cRUM-Audit ist der Speedtest von CoreDash für eine einzelne Seite. Es läuft, wenn ein Kunde den Report dieser Seite in CoreDash öffnet – und erneut, wenn er ihn neu startet oder zwischen Smartphone und Desktop wechselt. Es gibt keinen Zeitplan: Eine Seite, deren Report niemand öffnet, bekommt nie ein Audit.

Das Audit lädt die Seite einmal in Chrome ohne Cache – wie ein Erstbesucher auf dem Smartphone oder Desktop. Chrome ruft dann alles ab, was die Seite anfordert: CSS, Skripte und Bilder, genau wie bei jedem anderen Besucher. In deinem Log siehst du den Request für die Seite mit _cache_bust= und Zeitstempel in der URL. Danach folgen die Requests für ihre Dateien – alle mit dem Audit-User-Agent.

Dateien, die die Seite von einer anderen Website lädt – etwa ein Webfont oder ein Analytics-Skript –, werden ebenfalls mit dem Audit-User-Agent abgerufen. Hostest du so eine Datei, kann CoreDash in deinem Log für eine Seite auftauchen, die dir gar nicht gehört. Jeder dieser Requests gehört zum Laden der Seite, die ein Kunde ausgewählt hat.

So prüfst du, ob ein Request von CoreDash stammt

CoreDash veröffentlicht die Adressen seiner Bots unter app.coredash.app/bot/ips.json. Das ist eine JSON-Datei im selben Format, das Google für die Adressen seiner Crawler nutzt – mit einem service-Feld, das für jede Adresse „uptime“ oder „audit“ angibt. Ein Request mit CoreDash-User-Agent von einer Adresse, die nicht in dieser Datei steht, stammt nicht von CoreDash.

Diese Adressen können sich ändern: CoreDash fügt ab und zu Server hinzu oder verlegt Server. Prüfe daher immer gegen den aktuellen Stand der Datei. Der Wert von creationTime ändert sich mit jeder Änderung der Liste.

CoreDash-Kunden haben eine zweite Prüfmöglichkeit. Jedes Projekt hat ein eigenes, geheimes Bot-Token. Beide Bots senden es im Header X-CoreDash-Bot mit, wenn sie die Website des Projekts oder eine ihrer Subdomains aufrufen. Aufrufe anderer Websites enthalten kein Token. Das Token findest du in CoreDash unter Project settings im Tab „CoreDash bot token“.

CoreDash-Bots durch deine Firewall lassen

Manchmal stuft eine Firewall oder ein CDN die CoreDash-Bots als nicht vertrauenswürdig ein und blockiert sie. Um sie durchzulassen, erlaube Requests, deren User-Agent mit CoreDash/ beginnt. Gehört die Website zu deinem eigenen CoreDash-Projekt, ist eine Regel für dein Bot-Token sicherer: Nur Requests deines Projekts tragen es. Gib die IP-Adressen nur frei, wenn nichts anderes geht. Denk daran, dass sie sich ändern können. CoreDash-Bots durch dein CDN oder deine Firewall lassen beschreibt die Schritte für Cloudflare und AWS WAF.

Warum die CoreDash-Bots keine robots.txt lesen

Eine robots.txt sagt Crawlern, welche Seiten sie aufrufen dürfen, wenn sie eine Website eigenständig durchsuchen. Die CoreDash-Bots tun das nie. Jeder Aufruf wird von einem Kunden ausgelöst – genau wie Lighthouse eine Seite lädt, wenn jemand einen Test startet. Deshalb liest keiner der beiden Bots die robots.txt. Eine Disallow-Zeile stoppt sie nicht.

CoreDash-Bots auf deiner Website stoppen

Wenn du Fragen zu den Bots hast oder sie nicht auf deiner Website haben willst, kontaktiere CoreDash über die Kontaktseite. Schick die URL und eine CoreDash-Zeile aus deinem Log mit. CoreDash stoppt die Besuche auf deiner Website dann.