Pourquoi PageSpeed Insights affiche-t-il des scores différents de ce que Googlebot voit réellement ?

PageSpeed Insights et Googlebot sont-ils la même chose ?

Non. PageSpeed Insights utilise son propre crawler, techniquement basé sur Lighthouse et l'infrastructure de Chrome, pas sur Googlebot. Quand vous lancez un test PSI, Google récupère votre page avec un user-agent différent de celui qu'il utilise pour indexer votre contenu.

Concrètement ? Si votre robots.txt bloque certaines ressources à Googlebot (typiquement des fichiers CSS, JavaScript, ou des fonts), PageSpeed Insights y aura quand même accès. Il vous retournera un score basé sur une version complète de la page, avec tous les styles et scripts chargés. Mais Googlebot, lui, crawlera une version amputée.

Pourquoi cette distinction pose-t-elle problème en SEO ?

Parce que vous optimisez en aveugle. Vous lancez PSI, vous voyez du vert partout, vous vous dites que les Core Web Vitals sont au top. Sauf que Google, de son côté, indexe une page sans CSS critique ou sans certains scripts, ce qui peut dégrader l'expérience réelle mesurée par le moteur.

Le piège classique : bloquer /wp-content/themes/ ou /assets/ dans le robots.txt par peur du crawl budget ou par mauvaise configuration. PSI charge quand même tout, mais Googlebot voit une page cassée, mal structurée, avec un rendu incomplet. Vos métriques Search Console montrent alors des signaux dégradés qui ne matchent pas avec vos tests PSI.

Comment savoir si mon site est concerné ?

Trois signaux d'alerte : des écarts importants entre PSI et les rapports Core Web Vitals dans Search Console, des avertissements dans GSC sur des ressources bloquées, ou des pages qui s'affichent mal dans l'outil d'inspection d'URL (rendu HTML incomplet).

Vérifiez votre robots.txt ligne par ligne. Tout Disallow pointant vers des répertoires CSS, JS ou fonts est suspect. Google recommande depuis des années de ne bloquer aucune ressource critique au rendu, mais cette erreur reste fréquente sur des CMS mal configurés ou des migrations bâclées.

• PageSpeed Insights ne passe pas par Googlebot, donc il contourne les restrictions robots.txt que vous imposez au moteur
• Un score PSI optimal ne garantit pas que Google indexe une version performante de votre page
• Bloquer CSS ou JavaScript à Googlebot crée un décalage entre vos tests et la réalité du crawl
• Les Core Web Vitals mesurés par Google reposent sur ce que Googlebot peut réellement charger, pas sur ce que PSI voit
• Vérifiez systématiquement l'outil d'inspection d'URL pour comparer le rendu Googlebot avec votre version locale

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Totalement. On voit régulièrement des sites avec des scores PageSpeed Insights irréprochables mais des alertes Core Web Vitals persistantes dans Search Console. Le cas typique : un site Wordpress qui bloque /wp-includes/ ou /wp-content/ par précaution, pensant protéger des fichiers sensibles.

PSI charge la page sans restriction, affiche 95+ partout. Mais Googlebot, lui, se prend un 403 sur les CSS critiques, rend la page en mode dégradé, et remonte des métriques catastrophiques. Le client ne comprend pas pourquoi ses optimisations ne se reflètent pas dans les classements, alors que tous ses tests sont au vert.

Quelles nuances faut-il apporter à cette affirmation ?

Google ne précise pas explicitement quel user-agent PSI utilise ni comment il gère les éventuelles redirections ou variations géographiques. On sait que PSI se base sur l'infrastructure Lighthouse, mais les détails techniques restent flous. [A vérifier] : est-ce que PSI respecte les directives robots.txt pour d'autres user-agents, ou ignore-t-il complètement le fichier ?

Autre point : Google parle de "ressources cruciales" sans définir précisément ce qui est crucial. Dans les faits, tout ce qui impacte le rendu initial est crucial : CSS inline ou externe, JavaScript de chargement différé, webfonts, même certains SVG. Mais un praticien doit tester au cas par cas, car la frontière n'est pas documentée.

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

Si votre robots.txt est propre et ne bloque aucune ressource de rendu, la différence entre PSI et Googlebot sera marginale. C'est surtout un problème sur des sites legacy, des CMS mal configurés, ou des migrations où on a copié-collé un robots.txt sans l'auditer.

Attention aussi aux sites avec des règles Disallow trop larges (genre Disallow: /wp-content/), souvent héritées de vieilles recommandations SEO obsolètes. Là, PSI et Googlebot divergent systématiquement. Si vous avez un site moderne avec un robots.txt minimaliste, vous ne verrez probablement jamais cette incohérence.

Que faut-il faire concrètement pour éviter ce décalage ?

Première action : auditer votre robots.txt immédiatement. Ouvrez-le, repérez toutes les lignes Disallow qui pointent vers des dossiers contenant du CSS, du JavaScript, des fonts, ou des images critiques. Si vous avez un doute, commentez la ligne temporairement et testez le rendu Googlebot via l'outil d'inspection d'URL.

Ensuite, utilisez l'outil "Tester le fichier robots.txt" dans Search Console (section Paramètres > Explorateurs > robots.txt). Entrez l'URL de vos fichiers CSS et JS principaux, vérifiez qu'ils ne sont pas bloqués pour Googlebot Desktop et Googlebot Smartphone. Si un fichier critique est interdit, supprimez la règle correspondante.

Quelles erreurs éviter absolument ?

Ne bloquez jamais /wp-content/themes/, /assets/, /static/, /dist/, ou tout répertoire contenant des ressources de rendu. C'est une erreur classique héritée de vieilles pratiques SEO où on pensait protéger le contenu ou économiser du crawl budget. Aujourd'hui, ça casse juste le rendu Googlebot.

Autre piège : se fier uniquement aux tests PageSpeed Insights pour valider les optimisations. PSI est un bon indicateur, mais il ne reflète pas la réalité du crawl. Validez toujours avec l'outil d'inspection d'URL et les données CWV réelles de Search Console, collectées sur 28 jours glissants.

Comment vérifier que mon site est conforme après correction ?

Une fois votre robots.txt nettoyé, forcez une réindexation des pages clés via l'outil d'inspection d'URL. Attendez 48-72h, puis comparez le rendu HTML capturé par Googlebot avec votre version locale. Si les styles et scripts sont bien chargés, vous êtes bon.

Surveillez ensuite le rapport Core Web Vitals dans Search Console sur 4 semaines. Si les métriques remontent et se rapprochent de vos scores PSI, c'est que Googlebot voit enfin la même chose que votre outil de test. Sinon, il reste probablement d'autres blocages ou des redirections parasites.

• Auditer le robots.txt et supprimer toute règle Disallow bloquant CSS, JavaScript, fonts ou images critiques
• Tester chaque URL de ressource via l'outil "Tester le fichier robots.txt" dans Search Console
• Valider le rendu Googlebot avec l'outil d'inspection d'URL, comparer avec la version locale
• Croiser les scores PageSpeed Insights avec les données réelles du rapport Core Web Vitals (28 jours glissants)
• Forcer la réindexation des pages stratégiques après correction du robots.txt
• Monitorer les écarts entre PSI et GSC sur un mois pour confirmer la résolution du problème