Faut-il vraiment bloquer les images alternatives via robots.txt plutôt qu'avec x-robots-tag ?

Pourquoi cette distinction entre robots.txt et x-robots-tag pour les images ?

La directive de Mueller part d'un constat simple : de nombreux sites génèrent plusieurs versions d'une même image — miniatures, formats modernes (webp, avif), résolutions adaptatives. Sans contrôle explicite, Google peut indexer n'importe laquelle de ces versions, souvent pas celle que vous souhaitez mettre en avant.

Le x-robots-tag fonctionne via en-têtes HTTP et permet de contrôler finement l'indexation. Mais Google précise ici qu'il est « principalement pour les pages web ». Pour les images, la méthode recommandée devient le fichier robots.txt — plus simple, plus direct, et géré côté serveur sans toucher aux en-têtes.

Quelles versions d'images sont concernées par cette recommandation ?

On parle de toutes les variations techniques que votre infrastructure génère automatiquement : formats d'encodage différents, tailles multiples pour le responsive, miniatures CDN, versions optimisées pour réseaux sociaux. Chaque URL d'image peut être crawlée et indexée indépendamment.

Le problème ? Si Google indexe votre miniature 150x150 au lieu de l'original 1200x800, votre visibilité dans Google Images s'effondre. Ou pire : si une version non-optimisée (JPEG lourd au lieu du webp léger) est indexée, vous perdez sur deux tableaux — performance et référencement visuel.

Comment robots.txt bloque-t-il efficacement ces alternatives ?

La syntaxe classique s'applique : vous spécifiez les patterns d'URL à exclure du crawl. Par exemple, si vos miniatures sont dans /images/thumbs/ et vos formats webp dans /images/webp/, vous bloquez ces dossiers pour Googlebot-Image tout en laissant passer /images/originals/.

Attention toutefois — bloquer via robots.txt empêche le crawl, donc Google ne verra même pas ces fichiers. C'est radical mais efficace. Si vous préférez que Google connaisse l'existence de ces versions sans les indexer, vous entrez dans une zone grise que Mueller ne couvre pas explicitement dans cette déclaration.

• Robots.txt reste la méthode privilégiée pour bloquer les versions alternatives d'images selon Google
• Le x-robots-tag fonctionne, mais n'est pas l'outil recommandé pour ce cas d'usage spécifique
• Bloquer via robots.txt signifie absence totale de crawl — les images concernées ne seront ni vues ni indexées
• Cette approche concerne principalement les sites générant multiples formats automatiquement (CDN, responsive, conversion d'images)
• Sans directive claire, Google peut indexer n'importe quelle version, souvent pas celle que vous souhaitez valoriser

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

Soyons honnêtes : la plupart des sites corporate que j'ai audités n'utilisent ni robots.txt ni x-robots-tag pour gérer leurs images. Ils laissent Google décider, et ça fonctionne… jusqu'à ce que ça ne fonctionne plus. Les problèmes émergent surtout sur les sites e-commerce ou éditoriaux avec fort volume d'images et CDN agressif.

La directive de Mueller est cohérente avec ce qu'on observe : robots.txt est plus stable côté Google. Les en-têtes HTTP peuvent être mal interprétés selon les couches de cache (Cloudflare, Varnish, etc.), alors qu'un robots.txt bien configuré est lu directement par Googlebot sans ambiguïté. [A vérifier] — je n'ai jamais vu Google publier de chiffres sur le taux de respect des x-robots-tag pour images versus robots.txt.

Quelles nuances faut-il apporter à cette directive ?

Mueller dit que le x-robots-tag est « principalement » pour les pages web. Ce « principalement » laisse une porte ouverte — il ne dit pas « exclusivement ». Dans la réalité, le x-robots-tag fonctionne parfaitement pour les images si votre stack technique le supporte proprement. C'est juste pas la méthode recommandée.

Et c'est là que ça coince : pourquoi cette préférence pour robots.txt ? Parce que c'est plus scalable côté Google. Un fichier robots.txt peut couvrir des millions d'URLs avec quelques patterns regex. Le x-robots-tag nécessite que chaque requête HTTP soit examinée — plus coûteux en ressources serveur et en temps de crawl.

Dans quels cas cette recommandation ne s'applique-t-elle pas vraiment ?

Si vous gérez manuellement chaque image et ne générez pas de versions alternatives automatiquement, cette directive ne vous concerne tout simplement pas. Idem si vous n'avez qu'un format d'image par contenu — pas de webp, pas de miniatures, pas de CDN qui génère 12 tailles différentes.

Autre exception : les sites qui veulent que Google connaisse toutes les versions (pour des raisons de reverse image search ou de compatibilité cross-device) mais indexe une version préférée. Dans ce cas, le canonical pour images — qui n'est jamais mentionné par Mueller ici — serait plus adapté. Mais Google n'a jamais confirmé officiellement supporter un canonical pour images. [A vérifier].

Que faut-il faire concrètement pour appliquer cette recommandation ?

Première étape : identifier toutes les versions d'images générées par votre infrastructure. Crawlez votre site avec Screaming Frog ou Oncrawl en activant le crawl des images. Vous allez probablement découvrir 3 à 5 fois plus d'URLs d'images que prévu — formats multiples, tailles variées, versions CDN.

Ensuite, décidez quelle version vous voulez voir indexée. Généralement, c'est l'original haute résolution ou le format moderne le plus performant (webp, avif). Toutes les autres versions doivent être bloquées via robots.txt pour Googlebot et Googlebot-Image.

Quelles erreurs éviter lors de la mise en place ?

L'erreur classique : bloquer /images/ alors que vous vouliez bloquer uniquement /images/thumbs/. Résultat, toutes vos images disparaissent de l'index. Testez systématiquement vos directives avec le testeur robots.txt de la Search Console avant de pusher en production.

Autre piège — bloquer des images qui sont déjà indexées. Google va progressivement les retirer de l'index, mais ça prend du temps. Si vous voulez un retrait rapide, utilisez l'outil de suppression d'URL de la Search Console en parallèle. Et c'est là que ça devient complexe : gérer cette transition sans casser le référencement existant demande une planification rigoureuse.

Comment vérifier que votre configuration fonctionne correctement ?

Utilisez la Search Console, section Couverture des images. Vous devriez voir disparaître progressivement les versions alternatives bloquées. Parallèlement, vérifiez dans Google Images (recherche manuelle) que seules les bonnes versions apparaissent.

Pour un contrôle plus fin, analysez les logs serveur : Googlebot doit recevoir des 403 ou ignorer complètement les URLs bloquées via robots.txt. Si vous voyez encore des requêtes avec code 200 sur des images censées être bloquées, votre robots.txt n'est pas appliqué correctement.

• Auditez toutes les versions d'images générées automatiquement par votre infrastructure
• Identifiez quelle version unique doit être indexée (original haute résolution ou format moderne optimisé)
• Configurez robots.txt avec des patterns précis pour bloquer les versions alternatives (testez avec Search Console)
• Surveillez l'évolution dans la section Couverture des images de la Search Console
• Vérifiez manuellement dans Google Images que seules les bonnes versions apparaissent après quelques semaines
• Analysez vos logs serveur pour confirmer que Googlebot respecte bien vos directives robots.txt