Un client m’a contacté : une page tout juste créée renvoyait vers une autre page de son site. En cherchant la cause, j’ai découvert un mécanisme de WordPress que je ne connaissais pas, et j’ai fini par développer un outil pour le maîtriser.
Le point de départ : l’appel d’un client
La dernière fois, un client m’a contacté pour un souci étonnant : une page qu’il venait de créer ne s’affichait pas. À la place, le visiteur était renvoyé vers une autre page du site.
Mon premier réflexe a été de réenregistrer les permaliens : dans les réglages, un simple clic sur « Enregistrer » suffit à régénérer les règles de réécriture d’URL, et cela règle souvent ce genre de souci. Sans effet. J’ai ensuite cherché un plugin de redirections : aucun n’était installé. Le plugin de SEO, lui, était bien présent, mais il ne semblait pas suivre les redirections non plus. Je n’avais plus de piste évidente.
Besoin d’un spécialiste WordPress pour votre projet ? Contactez-moi
Je soupçonnais alors le cache. J’ai ajouté un paramètre à l’adresse de la page : elle s’affichait. J’ai ensuite changé le slug de la nouvelle page : elle s’affichait aussi. Le problème venait donc de cette adresse précise, et non du cache.
Ma recherche : ce que j’ai découvert
Restait à comprendre pourquoi cette adresse posait problème, et je dois l’avouer : je ne savais pas que WordPress gardait un historique des anciens slugs.
À chaque changement de slug d’une page ou d’un article, WordPress enregistre l’ancien dans une donnée cachée, nommée _wp_old_slug. Quand quelqu’un arrive ensuite sur l’ancienne adresse (une erreur 404), WordPress retrouve le contenu grâce à cet historique et fait une redirection 301 vers la nouvelle URL.
C’est un mécanisme malin, qui protège les liens et le référencement sans aucune configuration. Mais c’est aussi une redirection que personne n’a décidée, et dont personne ne se souvient.
C’est exactement ce qui s’est produit chez mon client : le slug de la nouvelle page avait déjà servi à un autre contenu. WordPress se souvenait de cette ancienne adresse et envoyait les visiteurs vers l’autre page. Réutiliser le slug d’un ancien contenu est donc un piège à connaître.
Le constat : un historique invisible
J’ai ensuite cherché un moyen de consulter ces anciens slugs depuis l’administration de WordPress. Il n’y en a pas : ils ne s’affichent nulle part. Pour les voir, il faut passer par la base de données et écrire une requête SQL, ce qui n’est pas idéal quand on veut simplement répondre à un client.
Il manquait un outil pour rechercher un ancien slug, savoir à quel contenu il correspond, et décider de le garder ou de le supprimer.
La solution : TD Old Slug Manager
J’ai donc développé un petit plugin d’administration, TD Old Slug Manager, qui liste tous les anciens slugs d’un site et permet de les retrouver rapidement :
- Recherche sur l’ancien slug, le slug actuel, le titre ou l’ID du contenu. On peut aussi coller une URL complète : l’outil en extrait le dernier segment.
- Filtres par type de contenu, par correspondance exacte, ou pour ne voir que les entrées orphelines (celles dont le contenu n’existe plus).
- Lecture claire : le texte recherché est surligné, avec le contenu associé, son type et son statut.
- Suppression de la sélection, ou de tous les résultats d’une recherche, avec une confirmation avant.
Je l’ai voulu prudent : il ne supprime que des anciens slugs, vérifie les droits de l’utilisateur et un jeton de sécurité avant chaque suppression, et garde une trace dans le journal d’erreurs quand le mode debug de WordPress est actif.
Ce que j’en retiens
Ce dépannage m’a rappelé qu’un site WordPress garde de nombreuses traces discrètes de son histoire, et qu’elles finissent parfois par influencer son comportement sans que personne s’en aperçoive.
Supprimer un ancien slug supprime aussi la redirection qui lui correspond. Avant de nettoyer, je sauvegarde donc la base de données, je commence par les entrées orphelines (sans aucun risque pour les visiteurs), puis je trie les autres en vérifiant si ces anciennes adresses reçoivent encore des visites ou des liens.
Pour la méthode pas à pas, avec la requête SQL et les précautions à prendre, j’ai détaillé le sujet côté dépannage : Pourquoi une ancienne URL redirige encore sur votre site WordPress.
Si vous voyez des redirections inattendues sur votre site et que vous ne savez pas d’où elles viennent, contactez-moi : c’est le genre d’enquête que j’aime mener.