Distinguer trois pannes avant de régénérer le sitemap
Votre sitemap WordPress renvoie une erreur, n’est pas reconnu par la Search Console ou contient des pages introuvables. Ces situations demandent des corrections différentes. Un fichier impossible à récupérer, un XML mal formé et des URL de contenu qui échouent ne se réparent pas en cliquant tous sur un même bouton de régénération.
Le résultat recherché est un fichier accessible et lisible, produit par le bon système, qui signale des adresses publiques cohérentes. Sa réussite de lecture ne prouve pas que toutes les pages seront indexées. Un sitemap aide à découvrir les URL ; il ne remplace ni leur contenu, ni leurs permissions, ni la décision du moteur.
Relevez l’adresse exacte du sitemap, le message reçu, l’heure et le dernier changement du site. Gardez un sous-sitemap touché et quelques URL de contenu comme témoins. Avant une modification de configuration, conservez les valeurs initiales et la sauvegarde adaptée. Pour un essai de composants, utilisez une copie dont les envois, paiements et synchronisations sont neutralisés.
Identifier le générateur et son adresse réelle
WordPress possède une génération native habituellement accessible à wp-sitemap.xml sous l’adresse publique de l’installation. Un gestionnaire SEO peut fournir une autre adresse et remplacer ce mécanisme. Retrouvez le système réellement actif avant d’ajouter une extension : deux générateurs ne corrigent pas un défaut de routage et compliquent le suivi des fichiers envoyés.
Si Yoast SEO gère déjà le site, ouvrez l’adresse fournie par sa fonction XML plutôt que de deviner un nom de fichier. Notez aussi les références Sitemap présentes dans robots.txt et les envois déjà enregistrés dans la Search Console. Elles peuvent conserver une ancienne adresse après une migration.
Sur WordPress.com, le service fournit un sitemap à sitemap.xml. Le parcours documenté passe par Jetpack, Traffic, ou Jetpack, Settings, onglet Traffic, section Sitemaps. Si la fonction manque alors que le site doit être public, vérifiez Generate XML Sitemaps et consultez l’adresse proposée. Gardez l’état initial pour annuler ce seul réglage. Une installation auto-hébergée avec un autre générateur ne doit pas recevoir cette procédure comme s’il s’agissait d’un menu natif universel.
Contrôler l’index et ses sous-sitemaps séparément
Un index de sitemaps répertorie d’autres fichiers XML. Il ne liste pas nécessairement les pages directement. Ouvrez l’index sans connexion, puis suivez un sous-sitemap d’articles ou de pages. Un index accessible peut pointer vers un sous-fichier en erreur ; inversement, l’ancien index envoyé à Google peut être faux alors que le générateur actuel fonctionne.
Dans chaque sous-sitemap témoin, choisissez une URL de contenu et ouvrez-la. Notez séparément les trois réponses : index, sous-sitemap et page. Cette méthode donne une localisation du défaut avant de toucher aux réglages. N’interprétez pas une liste de sous-fichiers comme une preuve que les pages individuelles sont absentes du sitemap.
Une présentation brute de XML n’est pas forcément une panne. Un navigateur peut afficher un arbre de balises ou signaler l’absence de style. Recherchez surtout une erreur de syntaxe, du HTML à la place du fichier ou une réponse de protection. Si l’affichage semble vide, consultez la réponse ou le code source avant de supprimer des fichiers : la feuille de présentation peut avoir un problème différent de celui des données.
Lire le statut et les en-têtes avec un GET borné
Ce contrôle facultatif demande un terminal et l’adresse publique exacte. La commande ci-dessous reçoit les en-têtes sans afficher le corps du sitemap. Elle effectue un GET, ne fournit pas d’identifiants et ne suit pas automatiquement une redirection. Remplacez le domaine et le chemin fictifs par le fichier réellement utilisé.
Sous Linux, employez la commande telle qu’adaptée. Sous Windows, utilisez curl.exe et remplacez /dev/null par NUL. Le paramètre -q reste en première position pour éviter une configuration personnelle inattendue. Les délais bornent l’attente du client, sans promettre d’arrêter un travail déjà commencé sur le serveur.
Un 200 contenant une page de connexion reste une mauvaise réponse pour ce fichier : confirmez donc aussi le corps dans le navigateur. Un 404 appelle la vérification de l’adresse et du générateur. Un 403, un défi ou une erreur serveur conduit aux journaux de la couche concernée. Pour les sitemaps Yoast, un en-tête noindex sur le XML lui-même est prévu par le code ; ne le confondez pas avec noindex sur les pages listées.
Lisez le statut HTTP lui-même : sans option spécifique, curl peut se terminer sans erreur de transfert même après une réponse 403. Sa fin d’exécution ne certifie donc ni un 200, ni un XML utilisable.
curl -q --silent --show-error --connect-timeout 5 --max-time 15 --dump-header - --output /dev/null 'https://exemple.invalid/wp-sitemap.xml'Vérifier le système natif sans rendre un site privé public
Si le cœur WordPress est le générateur prévu, son activation dépend notamment du réglage de visibilité blog_public et peut être modifiée par du code. Un site volontairement non public peut donc ne pas fournir le sitemap attendu. Vérifiez Réglages, Lecture, mais ne retirez pas l’exclusion d’une préproduction uniquement pour obtenir un fichier XML.
Si le site est bien destiné au public et que le réglage natif est resté incorrect, notez sa valeur initiale, décochez Demander aux moteurs de recherche de ne pas indexer ce site, puis cliquez sur Enregistrer les modifications et rouvrez le sitemap. S’il reste absent, recherchez le composant qui désactive la génération native ou la remplace. Forcer le filtre d’activation à true ne corrige pas le rôle de cet autre système et peut créer un conflit de responsabilité.
Le rendu natif demande aussi SimpleXML, une extension de PHP. Si WordPress signale explicitement son absence, faites activer cette extension pour le PHP qui sert le domaine avec l’hébergement. Le PHP du terminal peut être différent. Une extension WordPress de sitemap n’installe pas cette capacité PHP manquante. Après intervention, contrôlez l’index et un sous-sitemap ; si un essai de réglage est abandonné, rétablissez sa seule valeur initiale.
Rétablir une route de sitemap sur un indice de réécriture
Ce parcours convient si le générateur est actif et si l’erreur 404 paraît liée au routage, notamment après un changement d’installation. Pour le système natif, comparez par exemple /wp-sitemap.xml à /?sitemap=index si le site public est à la racine. Pour un site public en sous-dossier, conservez ce sous-dossier dans les deux adresses. Si l’une répond et l’autre échoue, vous obtenez un indice de réécriture ; cela ne justifie pas de changer tous les permaliens du site. Avec des permaliens simples, une adresse comportant ?sitemap=index peut être normale : utilisez l’adresse réellement annoncée par ce générateur avant de qualifier la route lisible de panne.
Avant d’ouvrir les réglages, relevez leur structure actuelle et gardez une copie privée du .htaccess concerné si Apache l’utilise, avec le moyen de le restaurer. Ouvrez Réglages, Permaliens une seule fois : dans le cœur actuel, cette ouverture régénère déjà les règles. Ne modifiez ni la structure ni les bases, et ne répétez pas les enregistrements en espérant un effet supplémentaire.
Reprenez ensuite les mêmes adresses de sitemap et deux pages ordinaires. Si le défaut persiste, examinez la configuration du serveur adaptée au générateur. Sur Nginx, modifier .htaccess ne répare pas ses règles. Évitez les blocs de configuration génériques qui écraseraient d’autres chemins. Si un fichier a été modifié pendant cette intervention et provoque une régression, rétablissez ce fichier depuis la copie initiale.
Rétablir la fonction XML de Yoast déjà présent
Cette approche convient si Yoast SEO est le générateur choisi et déjà installé. Au 3 novembre 2026, la version du répertoire est 28.8, par Yoast, avec WordPress 7.0 et PHP 7.4 minimum, et un test déclaré jusqu’à WordPress 7.1.4. La fonction XML est disponible gratuitement ; aucun achat Premium n’est nécessaire pour l’activer.
Le résultat attendu est l’accès à son index et à ses sous-sitemaps, avec les familles de contenu prévues. Gardez l’état du réglage avant de le changer et n’activez pas un autre générateur en parallèle. Si vous abandonnez cet essai, remettez le seul état initial et vérifiez quelle adresse reste en service.
- Dans le tableau de bord, ouvrez Yoast SEO, Settings, puis Site features.
- Sous Technical SEO, retrouvez XML sitemaps et activez-le si cette génération est bien celle attendue.
- Attendez la confirmation d’enregistrement ou enregistrez si votre interface le demande, puis utilisez View the XML sitemap.
- Ouvrez un sous-sitemap pertinent et une URL de page qu’il contient.
- Si un sous-sitemap reste en 404, vérifiez aussi qu’il existe des contenus publiés correspondants avant d’attribuer toute la panne au serveur.
Corriger une sortie parasite avant la déclaration XML
Une erreur indiquant que la déclaration XML n’est pas au début du document peut venir d’espaces, d’un message PHP ou d’une autre sortie ajoutée par un composant. Ouvrez le code source de la réponse et regardez ce qui précède la déclaration. Notez l’erreur et la ligne signalée ; ne publiez pas un avertissement contenant des chemins privés.
Sur une copie reproduisant le défaut, commencez par le composant récemment modifié ou celui désigné par le message. Dans Extensions, Extensions installées, désactivez ce seul composant, relisez le même sitemap, puis réactivez-le pour comparer. Gardez sa configuration et ses dépendances ; ne le supprimez pas. Si le thème est en cause, faites contrôler sa sortie et les fichiers personnalisés.
La correction doit supprimer la sortie parasite à son origine, avec le fichier initial conservé. Masquer un avertissement ne répare pas nécessairement l’erreur qui le déclenche. Ne nettoyez pas automatiquement tous les fichiers PHP pour enlever des caractères supposés fautifs. Après correction sur copie, vérifiez le XML complet et les fonctions du composant, puis préparez une intervention limitée. Le retour consiste à rétablir le seul fichier ou réglage modifié.
Distinguer la présentation du XML et sa validité
Une feuille XSL sert à présenter le XML de façon lisible dans le navigateur. Si cette feuille échoue, une page peut paraître vide ou mal présentée alors que les données restent disponibles. Vérifiez la réponse source et l’erreur exacte avant de traiter cette situation comme une absence de sitemap. Une modification esthétique ne corrige pas une balise mal fermée.
Pour un sitemap XML, le protocole définit une structure et un encodage UTF-8. Un fichier de pages contient notamment les éléments urlset, url et loc ; un index de sitemaps a une autre structure. Les adresses et leurs caractères réservés doivent être échappés correctement par le générateur. Ne remplacez pas tous les caractères & à la main dans une sortie dynamique : corrigez le composant qui produit les valeurs.
Dans un sitemap de pages, la date facultative lastmod décrit la modification réelle de la page indiquée, pas chaque lecture du XML. Dans un index, lastmod décrit au contraire la dernière modification du fichier de sitemap référencé. Ne corrigez pas ces deux niveaux comme s’ils représentaient la même date. Conservez le message de validation pour le mainteneur d’un générateur personnalisé. Le but est une sortie durablement valide après les prochains ajouts de contenu, pas un fichier corrigé une seule fois puis écrasé à sa prochaine génération.
Corriger la source des URL listées qui échouent
Prenez quelques URL signalées en erreur et comparez leur contenu attendu à leur réponse réelle. Une adresse supprimée, une ancienne variante qui redirige et une page encore utile mais en panne ne demandent pas la même décision. Notez le statut final, la présence d’une redirection et le domaine avant de modifier quoi que ce soit.
Si une page utile renvoie une erreur, rétablissez d’abord cette page ou son routage ; la retirer du sitemap ne répare pas son accès. Si elle a réellement été remplacée, faites correspondre les liens et le générateur à l’adresse finale retenue. Si elle n’a plus de raison d’exister, conservez le traitement prévu pour sa suppression au lieu de recréer un contenu vide uniquement pour obtenir un 200.
Après migration, des adresses de préproduction ou un ancien protocole peuvent révéler une configuration incohérente. Contrôlez Réglages, Général et les choix du gestionnaire SEO, avec un retour d’accès préparé avant toute correction d’adresse. Ne lancez pas un remplacement SQL global dans les données sérialisées. La sortie dynamique doit être corrigée par sa source ; éditer un XML généré à la main laisse la cause en place.
Réexaminer les exclusions et les pages manquantes
Une page absente du sitemap n’est pas forcément perdue. Elle peut être privée, non publiée, redirigée ou volontairement exclue par le générateur. Vérifiez son statut et son intention éditoriale avant de modifier sa visibilité. Un espace client ou un contenu de préproduction ne doit pas être rendu public pour compléter une liste.
Dans Yoast existant, les choix d’apparition dans les résultats participent aussi à la sélection du sitemap. Pour une page publique exclue par erreur, ouvrez sa boîte Yoast SEO, Advanced, puis le choix Allow search engines to show this content in search results. Sélectionnez Yes si cette exclusion était non voulue, enregistrez la page et contrôlez ensuite sa réponse et le sitemap. Pour un type entier, examinez le type exact dans Yoast SEO, Settings, Content types, avec la portée collective clairement validée.
Si une exclusion est volontaire, conservez-la. Si l’adresse canonique vise une autre page, vérifiez ce choix plutôt que de forcer les deux variantes dans le fichier. Gardez les valeurs initiales pour annuler l’essai. Retirer une URL du sitemap ne garantit pas son retrait des résultats : les consignes de page et les contrôles d’accès répondent à d’autres besoins.
Vérifier la pagination, le volume et le cache
Un index peut répartir les pages entre plusieurs sous-sitemaps. Le protocole limite un fichier de sitemap à 50 000 URL et 50 Mo sans compression ; les générateurs peuvent choisir des lots plus petits. Le cœur WordPress utilise 2 000 URL par fichier par défaut, avec une valeur filtrable. Ne concluez pas à des pages manquantes après avoir lu seulement le premier lot.
Pour le sitemap fourni par WordPress.com, la documentation consultée en novembre 2026 annonce une limite de 1 000 articles récemment mis à jour. Cette limite propre au service ne remplace pas celle du protocole et ne décrit pas tous les générateurs SEO installables. Si un ancien article manque, vérifiez d’abord quel système produit le fichier ; son absence ne prouve ni une suppression de contenu ni un noindex.
Si un sous-fichier volumineux dépasse les ressources disponibles, relevez lequel échoue et son temps de réponse. Faites examiner son découpage et la requête du générateur sur copie. N’augmentez pas toutes les limites PHP sans comprendre la cause, et ne rassemblez pas tous les lots dans un seul fichier pour simplifier l’affichage.
Un cache peut maintenir un ancien index ou un sous-sitemap après correction. Invalidez les seules réponses concernées par la procédure du système existant, puis vérifiez leur contenu une fois reconstituées. Si des URL retirées reviennent, cherchez le composant ou la synchronisation qui les réintroduit. L’index et ses sous-fichiers doivent rester cohérents entre eux, y compris après une publication, une modification et une suppression normales.
Lire le bon niveau d’erreur dans la Search Console
Dans la propriété correspondant au domaine final, ouvrez Sitemaps et sélectionnez l’envoi concerné. Relevez l’état et la date de dernière lecture. Impossible de récupérer le sitemap renvoie à son accès ; un nombre d’erreurs d’analyse concerne un fichier reçu mais mal traité. Une erreur sur une page listée ne signifie pas nécessairement que tout le sitemap est illisible.
Après correction, vérifiez d’abord la réponse publique. Avec les droits de propriétaire nécessaires, renvoyez l’adresse valide depuis Ajouter un sitemap, puis Envoyer, lorsque le précédent envoi a échoué ou que le changement le justifie. Ne transmettez pas une URL privée de prévisualisation ou un ancien domaine pour essayer de faire disparaître l’erreur.
Un état Opération effectuée confirme que Google a récupéré et lu le fichier. Il ne certifie pas l’indexation des URL listées. Si une ancienne adresse a été remplacée, documentez l’envoi actuel ; supprimer l’ancienne entrée du rapport ne fait pas oublier à Google les pages déjà découvertes. Contrôlez ensuite quelques pages importantes par l’inspection d’URL pour distinguer leur état de celui du fichier XML.
Valider la réparation et garder un seul responsable du sitemap
La réparation est cohérente lorsque l’index et les sous-sitemaps témoins répondent correctement, que le XML ne contient plus la sortie parasite et que les pages choisies sont accessibles à leur adresse finale. Vérifiez aussi une exclusion volontaire et un contenu récemment modifié. Conservez les observations avant et après, avec le générateur et le réglage exact touché.
Retirez les seuls ajustements temporaires devenus inutiles et rétablissez les composants utilisés pour la comparaison. Gardez les exclusions encore justifiées et les protections de préproduction. Après la prochaine publication prévue, contrôlez que le système met à jour sa sortie sans intervention manuelle ; une copie figée de XML ne doit pas devenir le correctif permanent d’une génération cassée.
Pour poursuivre avec un mainteneur, transmettez l’index, le sous-sitemap fautif, quelques URL de contenu, les statuts, le message XML, les versions et l’heure de l’échec. Masquez chemins privés et informations sensibles. Précisez si le site est auto-hébergé, sur WordPress.com ou dans un multisite. Ce dossier permet de corriger l’accès, la génération ou les données au bon endroit, sans promettre que la lecture réussie suffira à obtenir un classement.
