Un validateur de sitemap vérifie qu'un sitemap XML utilise la structure attendue et des valeurs de champs prises en charge. Screpy examine un document et signale les erreurs, avertissements et éléments de preuve pour corriger le générateur. Un résultat sans anomalie ne concerne que le périmètre vérifié : il ne prouve ni que les pages fonctionnent ni que Google les a indexées.
Choisissez le document à valider
Saisissez l'adresse publique exacte du XML, par exemple https://example.com/sitemap.xml, pour contrôler le fichier publié. Cette adresse fictive illustre le format. Une page d'accueil peut renvoyer du HTML ; utilisez Sitemap Checker pour trouver d'abord le sitemap.
Choisissez le XML collé pour vérifier une source avant publication ou examiner un document enregistré. Copiez le XML brut, pas le tableau mis en forme du navigateur. Aucun champ de téléversement de fichier n'est proposé. L'URL de base facultative fournit le contexte de comparaison des origines ; elle ne corrige pas les adresses relatives. Même avec https://example.com/ comme base, <loc>/products/</loc> nécessite une adresse HTTP ou HTTPS complète.
Sans URL de base, le contenu collé n'a pas de contexte d'origine pour cette comparaison. Sa structure et les valeurs prises en charge restent vérifiables.
Corrigez la racine, l'espace de noms et l'échappement XML
Un sitemap de pages nécessite une racine urlset dans l'espace de noms standard et un loc dans chaque url. Ce document fictif à une entrée montre la structure requise :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/products/blue-mug/</loc>
</url>
</urlset>
Conservez exactement l'URI de l'espace de noms, y compris http. Il identifie le vocabulaire XML ; le remplacer par https n'améliore pas la sécurité et modifie cet identifiant. Un index utilise une autre racine, expliquée plus bas. Le protocole Sitemaps définit les deux structures.
Dans le XML, écrivez le & d'une URL sous la forme &, par exemple ?color=blue&size=m. Corrigez l'échappement dans le générateur plutôt que de supprimer un paramètre nécessaire. Des balises de fermeture manquantes, un contenu non pris en charge ou une déclaration DOCTYPE peuvent interrompre le contrôle avant le rapport détaillé. Un contrôle échoué n'est pas une validation réussie.
Transformez chaque constat en correction de la source
Lisez ensemble les badges de résultat et de couverture. Le rouge indique les erreurs, le jaune les avertissements ou une couverture partielle, le vert l'absence de constats nécessitant votre attention dans le périmètre vérifié. Texte et icônes complètent les couleurs. Utilisez la preuve et la ligne de début de l'entrée pour retrouver son bloc XML, puis corrigez la source qui le génère.
| Constat | Exemple de problème | Correction de la source |
|---|---|---|
| Adresse invalide | /products/ ou loc vide |
Fournir l'URL HTTP ou HTTPS absolue prévue. |
| Valeur facultative invalide | lastmod à 2026-02-30 ou priority à 1.2 |
Corriger la valeur ou omettre un champ facultatif impossible à maintenir. |
| Champ répété | Deux champs loc dans une entrée |
Produire une seule valeur ; il s'agit d'une erreur. |
| Adresse répétée | Même adresse dans deux entrées | Dédupliquer la liste source ; il s'agit d'un avertissement. |
| Élément inattendu | priority dans une entrée d'index |
Conserver les champs adaptés au type de document. |
Le contrôle des doublons compare les chaînes d'adresse après retrait des espaces extérieurs. Il ne détermine pas si différentes URL partagent un contenu et ne choisit pas d'URL canonique. Une répétition dans un autre fichier dépasse aussi le périmètre de ce contrôle d'un document.
« Entrées à examiner » compte les entrées comportant des erreurs, pas tous les avertissements ou défauts du document. Ce nombre peut donc être nul malgré une erreur de racine ou d'espace de noms. Lisez les constats plutôt que d'utiliser cette mesure comme un score de validité. Plusieurs constats peuvent concerner la même entrée.
Vérifiez le sens de la date autant que son format
lastmod, changefreq et priority sont facultatifs dans un sitemap de pages. Leur absence n'est pas une erreur de champ. Si vous indiquez une date, utilisez une valeur valide telle que 2026-09-01 ou 2026-09-01T14:30:00Z. Un format plausible ne rend pas valide une date impossible.
Pour une page, lastmod doit refléter une modification significative, pas chaque reconstruction du sitemap. Un générateur qui remplace toutes les dates par celle d'aujourd'hui peut produire des données syntaxiquement valides mais trompeuses. Comparez la date source aux changements réels ; ce validateur ne vérifie pas l'historique des modifications.
Le guide des sitemaps de Google indique que Google utilise des dates de modification toujours exactes et vérifiables et ignore priority et changefreq. Corriger ces deux champs répare les métadonnées fournies ; cela n'améliore pas le classement à lui seul. S'ils sont conservés, la priorité doit être comprise entre 0 et 1 et la fréquence doit employer une valeur prise en charge en minuscules, comme weekly.
Lisez un index comme une liste de fichiers
Un sitemapindex contient des entrées sitemap. Chaque loc pointe vers un fichier de sitemap enfant ; le lastmod facultatif décrit la modification de ce fichier. Il ne décrit pas chaque page qu'il contient. Un index de trois fichiers possède donc trois entrées, pas trois pages du site.
Screpy valide l'index soumis lui-même et n'ouvre pas les fichiers enfants. Validez chaque fichier concerné séparément pour examiner une erreur à l'intérieur. Pour un inventaire téléchargeable, XML Sitemap Parser extrait les entrées sans transformer un index en liste combinée de pages.
Un avertissement d'origine compare le protocole, le nom d'hôte et le port de l'entrée à l'URL finale du document récupéré ou à la base du XML collé. Vérifiez un http inattendu, un autre hôte ou un port différent avant de changer les adresses. Une différence appelle un examen, pas un verdict automatique de soumission invalide.
Google autorise les soumissions de sitemaps intersites configurées avec la propriété appropriée ou des références de sitemap propres à chaque site. Cet outil ne vérifie pas ces réglages. Confirmez la configuration prévue avant de remplacer des adresses légitimes uniquement pour supprimer un avertissement.
Revérifiez le fichier corrigé dans le périmètre indiqué
Le protocole limite chaque fichier à 50 000 entrées et 50 MiB de contenu non compressé. Screpy accepte jusqu'à 256 KiB de XML collé ou 50 MiB de XML distant décodé. Ces limites mesurent des octets, pas des caractères.
La validation s'arrête à 50 000 entrées traitées ; le total complet peut rester inconnu et le caractère bien formé du XML non établi. Au maximum 1 000 lignes sont conservées et les limites de taille de réponse peuvent réduire davantage le résultat. Lire davantage d'entrées qu'il n'en apparaît ne rend pas la liste affichée complète. Vérifiez la couverture avant d'interpréter les totaux ou de partager le rapport.
CSV et TXT contiennent les entrées conservées ; JSON contient le rapport limité. Exporter un résultat partiel ne garantit pas un inventaire complet. Des éléments d'extension peuvent aussi entraîner une couverture partielle : l'outil vérifie les champs fondamentaux pris en charge, pas l'ensemble des schémas d'extension ni une conformité XSD complète.
Corrigez le générateur, le modèle ou les données source, régénérez le XML et contrôlez de nouveau l'adresse publiée corrigée. Modifier seulement le fichier généré peut être annulé à la prochaine reconstruction. Pour un grand fichier, validez séparément de plus petits sitemaps source et notez les contrôles achevés.
Enfin, examinez séparément le comportement des pages. Bulk HTTP Status Checker aide à contrôler les réponses et redirections des URL listées. Réussir les contrôles XML ne démontre ni le statut des pages, ni la canonicalisation, ni noindex, ni l'indexation. Après la soumission, consultez le traitement du sitemap et les preuves d'indexation de Google plutôt que de considérer ce rapport comme une preuve de visibilité dans les recherches.