Faut-il bloquer les paramètres d'URL dans le robots.txt ou privilégier les canonicals ?

Pourquoi Google déconseille-t-il le blocage robots.txt pour les paramètres d'URL ?

Le fichier robots.txt ordonne à Googlebot de ne jamais accéder à certaines URL. Problème : si une page est bloquée, le bot ne peut pas lire son contenu ni ses balises HTML. Cela signifie qu'il ne verra jamais une balise canonical pointant vers la version principale, ni une directive noindex si vous souhaitez exclure la page de l'index.

Pour les sites e-commerce ou applicatifs qui génèrent des centaines de variations d'URL (filtres, tris, sessions, tracking), le réflexe historique était de tout bloquer dans robots.txt pour « économiser le crawl budget ». Google affirme ici que cette approche crée un trou noir : vous interdisez au moteur de comprendre votre intention. Si Googlebot ne crawle jamais produit.html?sort=price, il ne saura pas que cette URL doit canonicaliser vers produit.html.

Quelles sont les alternatives recommandées par Google ?

La consigne claire : laissez Googlebot accéder aux URL avec paramètres, et guidez-le avec des signaux on-page. La balise canonical indique la version de référence. La balise meta robots noindex demande explicitement de ne pas indexer une variante tout en autorisant le crawl. L'outil « Paramètres d'URL » dans Search Console (aujourd'hui en mode lecture seule pour beaucoup) permettait de spécifier l'impact des paramètres (filtrage, tri, tracking).

En pratique, la stratégie devient : crawlable mais non indexable pour les variantes sans valeur. Google peut explorer ?color=blue&size=M, lire la canonical vers la fiche produit principale, et comprendre qu'il ne doit pas créer d'entrée d'index séparée. Cela permet aussi de consolider les signaux (backlinks, ancres) vers l'URL canonique, ce qui serait impossible si la page était bloquée.

Que se passe-t-il concrètement si je bloque dans robots.txt ?

Si vous bloquez /produit.html?* dans robots.txt, Googlebot ne découvrira jamais les signaux de consolidation. Pire : si un backlink externe pointe vers produit.html?ref=newsletter, Google voit ce lien mais ne peut pas suivre l'URL ni transférer son jus vers la version canonique. Le lien reste « en suspens », sans bénéfice SEO.

Autre risque : certains paramètres créent du contenu unique (ex. ?category=shoes filtre réellement le catalogue). Bloquer ces URL empêche Google de les indexer alors qu'elles ont peut-être une valeur. La gestion par canonical ou noindex laisse la décision granulaire : indexer cette variante-ci, consolider celle-là. Le robots.txt est binaire : tout ou rien.

• Laisser crawlable les URL à paramètres pour que Google lise les signaux de canonicalisation
• Utiliser rel=canonical pour pointer les variantes vers l'URL de référence
• Ajouter meta robots noindex sur les pages sans valeur SEO (tris, tracking) pour éviter l'indexation tout en autorisant le crawl
• Limiter robots.txt aux zones vraiment inutiles (admin, espaces privés, doublons techniques massifs sans signaux possibles)
• Monitorer Search Console pour détecter les paramètres problématiques et affiner la stratégie de canonicalisation

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

Oui, et c'est l'un des messages les plus cohérents de Google depuis des années. Les audits SEO montrent régulièrement que les sites bloquant massivement via robots.txt souffrent d'une indexation fragmentée. Les backlinks vers des variantes bloquées ne consolident jamais leur autorité. Les outils de crawl détectent souvent des centaines d'URL « discovered but not crawled » : Google connaît leur existence via des liens, mais ne peut pas les explorer pour comprendre la structure.

La nuance : certains sites génèrent des millions de paramètres poubelles (sessions PHP, IDs temporaires, tracking Analytics). Dans ces cas extrêmes, bloquer reste parfois la seule option viable pour éviter un épuisement du crawl budget. Mais même là, la meilleure pratique est d'abord de corriger le code source pour ne pas générer ces URL en premier lieu (URLs propres, gestion côté serveur, sessions en cookies). Le robots.txt devient un pansement, pas une solution.

Quelles zones d'ombre subsistent dans cette recommandation ?

Google reste flou sur le seuil de tolérance du crawl budget. Pour un petit site, laisser 500 URL paramétrées crawlables ne pose aucun problème. Pour un site de 10 millions de pages, cela peut diluer le budget. [A verifier] : aucune métrique officielle ne permet de savoir si Google crawle « assez » vos pages importantes après avoir exploré les variantes.

Autre point : l'outil « Paramètres d'URL » dans Search Console est devenu quasi inactif. Google a annoncé qu'il le gère désormais « automatiquement », mais les retours praticiens montrent des incohérences. Certains paramètres évidents (sort, page, ref) sont mal interprétés, créant des doublons indexés. La recommandation de Google suppose que leur algo détecte toujours les patterns, ce qui n'est pas garanti.

Dans quels cas peut-on encore utiliser robots.txt pour les paramètres ?

Deux scénarios légitimes. Premier cas : faceted navigation explosive (combinatoires de filtres générant des centaines de milliers d'URL). Si votre CMS produit mécaniquement ces pages sans canonical automatique, et que corriger le code demande 6 mois, un blocage robots.txt temporaire limite les dégâts en attendant. Mais c'est un pis-aller.

Deuxième cas : paramètres de tracking sans aucune valeur (UTM purs, identifiants de campagne). Si ?utm_source=facebook&utm_medium=cpc n'affecte ni le contenu ni l'URL affichée, mais que Google les indexe quand même (canonical ignorée), un blocage ciblé peut empêcher la pollution de l'index. Encore une fois, la vraie solution est de nettoyer les liens internes pour ne jamais afficher ces paramètres dans le HTML.

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

Première étape : récupérer tous les patterns bloqués dans votre robots.txt. Cherchez les lignes Disallow: /*? ou Disallow: *.php?* qui interdisent l'accès aux URL avec paramètres. Listez les paramètres concernés : sont-ils vraiment tous sans valeur ? Certains filtrent-ils du contenu pertinent ?

Deuxième action : croiser avec les données Search Console. Allez dans « Pages > Non indexées » et filtrez par « Bloquée par robots.txt ». Si vous voyez des URL avec des backlinks ou du trafic organique historique (avant blocage), c'est un signal fort : ces pages ont de la valeur et doivent être libérées avec des canonicals.

Comment migrer d'un blocage robots.txt vers une gestion par canonical ?

Ne supprimez pas brutalement toutes les lignes Disallow. Procédez par vagues. Identifiez d'abord les paramètres à faible volume (ex. ?print=1) et ajoutez une canonical vers l'URL propre sur ces pages. Attendez 2 semaines, vérifiez que Google crawle et respecte la canonical (Search Console > Inspecteur d'URL). Si tout est stable, levez le blocage robots.txt pour ce paramètre.

Pour les paramètres massifs (tris, filtres e-commerce), automatisez la logique : toute URL avec ?sort= doit canonicaliser vers la version sans paramètre. Testez sur un échantillon de 100 URL, suivez l'indexation dans Search Console. Si Google respecte les canonicals, déployez sur l'ensemble. Ce n'est qu'après validation que vous retirez la ligne Disallow correspondante du robots.txt.

Quelles erreurs critiques éviter lors de la transition ?

Erreur classique : ajouter une canonical mais laisser le blocage robots.txt actif. Google ne verra jamais la balise. Autre piège : utiliser des canonicals relatives () sur un site avec plusieurs sous-domaines ou protocoles (http/https). Les canonicals doivent être absolues pour éviter toute ambiguïté.

Troisième erreur : croire que noindex suffit sans canonical. Si une page est noindex, Google ne l'indexe pas, mais il ne sait pas où consolider les signaux (backlinks, ancres). Combinez : noindex, follow pour exclure de l'index, et canonical vers la version principale pour transférer l'autorité. Cette approche double est souvent la plus propre pour les variantes sans valeur.

• Auditer le robots.txt et lister tous les patterns bloquant des paramètres d'URL
• Vérifier dans Search Console les pages bloquées avec backlinks ou trafic historique
• Ajouter des balises canonical absolues sur toutes les variantes paramétrées avant de lever tout blocage
• Déployer des meta robots noindex, follow sur les paramètres purement techniques (tracking, sessions)
• Retirer progressivement les lignes Disallow du robots.txt, par groupes de paramètres, en surveillant l'impact sur le crawl et l'indexation
• Monitorer le rapport « Couverture » dans Search Console pour détecter les doublons indexés après migration