Les bots CoreDash : ce qu'ils demandent et comment les reconnaître

Qui gère les bots CoreDash et pourquoi ils visitent votre site

CoreDash est un outil de real user monitoring pour les Core Web Vitals. Les propriétaires de sites l'utilisent pour mesurer la vitesse de chargement de leurs pages auprès des vrais visiteurs, sur mobile comme sur desktop. CoreDash est basé à Bergen op Zoom, aux Pays-Bas, et opère lui-même les deux bots.

Un bot CoreDash visite une page uniquement à la demande d'un client CoreDash : en ajoutant la page à un moniteur d'uptime ou en ouvrant son audit. Les bots ne suivent aucun lien et ne cherchent jamais de pages par eux-mêmes. Rien de ce qu'ils récupèrent ne finit dans un index de recherche ni ne sert à entraîner un modèle d'IA. Les résultats vont au client qui les a demandés, et à personne d'autre.

User agents CoreDash

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

Le mot entre parenthèses indique quel bot a envoyé la requête, et le lien renvoie vers cette page. Chaque outil CoreDash envoie un user agent commençant par CoreDash/, y compris ceux ajoutés par la suite. Une recherche dans les logs ou une règle de firewall sur CoreDash/ les trouve tous. N'importe qui peut toutefois envoyer ce nom : vérifiez donc aussi l'adresse d'origine de la requête par rapport à ips.json.

Le check d'uptime et l'audit cRUM

Dans les logs d'accès d'un serveur, les deux bots se présentent ainsi : le check d'uptime à l'heure pile et à la demi-heure, et un audit qui charge une page avec son CSS et une image.

Les logs d'accès de www.example-shop.com.

Le check d'uptime

Un client ajoute une URL à un moniteur d'uptime dans CoreDash. Dès lors, le check d'uptime demande cette URL toutes les 30 minutes : un serveur CoreDash à l'heure pile, l'autre à la demi-heure. Cela fait 48 checks par jour pour chaque moniteur.

Chaque check correspond à une requête GET pour le HTML, plus une par redirection, jusqu'à cinq d'affilée. Il lit au maximum les 256 premiers Ko de la réponse et ne charge ni image, ni script, ni CSS. Si le client a renseigné l'adresse IP du serveur du site, chaque check envoie aussi une requête directe à ce serveur, en contournant le CDN, pour vérifier si le serveur répond. CoreDash conserve le code de statut et les temps de réponse, et rien de la page elle-même.

L'audit cRUM

L'audit cRUM est le test de vitesse de CoreDash sur une seule page. Il s'exécute lorsqu'un client ouvre le rapport de cette page dans CoreDash, puis lorsqu'il relance le test ou bascule entre mobile et desktop. Il n'y a aucune planification : une page dont personne n'ouvre le rapport n'est jamais auditée.

L'audit charge la page une fois dans Chrome, cache désactivé, comme un nouveau visiteur sur mobile ou desktop. Chrome récupère ensuite tout ce que la page demande, le CSS, les scripts et les images, exactement comme pour n'importe quel visiteur. Dans vos logs, vous voyez la requête de la page avec _cache_bust= et un timestamp ajoutés à son URL, suivie des requêtes pour ses fichiers, toutes avec le user agent de l'audit.

Les fichiers que la page charge depuis un autre site, comme une police web ou un script d'analytics, partent aussi avec le user agent de l'audit. Si vous hébergez un tel fichier, CoreDash peut apparaître dans vos logs pour une page qui ne vous appartient pas. Chacune de ces requêtes fait partie du chargement de la page choisie par un client.

Comment vérifier qu'une requête provient de CoreDash

CoreDash publie les adresses d'émission de ses bots sur app.coredash.app/bot/ips.json. C'est un fichier JSON au format utilisé par Google pour les adresses de ses crawlers, avec un champ service qui indique « uptime » ou « audit » pour chaque adresse. Une requête avec un user agent CoreDash issue d'une adresse absente de ce fichier ne provient pas de CoreDash.

Ces adresses peuvent changer : CoreDash ajoute ou déplace des serveurs de temps à autre. Fiez-vous toujours à la version actuelle du fichier. Sa valeur creationTime change à chaque mise à jour de la liste.

Les clients CoreDash disposent d'un second moyen de vérification. Chaque projet possède son propre token secret de bot, et les deux bots l'envoient dans le header X-CoreDash-Bot lorsqu'ils visitent le site du projet ou l'un de ses sous-domaines. Une visite vers tout autre site ne comporte aucun token. Le token se trouve dans CoreDash sous Project settings, onglet « CoreDash bot token ».

Laisser passer les bots CoreDash à travers votre firewall

Un firewall ou un CDN prend parfois les bots CoreDash pour des bots suspects et les bloque. Pour les laisser passer, autorisez les requêtes dont le user agent commence par CoreDash/. Si le site appartient à votre propre projet CoreDash, une règle sur votre token de bot est plus sûre, car seules les requêtes de votre projet le transmettent. N'autorisez les adresses IP que si rien d'autre ne fonctionne, et gardez en tête qu'elles peuvent changer. Le guide Laisser passer les bots CoreDash à travers votre CDN ou firewall détaille les étapes pour Cloudflare et AWS WAF.

Pourquoi les bots CoreDash ne lisent pas robots.txt

Un fichier robots.txt indique aux crawlers quelles pages ils peuvent visiter lorsqu'ils parcourent un site par eux-mêmes. Les bots CoreDash ne font jamais cela. Chaque visite est déclenchée par un client, tout comme Lighthouse charge une page quand quelqu'un lance un test. Voilà pourquoi aucun des deux bots ne lit robots.txt, et une directive Disallow ne les arrêtera pas.

Bloquer les bots CoreDash sur votre site

Si vous avez une question sur les bots ou si vous préférez ne pas les avoir sur votre site, contactez CoreDash via la page de contact. Envoyez l'URL ainsi qu'une ligne CoreDash issue de vos logs. CoreDash arrêtera alors les visites sur votre site.