Documentation

Repérer avant tout le monde un flux figé ou un sitemap vide

Les fichiers XML cassent rarement avec fracas. La tâche qui écrit le flux RSS s’arrête, et le serveur continue de servir le dernier fichier écrit — pendant des semaines, jusqu’à ce qu’un lecteur demande pourquoi rien de nouveau n’apparaît. Un déploiement régénère le sitemap sans aucune URL, ou avec le nom d’hôte de préproduction dans chacune, et le trafic venu des moteurs de recherche baisse assez lentement pour que personne ne fasse le lien avec la mise en production. Un export destiné à un partenaire est coupé à mi-chemin, et son import échoue dans la nuit.

Dans tous ces cas, le serveur répond 200 OK. Pingsured analyse le XML et vérifie ce qu’il contient.

Que vérifier ?

Un flux RSS :

La deuxième ligne échoue lorsque l’élément le plus récent a plus de deux jours — réglez-la sur votre rythme de publication. Pour un flux Atom, les mêmes vérifications portent sur /feed/entry et /feed/updated.

Un sitemap :

La première repère un sitemap qui a perdu ses pages ; la seconde, un sitemap qui envoie les moteurs de recherche vers le mauvais hôte.

L’espace de noms que déclare un sitemap ou un flux Atom n’a pas besoin de figurer dans l’expression : /urlset/url correspond tel quel.

Les dates dans les flux

Les opérateurs d’âge lisent les formats de date qu’utilisent les flux :

• Atom et la plupart des API XML : ISO 8601, par exemple 2026-10-05T14:30:00Z ;
• RSS : Mon, 05 Oct 2026 14:30:00 +0000, ou avec GMT à la place du décalage.

Le jour doit s’écrire sur deux chiffres. Un flux qui écrit Mon, 5 Oct 2026 n’est pas reconnu, et la vérification échoue avec « not a recognised timestamp » au lieu de réussir — vous le voyez donc dès la première vérification, et non le jour où le flux se fige.

Pourquoi surveiller vos flux avec Pingsured

• Un fichier cassé échoue de lui-même. Une réponse qui n’est pas du XML bien formé fait échouer toutes les vérifications XML du ping : un export tronqué est signalé sans qu’il faille écrire une vérification pour ce cas.
• La fraîcheur tient en une ligne. Pas de script qui télécharge le flux, analyse la date et devrait lui-même être surveillé.
• XPath tel que vous le connaissez, avec nombres, comparaisons de texte et expressions régulières, et jusqu’à 16 vérifications par ping.
• Chaque emplacement séparément. Un flux servi par un CDN peut être à jour sur un nœud et périmé sur un autre ; vérifier depuis plusieurs emplacements montre lequel.
• Une vérification, pas un robot d’exploration. Chaque ping est une requête à l’intervalle que vous choisissez, identifiée par son User-Agent : la charge sur votre serveur est connue d’avance.

Limites à connaître

• Le corps de la réponse est lu jusqu’à 1 Mo, et un XML coupé à cette limite n’est plus bien formé — la vérification échoue. Un grand sitemap est généralement découpé en plusieurs fichiers sous un index de sitemaps : vérifiez l’index et l’un des petits fichiers, pas un sitemap de 10 Mo.
• Les vérifications envoient des requêtes GET ou HEAD : les services XML qui exigent une requête POST, comme SOAP, ne peuvent pas encore être vérifiés.