Un sitemap bourré d’adresses qui renvoient une page blanche, voilà une tuile que personne ne souhaite découvrir un lundi matin dans la Search Console. Le réflexe courant consiste à pointer le plugin, à le désactiver puis à le réactiver en espérant un miracle. Ça marche parfois. Mais la plupart du temps, le coupable se cache ailleurs, dans une règle serveur écrite des mois plus tôt ou dans une case décochée au fond d’un onglet. Le diagnostic tient en quelques tests simples, à condition de savoir dans quel ordre les mener.
Un sitemap en erreur : vérifier ce que Google reçoit vraiment
Avant de toucher au moindre réglage, il faut regarder ce que le serveur balance réellement quand on demande le fichier XML. Ouvrez l’adresse de votre sitemap dans un onglet neuf, sans cache, et observez le code de réponse dans les outils de développement. Une 404 franche, un contenu vide ou une redirection vers l’accueil racontent trois histoires différentes.
Confondre les trois fait perdre un temps fou. Sur un site qui utilise The SEO Framework, un détail revient souvent dans les forums techniques comme dedieonet.fr le documente : l’endpoint par défaut saute, mais un endpoint alternatif répond normalement. C’est ce décalage qui met sur la piste.
La méthode par élimination démarre là. Si l’adresse de secours fonctionne alors que l’adresse principale échoue, le plugin n’est pas en cause, il génère bien son XML. Le problème se situe en amont, entre la requête du visiteur et l’exécution de WordPress. Cette comparaison coûte trente secondes. Elle oriente tout le reste du diagnostic.
La règle nginx qui avale vos fichiers .xml avant WordPress
Sur un serveur nginx mal configuré, une directive peut intercepter toutes les requêtes vers des fichiers statiques avant que WordPress n’ait la parole. Le sitemap généré dynamiquement n’existe pas comme fichier sur le disque, donc nginx cherche, ne trouve rien, et renvoie une 404 propre et nette.
SkyMinds décrit ce cas de figure comme une cause fréquente de panne avec The SEO Framework. Le symptôme est reconnaissable entre tous : n’importe quelle URL se terminant par .xml casse, même sans rapport avec le référencement.
La correction tient dans une ligne du bloc server. Remplacez la règle de location par une directive qui sert le fichier ou le dossier s’il existe, puis passe la main à WordPress dans le cas contraire. Le sitemap virtuel retrouve alors son chemin normal. Pensez à recharger nginx après modification, sinon la nouvelle directive dort dans le fichier sans jamais s’appliquer.
Quelques indices confirment cette piste plutôt qu’une autre. Le sitemap alternatif en .xml-alt répond correctement, ce qui prouve que la génération côté WordPress fonctionne toujours. Des fichiers statiques comme un robots.txt ou une image passent sans encombre, mais tout ce qui finit en .xml bloque.
Pourquoi les autres URL du site restent-elles accessibles alors que le sitemap tombe ? Un test sur un fichier .xml quelconque placé à la racine renvoie la même 404. Les logs nginx montrent une tentative de lecture sur le disque, suivie d’un échec immédiat, sans passage par PHP. Ces signaux serveur ne trompent pas.
All in One SEO : la case décochée et les URL qui disparaissent sans bruit
Autre scénario, autre logique. Dans les réglages du plugin All in One SEO, un interrupteur nommé « Activer le Sitemap » se trouve sous Tout en un SEO » Sitemaps. Décoché, il coupe la génération et l’adresse renvoie une 404 Page non trouvée.
Une mise à jour, une restauration de sauvegarde ou une manipulation malheureuse suffisent à le désactiver, et rien dans l’interface ne vous alertera. Vérifiez cette case avant même de creuser côté serveur. Elle coûte cinq secondes à contrôler.
Le plugin réserve aussi des surprises plus discrètes. Il n’intègre pas au sitemap le contenu défini sur Noindex : une page volontairement exclue des résultats disparaît de la carte sans jamais produire d’erreur. Ce comportement est attendu, mais il déroute quand on s’attend à retrouver la page.
Pour le sitemap d’actualités, la règle se durcit encore, puisque le contenu doit avoir été publié dans les dernières 48 heures pour être inclus. Une URL récente peut donc s’évaporer du flux sans le moindre 404, simplement parce que la fenêtre est passée. Sur ce point, voir aussi notre article sur site invisible google.
Cette distinction change tout dans la façon de chercher. Une URL absente du sitemap n’est pas une URL cassée : ce sont deux problèmes séparés, avec deux méthodes de résolution différentes. Mélanger les deux revient à chercher ses clés sous le canapé alors qu’elles sont dans la poche.
Tester les URL une par une, sans se fier au fichier XML
Un sitemap n’est qu’une déclaration d’intention, pas une preuve que les pages répondent. Il faut donc sortir les adresses du fichier et les interroger une à une, en relevant le code de statut de chacune. Un tableur suffit pour commencer, avec une colonne URL et une colonne code. L’exercice révèle vite des schémas : une catégorie entière tombée après une refonte, une série d’articles migrés vers une nouvelle arborescence, un paramètre oublié dans une règle de réécriture.
Le piège classique vient des redirections en chaîne. Une adresse peut renvoyer une redirection vers une autre redirection avant d’atterrir sur une 404, et un simple coup d’œil à la première réponse donnera l’illusion que tout va bien. Suivez le chemin complet, pas seulement la première étape.
Pour les gros volumes, un script qui parcourt la liste et note les codes fait le travail en quelques minutes. Commencez toujours par un échantillon manuel : c’est en regardant les cas isolés qu’on comprend la logique derrière la casse.
Franchement, la tentation est grande de tout réparer à coups de redirections dans le fichier .htaccess. Ça fonctionne, jusqu’au jour où la liste dépasse la centaine de lignes et où plus personne n’ose y toucher. Mieux vaut corriger la cause, puis laisser Google oublier les vieilles adresses au fil de ses passages, plutôt que d’empiler des rustines.
Repérer les liens morts avant que le robot ne les trouve
La Search Console affiche les erreurs avec du retard, parfois plusieurs semaines après leur apparition. Ce décalage laisse le temps à un robot de visiter des pages cassées, de les signaler, et de dégrader la perception du site.
Un contrôle régulier du sitemap, disons une fois par mois, avec un test rapide des adresses nouvellement ajoutées, évite d’arriver devant le problème une fois qu’il est installé. La vérification ne prend pas longtemps quand elle devient une habitude.
Il existe un moyen encore plus simple de repérer une coupure : comparer le nombre d’URL listées dans le sitemap avec le nombre de pages réellement publiées. Un écart net, surtout s’il grandit d’un coup, signale une génération partielle ou un contenu qui n’arrive plus jusqu’au plugin.
Surveillez aussi les dates de dernière modification affichées dans le fichier. Un sitemap figé depuis des mois alors que vous publiez chaque semaine indique que quelque chose s’est enrayé en silence. Ce contrôle mensuel reste votre meilleure assurance.
Les robots ne sont pas les seuls à suivre ces liens. Un visiteur qui tombe sur une 404 depuis un vieux partage repart aussi vite qu’il est arrivé, et cette visite perdue ne se rattrape pas. Un lien mort dans un sitemap reste un lien mort quelque part sur le web, quelque part dans une conversation, quelque part dans un signet oublié.
La panne se répare toujours dans le bon ordre
La séquence compte plus que l’outil. On vérifie d’abord que le plugin génère bien son XML via un endpoint alternatif, on contrôle ensuite la case d’activation côté All in One SEO, puis on inspecte la règle nginx si les deux premières étapes n’ont rien donné. Cette progression évite de modifier une configuration serveur pour un problème qui tenait à un interrupteur mal placé.
L’erreur est fréquente, et coûteuse en temps. Une fois la cause identifiée, le correctif tient souvent en une ligne, et le sitemap repart comme si rien ne s’était passé. Reste une question à trancher : combien de temps laissez-vous une erreur dormir avant de la chercher vraiment ?