Indexation mobile-first : repérer un écart entre mobile et desktop

Un site peut afficher une fiche produit complète sur ordinateur et une version amaigrie sur téléphone, et personne ne s’en aperçoit pendant des mois. Le trafic desktop reste correct, les statistiques de Search Console semblent normales, et pourtant Google n’indexe qu’une partie du contenu. Depuis que l’exploration se fait avec l’agent pour smartphone, la question n’est plus de savoir si le site est joli sur mobile, mais ce que Googlebot Smartphone voit vraiment quand il passe. Voici comment repérer l’écart sans se contenter de la théorie.

la version mobile est devenue la seule qui compte

Google a annoncé le passage au Mobile First Index le 4 novembre 2016, puis l’a confirmé en français le 15 du même mois. Depuis le 26 mars 2018, le dispositif est en place officiellement. Concrètement, l’exploration se fait avec l’agent pour smartphone, et c’est le contenu récupéré par cet agent qui sert à l’indexation et au classement.

Un paragraphe présent uniquement sur la version ordinateur n’existe donc pas pour le moteur. Le comprendre change radicalement la façon d’auditer un site, comme le rappellent les ressources techniques de dedieonet.fr sur le crawling et l’indexation.

Beaucoup de propriétaires de sites croient encore que Google compare les deux versions et retient la meilleure. C’est faux depuis longtemps. Si la version mobile ne contient pas une information, elle est traitée comme absente, même si elle figure en clair sur la page desktop. Le point de départ de toute détection d’écart consiste donc à oublier son écran d’ordinateur pour adopter le regard d’un robot qui se présente avec un user-agent de téléphone.

simuler Googlebot depuis son navigateur, sans se tromper d’outil

La manipulation la plus simple consiste à changer le user-agent de son navigateur. Sur Chrome, les outils de développement proposent un mode d’appareil qui modifie l’agent envoyé et la largeur de fenêtre, mais l’opération ne suffit pas toujours.

Le rendu change, l’agent aussi, et pourtant l’URL interrogée reste la même : certaines configurations servent un HTML différent selon l’en-tête envoyé, et le navigateur peut conserver en cache une réponse destinée au desktop. Mieux vaut croiser plusieurs méthodes avant de conclure à une absence de contenu.

les vérifications qui révèlent un écart réel

Un audit sérieux se fait en plusieurs passes, et chaque passe répond à une question différente. Il ne s’agit pas de cocher des cases, mais de comprendre ce que le robot reçoit à chaque étape de son parcours.

• Récupérer le code source avec un agent de smartphone depuis la ligne de commande, puis comparer le nombre de blocs de texte avec celui de la version ordinateur.
• Inspecter l’URL dans la Search Console : l’outil affiche exactement le HTML exploré, et un onglet permet de voir la version mobile capturée.
• Le contenu principal de la page mobile est-il réellement plus court, ou seulement masqué par du CSS ?
• Vérifier les en-têtes de réponse : la présence de Vary: user-agent signale une diffusion dynamique, et donc un risque de divergence entre les deux versions servies.
• Comparer les liens internes des deux versions, car une navigation mobile incomplète coupe des chemins d’exploration.

Cette dernière vérification est celle qu’on oublie le plus souvent. Un menu mobile réduit à quelques entrées laisse le robot sans accès à des pages entières, même si le plan du site les liste. Le crawl s’arrête là où les liens s’arrêtent, et l’indexation suit.

comprendre l’indexation pour mieux cibler l’écart

L’indexation d’un document désigne l’étape où le moteur enregistre une page dans sa base après l’avoir explorée, analysée et jugée digne d’être conservée. C’est un processus distinct du crawl, qui se contente de récupérer le code, et distinct du classement, qui ordonne ensuite les pages retenues. Une page peut donc être explorée sans être indexée, et c’est fréquent quand le contenu mobile paraît trop pauvre ou dupliqué par rapport à d’autres URL du site. Sur ce point, voir aussi notre article sur erreurs 404 wordpress.

Une page web peut échouer à l’indexation pour des raisons variées : une balise noindex oubliée, une canonique qui pointe vers une autre adresse, un contenu quasi identique à celui d’une page déjà connue, un statut de réponse en erreur, ou un blocage dans le fichier robots.txt. La configuration par URL distinctes complique encore les choses, puisqu’elle affiche un code HTML différent sur chaque appareil et sur des adresses différentes : la canonique doit alors désigner la version mobile, sans quoi le moteur peut ignorer l’une des deux. Avec la diffusion dynamique, la même URL sert les deux versions selon l’agent et l’en-tête Vary, ce qui masque les divergences à l’œil nu.

Google recommande le Responsive Web Design parmi les trois configurations possibles, et pour une bonne raison : avec une seule URL et un seul HTML, l’écart entre versions ne peut pas se creuser. Les deux autres modèles restent valables, à condition de vérifier régulièrement que les deux variantes racontent la même chose. Un site responsive n’est pas à l’abri pour autant, car un contenu chargé en JavaScript côté client peut très bien ne pas apparaître dans la capture du robot.

voir la page mobile sur son ordinateur, mode d’emploi honnête

Réduire la fenêtre du navigateur ne montre pas la version mobile : cela affiche la version desktop dans un cadre étroit. Pour obtenir le rendu réellement servi aux smartphones, il faut passer par l’émulation d’appareil des outils de développement, qui ajuste la largeur et l’agent, ou par une extension dédiée au changement de user-agent. Un détail piège les curieux : les CDN et les pare-feux peuvent renvoyer une version mise en cache pour l’agent précédent, et forcer un rechargement complet évite de travailler sur de vieilles données.

Franchement, la méthode la plus fiable reste l’inspection d’URL de la Search Console. L’outil montre le HTML tel que Google l’a reçu, avec l’agent du smartphone, et le résultat ne dépend ni de votre connexion ni de votre cache.

C’est un peu austère, mais c’est la seule vision qui corresponde à ce qui est réellement indexé. Pour le reste, l’émulation suffit à repérer les blocs disparus, à condition de comparer avec méthode et de noter les différences au fur et à mesure.

Les écarts les plus fréquents tiennent à peu de chose : une description tronquée, un tableau de caractéristiques transformé en accordéon vide, des avis clients chargés après le chargement initial, un lien de pagination remplacé par un bouton. Aucun de ces éléments ne casse le site, et c’est bien le problème. Le visiteur s’en accommode, le robot enregistre une page appauvrie, et le classement se dégrade sans signal clair. La détection demande donc de la régularité, pas un audit unique.

ce qui se joue vraiment dans la comparaison

Repérer un écart entre mobile et desktop n’a d’intérêt que si l’on accepte de regarder sa page comme un robot et non comme un utilisateur pressé. La simulation d’agent, l’inspection d’URL et la comparaison des codes sources donnent des réponses concrètes, là où les explications générales sur l’indexation mobile-first restent abstraites. Le travail se fait page par page, sur les modèles qui comptent, et il révèle souvent des différences que personne n’avait jamais vues. Votre dernière vérification de la version mobile date de quand ?