Nous considérons Sitemap: comme un signal de découverte, pas comme une règle Allow ou Disallow.
Nous contrôlons d’abord le sitemap
Nous ouvrons le XML, vérifions le statut HTTP, HTTPS, l’hôte canonique et les URL indexables. Ensuite nous utilisons une URL absolue :
Sitemap: https://example.com/sitemap.xml
Plusieurs fichiers ou un index
Plusieurs lignes Sitemap: sont valides. Lorsqu’un sitemap index stable existe, nous préférons le référencer pour éviter de maintenir deux inventaires.
Sitemap: https://example.com/sitemap-index.xml
Nous séparons les hôtes
Le robots.txt de example.com ne gouverne pas automatiquement shop.example.com. Pour les architectures multi-hôtes, nous vérifions chaque origine et utilisons le guide des sous-domaines.
Search Console complète la vérification
La déclaration facilite la découverte, mais ne garantit pas la qualité du sitemap. Nous contrôlons aussi les redirections, noindex et URL non canoniques.
Nous vérifions la production
Après publication, nous ouvrons /robots.txt, chaque sitemap, puis utilisons le checker et le validator.
Ce que la ligne Sitemap peut — et ne peut pas — faire
Sitemap: aide les crawlers à découvrir le XML, mais ne rend pas les URL indexables et n’annule pas une règle Disallow. Nous utilisons une URL absolue avec protocole et hôte, vérifions le domaine de production et préférons un index de sitemap stable lorsqu’il gère déjà les fichiers enfants.
Un sitemap sur un autre hôte peut être valide, mais nous vérifions son propriétaire et son contenu. Pendant une migration, redirections, canonical, sitemap et Search Console doivent raconter la même histoire ; une ligne techniquement correcte peut sinon continuer à promouvoir un ancien domaine.
Vérifications avant publication
Nous ouvrons chaque sitemap, contrôlons le statut HTTP, l’hôte canonique, les URL publiques et un échantillon de pages indexables. robots.txt ne fait qu’aider à la découverte : une mauvaise liste XML reste mauvaise même si la directive est parfaite.
