Vitesse de crawl et Core Web Vitals : pourquoi Google fait-il la distinction ?

Qu'est-ce que Google entend par "vitesse de crawl" ?

La vitesse de crawl mesure le temps nécessaire pour que Googlebot récupère le code HTML brut depuis votre serveur. Point final. Pas de rendu, pas d'exécution JavaScript, pas de chargement de ressources externes.

C'est une métrique purement technique qui concerne la performance infrastructure : temps de réponse serveur (TTFB), latence réseau, disponibilité des ressources. Si votre serveur met 3 secondes à cracher le HTML, votre vitesse de crawl est catastrophique — même si la page s'affiche ensuite instantanément côté utilisateur.

Les Core Web Vitals mesurent-ils la même chose ?

Non. Les Core Web Vitals évaluent l'expérience utilisateur réelle dans le navigateur. Ils incluent le rendu complet : temps d'affichage du contenu principal (LCP), réactivité aux interactions (INP), stabilité visuelle (CLS).

Ces métriques intègrent JavaScript, CSS, images, polices externes, lazy loading, hydratation React/Vue — tout ce qui constitue l'expérience perçue. Un site peut avoir une vitesse de crawl excellente (HTML livré en 200ms) mais des CWV désastreux (LCP à 5s à cause d'un bundle JS obèse).

Pourquoi cette distinction change-t-elle la donne pour le SEO ?

Parce que Google utilise ces deux métriques pour des objectifs différents. La vitesse de crawl impacte le crawl budget : plus vos pages sont rapides à récupérer côté serveur, plus Googlebot peut en explorer dans le temps imparti.

Les CWV influencent le classement via le signal Page Experience. Optimiser l'un sans l'autre, c'est boiter sur une jambe. Un site lent côté serveur sera peu crawlé. Un site rapide côté serveur mais pourri côté utilisateur sera bien crawlé mais mal classé.

• Vitesse de crawl : métrique serveur, impacte le crawl budget et l'efficacité de découverte de contenu
• Core Web Vitals : métriques utilisateur, intègrent rendu complet et JavaScript, influencent le ranking
• Optimiser uniquement le TTFB ne garantit pas de bons CWV si le front-end est mal ficelé
• À l'inverse, un front-end ultraléger ne compense pas un serveur qui rame

Cette distinction est-elle nouvelle ou Google enfonce-t-il des portes ouvertes ?

Soyons honnêtes : pour les SEO aguerris, cette clarification n'est pas une révélation. On sait depuis des années que TTFB et LCP ne jouent pas dans la même catégorie. Mais Mueller répond ici à une confusion récurrente chez les débutants et même certains développeurs qui pensent qu'un CDN + cache résout tout.

Ce que cette déclaration confirme, c'est que Google mesure deux pipelines distincts. L'un pour l'efficacité de son exploration (combien d'URLs je peux aspirer par seconde), l'autre pour la qualité de l'expérience (est-ce que l'utilisateur souffre ou non). Les confondre, c'est optimiser à côté de la plaque.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller simplifie — volontairement. Il dit que la vitesse de crawl "ne mesure que le temps de récupération", mais Googlebot ne crawle pas dans le vide. Il prend en compte la réponse HTTP, les redirections, les erreurs 5xx, les timeouts. Un serveur qui balance des 503 aléatoires aura une "vitesse" catastrophique même si le HTML arrive vite quand ça marche.

Autre point : Mueller parle de "rendu complet" pour les CWV, mais attention — les CWV sont mesurés côté utilisateur réel (CrUX), pas par Googlebot. Le bot peut crawler sans exécuter de JS (mode standard), ou avec rendu (WRS), mais ça n'impacte pas les CWV. Ces derniers viennent de Chrome, pas du crawl. [À vérifier] si Google utilise aussi des données synthétiques Lighthouse dans certains cas de figure (sites neufs sans trafic Chrome).

Dans quels cas cette règle ne s'applique-t-elle pas totalement ?

Pour les sites avec crawl budget serré (gros e-commerce, agrégateurs, sites d'actualité), la vitesse de crawl devient critique même si les CWV sont au vert. Si Google met 2 secondes à récupérer chaque URL, il n'explorera que 43 000 pages par jour avec un budget crawl fixe. Réduire à 500ms, c'est multiplier par 4 la surface explorée.

À l'inverse, pour un site vitrine de 20 pages, la vitesse de crawl est anecdotique. Google crawlera tout de toute façon. Par contre, des CWV pourris peuvent plomber le CTR et le taux de rebond — donc indirectement le SEO via les signaux comportementaux.

Que faut-il optimiser en priorité : vitesse de crawl ou Core Web Vitals ?

Ça dépend de votre contexte. Si vous avez des millions de pages et que Search Console indique des URLs non crawlées ou un budget crawl saturé, la vitesse serveur est prioritaire. Réduisez le TTFB, activez la compression Brotli, optimisez vos requêtes BDD, scalez l'infra.

Si vous avez un site classique (quelques centaines à dizaines de milliers de pages) et que vos CWV sont orange ou rouges, foncez sur le front-end. LCP, INP, CLS — c'est ça qui impacte votre ranking et votre taux de conversion. Un TTFB de 300ms vs 150ms ne changera rien si votre LCP est à 4 secondes.

Comment mesurer précisément ces deux métriques ?

Pour la vitesse de crawl, regardez Search Console > Paramètres > Statistiques d'exploration. Google vous donne le temps moyen de téléchargement en millisecondes. Comparez avec votre TTFB réel (curl, WebPageTest, New Relic). Si l'écart est important, c'est que Googlebot voit autre chose que vos utilisateurs — probablement un problème de géolocalisation serveur ou de gestion du user-agent.

Pour les Core Web Vitals, fiez-vous aux données terrain CrUX (PageSpeed Insights, Search Console > Expérience > Signaux Web essentiels). Lighthouse est utile pour le diagnostic, mais les scores synthétiques ne reflètent pas toujours la réalité. Un site peut scorer 95/100 en labo et planter en production à cause du trafic réel, des A/B tests, des pubs tierces.

Quelles erreurs éviter absolument ?

• Ne pas bloquer CSS/JS dans robots.txt sous prétexte d'économiser du crawl budget — Google a besoin de ces ressources pour évaluer les CWV via le rendu
• Optimiser uniquement le HTML initial en oubliant les ressources critiques (fonts, hero images, JS de navigation) qui plombent le LCP
• Confondre TTFB et FCP : un serveur rapide ne garantit pas un First Contentful Paint rapide si le navigateur doit attendre 50 requêtes externes
• Ignorer le crawl budget pour les gros sites : même avec des CWV parfaits, si Google ne crawle pas vos nouvelles pages, elles ne rankeront jamais
• Sacrifier l'UX pour gratter 50ms de TTFB : l'impact ranking des CWV est supérieur à celui de la vitesse de crawl pour 99% des sites