Peut-on bloquer la collecte des Core Web Vitals avec robots.txt ou noindex ?

D'où viennent réellement les données Core Web Vitals ?

Les Core Web Vitals ne sont pas des métriques calculées par les robots de Google lors du crawl. Elles proviennent du Chrome User Experience Report (CrUX), une base de données publique qui agrège les performances réelles mesurées dans le navigateur Chrome.

Quand un utilisateur visite votre site avec Chrome — et qu'il a accepté le partage de statistiques d'usage — le navigateur enregistre le LCP, CLS et INP de chaque page consultée. Ces données remontent ensuite anonymement vers CrUX, indépendamment de toute directive SEO.

Pourquoi robots.txt et noindex n'ont aucun effet sur CrUX ?

Le fichier robots.txt contrôle ce que Googlebot peut explorer. La balise noindex empêche l'indexation d'une URL dans les résultats de recherche. Mais ni l'un ni l'autre n'agissent sur le navigateur Chrome de vos visiteurs.

Si une page reçoit du trafic — même minime — et que ces visiteurs utilisent Chrome, les données de performance seront collectées. Vous pouvez donc avoir une page totalement bloquée pour Googlebot, invisible dans la Search Console, mais qui génère quand même des Core Web Vitals dans CrUX.

Comment une page invisible dans Google peut-elle impacter mon SEO ?

C'est là que ça devient pervers. Google utilise les données CrUX pour évaluer l'expérience utilisateur à l'échelle du domaine. Si vous avez des pages cachées (dev, staging, pages internes) qui reçoivent du trafic interne avec de mauvaises performances, elles polluent potentiellement vos métriques globales.

Pire encore : une page bloquée par robots.txt mais accessible en direct (via lien partagé, bookmark) peut générer de mauvais signaux CWV qui impactent la perception de votre domaine par Google, même si cette page n'apparaît jamais dans les SERP.

• CrUX collecte les données côté navigateur, pas côté serveur ou crawler
• robots.txt et noindex n'ont aucune influence sur cette collecte
• Toute page accessible avec du trafic Chrome génère des Core Web Vitals
• Les métriques polluées peuvent impacter la réputation globale du domaine
• Les environnements de dev/staging accessibles publiquement sont des sources de pollution fréquentes

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même une source de confusion fréquente chez les praticiens. On observe régulièrement des clients perplexes devant des données CWV dans Search Console pour des URLs qu'ils pensent avoir bloquées. Le problème vient d'une incompréhension fondamentale : CrUX et indexation sont deux circuits totalement distincts.

J'ai vu des sites avec des environnements de préproduction accessibles publiquement (protégés uniquement par obscurité d'URL) polluer leurs métriques domaine pendant des mois. Le trafic interne — QA, développeurs, clients testeurs — suffit à générer des données CrUX si ces utilisateurs ont Chrome. [A vérifier] : Google n'a jamais clarifié le seuil minimal de trafic nécessaire pour qu'une URL apparaisse dans CrUX, mais l'observation suggère que quelques dizaines de visites mensuelles suffisent.

Quelles sont les zones grises de cette affirmation ?

Google reste délibérément flou sur plusieurs points critiques. D'abord, comment les métriques au niveau page vs domaine sont-elles réellement agrégées et pondérées dans l'algorithme ? On sait que Google regarde les CWV à l'échelle du domaine, mais avec quel poids pour chaque URL ?

Ensuite, la période de collecte et d'agrégation : CrUX compile 28 jours glissants, mais comment Google lisse-t-il les variations ? Une page avec un pic de mauvaises performances pendant 3 jours pollue-t-elle durablement le score global ? [A vérifier] : impossible d'obtenir une réponse claire de Google sur ce point.

Enfin, le cas des pages protégées par authentification : techniquement, si elles reçoivent du trafic Chrome, elles génèrent des données CrUX. Mais sont-elles réellement prises en compte dans l'évaluation SEO ? Aucune certitude.

Dans quels cas cette règle devient-elle problématique ?

Le principal piège concerne les sites avec multiples environnements : dev, staging, UAT, pre-prod. Si ces environnements sont accessibles sans authentification forte (IP whitelisting, VPN), ils génèrent des données CrUX parasites. J'ai vu des domaines pénalisés par des Core Web Vitals médiocres provenant à 80% de leur staging mal optimisé.

Autre cas vicieux : les anciennes URLs migrées mais encore bookmarkées ou partagées en interne. Elles peuvent rester actives dans CrUX pendant des mois après migration si elles continuent de recevoir du trafic résiduel, traînant des métriques obsolètes.

Comment identifier les pages qui polluent vos Core Web Vitals ?

La première étape consiste à auditer toutes les URLs accessibles publiquement sur votre domaine, y compris celles que vous pensez "cachées". Utilisez un crawler configuré pour ignorer robots.txt (Screaming Frog en mode "ignore robots.txt") et vérifiez quelles pages répondent en 200.

Ensuite, testez chacune dans PageSpeed Insights. Si des données CrUX apparaissent (onglet "Discover what your real users are experiencing"), c'est que cette page génère des métriques. Croisez avec vos logs serveur pour identifier la source du trafic : interne, partenaires, liens résiduels.

Quelles actions concrètes pour bloquer la pollution CrUX ?

Robots.txt et noindex ne servent à rien ici. La seule méthode efficace est de bloquer l'accès HTTP lui-même. Pour les environnements de dev/staging, mettez en place une authentification HTTP Basic (htpasswd) ou, mieux encore, un whitelisting IP strict.

Pour les pages internes accessibles aux collaborateurs, considérez un système d'authentification SSO ou un accès via VPN. L'objectif : aucun trafic Chrome "standard" ne doit atteindre ces pages. Attention : même un accès restreint par cookie peut générer des données CrUX si le navigateur n'est pas configuré pour bloquer les rapports d'usage.

Comment surveiller l'évolution de vos métriques domaine ?

Configurez un monitoring CrUX automatisé via l'API publique ou des outils comme CrUX Dashboard. Surveillez particulièrement les pics de dégradation non expliqués par vos déploiements sur les pages principales. Un CWV qui se dégrade sans changement apparent sur vos URLs prioritaires peut signaler une pollution par une page cachée.

Vérifiez régulièrement la liste des URLs remontées dans Search Console (rapport Core Web Vitals). Si des pages bloquées ou obsolètes apparaissent, c'est qu'elles reçoivent encore du trafic Chrome. Tracez la source et coupez-la à la racine.

• Auditez toutes les URLs accessibles publiquement, même celles "cachées" par robots.txt
• Testez chaque page suspecte dans PageSpeed Insights pour vérifier si elle génère des données CrUX
• Bloquez l'accès HTTP aux environnements de dev/staging via authentification ou IP whitelisting
• Protégez les pages internes par SSO ou VPN plutôt que par simple robots.txt
• Configurez un monitoring CrUX automatisé pour détecter les dégradations inexpliquées
• Surveillez le rapport Core Web Vitals de Search Console pour identifier les URLs parasites