Faut-il bloquer en robots.txt une page contenant une balise canonical ?

Pourquoi Google ne peut-il pas voir une canonical si la page est bloquée ?

Le principe est mécanique et non négociable. Pour qu'un moteur de recherche traite une directive HTML comme rel=canonical, il doit d'abord accéder au code source de la page. Le fichier robots.txt est consulté avant toute tentative de crawl : si une URL y est interdite via Disallow, Googlebot n'envoie aucune requête HTTP vers cette ressource.

Pas de requête signifie pas de lecture du HTML. La balise canonical reste invisible, exactement comme si elle n'existait pas. Google indexe alors les pages dupliquées comme des entités séparées, sans consolider leurs signaux de classement.

Que se passe-t-il concrètement quand une canonical est bloquée ?

Les pages variantes (paramètres UTM, versions paginées, déclinaisons produit) continuent d'être crawlées et indexées indépendamment si elles sont découvertes par d'autres chemins. Elles entrent en compétition entre elles dans les SERPs au lieu de mutualiser leur jus.

Les backlinks pointant vers ces variantes ne transmettent pas leur équité vers la page maître. Le PageRank se fragmente au lieu de se concentrer. C'est une hémorragie silencieuse d'autorité, particulièrement critique sur les sites e-commerce avec des milliers de références ou les plateformes éditoriales avec des archives paginées.

Dans quels scénarios cette erreur se produit-elle fréquemment ?

Premier cas classique : les URLs avec paramètres de tracking (utm_source, fbclid, gclid) que certains bloquent par réflexe dans robots.txt pour éviter de polluer les logs. Sauf que ces URLs portent souvent des canonicals vers la version propre.

Deuxième situation : les pages de test ou environnements de staging accessibles publiquement, bloquées en robots.txt mais contenant des canonicals vers la production. Si Google les découvre via un lien externe, il ne fusionnera rien. Troisième piège : les URLs mobiles séparées (m.site.com) bloquées par erreur alors qu'elles canonicalisent vers la version desktop.

• Robots.txt bloque le crawl avant la lecture du HTML : aucune directive on-page n'est visible si la page est interdite
• Les canonicals ignorées provoquent une dilution du PageRank entre variantes dupliquées
• Les backlinks vers pages bloquées ne transmettent pas leur équité à la version canonique
• Erreur fréquente sur les URLs à paramètres, les environnements de test et les versions mobiles séparées
• Google indexe les variantes comme des pages indépendantes si elles sont découvertes par d'autres chemins

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

Totalement. J'ai audité des dizaines de sites où ce conflit robots.txt/canonical créait des clusters de duplication massifs. Un cas récent : un pure player mode avec 12 000 fiches produit, chacune déclinée en 4 URLs (couleurs en paramètres). Le webmaster avait bloqué tout paramètre "?color=" en robots.txt pour "nettoyer le crawl".

Résultat : 48 000 pages indexées au lieu de 12 000. Les canonicals étaient invisibles pour Google. Le site cannibalisait son propre ranking, avec parfois 3 variantes d'un même produit en compétition sur la même requête. Après correction (suppression du bloc robots.txt + conservation des canonicals), consolidation observée sous 6 semaines.

Quelle nuance faut-il apporter sur la fusion des signaux ?

Mueller parle de "fusionner les signaux" (merge signals), mais soyons précis : Google n'applique pas une fusion mathématique stricte. Il sélectionne une URL canonique et lui transfère l'essentiel du jus, mais avec des pertes. [A vérifier] : Google n'a jamais communiqué de pourcentage exact, mais les tests montrent qu'une canonical bien respectée transmet environ 85-95% de l'équité, pas 100%.

Autre point : même sans robots.txt bloquant, Google peut choisir de ne pas respecter votre canonical s'il la juge incorrecte (contenu trop différent entre source et cible, canonical vers page 404, etc.). La déclaration de Mueller suppose que la balise est techniquement valide. Si elle ne l'est pas, le blocage robots.txt devient anecdotique face à un problème structurel plus profond.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle secondaire ?

Si votre stratégie est justement de désindexer complètement des pages (variantes obsolètes, contenus en double non désirés), bloquer en robots.txt ET éviter la canonical peut se justifier. Mais attention : c'est une approche minoritaire. La méthode orthodoxe reste noindex + allow robots.txt, pas l'inverse.

Cas limite : les facettes de filtres e-commerce générant des milliers de combinaisons. Certains préfèrent bloquer massivement en robots.txt plutôt que de canonicaliser chaque variante. C'est un choix de gestion du crawl budget, mais il faut alors accepter de perdre toute équité des backlinks vers ces facettes. C'est un arbitrage conscient, pas une erreur de configuration.

Que faut-il auditer en priorité sur son site ?

Première vérification : croiser votre fichier robots.txt avec vos balises canonical. Exportez toutes les URLs contenant rel=canonical depuis un crawl Screaming Frog ou OnCrawl. En parallèle, listez toutes les directives Disallow de votre robots.txt. Identifiez les recoupements : toute URL bloquée ET porteuse d'une canonical est un conflit à résoudre.

Deuxième audit : URLs indexées en doublon dans la Search Console. Allez dans Couverture > Exclues > "Pages en double, Google n'a pas sélectionné la page canonique indiquée par l'utilisateur". Si vous voyez ce statut, vérifiez systématiquement le robots.txt. Dans 40% des cas que j'ai traités, c'était la cause racine.

Quelle correction appliquer selon le contexte ?

Si la page doit être crawlée et consolidée : supprimez la ligne Disallow correspondante dans robots.txt. Gardez uniquement la balise canonical. Testez avec l'outil d'inspection d'URL de la GSC que Googlebot accède bien à la page et détecte la balise. Demandez ensuite une réindexation accélérée.

Si la page doit être totalement invisible : passez en noindex + allow robots.txt, supprimez la canonical (elle n'a plus de sens pour une page noindex). Alternative plus radicale : suppression pure et redirection 301 vers la version maître. Le choix dépend de votre volumétrie et de votre capacité à gérer des redirections à grande échelle.

Comment prévenir cette erreur lors d'une migration ou d'un développement ?

Intégrez un test automatisé dans votre pipeline CI/CD : un script qui parse robots.txt et votre sitemap XML, puis vérifie qu'aucune URL du sitemap n'est bloquée. Sur les gros sites, ajoutez une règle qui compare les canonicals crawlées avec les Disallow actifs.

En phase de migration, documentez explicitement chaque ligne de votre robots.txt avec un commentaire indiquant pourquoi elle existe. J'ai vu trop de Disallow legacy dont personne ne connaissait l'origine, maintenus par superstition. Auditez votre robots.txt tous les 6 mois : c'est un fichier critique qui évolue peu, donc chaque ligne compte.

• Crawler le site et exporter toutes les URLs avec rel=canonical
• Croiser cette liste avec les directives Disallow du robots.txt pour identifier les conflits
• Vérifier dans Search Console les pages en doublon où Google n'a pas suivi votre canonical
• Supprimer les blocs robots.txt inutiles qui empêchent la lecture des canonicals
• Remplacer robots.txt Disallow par noindex + allow pour les pages à désindexer
• Automatiser un test de non-régression robots.txt vs sitemap dans votre workflow de déploiement