Faut-il absolument placer son sitemap à la racine du domaine ?

Quelle est la portée par défaut d'un sitemap placé dans un sous-répertoire ?

La déclaration de Mueller précise une règle souvent méconnue : un fichier sitemap stocké dans un sous-répertoire possède une portée limitée par défaut. Concrètement, si vous déposez sitemap.xml dans example.com/blog/, ce fichier ne pourra référencer que des URLs commençant par example.com/blog/.

Cette restriction s'explique par des considérations de sécurité et de permissions. Google considère qu'un fichier situé dans /blog/ n'a pas l'autorité pour déclarer des URLs situées à la racine ou dans d'autres répertoires. Un sous-dossier ne peut pas « prétendre » représenter l'ensemble du domaine sans validation explicite.

Comment Search Console change-t-il cette limitation ?

Mueller précise que le placement physique devient secondaire si le sitemap est correctement configuré dans Google Search Console. Une fois déclaré manuellement dans GSC, le fichier peut référencer n'importe quelle URL du domaine vérifié, peu importe son emplacement physique.

Cette souplesse s'avère particulièrement utile dans les architectures complexes où différents sous-répertoires sont gérés par des équipes ou systèmes distincts. Un sitemap technique peut vivre dans /seo-tools/ tout en couvrant l'ensemble du site, à condition d'être enregistré dans GSC avec les permissions appropriées.

Cette règle s'applique-t-elle aussi au fichier robots.txt ?

La déclaration via robots.txt suit exactement la même logique. Si vous indiquez « Sitemap: https://example.com/blog/sitemap.xml » dans votre robots.txt à la racine, vous donnez explicitement l'autorisation à ce fichier de couvrir tout le domaine.

Sans cette déclaration explicite (robots.txt ou GSC), le sitemap reste cantonné à son périmètre de sous-répertoire. Cette double couche de validation — emplacement physique ET déclaration explicite — constitue un mécanisme de sécurité contre les injections de sitemaps malveillants.

• Un sitemap dans un sous-répertoire ne couvre que ce sous-répertoire par défaut
• La déclaration dans Search Console ou robots.txt élargit cette portée à l'ensemble du domaine vérifié
• Cette restriction vise à empêcher qu'un accès partiel au serveur permette de manipuler l'indexation globale
• Le placement physique importe peu une fois la configuration GSC correctement effectuée
• Même règle pour les sitemaps d'images, vidéos ou actualités

Cette limitation est-elle réellement appliquée dans la pratique ?

Les tests terrain confirment que Google applique strictement cette règle pour les sitemaps découverts automatiquement. Si Googlebot trouve un sitemap.xml dans /ressources/ sans déclaration explicite, il ignorera les URLs situées hors de ce répertoire. J'ai observé ce comportement sur plusieurs audits où des URLs racines n'étaient pas crawlées malgré leur présence dans un sitemap « orphelin ».

En revanche, la souplesse de Search Console est réelle. Une fois le sitemap enregistré manuellement dans GSC, Google respecte la portée déclarée indépendamment du chemin physique. Cette approche permet des configurations hybrides utiles pour les gros sites avec architecture distribuée.

Quels pièges guettent les SEO mal informés ?

Le piège classique : déployer un sitemap dans un sous-dossier, l'indexer correctement dans GSC, puis changer d'URL sans mettre à jour la déclaration. Le nouveau fichier sera découvert mais limité à son sous-répertoire, créant un trou dans la couverture d'indexation. [A vérifier] sur les sites avec multiples migrations de sitemaps.

Autre confusion fréquente : croire que la présence dans robots.txt suffit. Si le robots.txt pointe vers /blog/sitemap.xml mais que ce fichier liste des URLs racines, Google les crawlera... mais pourrait appliquer un trust réduit comparé à un sitemap déclaré depuis la racine ET dans GSC. Cette double validation renforce la légitimité du fichier.

Cette règle diffère-t-elle selon les types de sitemaps ?

La logique s'applique identiquement aux sitemaps d'index, d'images, de vidéos et d'actualités. Un sitemap vidéo dans /media/video-sitemap.xml ne pourra référencer que des URLs /media/* sauf déclaration explicite. Cette cohérence simplifie la gouvernance SEO des gros sites.

Point intéressant : les sitemaps générés dynamiquement (exemple : /sitemap.php?type=blog) suivent la même règle selon leur URL apparente, pas leur logique serveur. Si l'URL affichée est /blog/sitemap.php, la limitation s'applique même si le script PHP génère des URLs globales. Seule compte l'URL telle que Google la voit.

Où placer concrètement ses fichiers sitemap ?

La meilleure pratique reste le placement à la racine du domaine : example.com/sitemap.xml pour le sitemap principal, avec des sitemaps d'index si nécessaire. Cette approche évite toute ambiguïté et fonctionne même si la configuration GSC est accidentellement supprimée.

Pour les architectures multi-sections (blog, e-commerce, documentation), privilégiez un sitemap d'index à la racine pointant vers des sitemaps thématiques : /blog/sitemap.xml, /shop/sitemap.xml. Déclarez chaque fichier individuellement dans GSC pour garantir une couverture complète et trackable.

Comment vérifier que la configuration actuelle est correcte ?

Dans Search Console, section Sitemaps, vérifiez que tous les sitemaps déclarés affichent un statut « Réussite » avec un nombre d'URLs découvertes cohérent. Un sitemap qui liste 5000 URLs mais n'en remonte que 200 signale probablement un problème de portée.

Utilisez un crawler comme Screaming Frog ou OnCrawl pour croiser les URLs présentes dans vos sitemaps avec celles effectivement indexées. Un écart significatif entre URLs soumises et URLs indexées peut indiquer une limitation de portée non détectée, surtout si les URLs manquantes sont hors du répertoire du sitemap.

Quelles erreurs éviter absolument ?

Ne déployez jamais un sitemap dans un sous-répertoire sans validation explicite dans GSC ou robots.txt. Cette configuration silencieuse échoue sans générer d'alerte visible, créant des trous d'indexation difficiles à diagnostiquer. Google ne vous préviendra pas que 60% de votre sitemap est ignoré.

Évitez aussi de multiplier les sitemaps redondants dans différents répertoires. Un même ensemble d'URLs déclaré dans /sitemap.xml et /blog/sitemap.xml crée de la confusion pour le crawl budget et dilue les signaux de priorité. Chaque URL doit apparaître dans un seul sitemap canonique.

• Placer le sitemap principal à la racine du domaine (example.com/sitemap.xml)
• Déclarer explicitement chaque sitemap dans Google Search Console
• Vérifier que le fichier robots.txt référence correctement les sitemaps utilisés
• Auditer régulièrement la cohérence entre URLs soumises et URLs indexées
• Éviter les sitemaps orphelins dans des sous-répertoires sans déclaration GSC
• Documenter l'architecture des sitemaps pour faciliter la maintenance par les équipes