Pourquoi Google ignore-t-il vos données structurées desktop après le mobile-first indexing ?

Que se passe-t-il exactement quand un site migre en mobile-first indexing ?

Avant le basculement, Google crawlait et indexait principalement la version desktop de votre site. Les données structurées du desktop servaient de référence pour tous les affichages, mobiles comme desktop. Après la migration en mobile-first indexing, c'est l'inverse strict : Google n'utilise plus que le code source de la version mobile pour tout.

Cela inclut les balises schema.org, les JSON-LD, les microdonnées, tout ce qui sert à générer les rich snippets. Si un markup Product avec price et rating existe sur desktop mais pas sur mobile, Google ne le verra plus — même pour afficher un résultat enrichi à un utilisateur sur un écran de bureau.

Pourquoi cette règle existe-t-elle ?

Google indexe désormais une seule version de chaque page, celle qu'il considère comme primaire. Pour la majorité du trafic mondial qui vient du mobile, cette version primaire est logiquement la mobile. Dupliquer l'indexation entre deux versions créerait des incohérences et gaspillerait du crawl budget.

L'idée sous-jacente : si une information n'est pas assez importante pour figurer sur mobile, elle n'est pas assez importante tout court. Google force ainsi les sites à aligner leur contenu et leurs métadonnées structurées sur toutes les plateformes.

Que signifie la période de transition avec deux crawlers actifs ?

Pendant que Google prépare le basculement d'un site vers le mobile-first indexing, les deux user-agents (Googlebot desktop et smartphone) peuvent crawler simultanément. Cette phase de test permet à Google de vérifier que la version mobile contient bien tout le contenu et les métadonnées nécessaires avant de couper définitivement l'indexation desktop.

Une fois la migration terminée, seul le crawler mobile reste actif pour ce site. Les logs montrent alors une chute brutale des requêtes du Googlebot desktop. À partir de ce moment, toute modification des données structurées desktop n'a aucun impact sur les SERP.

• Google utilise exclusivement les données structurées de la version mobile après MFI
• Les rich snippets affichés sur desktop proviennent du markup mobile, pas du markup desktop
• Durant la transition, deux crawlers peuvent coexister, mais un seul indexe réellement après migration
• L'alignement des métadonnées entre mobile et desktop devient obligatoire, pas optionnel
• Toute donnée structurée absente du mobile disparaît de l'indexation, quel que soit le device de consultation

Cette règle est-elle vraiment appliquée de façon stricte sur tous les sites ?

Terrain : oui, sans exception observée. Dès qu'un site bascule en MFI — et c'est le cas de la quasi-totalité du web indexé aujourd'hui — seule la version mobile compte. On a documenté des dizaines de cas où des rich snippets Product, Recipe ou FAQ disparaissaient côté desktop après migration, simplement parce que le markup existait uniquement dans le code desktop.

Le piège classique : les sites qui servent une version mobile allégée avec moins de contenu, moins de modules, et donc moins de balisage structuré. Google ne fait pas de compromis là-dessus. Si le JSON-LD manque sur mobile, il manque partout. [A vérifier] : certains sites responsive ultra-optimisés cachent du contenu en CSS sur mobile — Google ignore-t-il vraiment ces blocs masqués, ou les parse-t-il quand même ? Les guidelines disent "oui, il les ignore", mais les tests à grande échelle manquent.

Quelles sont les conséquences imprévues de cette règle ?

Premier point : beaucoup de sites ont encore des implémentations divergentes entre mobile et desktop, souvent à cause de templates différents ou de systèmes de cache séparés. Le balisage schema.org se retrouve fragmenté. Résultat : des rich results qui clignotent entre présence et absence selon les recrawls.

Deuxième point : les outils de test Google (Rich Results Test, Schema Markup Validator) crawlent parfois en mode desktop par défaut si vous ne forcez pas l'user-agent. Vous validez un markup qui ne sera jamais pris en compte. Il faut systématiquement tester avec l'URL mobile ou forcer le smartphone user-agent pour voir la vérité.

Faut-il dupliquer absolument tous les markups sur mobile ?

Oui, mais avec nuance. Dupliquer ne veut pas dire "coller le même JSON-LD de 150 lignes partout". Ce qui compte, c'est que les propriétés critiques pour les rich results soient présentes sur mobile : price, rating, datePublished, author, etc. Certaines propriétés optionnelles peuvent être omises si elles n'influencent pas l'affichage enrichi.

Soyons honnêtes : personne ne vérifie manuellement 10 000 URLs. Il faut auditer par échantillonnage stratifié (pages produits, articles, landing pages) et automatiser la détection des écarts entre versions mobile/desktop. Un script qui compare les JSON-LD extraits des deux user-agents fait gagner des semaines. [A verifier] : Google prend-il vraiment en compte les données structurées injectées via Google Tag Manager en mode asynchrone sur mobile ? Officiellement oui, en pratique les délais de rendu peuvent poser problème.

Comment vérifier que mes données structurées sont bien présentes sur mobile ?

Premier réflexe : ouvrir Google Search Console, section "Paramètres" > "Exploration", et confirmer que le site est bien passé en mobile-first indexing. Si c'est le cas, direction le rapport "Améliorations" pour voir si des erreurs de balisage structuré remontent spécifiquement sur les URLs mobiles.

Ensuite, utilisez le Rich Results Test de Google en mode inspection d'URL réelle (pas mode code snippet), et forcez l'user-agent Googlebot Smartphone. Comparez le rendu HTML récupéré par Google avec ce que vous voyez dans le DOM desktop. Les différences sautent aux yeux : JSON-LD manquant, propriétés tronquées, balises schema.org absentes.

Que faire si mes données structurées diffèrent entre mobile et desktop ?

Première action : unifier les templates. Si vous utilisez un thème responsive propre, le même code HTML (et donc le même balisage) devrait s'afficher partout. C'est la solution la plus pérenne. Si vous avez des versions séparées (m.example.com ou dynamic serving), assurez-vous que le script qui génère le JSON-LD tourne dans les deux contextes.

Deuxième action : si votre CMS ou votre stack technique rend la synchronisation complexe, envisagez d'injecter les données structurées critiques via un système centralisé (API, microservice, tag manager) qui sert le même payload quel que soit le device. C'est plus maintenable que de dupliquer manuellement du code dans plusieurs fichiers de templates.

Quels points de contrôle intégrer dans un processus qualité SEO ?

Intégrez un test automatisé pré-déploiement qui crawle une URL en mode desktop et mobile, extrait les JSON-LD, et compare les propriétés critiques (type, name, description, image, etc.). Si un écart est détecté, le pipeline CI/CD devrait alerter ou bloquer le déploiement.

Côté monitoring post-déploiement, tracez dans vos dashboards le taux d'apparition des rich snippets par type de page. Une chute brutale après une mise en production signale souvent un markup disparu sur mobile. Surveillez aussi les logs serveur : si le ratio Googlebot smartphone / desktop change soudainement, c'est peut-être un basculement MFI en cours.

• Vérifier dans Search Console que le site est bien en mobile-first indexing
• Tester toutes les URLs stratégiques avec le Rich Results Test en mode Googlebot Smartphone
• Comparer les JSON-LD extraits côté mobile et desktop via un script automatisé
• Unifier les templates ou centraliser l'injection des données structurées pour éviter les divergences
• Intégrer un test de régression automatique dans le pipeline de déploiement
• Monitorer le taux d'affichage des rich snippets et les logs de crawl pour détecter les anomalies