Chez Digitalblitz, une question revient sans cesse : pourquoi une page bien classée sur ordinateur perd-elle du terrain sans raison apparente ? La réponse tient le plus souvent en deux mots : mobile-first. Depuis juillet 2024, Google explore et indexe la quasi-totalité des sites avec son robot smartphone. C'est donc la version mobile de vos pages qui sert de référence pour le classement, y compris pour les recherches faites depuis un ordinateur. Si un contenu, un lien ou une donnée structurée manque sur mobile, il n'existe tout simplement pas aux yeux du moteur. Ce guide montre comment vérifier ce que Google voit, mesurer la vitesse réellement perçue et tester vos pages dans des conditions proches de celles de vos visiteurs.
Ce que l'indexation mobile-first change réellement pour Google
Beaucoup d'éditeurs pensent encore que le mobile est une « version secondaire ». C'est l'inverse : Googlebot smartphone récupère le HTML rendu sur un viewport étroit, et c'est ce rendu qui alimente l'index. Trois éléments méritent une vérification systématique.
- La parité du contenu : textes, images, vidéos et tableaux doivent être présents sur mobile, même repliés dans un onglet ou un accordéon. Un bloc supprimé pour alléger l'écran fait perdre la pertinence qu'il portait.
- Les liens internes : un menu simplifié qui retire des catégories coupe des chemins d'exploration. Le maillage visible sur ordinateur doit avoir un équivalent sur petit écran.
- Les balises techniques : title, meta robots, canonical, hreflang et données structurées doivent être identiques entre les deux versions. Un noindex oublié sur le gabarit mobile suffit à désindexer une section entière.
L'outil d'inspection d'URL de la Search Console reste le moyen le plus direct de contrôler la page telle que Google l'a rendue. Comparez la capture et le HTML récupéré avec ce que vous attendez : les écarts sautent souvent aux yeux.
Mesurer la vitesse perçue avec LCP, INP et CLS
Les Core Web Vitals traduisent l'expérience vécue sur la page. Ils ne remplacent pas la pertinence, mais ils départagent des résultats proches et influencent fortement le taux de rebond. Depuis mars 2024, l'INP a remplacé le FID pour évaluer la réactivité.
IndicateurCe qu'il mesureSeuil « bon »Cause fréquente d'échec sur mobileLCPAffichage du plus grand élément visible2,5 s maximumImage principale trop lourde ou chargée en différéINPDélai de réaction aux interactions200 ms maximumJavaScript tiers qui monopolise le processeurCLSStabilité visuelle pendant le chargement0,1 maximumBannières et encarts publicitaires sans dimensions réservéesUn point trompe souvent les audits : la différence entre données de laboratoire et données de terrain. Lighthouse simule un chargement dans des conditions fixes, utile pour diagnostiquer. Le rapport Core Web Vitals de la Search Console, lui, s'appuie sur le Chrome UX Report, c'est-à-dire sur les visites réelles, évaluées au 75e centile. C'est ce second chiffre qui compte pour Google. Un score Lighthouse de 95 peut cohabiter avec un INP médiocre chez vos vrais visiteurs si leurs appareils sont moins puissants que la machine de test.
Constituer un parc de test fidèle à votre audience
Prenons une situation concrète. Un site éditorial voit son INP passer en « à améliorer » dans la Search Console, alors que tous les tests faits depuis le bureau sont au vert. L'équipe travaille sur des ordinateurs récents et vérifie le rendu mobile dans l'émulateur du navigateur. Or l'émulateur réduit la taille de l'écran, pas la puissance du processeur : il ne reproduit ni la chauffe, ni la mémoire limitée, ni le navigateur réel des visiteurs.
La correction passe par quelques appareils physiques choisis avec méthode. Commencez par les statistiques de votre outil d'analyse : systèmes d'exploitation, résolutions d'écran et gammes de prix dominantes. Dans la plupart des audiences françaises, un modèle milieu de gamme de deux ou trois ans représente bien mieux le visiteur type qu'un appareil haut de gamme sorti cette année. Pour choisir ces modèles sans deviner, les les revues d'Android24tech détaillent processeur, mémoire, définition d'écran et comportement en usage réel des appareils du marché, ce qui permet de repérer celui qui ressemble le plus au terminal moyen de vos lecteurs.
Une fois le parc réuni (trois appareils suffisent souvent : un d'entrée de gamme, un milieu de gamme, un récent), testez les gabarits clés plutôt que des pages au hasard : accueil, catégorie, article, page de conversion. Activez le débogage à distance de Chrome pour profiler le JavaScript directement sur l'appareil. Vous verrez alors quels scripts bloquent le fil principal au moment précis où l'utilisateur touche un bouton.
Adapter contenu, navigation et maillage au petit écran
La performance ne fait pas tout. Une page rapide mais pénible à parcourir perd ses visiteurs dès le deuxième écran. Quelques principes servent à la fois l'utilisateur et le robot :
- placer la réponse principale dans le premier écran, sans la repousser derrière une image décorative ou un bandeau de consentement envahissant ;
- garder des zones tactiles d'au moins 48 pixels et un espacement suffisant entre les liens ;
- éviter les interstitiels qui masquent le contenu à l'arrivée, Google les considère comme une mauvaise expérience ;
- conserver un fil d'Ariane et des liens contextuels dans le corps du texte, qui compensent un menu réduit ;
- servir des images au format WebP ou AVIF avec l'attribut srcset, pour que chaque écran reçoive la taille adaptée.
Le contenu replié dans un accordéon est bien pris en compte par Google, à condition qu'il soit présent dans le HTML dès le chargement. Un bloc injecté seulement après un clic, via une requête JavaScript, risque en revanche de ne jamais être vu.
Les erreurs qui coûtent des positions sur mobile
Certaines fautes reviennent dans presque chaque audit. La plus coûteuse est le blocage de ressources CSS ou JavaScript dans le fichier robots.txt : Google ne peut alors pas rendre la page correctement et l'évalue comme cassée. Viennent ensuite les sites qui servent une version mobile distincte (sous-domaine en m.) sans balises canonical et alternate cohérentes, ce qui crée des doublons. On trouve aussi des polices web chargées sans font-display: swap, qui retardent l'affichage du texte, et des carrousels automatiques en tête de page qui dégradent à la fois le LCP et le CLS.
Dernier piège, plus discret : les outils tiers ajoutés au fil des années (chat, tests A/B, pixels publicitaires). Chacun semble léger isolément, mais leur somme pèse lourd sur un processeur mobile modeste. Un inventaire annuel de ces scripts, avec suppression de ceux qui ne servent plus, fait souvent gagner davantage qu'une refonte graphique.
Google indexe-t-il encore la version ordinateur d'un site ?
Non, sauf cas marginaux. Depuis la fin de la migration annoncée en 2024, l'exploration se fait avec Googlebot smartphone. Un site accessible uniquement sur ordinateur peut encore être indexé, mais il est évalué à travers le rendu mobile, ce qui le pénalise s'il s'affiche mal sur petit écran.
Un design responsive suffit-il à garantir un bon référencement mobile ?
Il règle la parité de contenu et évite les doublons d'URL, ce qui est déjà beaucoup. Il ne garantit pas la vitesse : une page responsive peut charger les mêmes images lourdes et les mêmes scripts sur tous les écrans. Il faut donc compléter avec un travail sur les ressources et sur les Core Web Vitals.
Quel poids les Core Web Vitals ont-ils dans le classement ?
Leur poids reste modéré face à la pertinence du contenu : une page lente mais très utile peut devancer une page rapide et creuse. Ils jouent surtout entre résultats de qualité comparable, et leur effet indirect sur l'engagement des visiteurs est souvent plus marqué que leur effet direct sur le positionnement.
Combien d'appareils faut-il pour tester un site correctement ?
Trois appareils physiques couvrent la majorité des situations, à condition de les choisir d'après les statistiques réelles de l'audience. Un appareil d'entrée de gamme révèle les problèmes de réactivité, un milieu de gamme reflète le visiteur médian, et un modèle récent sert de point de comparaison.
