Avec WordPress, nginx et The SEO Framework, il peut arriver que l’URL /sitemap.xml renvoie une erreur 404 Not Found. Le plugin est actif, les permaliens fonctionnent, mais le sitemap refuse de s’afficher. Classique. Agaçant. Très nginx.
Dans la plupart des cas, The SEO Framework n’est pas le coupable. Le problème vient de la configuration nginx : une règle intercepte les fichiers .xml avant que WordPress puisse générer le sitemap virtuel.
Pourquoi sitemap.xml peut renvoyer une 404 sous nginx
The SEO Framework génère son sitemap dynamiquement. Cela signifie que /sitemap.xml n’est pas forcément un vrai fichier présent sur le disque. C’est une URL virtuelle servie par WordPress.
Avec Apache, WordPress peut souvent gérer ce type de réécriture via .htaccess. Avec nginx, c’est différent : il n’y a pas de fichier .htaccess lu dossier par dossier. Les règles doivent être écrites dans le server block nginx.
Si nginx tente de servir /sitemap.xml comme un fichier statique réel, il cherche un fichier nommé sitemap.xml à la racine du site. S’il n’existe pas, nginx renvoie une 404 avant même que WordPress puisse répondre.
Tester le sitemap avec curl
Commencez par tester l’URL du sitemap :
curl -I https://www.example.com/sitemap.xmlLangage du code : JavaScript (javascript)Une réponse correcte ressemble à ceci :
HTTP/2 200
content-type: text/xml; charset=UTF-8Langage du code : HTTP (http)Si vous obtenez une 404, testez aussi l’endpoint alternatif proposé par The SEO Framework :
curl -I https://www.example.com/sitemap.xml-altLangage du code : JavaScript (javascript)Si /sitemap.xml-alt fonctionne mais pas /sitemap.xml, vous avez presque certainement une règle nginx qui intercepte les fichiers .xml.
Vérifier la règle WordPress principale
Votre server block nginx doit contenir une règle capable d’envoyer les URLs non trouvées vers WordPress :
location / {
try_files $uri $uri/ /index.php?$args;
}Langage du code : PHP (php)Cette directive dit à nginx : sers le fichier s’il existe, sers le dossier s’il existe, sinon passe la requête à WordPress. Sans cette règle, les permaliens WordPress et les endpoints virtuels comme le sitemap peuvent casser.
Après modification, testez nginx :
sudo nginx -tPuis rechargez le service :
sudo systemctl reload nginxCorriger la vraie cause : les locations XML
Le cas le plus fréquent est une location regex qui regroupe les fichiers statiques, comme ceci :
location ~* \.(?:css|js|jpg|jpeg|gif|png|webp|avif|ico|svg|xml)$ {
expires 30d;
access_log off;
}Cette règle paraît innocente. Pourtant, elle capture aussi /sitemap.xml. nginx traite alors le sitemap comme un fichier statique. Comme le fichier n’existe pas physiquement, la réponse peut devenir une 404.
La correction durable consiste à retirer xml de cette location :
location ~* \.(?:css|js|jpg|jpeg|gif|png|webp|avif|ico|svg)$ {
expires 30d;
access_log off;
}Faites la même vérification pour xsl si le sitemap s’affiche en page blanche ou sans style. The SEO Framework peut utiliser une feuille XSL pour présenter le sitemap dans le navigateur.
Trouver les règles nginx qui ciblent XML
Pour inspecter toute la configuration nginx active :
sudo nginx -T | grep -Ei "xml|xsl|sitemap|location|try_files|rewrite"Langage du code : JavaScript (javascript)Si vous voyez une location comme celle-ci, elle mérite votre attention :
location ~* \.(xml|xsl)$ {
...
}Ou une règle plus large :
location ~* \.(?:css|js|png|jpg|jpeg|gif|svg|webp|avif|xml|xsl)$ {
...
}Dans ce cas, retirez xml et xsl, ou créez des exceptions précises avant la règle statique.
Option : créer une exception pour sitemap.xml
Si vous ne pouvez pas modifier la règle statique globale, vous pouvez ajouter une exception exacte avant la location regex :
location = /sitemap.xml {
try_files $uri /index.php?$args;
}Langage du code : PHP (php)Cette règle renvoie /sitemap.xml vers WordPress si aucun fichier physique n’existe. Elle est plus propre qu’une redirection permanente vers une URL interne avec des paramètres.
Si vous utilisez aussi le fichier XSL du sitemap, ajoutez l’exception correspondante si nécessaire :
location = /sitemap.xsl {
try_files $uri /index.php?$args;
}Langage du code : PHP (php)Gardez toutefois en tête que la meilleure correction reste de ne pas capturer .xml avec une règle statique trop large.
Ancienne méthode : rewrite vers the_seo_framework_sitemap
On trouve encore parfois cette ancienne directive :
location = /sitemap.xml {
rewrite ^/sitemap.xml$ "/?the_seo_framework_sitemap=xml" permanent;
}Langage du code : PHP (php)Elle pouvait dépanner, mais je ne la recommande plus comme solution principale. Une redirection permanente peut créer du cache indésirable côté navigateur, CDN ou moteur de recherche. Elle masque aussi le vrai problème : nginx ne laisse pas WordPress traiter l’endpoint virtuel.
Préférez donc une correction de la location nginx, ou une exception avec try_files.
Vérifier les permaliens WordPress
Si nginx est correct mais que le sitemap reste introuvable, régénérez les règles de réécriture WordPress :
wp rewrite flush --hardAvec nginx, --hard ne modifie pas un .htaccess comme sur Apache, mais la commande reste utile pour rafraîchir les règles internes de WordPress.
Vous pouvez aussi passer par l’admin WordPress : Réglages → Permaliens, puis enregistrer sans rien changer.
Pour d’autres commandes WP-CLI utiles lors d’un audit WordPress, vous pouvez consulter l’article sur la liste des articles publiés avec WP-CLI. C’est le même esprit : diagnostiquer vite, proprement, sans cliquer partout.
Vérifier les conflits de sitemaps
WordPress possède son propre sitemap natif depuis WordPress 5.5, accessible généralement via /wp-sitemap.xml. D’autres plugins SEO peuvent aussi générer leur propre sitemap, par exemple Yoast SEO, Rank Math ou All in One SEO.
Évitez d’avoir plusieurs plugins SEO qui tentent de gérer le sitemap en même temps. Choisissez une source principale, puis désactivez les autres sitemaps. Sinon, vous risquez les redirections étranges, les 404 intermittentes, ou les soumissions inutiles dans Search Console.
Testez les endpoints principaux :
curl -I https://www.example.com/sitemap.xml
curl -I https://www.example.com/wp-sitemap.xml
curl -I https://www.example.com/sitemap_index.xmlLangage du code : JavaScript (javascript)Vous devez savoir quel sitemap vous voulez soumettre à Google. Si vous utilisez The SEO Framework, gardez généralement /sitemap.xml comme référence.
Vérifier robots.txt
Une fois le sitemap fonctionnel, vérifiez que robots.txt le déclare correctement :
curl https://www.example.com/robots.txtLangage du code : JavaScript (javascript)Vous pouvez y ajouter une ligne de ce type :
Sitemap: https://www.example.com/sitemap.xmlLangage du code : JavaScript (javascript)Google peut découvrir un sitemap via Search Console, mais aussi via une directive Sitemap: dans robots.txt. Utilisez une URL absolue, canonique, avec le bon protocole et le bon domaine.
Si votre site force le www, déclarez la version www. Si votre site fonctionne sans www, déclarez la version sans www. Même combat pour HTTPS. Les sitemaps aiment la précision, pas l’à-peu-près.
Vider les caches après correction
Après avoir modifié nginx ou les permaliens, purgez les caches concernés :
- cache page WordPress ;
- cache objet Redis ou Memcached ;
- cache nginx fastcgi, si utilisé ;
- cache hébergeur ;
- cache Cloudflare ou autre CDN.
Testez ensuite sans cache navigateur :
curl -I -H "Cache-Control: no-cache" https://www.example.com/sitemap.xmlLangage du code : JavaScript (javascript)Si Cloudflare est devant le site, vérifiez aussi les en-têtes :
curl -I https://www.example.com/sitemap.xml | grep -Ei "HTTP|cf-cache-status|cache-control|content-type|location"Langage du code : JavaScript (javascript)Soumettre le sitemap dans Google Search Console
Quand /sitemap.xml répond bien en 200, soumettez l’URL dans Google Search Console :
- ouvrez la propriété du site ;
- allez dans Sitemaps ;
- soumettez
sitemap.xml; - vérifiez la date de dernière lecture ;
- corrigez les éventuelles erreurs d’exploration.
Soumettre un sitemap ne garantit pas l’indexation. En revanche, cela aide Google à découvrir les URLs canoniques importantes du site, surtout après une refonte, une migration ou une grosse republication d’articles.
Checklist de correction
- Tester
/sitemap.xmlaveccurl -I. - Tester
/sitemap.xml-altpour confirmer un problème nginx. - Vérifier la règle
try_files $uri $uri/ /index.php?$args;. - Retirer
xmldes locations statiques nginx trop larges. - Vérifier aussi
xslsi le sitemap s’affiche mal. - Éviter les redirections permanentes vers des paramètres internes.
- Rafraîchir les permaliens WordPress.
- Vérifier les conflits avec le sitemap natif WordPress ou un autre plugin SEO.
- Déclarer le sitemap canonique dans
robots.txt. - Purger les caches WordPress, nginx et CDN.
- Soumettre le sitemap dans Google Search Console.
Conclusion
Si le sitemap de The SEO Framework renvoie une 404 sous nginx, ne cherchez pas d’abord un fichier sitemap.xml manquant. Il n’est pas forcément censé exister physiquement. Le sitemap est généré dynamiquement par WordPress.
La correction propre consiste à laisser nginx transmettre cette URL virtuelle à WordPress. Vérifiez donc try_files, retirez xml des règles statiques trop larges, purgez les caches, puis testez avec curl. Une fois le sitemap en 200, vous pouvez le soumettre sereinement dans Search Console.
Comme souvent avec nginx, le problème n’est pas que le serveur ne sait pas quoi faire. C’est qu’il fait exactement ce qu’on lui a demandé. Même quand on aurait préféré qu’il s’abstienne.
