Robots.txt et balises noindex bloquent-ils vraiment l'indexation mobile sur Google ?

Pourquoi Google insiste-t-il sur la cohérence desktop/mobile des directives de crawl ?

Depuis le passage au mobile-first indexing, Google utilise principalement la version mobile d'un site pour l'indexation et le classement. Si votre version mobile bloque des ressources que la version desktop autorise, Googlebot se retrouve avec une vue partielle — voire tronquée — de votre contenu.

Cette incohérence crée une asymétrie d'information : Google indexe ce qu'il voit sur mobile, mais si des CSS, JavaScript ou pages entières sont bloqués uniquement sur cette version, l'algorithme travaille avec des données incomplètes. Le résultat ? Une indexation dégradée, un rendu partiel, et potentiellement un classement inférieur à ce que votre contenu desktop mériterait.

Que se passe-t-il concrètement si j'utilise noindex ou robots.txt sur mobile ?

La balise meta noindex sur une page mobile indique explicitement à Google de ne pas l'indexer. Si votre version desktop n'a pas cette directive mais que le mobile l'a, Google privilégie la version mobile — et n'indexe donc pas la page. C'est un cas de figure fréquent sur les sites qui ont mal migré leurs règles lors du passage au responsive.

Le robots.txt fonctionne différemment : il empêche le crawl en amont. Si Googlebot mobile ne peut pas crawler une page ou une ressource (CSS, JS), il ne peut ni la découvrir, ni l'indexer, ni évaluer correctement son rendu. Le nofollow, quant à lui, bloque la transmission de PageRank et empêche le suivi des liens — ce qui, sur une version mobile, coupe la découverte de pages liées.

Cette directive s'applique-t-elle aussi aux sites desktop uniquement ?

Soyons honnêtes : un site 100 % desktop sans version mobile optimisée est une espèce en voie d'extinction. Google continue d'indexer ces sites, mais avec l'index mobile-first activé par défaut depuis 2021, même un site desktop sera crawlé en priorité avec le user-agent mobile.

Si votre robots.txt ou vos balises noindex diffèrent selon le user-agent (desktop vs mobile), vous créez une friction technique. Google recommande une parité stricte : ce qui est autorisé sur desktop doit l'être sur mobile, et inversement. Toute divergence est un signal d'alerte pour l'indexation.

• Mobile-first indexing : Google utilise la version mobile comme référence principale pour l'indexation et le classement.
• Cohérence des directives : robots.txt, noindex, et nofollow doivent être identiques entre desktop et mobile.
• Ressources bloquées : Un CSS ou JS bloqué sur mobile peut dégrader le rendu et nuire au classement.
• Nofollow mobile : Bloquer les liens avec nofollow sur mobile empêche la découverte de nouvelles pages par Googlebot.
• Impact direct : Une incohérence desktop/mobile peut entraîner une indexation partielle ou nulle de pages stratégiques.

Cette directive est-elle cohérente avec les observations terrain ?

Oui, et c'est même un classique des audits SEO post-migration mobile. On voit régulièrement des sites qui ont gardé un robots.txt legacy bloquant des ressources critiques uniquement sur mobile, ou des balises noindex ajoutées « par précaution » sur une version mobile qui n'était pas encore prête. Résultat : des pages qui rankaient bien en desktop disparaissent après le basculement mobile-first.

Le point sur le nofollow est moins documenté dans les discussions publiques, mais il est logique : si un lien est en nofollow sur mobile et pas sur desktop, Google suit la version mobile et ne transmet pas de PageRank. Cela casse le maillage interne et la découverte de contenu profond. C'est particulièrement critique sur les sites e-commerce avec des filtres ou des paginations bloqués en nofollow uniquement sur mobile.

Quelles nuances faut-il apporter à cette recommandation ?

