Pourquoi Google retarde-t-il la migration mobile-first de certains sites ?

Qu'est-ce que Google entend exactement par « headings mal balisés » ?

Un heading mal balisé, c'est du texte qui ressemble visuellement à un titre (police grande, grasse, espacée) mais qui n'utilise pas les balises sémantiques HTML <h1>, <h2>, etc. À la place, le développeur a appliqué du CSS sur un <div> ou un <p> pour simuler l'apparence d'un titre.

Google ne peut pas deviner qu'un <div class="big-title"> est un heading structurel. Pour le crawler, c'est juste du texte. Si cette pratique est courante sur la version desktop mais corrigée (ou pire, absente) sur mobile, Google détecte une incohérence de structure entre les deux versions et suspend la migration mobile-first.

Pourquoi le nombre d'images entre desktop et mobile pose-t-il problème ?

Beaucoup de sites masquent des thumbnails ou galeries d'images en mobile pour alléger la page ou accélérer le chargement. Problème : si Google indexe uniquement la version mobile, ces images disparaissent de l'index. Résultat ? Perte de visibilité dans Google Images, perte de contexte sémantique pour certains contenus (produits e-commerce, portfolios, articles illustrés).

Google considère que si la version mobile est trop appauvrie par rapport au desktop, elle ne représente pas fidèlement le contenu du site. La migration est donc reportée jusqu'à ce que l'écart soit réduit. Ce n'est pas un blocage définitif, mais un signal d'alerte.

Cette vérification concerne-t-elle tous les sites ou seulement ceux en attente de migration ?

Mueller précise bien : « Pour un site non encore migré en mobile-first indexing ». En pratique, la majorité des sites ont déjà basculé depuis 2019-2021. Mais certains projets — refonte en cours, CMS legacy, sites à fort trafic desktop — restent en indexation desktop-first.

Pour ces derniers, Google applique un examen manuel ou algorithmique avant la bascule. Si les critères (headings, images, contenu textuel) ne sont pas remplis, la migration est repoussée. Une fois migré, le site reste en mobile-first : il n'y a pas de retour en arrière, même si la qualité mobile se dégrade par la suite.

• Balises HTML sémantiques obligatoires : <h1> à <h6> doivent être présentes dans le DOM, pas simulées en CSS.
• Parité d'images desktop/mobile : le nombre et le type d'images (notamment thumbnails, galeries, visuals produits) doivent être équivalents.
• Migration différée, pas refusée : Google ne bloque pas définitivement, mais attend que le site corrige les écarts détectés.
• Audit technique indispensable : comparer les deux versions avec un crawler (Screaming Frog, OnCrawl) en User-Agent desktop puis mobile.
• Pas de retour en arrière : une fois migré en mobile-first, le site y reste — d'où l'importance de bien préparer la version mobile avant la bascule.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, et elle confirme ce que beaucoup d'entre nous constatent depuis des années. Les sites qui masquent du contenu en mobile — par display:none, lazy-loading agressif, ou suppression pure et simple de sections entières — voient leur visibilité chuter après la migration mobile-first. Ce n'est pas une pénalité : c'est la conséquence logique d'un index appauvri.

Mais la nuance, c'est que Google ne détaille jamais le seuil de tolérance. Combien d'images en moins est acceptable ? 10 % ? 30 % ? Aucune métrique publique. [A vérifier] sur chaque projet avec un test progressif : comparer les performances avant/après ajustement du nombre d'images mobiles.

Le problème des headings stylisés est-il encore fréquent en pratique ?

Moins qu'avant, mais ça arrive encore — surtout sur des sites legacy ou des builders no-code qui génèrent du HTML atypique. Le vrai danger, c'est le heading invisible : un <h2> présent en desktop, masqué en CSS (display:none) ou remplacé par une image en mobile.

Google traite ces cas comme des incohérences structurelles. Si le heading est masqué uniquement en mobile, il disparaît de l'index mobile-first. Si c'est un <h1> ou <h2> stratégique, l'impact SEO peut être brutal. Toujours vérifier que les balises sémantiques sont présentes dans le DOM mobile, pas seulement visibles à l'écran.

Faut-il vraiment avoir autant d'images en mobile qu'en desktop ?

Soyons honnêtes : non, ce n'est pas toujours pertinent. Un site e-commerce avec 12 photos produit en desktop peut légitimement n'en afficher que 4-5 en mobile pour des raisons d'UX et de performance. Mais — et c'est là que ça coince — ces images doivent quand même exister dans le HTML mobile, même si elles sont en lazy-loading ou dans un carrousel replié.

Google indexe ce qui est dans le DOM, pas ce qui est immédiatement visible. Si les thumbnails sont chargées en JavaScript après un clic utilisateur, elles peuvent être invisibles pour Googlebot. Résultat : perte d'indexation dans Google Images, perte de contexte sémantique. [A vérifier] avec un rendu JavaScript via Search Console ou un crawler configuré en mode JS.

Que faut-il vérifier concrètement avant une migration mobile-first ?

Premier réflexe : crawler le site en User-Agent mobile (Googlebot Smartphone) et comparer avec un crawl desktop. Screaming Frog, OnCrawl, Botify — tous permettent de changer l'User-Agent. Ensuite, exporter les headings (<h1> à <h6>) et les images de chaque version, puis croiser les données dans un tableur.

Si des headings disparaissent ou changent de niveau (un <h2> devient <h3>), c'est un signal d'alerte. Si le nombre d'images mobiles est inférieur de plus de 20-30 % au desktop, il faut investiguer : lazy-loading trop agressif ? Images masquées en CSS ? Carrousels non crawlables ?

Comment corriger un site qui masque du contenu en mobile ?

Si des images ou headings sont masqués en display:none ou visibility:hidden, remplacez par du lazy-loading natif (loading="lazy") ou un carrousel accessible en HTML. L'idée : le contenu doit être présent dans le DOM, même s'il n'est pas immédiatement visible à l'écran.

Pour les headings stylisés en CSS, il faut refactoriser le HTML : remplacer <div class="heading"> par <h2>, puis ajuster le CSS. C'est un chantier technique, mais c'est le seul moyen de garantir que Google reconnaît la structure sémantique du contenu.

Quels outils utiliser pour détecter ces problèmes en amont ?

Search Console reste l'outil de référence : section « Expérience sur la page » → vérifier si Google signale des différences entre desktop et mobile. Mais attention, Search Console ne détaille pas toujours les écarts précis. Il faut compléter avec un crawler configuré en mode mobile et un test de rendu JavaScript (via Puppeteer, par exemple).

Autre piste : comparer les logs serveur pour voir si Googlebot Smartphone crawle autant de ressources (images, CSS, JS) que Googlebot Desktop. Si le nombre de requêtes serveur en mobile est nettement inférieur, c'est un signe que du contenu est inaccessible ou masqué.

• Crawler le site en User-Agent Googlebot Smartphone et comparer avec un crawl desktop.
• Vérifier que tous les headings (<h1> à <h6>) sont présents dans le DOM mobile, pas simulés en CSS.
• S'assurer que le nombre d'images (notamment thumbnails, galeries, visuals produits) est équivalent entre desktop et mobile.
• Remplacer les display:none par du lazy-loading natif ou des carrousels accessibles en HTML.
• Tester le rendu JavaScript pour vérifier que les images lazy-loadées sont bien visibles pour Googlebot.
• Consulter les logs serveur pour détecter d'éventuelles ressources non crawlées en mobile.