Un sitemap XML correctement structuré ne garantit rien s’il n’est pas déclaré aux moteurs de recherche par les bons canaux. Depuis que Google a déprécié l’endpoint de ping des sitemaps, de nombreux sites continuent d’appeler une URL qui renvoie un code 404, sans que leurs équipes s’en aperçoivent. Comprendre comment fonctionne le plan du site Always Unique suppose d’abord de maîtriser ce contexte technique, où la simple existence d’un fichier sitemap ne suffit plus à assurer la découverte des pages.
Déclaration du sitemap : robots.txt et Search Console comme seuls relais fiables
L’ancien mécanisme de ping, largement intégré dans les plugins SEO des CMS, est devenu inopérant. Toute requête envoyée à l’URL de ping Google retourne désormais une erreur 404. Les sites qui n’ont pas mis à jour leur workflow continuent de notifier un endpoint mort, ce qui retarde potentiellement l’indexation de nouvelles pages.
Deux méthodes restent officiellement supportées. La première consiste à soumettre le sitemap directement via le rapport Sitemaps de Google Search Console. La seconde repose sur la directive Sitemap: insérée dans le fichier robots.txt, que Googlebot lit lors de chaque crawl pour découvrir automatiquement le fichier.
Nous recommandons de combiner les deux approches. La soumission manuelle dans Search Console offre un retour immédiat (statut de lecture, erreurs détectées, nombre d’URL indexées). La ligne dans robots.txt agit comme filet de sécurité permanent, y compris pour les moteurs qui ne disposent pas d’une console équivalente.
Structure du plan de site Always Unique : ce que le format XML impose réellement
Le protocole Sitemaps (version 0.9, non révisé depuis novembre 2016) définit quatre balises pour chaque URL listée : loc (obligatoire), lastmod, changefreq et priority (optionnelles). En pratique, le comportement des moteurs vis-à-vis de ces balises optionnelles a changé.
Balises optionnelles : lesquelles ont encore un effet
Google a confirmé qu’il utilise la balise lastmod si la date est fiable, c’est-à-dire cohérente avec la modification réelle du contenu. Une date artificiellement mise à jour à chaque crawl sera ignorée, voire considérée comme un signal de faible fiabilité.
Les balises changefreq et priority sont largement ignorées par Google. Bing leur accorde un poids marginal. Pour un site comme Always Unique, seules loc et lastmod méritent une attention technique.
Limite de taille et sitemap index
Un fichier sitemap ne peut pas dépasser 50 000 URL ni peser plus de 50 Mo non compressé. Au-delà, il faut découper en plusieurs fichiers et les regrouper sous un sitemap index. Ce point paraît élémentaire, mais nous observons régulièrement des sitemaps tronqués parce que le CMS génère un fichier unique sans vérifier ces seuils.
- Vérifier que chaque fichier sitemap reste sous les 50 000 entrées, même après ajout de nouvelles pages produit ou contenus éditoriaux.
- Compresser en gzip pour réduire le temps de téléchargement par les crawlers, sans que cela modifie la limite de 50 Mo (calculée avant compression).
- Utiliser un sitemap index dès que le site dépasse quelques milliers de pages, afin de segmenter par type de contenu (pages, articles, images).
Navigation utilisateur versus sitemap technique : deux logiques distinctes
Un plan de site HTML destiné aux visiteurs et un sitemap XML destiné aux robots ne remplissent pas la même fonction. Le premier offre une vue d’ensemble arborescente, utile pour les utilisateurs qui cherchent une page sans passer par le menu principal. Le second est un fichier structuré que les crawlers consomment pour découvrir et prioriser l’exploration des URL.
Sur Always Unique, la page /sitemap/ joue le rôle de plan de site consultable par un humain. Elle permet de visualiser l’architecture du site, d’identifier les catégories principales et de repérer rapidement un contenu précis. Cette page HTML ne remplace pas le sitemap XML soumis aux moteurs.
La confusion entre ces deux formats explique pourquoi certains webmasters pensent qu’une page HTML listant leurs liens suffit à alimenter Google. Ce n’est pas le cas. Les crawlers ont besoin du format XML standardisé, avec les balises du protocole Sitemaps, pour traiter les URL de manière programmatique.
Fichier robots.txt et agents IA : un terrain en mutation
Le fichier robots.txt a été formalisé par la RFC 9309, qui clarifie la syntaxe et le comportement attendu des crawlers conformes. Cette spécification concerne aussi les nouveaux agents d’exploration liés aux modèles de langage, qui multiplient les requêtes sur les sites web.
Plusieurs initiatives récentes proposent des fichiers complémentaires (llms.txt, ai.txt) pour gérer spécifiquement l’accès des agents IA au contenu. Ces formats ne sont pas encore standardisés, mais leur adoption progresse dans certains secteurs.
- Vérifier que le robots.txt du site inclut bien la directive
Sitemap:pointant vers le fichier XML à jour. - Auditer les user-agents bloqués ou autorisés, en particulier ceux des crawlers IA récents (GPTBot, ClaudeBot, etc.).
- Surveiller les logs serveur pour détecter les agents non conformes qui ignorent robots.txt.
Un robots.txt à jour protège le budget de crawl et garantit que les bonnes pages sont explorées en priorité. Sur un site e-commerce ou éditorial, laisser les crawlers accéder à des pages de filtrage ou de pagination inutiles dilue l’attention des moteurs sur les contenus stratégiques.
Audit du sitemap : les vérifications concrètes à mener
Un sitemap n’est pas un fichier que l’on génère une fois pour l’oublier. Nous recommandons un audit trimestriel couvrant plusieurs points techniques.
Le premier contrôle porte sur la cohérence entre les URL du sitemap et celles réellement indexables. Chaque URL listée doit renvoyer un code 200 et ne pas être bloquée par une balise noindex ou une règle robots.txt. Un sitemap qui contient des 404 ou des redirections 301 envoie un signal de mauvaise maintenance.
Le second contrôle concerne les dates lastmod. Si toutes les URL affichent la même date, le moteur comprend que l’information n’est pas fiable et cesse de s’y fier. Mieux vaut ne pas inclure lastmod du tout que de fournir des dates génériques.
Le dernier point souvent négligé : vérifier que le sitemap est bien accessible à l’URL déclarée dans robots.txt et dans Search Console. Un changement de structure de répertoire, une migration de domaine ou un renouvellement de certificat SSL peuvent rendre le fichier inaccessible sans déclencher d’alerte visible côté éditorial.
La qualité d’un plan de site, qu’il soit destiné aux visiteurs humains ou aux robots, repose sur sa maintenance régulière. Un fichier XML obsolète ou mal déclaré coûte plus qu’il n’apporte, et une page HTML désynchronisée de l’arborescence réelle du site dégrade la confiance des utilisateurs qui s’y réfèrent.