Google parle ici de pages et ressources, mais ne détaille pas la granularité. Concrètement, bloquer une image secondaire en robots.txt sur mobile n'aura pas le même impact que bloquer un fichier CSS critique pour le rendu. Il faut donc prioriser : les ressources qui affectent le rendu initial (above-the-fold, CSS, JS) doivent absolument être accessibles.

Autre nuance : certains sites utilisent volontairement des balises noindex sur des pages mobiles spécifiques (ex. pages AMP alternatives, versions simplifiées). Dans ce cas, il faut s'assurer que la version canonique (desktop ou mobile standard) reste bien indexable. [A vérifier] : Google ne précise pas comment il gère les cas où une page mobile noindex pointe vers une canonique desktop indexable — les remontées terrain suggèrent que cela fonctionne, mais c'est une zone grise.

Dans quels cas cette règle peut-elle poser problème ?

Sur les sites avec des versions mobiles dédiées (m.example.com), la tentation est forte de gérer différemment les directives. Mais Google ne fait pas de distinction : si la version mobile est celle qu'il indexe, elle doit être traitée comme la version principale. Bloquer des ressources ou pages sur cette version revient à les bloquer pour l'indexation, point.

Que faut-il vérifier en priorité sur son site ?

Première étape : ouvrir la Google Search Console et aller dans l'outil de test d'URL. Testez vos pages stratégiques avec le user-agent mobile et vérifiez que toutes les ressources (CSS, JS, images critiques) sont bien chargées. Si des ressources sont bloquées, la capture d'écran du rendu vous montrera l'impact visuel.

Ensuite, comparez votre robots.txt desktop et mobile. Sur la plupart des sites, il n'y a qu'un seul fichier robots.txt, donc pas de divergence — mais si vous utilisez des règles conditionnelles par user-agent (rare mais existant), vérifiez la parité. Même logique pour les balises meta : un diff entre les templates desktop et mobile peut révéler des noindex ou nofollow parasites.

Comment corriger une incohérence desktop/mobile existante ?

Si vous avez identifié des ressources bloquées uniquement sur mobile, modifiez votre robots.txt pour les autoriser. Attention : après modification, il faut attendre que Googlebot recrawle le fichier (généralement sous 24-48h) puis relancer l'exploration des pages concernées via Search Console.

Pour les balises noindex ou nofollow, le correctif est plus direct : supprimez-les des templates mobiles ou harmonisez avec le desktop. Mais là encore, le délai de prise en compte dépend du crawl budget et de la fréquence de passage de Googlebot. Sur un site peu crawlé, cela peut prendre plusieurs semaines. Pensez à soumettre manuellement les URL corrigées via Search Console pour accélérer le processus.

Quelles erreurs éviter lors de la migration mobile-first ?

L'erreur classique : copier-coller un robots.txt desktop sans vérifier que les règles restent pertinentes sur mobile. Certains sites bloquent des sections entières (ex. /print/, /amp/) qui n'existent que sur desktop, mais oublient que la version mobile peut avoir une structure d'URL différente.

Autre piège : ajouter des balises nofollow sur des liens internes mobiles pour « économiser le crawl budget ». C'est contre-productif : Google a besoin de suivre ces liens pour découvrir et indexer les pages. Si vous voulez optimiser le crawl budget, jouez plutôt sur la profondeur de clic et la structure de maillage interne, pas sur le nofollow.

• Tester les pages stratégiques avec l'outil d'inspection d'URL de Google Search Console (user-agent mobile).
• Comparer robots.txt desktop et mobile (ou vérifier qu'un seul fichier est utilisé pour les deux).
• Auditer les templates mobiles pour détecter des balises noindex ou nofollow absentes du desktop.
• Autoriser en robots.txt toutes les ressources critiques pour le rendu mobile (CSS, JS principaux).
• Vérifier que le maillage interne mobile n'utilise pas de nofollow sur les liens stratégiques.
• Relancer l'indexation des pages corrigées via Search Console après modification.