• 5 min de lecture • AI Data Stream Team

Sitemap : savoir quelles pages sont apparues, lesquelles ont disparu et quel trafic est parti avec elles

Connectez votre sitemap.xml et demandez à votre IA quelles pages ont été ajoutées ou supprimées, quand une page a disparu et quel trafic de recherche est parti avec elles. Plans Pro et Business.

Des pages disparaissent des sites web en permanence. Un produit est épuisé et sa page est dépubliée. Une annonce expire. Une refonte supprime une rubrique que personne ne jugeait importante. Des semaines plus tard, le trafic organique a baissé et personne ne peut dire exactement quelles pages sont parties, ni quand.

Votre sitemap sait quelles pages existent en ce moment. Il ne sait pas lesquelles existaient le mois dernier. La connexion Sitemap est désormais disponible dans AI Data Stream, sur les plans Pro et Business, et elle ajoute ce qui manque au sitemap : la mémoire.

Ce qu’elle fait

Indiquez votre sitemap.xml ou votre index de sitemaps à la connexion. Dès lors, AI Data Stream garde une trace de chaque URL listée : sa première apparition, sa dernière observation et sa disparition. Le sitemap est un fichier public : aucun identifiant à configurer, aucun plugin CMS à installer. Cela fonctionne pour les sites statiques, Shopify, les CMS headless, les frameworks maison et tous les sites que les outils propres à WordPress ne peuvent pas atteindre.

Votre IA dispose de quatre outils :

  • Statistiques : combien d’URL sont listées, combien ont disparu au fil du temps, ajouts et suppressions sur les 7 et 30 derniers jours, et les plus grandes sections du site
  • Changements : les URL ajoutées, supprimées ou modifiées sur une période
  • Recherche : les URL par chemin, section ou plage de lastmod, y compris celles qui ont disparu
  • Actualisation : récupérer la dernière copie à la demande

Les questions qui comptent sont celles qui les combinent avec vos autres données. « Quelles pages avons-nous supprimées en septembre, et combien de clics rapportaient-elles avant ? » tient en une seule question dans le chat. L’IA extrait les URL supprimées de l’historique du sitemap, recherche chacune dans Search Console pour les semaines précédant sa disparition et additionne le trafic parti avec elles. La nouvelle compétence Sitemap Content Changes exécute cette analyse sous forme de rapport.

Honnête sur le « quand »

Un sitemap ne dit que ce qui est listé au moment où on le lit. Si une page était là le 9 et absente le 24, personne ne peut dire quel jour, entre les deux, elle a été supprimée. La plupart des outils en choisiraient un en silence. Pas nous.

Chaque suppression est présentée comme une fenêtre : encore listée à une récupération, disparue à la suivante. Quand les deux dates sont séparées d’un jour, c’est un jour. Quand elles sont séparées de deux semaines, vous voyez deux semaines, et l’IA a pour consigne de citer la plage plutôt que d’inventer une date.

La largeur de ces fenêtres dépend de vous. Par défaut, le sitemap n’est récupéré que lorsqu’un outil est utilisé ou que vous cliquez sur Actualiser maintenant : cela ne coûte rien quand personne ne regarde, mais les trous durent aussi longtemps que les silences. Activez Actualiser en arrière-plan et le sitemap est vérifié à chaque intervalle de rafraîchissement, jusqu’à deux fois par jour. Les vérifications sont conditionnelles : si votre serveur indique que le sitemap n’a pas changé, rien n’est téléchargé, et pour un index de sitemaps seuls les fichiers enfants dont le lastmod a bougé sont récupérés. Les fenêtres de suppression se réduisent à une journée sans marteler votre serveur ni le nôtre.

Dater une disparition, ou trier vos 404

Deux usages sont tombés presque gratuitement de l’historique.

Quand cette page est-elle partie ? Donnez une URL à l’IA et elle vous indique la dernière récupération qui la listait encore et la première qui ne la listait plus. Pour une page qu’un client jure n’avoir jamais supprimée, c’est une chose utile à pouvoir dire.

Quels 404 comptent ? Transmettez une liste d’URL renvoyant un 404, issue des données d’exploration de Search Console ou de Cloudflare, et l’historique du sitemap les trie en trois tas. Les pages listées puis supprimées sont de vraies suppressions qui méritent sans doute une redirection. Les URL qui n’ont jamais figuré dans le sitemap sont de vieux liens, du bruit de scanners et des fautes de frappe à ignorer. Et les pages encore listées mais en 404 sont celles que votre CMS annonce activement à Google sans réussir à les servir : un bug, pas une décision éditoriale.

Contrôle de votre lastmod

En analysant des sitemaps, nous voyons beaucoup de champs lastmod, et beaucoup ne valent pas grand-chose. Certains sitemaps omettent complètement la date. D’autres datent chaque URL du même jour, ou de l’heure du dernier build du site. Google et Bing ont tous deux indiqué qu’ils n’utilisent lastmod que lorsqu’il est systématiquement exact et l’ignorent dès que ce n’est plus le cas : un sitemap plein de fausses dates a donc jeté un indice d’exploration pour tout le site.

La connexion signale désormais les deux cas. Si moins de la moitié de vos URL portent une date, ou si presque toutes portent la même, le tableau de bord et l’IA le disent et expliquent la solution : faire émettre par le CMS la vraie date de dernière modification de chaque page. C’est une note, pas une erreur. Les sitemaps sans lastmod sont valides et la connexion fonctionne très bien avec eux. Vous devez simplement le savoir.

Conçue pour ne pas vous mentir

Une connexion dont toute la valeur réside dans des données historiques a un mode de défaillance catastrophique : enregistrer des suppressions qui n’ont jamais eu lieu. Une page de défi WAF, un sitemap à moitié écrit pendant un déploiement ou un délai dépassé sur un gros index peuvent faire qu’une récupération ne renvoie qu’une fraction des URL présentes la veille. Prenez cela pour la vérité et des milliers de pages vivantes sont marquées supprimées, avec un faux historique impossible à effacer.

Alors la connexion refuse. Si une récupération renvoie moins de la moitié des URL stockées lors de la précédente, rien n’est marqué supprimé, la connexion affiche un avertissement et on vous demande de vérifier le sitemap dans un navigateur. Les lectures partielles se comportent de la même façon : si un sitemap dépasse ce que votre plan stocke (10 000 URL sur Pro, 50 000 sur Business) ou la limite de taille, la copie est signalée comme partielle et aucune URL n’en est jamais marquée supprimée.

Pour commencer

Ouvrez l’onglet Connexions d’une propriété, cliquez sur Ajouter une connexion et choisissez Sitemap. Collez l’URL du sitemap, gardez l’intervalle par défaut de 24 heures, décidez si vous voulez des actualisations en arrière-plan et cliquez sur Tester. Puis demandez à l’IA ce qui a changé ce mois-ci, ou activez le widget du tableau de bord et regardez les ajouts et suppressions s’accumuler.

Le guide de configuration est dans la documentation. Le suivi commence à la première récupération : plus un site est connecté tôt, plus il a d’historique quand vous en avez besoin.

Articles associes