Indexation mobile-first : ce que Google voit vraiment de votre site

L'indexation mobile-first n'est plus une transition en cours : elle s'applique à l'ensemble du web. Google explore avec un agent mobile, indexe ce que cet agent voit, et ignore ce qui n'apparaît que sur la version desktop.

Ce que cela signifie concrètement

Le contenu, les balises, les liens internes et les données structurées pris en compte sont ceux du rendu mobile.

Si votre site sert un HTML différent selon l'appareil, ce qui reste courant sur les sites qui ont conservé une version mobile séparée ou un rendu adaptatif côté serveur, tout écart est un risque.

Un site en responsive design classique, qui sert le même HTML et adapte l'affichage par CSS, est protégé par construction. C'est la raison principale pour laquelle cette approche s'est imposée.

Les écarts qui coûtent le plus cher

Les données structurées absentes en mobile. Elles sont parfois injectées par un script chargé uniquement sur desktop, ou retirées pour alléger la page. Résultat, le balisage n'existe pas pour Google.

Les liens internes supprimés. Un menu desktop riche remplacé en mobile par trois entrées, un fil de navigation retiré, un bloc de liens connexes masqué. Le maillage interne s'effondre sans que personne ne le voie.

Le contenu tronqué. Une page qui affiche 2 000 mots sur desktop et 600 en mobile est indexée sur 600 mots.

Les images non chargées. Un chargement différé mal implémenté, sans repli en HTML, peut rendre les images invisibles à l'indexation.

Le cas du contenu replié

Un contenu masqué derrière un accordéon ou un onglet est indexé normalement, à condition d'être présent dans le HTML dès le chargement. Google l'a confirmé de longue date.

La nuance porte sur le contenu injecté au clic par un appel réseau : celui-là n'existe pas pour l'indexation. Le test est simple, désactivez JavaScript et regardez ce qui reste.

Comment vérifier

L'outil d'inspection d'URL de Search Console montre le HTML rendu tel que Google le voit. Comparez-le à ce que vous voyez dans votre navigateur : les différences sautent aux yeux.

Vérifiez trois choses en priorité. Le texte principal est-il présent en entier ? Les données structurées apparaissent-elles ? Les liens internes vers vos pages importantes sont-ils là ?

Faites le même test sur trois types de pages : accueil, page de catégorie, page de contenu. Les écarts se logent rarement au même endroit.

Si le doute persiste sur ce que les robots reçoivent réellement, les journaux du serveur tranchent : ils enregistrent chaque requête, son agent et son code de réponse. La méthode est dans notre guide sur l'analyse de logs.

Ce qui ne relève pas de ce sujet

Les Core Web Vitals mesurent l'expérience de chargement et pèsent modérément sur le classement. Ils ne conditionnent pas l'indexation : une page lente est indexée, une page vide de contenu mobile ne l'est pas.

La distinction compte, parce que beaucoup d'audits confondent les deux et dépensent des semaines sur la performance alors que le contenu mobile est incomplet. Le second problème coûte infiniment plus cher.

Ce que cela change pour les moteurs de réponse

Le sujet dépasse largement Google, et c'est la partie que la plupart des audits mobiles ignorent encore.

Les robots des moteurs de réponse exécutent beaucoup moins de JavaScript que Googlebot. GPTBot, OAI-SearchBot et PerplexityBot se contentent, pour l'essentiel, du HTML servi. Un site dont le contenu n'apparaît qu'après rendu est donc doublement pénalisé : partiellement indexé par Google, et invisible pour les moteurs de réponse.

La conséquence est presque rassurante. Le même correctif règle les deux problèmes : servir le texte principal, les liens internes et les données structurées dans le HTML initial, sur mobile comme sur desktop. C'est le prérequis technique décrit dans notre guide sur les six plateformes où se joue la visibilité IA.

Les trois contrôles à automatiser

Une vérification manuelle se fait une fois, puis se perd. Trois contrôles méritent d'être intégrés à la recette avant chaque mise en production.

Le nombre de mots du HTML servi, comparé entre le rendu mobile et le rendu desktop. Un écart de plus de 10 % signale une amputation. Une simple requête curl avec un agent mobile suffit à produire la mesure.

La présence du JSON-LD dans le HTML mobile. Un test qui cherche la balise application/ld+json et vérifie que le type attendu s'y trouve prend quelques lignes et évite la panne la plus discrète de cette liste.

Le nombre de liens internes dans le HTML mobile. Une chute brutale après une refonte du menu se voit immédiatement, alors qu'elle passerait inaperçue pendant des mois dans Search Console.

Ces trois mesures ne demandent aucun outil payant. Elles demandent seulement d'être faites avant la mise en ligne plutôt que six mois après la baisse de trafic.