Pourquoi PageSpeed Insights et le test mobile-friendly donnent-ils des résultats contradictoires ?

Quelle est la différence technique entre ces deux outils ?

PageSpeed Insights s'appuie sur Lighthouse, un outil open-source de Google Chrome qui analyse les performances côté client. Il charge votre page dans un environnement de test simulé, sans passer par l'infrastructure Googlebot.

Le test mobile-friendly, lui, fait appel directement à Googlebot Mobile pour récupérer et rendre la page. Il respecte donc strictement les règles du robots.txt, les directives noindex, et reproduit fidèlement les limitations de rendu que rencontre le crawler réel.

Pourquoi cette distinction crée-t-elle des écarts de résultats ?

Googlebot peut se heurter à des ressources bloquées (CSS, JS) via robots.txt que Lighthouse chargera sans problème. Un site peut ainsi afficher un excellent score PSI tout en étant mal rendu par Google lors de l'indexation.

L'inverse existe aussi : une page peut échouer au test mobile-friendly à cause d'un contenu interstitiel bloquant ou d'un viewport mal configuré, tout en obtenant de bonnes métriques Core Web Vitals sur PSI. Ces deux outils mesurent des choses différentes avec des contextes d'exécution distincts.

Comment Googlebot traite-t-il réellement les pages ?

Googlebot Mobile exécute JavaScript et rend les pages, mais avec des contraintes de temps et de ressources plus strictes qu'un navigateur classique. Si votre JS tarde à s'exécuter ou si des ressources critiques sont bloquées, le rendu final peut diverger significativement de ce que voit PSI.

Le bot respecte aussi les directives HTTP (redirections, codes status, headers) qui peuvent bloquer l'accès ou modifier le contenu servi. PSI, fonctionnant comme un navigateur, ignore souvent ces subtilités serveur.

• PageSpeed Insights simule un navigateur Chrome et charge toutes les ressources disponibles publiquement
• Test mobile-friendly utilise Googlebot Mobile réel et respecte robots.txt, headers HTTP, et limitations de rendu
• Un score PSI élevé ne garantit pas une bonne indexation si des ressources critiques sont bloquées pour Googlebot
• Les écarts de rendu entre les deux outils révèlent souvent des problèmes de configuration côté serveur
• Pour diagnostiquer un problème d'indexation mobile, fiez-vous au test mobile-friendly et à la Search Console, pas uniquement à PSI

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

Absolument. Les incohérences entre PSI et le rendu réel dans la Search Console sont un classique du diagnostic SEO. J'ai vu des sites avec des scores PSI impeccables (90+) être quasi invisibles dans l'index mobile parce que leur CSS était bloqué via robots.txt.

Google ne communique pas assez clairement sur cette différence. Beaucoup de clients arrivent avec un rapport PSI vert en pensant que leur site est techniquement irréprochable, alors que l'outil URL Inspection de la GSC montre un rendu complètement cassé.

Quelles nuances faut-il apporter à cette déclaration ?

Google simplifie un peu. PSI utilise Lighthouse avec des conditions réseau simulées (throttling 4G, CPU bridé), mais ces conditions restent plus généreuses que les contraintes réelles de Googlebot en production. Le bot peut abandonner le rendu si le JS prend trop de temps ou consomme trop de mémoire.

Par ailleurs, PSI offre maintenant des données de terrain via CrUX (Chrome User Experience Report) en complément des tests lab. Ces métriques terrain reflètent l'expérience utilisateur réelle, mais pas forcément ce que voit Googlebot. [À vérifier] : Google n'a jamais confirmé officiellement si les données CrUX influencent directement le ranking ou si seul le rendu Googlebot compte pour l'évaluation technique.

Dans quels cas cette règle pose-t-elle le plus de problèmes ?

Les sites JavaScript-heavy (React, Vue, Angular en CSR) sont les plus touchés. Si le JS met du temps à charger ou si des bundles critiques sont bloqués, PSI peut quand même restituer le contenu final alors que Googlebot abandonne.

Les configurations serveur complexes (CDN avec règles de cache agressives, A/B testing côté serveur, paywalls) créent aussi des divergences. PSI voit une version, Googlebot en voit une autre. Si vous avez des écarts inexpliqués, vérifiez systématiquement les logs serveur pour comparer les user-agents.

Comment vérifier ce que Googlebot voit réellement ?

L'outil Inspection d'URL dans la Google Search Console reste votre allié principal. Il vous montre le rendu HTML final après exécution du JavaScript, exactement comme Googlebot l'a indexé. Comparez ce rendu avec ce que vous voyez dans votre navigateur.

Analysez aussi les logs serveur en filtrant sur le user-agent Googlebot Mobile. Vérifiez les codes status retournés, les temps de réponse, et les ressources effectivement récupérées. Les écarts entre PSI et la réalité se cachent souvent là.

Quelles erreurs techniques provoquent ces incohérences ?

Le blocage de ressources critiques via robots.txt est le cas numéro un. CSS et JS essentiels au rendu doivent être accessibles à Googlebot. Un simple Disallow: /*.css$ peut ruiner votre indexation mobile sans que PSI ne détecte quoi que ce soit.

Les temps de chargement JS excessifs posent problème aussi. Si votre app met 8 secondes à hydrater le DOM, Googlebot peut capturer un snapshot intermédiaire alors que PSI, plus patient, attend le rendu complet. Optimisez le critical rendering path et privilégiez le SSR ou le pre-rendering pour le contenu critique.

Quelle stratégie de testing adopter concrètement ?

Ne vous reposez jamais sur un seul outil. Utilisez PSI pour les Core Web Vitals et l'optimisation des performances utilisateur, mais validez systématiquement avec le test mobile-friendly et l'Inspection d'URL pour l'indexabilité.

Mettez en place un monitoring régulier du rendu Googlebot via la GSC API. Automatisez des alertes si des pages clés deviennent invisibles ou si le rendu se dégrade. Les incohérences entre outils révèlent souvent des régressions techniques avant qu'elles n'impactent le trafic.

• Tester chaque page stratégique avec l'outil Inspection d'URL de la GSC avant et après déploiement
• Vérifier que le robots.txt n'empêche pas Googlebot d'accéder aux CSS et JS critiques
• Comparer le HTML rendu dans la GSC avec le code source initial pour détecter les problèmes de rendu JS
• Monitorer les logs serveur pour identifier les requêtes Googlebot qui échouent ou retournent des codes 4xx/5xx
• Ne jamais considérer un score PSI élevé comme une validation de l'indexabilité mobile
• Privilégier le SSR ou pre-rendering pour les sites JavaScript-heavy afin de garantir un rendu cohérent