Robots.txt bloque-t-il vraiment l'exploration de vos images sur tous vos domaines ?

Pourquoi robots.txt est-il lié au protocole et au nom d'hôte ?

Googlebot traite chaque combinaison protocole + nom d'hôte comme une entité distincte. Concrètement, un robots.txt placé sur https://example.com ne s'applique ni à http://example.com ni à https://images.example.com.

Cette logique découle de la RFC 9309 qui standardise robots.txt : le fichier doit être récupéré à la racine du scheme + authority. Si vous migrez de HTTP vers HTTPS sans mettre à jour le robots.txt HTTPS, Googlebot peut explorer des URLs que vous pensiez bloquées.

Que se passe-t-il avec un code 503 dans robots.txt ?

Un statut 503 signale une indisponibilité temporaire. Google interprète ce code comme un signal de prudence et suspend l'exploration en attendant que le serveur redevienne disponible.

À l'inverse, un 404 ou 410 indique l'absence de fichier robots.txt, ce qui équivaut à une autorisation totale d'explorer. Un 503 mal configuré peut donc paralyser votre crawl sans que vous le réalisiez.

Les sous-domaines héritent-ils des règles du domaine principal ?

Non. Chaque sous-domaine nécessite son propre robots.txt. Si vous bloquez /images/ sur www.example.com, un bot peut toujours accéder à cdn.example.com/images/ sans restriction.

C'est un piège fréquent lors de migrations ou de refonte : les équipes oublient que blog.example.com ou shop.example.com doivent recevoir leur propre configuration. Les CDN externes (Cloudflare, Akamai) posent le même problème si vous ne maîtrisez pas leur robots.txt.

• Un robots.txt s'applique uniquement au couple protocole + nom d'hôte (ex : https://example.com ≠ https://www.example.com)
• Un code 503 suspend temporairement l'exploration ; un 404 équivaut à une autorisation totale
• Les sous-domaines et domaines externes nécessitent chacun leur propre fichier robots.txt
• Une migration HTTP → HTTPS impose de vérifier le robots.txt sur les deux protocoles
• Les CDN tiers peuvent exposer vos images même si votre domaine principal les bloque

Cette déclaration contredit-elle les pratiques observées sur le terrain ?

Non, elle confirme ce que les SEO techniques documentent depuis des années. Les audits montrent régulièrement des sites avec un robots.txt strict sur www mais un CDN ou un sous-domaine totalement ouvert.

Ce qui manque ici, c'est une position claire sur les CDN avec domaines personnalisés (type cdn.votredomaine.com vs cdn-1234.cloudflare.net). Google explore-t-il les deux ? Quelle priorité ? [A vérifier] en fonction de vos canonical et de votre configuration DNS.

Que signifie vraiment "temporairement" pour un 503 ?

Mueller ne donne aucun chiffre. Les observations terrain suggèrent que Googlebot retente après quelques heures à plusieurs jours, avec un backoff exponentiel. Mais cela dépend de la fréquence de crawl habituelle de votre site.

Un 503 accidentel sur un site à fort crawl budget peut coûter des milliers de pages non mises à jour dans l'index. Si votre serveur renvoie un 503 à cause d'une surcharge ponctuelle, Google peut attendre 48h avant de réessayer. Aucune garantie officielle n'existe sur ce délai.

Faut-il dupliquer robots.txt sur tous les sous-domaines ?

Pas nécessairement. Si un sous-domaine héberge des ressources publiques sans valeur SEO (assets statiques, API internes), un robots.txt permissif ou absent peut convenir.

En revanche, si vous utilisez plusieurs sous-domaines pour segmenter du contenu (blog, support, shop), chacun doit recevoir une configuration adaptée. Le risque : oublier un sous-domaine qui expose des URLs de test ou des doublons non canonicalisés.

Comment vérifier que vos robots.txt couvrent tous vos domaines ?

Utilisez la Search Console pour chaque propriété (domaine principal, sous-domaines, variantes HTTP/HTTPS). Vérifiez que le fichier robots.txt de chaque entité correspond à votre stratégie.

Listez ensuite tous vos noms d'hôte actifs : CDN, sous-domaines fonctionnels, anciens domaines redirigés. Un crawl Screaming Frog en mode "liste d'URLs" peut révéler des domaines tiers qui servent vos images sans restriction.

Que faire si vous détectez un 503 accidentel ?

Corrigez immédiatement le code HTTP et forcez un re-crawl via Search Console. Un 503 prolongé peut réduire drastiquement votre crawl budget et retarder l'indexation de nouvelles pages.

Mettez en place une alerte monitoring (Pingdom, UptimeRobot, script custom) pour être notifié si robots.txt renvoie autre chose qu'un 200. Un 503 ponctuel de 10 minutes passe inaperçu ; un 503 de 6 heures peut impacter votre visibilité pendant des jours.

Faut-il bloquer les images sur un CDN externe ?

Cela dépend de votre stratégie. Si vos images sont hotlinkées sans contexte éditorial, Google peut les indexer sans associer votre marque. Un robots.txt sur le CDN peut limiter ce risque.

Mais bloquer totalement un CDN peut empêcher Google de valider vos Core Web Vitals si vos LCP ou CLS dépendent d'images hébergées là-bas. Testez l'impact avant de bloquer massivement. Si vous utilisez un CDN tiers sans accès au robots.txt (ex : service mutualisé), envisagez des headers X-Robots-Tag sur vos URLs d'images.

• Auditez tous vos noms d'hôte (www, non-www, sous-domaines, CDN) et vérifiez leur robots.txt respectif
• Configurez des alertes pour détecter un 503 accidentel sur robots.txt
• Testez l'exploration de vos images via Search Console sur chaque propriété distincte
• Si vous migrez HTTP → HTTPS, vérifiez que les deux protocoles ont un robots.txt cohérent
• Documentez les domaines tiers (CDN, APIs) qui servent vos ressources et leur politique d'exploration
• Envisagez des X-Robots-Tag si vous ne contrôlez pas le robots.txt d'un domaine tiers