Pour vérifier ce que robots.txt bloque réellement, il faut tester l'URL exacte de l'image, sur son propre domaine, et pas seulement l'URL de la page produit. Si l'image est servie par un CDN, le robots.txt du domaine du CDN s'applique. Un blocage de l'image empêche son exploration, mais l'URL de la page produit peut rester indexable si d'autres pages la citent.
Pourquoi l'URL de l'image et celle de la page produit ne dépendent pas du même robots.txt
Dans une fiche produit classique, le navigateur charge une page HTML sur boutique-exemple.fr et une image sur cdn-exemple.net. Ce sont deux domaines distincts. Google applique le robots.txt du domaine qui héberge la ressource demandée. Un Disallow: /images/ dans le robots.txt de la boutique n'a donc aucun effet sur une image servie par le CDN, et inversement.
La documentation Google sur l'indexation des images rappelle que les exigences techniques habituelles s'appliquent aussi aux images, avec des règles propres à leur format : leur découverte et leur présentation influencent l'indexation (Official source). Autrement dit, une image peut être techniquement accessible mais mal découverte, ou bien bloquée à l'exploration alors que la page qui la contient reste parfaitement indexable.
Que bloque réellement un robots.txt : page, image ou ressource ?
La documentation d'introduction à robots.txt distingue les effets selon le type de fichier (Official source). Pour une page web, un blocage empêche l'exploration, mais l'URL peut encore apparaître dans les résultats si d'autres pages la citent avec un texte descriptif. Pour un fichier média, un blocage vise aussi à empêcher l'image, la vidéo ou l'audio d'apparaître dans les résultats de recherche, sans empêcher d'autres sites de pointer vers ce fichier.
Cette distinction est centrale pour une boutique. Bloquer une image dans robots.txt ne supprime pas la page produit, et bloquer la page produit ne supprime pas l'image si elle est servie ailleurs. Les deux décisions se prennent séparément, sur deux domaines potentiellement différents.
Comment vérifier concrètement, sans supposer
La méthode fiable consiste à raisonner par URL, pas par intention.
- Relever l'URL exacte de l'image telle qu'elle apparaît dans l'attribut
srcde la balise<img>, pas l'URL de la page. Google peut trouver les images dans lesrcd'un élément<img>, y compris imbriqué dans un<picture>, mais n'indexe pas les images CSS (Official source). - Identifier le domaine de cette URL. Si c'est un sous-domaine ou un domaine CDN, c'est son robots.txt qu'il faut lire, pas celui du site principal.
- Lire le robots.txt de ce domaine et vérifier les règles qui s'appliquent au chemin de l'image, pour l'agent concerné.
- Tester l'URL de l'image dans un outil d'inspection d'URL lorsque vous en avez un, en visant l'URL de l'image et non celle de la page.
- Comparer avec la page produit : testez aussi l'URL de la page, car les deux peuvent avoir des statuts différents.
Si vous ne disposez pas d'un outil d'inspection, la vérification manuelle du robots.txt du bon domaine reste la première étape, et elle suffit souvent à trancher.
Exemple hypothétique de diagnostic
Prenons une boutique hypothétique, ma-boutique.test, qui sert ses visuels produit via images.ma-boutique.test. Son robots.txt principal contient Disallow: /produits/ mais rien sur les images. Le robots.txt du sous-domaine d'images contient Disallow: /photos/.
Une fiche produit située à /produits/chaise-bleue est donc bloquée à l'exploration. Son image, servie à /photos/chaise-bleue.jpg, est elle aussi bloquée, mais par une règle différente, sur un autre domaine. Si l'équipe ne lit que le robots.txt principal, elle conclura à tort que les images sont accessibles. Cet exemple est illustratif : les chemins et les règles varient selon chaque configuration.
Le rôle du sitemap images et de la vérification de propriété
Un sitemap d'images permet de fournir des URL d'images qui n'auraient pas été découvertes autrement. Particularité utile : contrairement aux sitemaps classiques, les éléments <image:loc> peuvent inclure des URL d'autres domaines, ce qui autorise l'hébergement via un CDN. Google encourage à vérifier la propriété du domaine du CDN dans Search Console (Official source).
C'est un point souvent négligé : sans vérification du domaine CDN, vous pouvez recevoir des alertes incomplètes et croire que tout va bien alors que l'exploration des images échoue silencieusement.
Ce que robots.txt ne fait pas
Un robots.txt n'est pas un mécanisme pour retirer une page des résultats de recherche. La documentation est explicite sur ce point : pour empêcher une page d'apparaître, il faut utiliser noindex ou une protection par mot de passe (Official source). De même, bloquer une image dans robots.txt n'empêche pas d'autres sites de la lier.
Pour une boutique, cela signifie qu'un blocage mal placé peut dégrader la visibilité des images sans protéger quoi que ce soit. La question à se poser n'est pas « ai-je un robots.txt ? » mais « quelle URL, sur quel domaine, est concernée par quelle règle ? ».
Questions fréquentes
Un robots.txt qui bloque une image empêche-t-il la page produit d'être indexée ?
Non, pas directement. La page et l'image sont deux ressources distinctes, souvent sur deux domaines. Une page peut rester indexable même si son image est bloquée, et une image peut rester accessible même si la page est bloquée.
Faut-il vérifier le robots.txt du CDN même s'il appartient à un prestataire ?
Oui, car c'est ce fichier qui s'applique aux images servies par ce domaine. Si vous ne contrôlez pas ce robots.txt, il faut demander au prestataire quelles règles s'appliquent et vérifier la propriété du domaine dans Search Console lorsque c'est possible.
Pour aller plus loin
Si vous travaillez la production visuelle en amont, notre guide sur les images produit gratuites et les outils IA aide à choisir un outil sans sacrifier la fidélité au produit. Pour tester une vidéo produit, voyez Google Flow gratuit. Et pour mesurer ensuite ce qui remonte réellement, Search Console et les recherches multimodales précisent ce que les rapports couvrent.