Un cabinet d’architectes avait changé sa structure de permaliens trois fois en huit ans, chaque webmaster successif imposant sa préférence : d’abord /date/nom-du-projet/, puis /projets/nom-du-projet/, enfin /realisations/nom-du-projet/. Résultat : des liens partagés sur les réseaux sociaux, indexés par Google, ou glissés dans une plaquette commerciale imprimée, pointaient vers trois structures différentes selon leur ancienneté.
La solution évidente — une extension de redirections avec une ligne par URL — aurait demandé de lister manuellement plusieurs centaines d’anciennes adresses. Le vrai enjeu, ici, était de reconnaître un motif d’URL, pas une liste d’exceptions : toutes les anciennes adresses suivaient une structure prévisible, ce qui permet de la reconstruire par calcul plutôt que de la stocker.
Repérer le motif exact de l’ancienne structure
Avant d’écrire la moindre ligne de code, il faut documenter précisément l’ancien motif. Ici, l’ancienne structure datée ressemblait à /2019/03/renovation-loft-belleville/, avec l’année, le mois, puis le slug du projet — un motif de permalien classique de type /%year%/%monthnum%/%postname%/.
Le principe général : intercepter la requête avant que WordPress ne cherche à la résoudre normalement (et échoue en 404), reconnaître le motif par expression régulière, en extraire le slug, retrouver l’article correspondant, puis rediriger vers son URL actuelle.
Intercepter la requête au bon moment
Le hook template_redirect est le point d’entrée classique pour ce genre de logique : il se déclenche après la résolution de la requête principale, ce qui permet de tester si WordPress s’apprête à afficher une page 404, sans pour autant intervenir trop tôt dans le cycle de chargement.
add_action( 'template_redirect', 'cabinet_rediriger_anciennes_urls_datees' );
function cabinet_rediriger_anciennes_urls_datees() {
if ( ! is_404() ) {
return;
}
$chemin = trim( parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH ), '/' );
// Motif : annee/mois/slug, par exemple 2019/03/renovation-loft-belleville
if ( ! preg_match( '#^(\d{4})/(\d{2})/([a-z0-9\-]+)$#', $chemin, $correspondances ) ) {
return;
}
$slug = $correspondances[3];
$article = get_page_by_path( $slug, OBJECT, 'post' );
if ( ! $article instanceof WP_Post ) {
return;
}
wp_safe_redirect( get_permalink( $article ), 301 );
exit;
}
Ce filtre ne se déclenche que sur une vraie 404 : c’est important, car on ne veut surtout pas court-circuiter les pages qui s’affichent normalement. On ne cherche à reconstruire l’ancienne URL que dans le cas précis où WordPress n’a rien trouvé avec la structure actuelle.
Et s’il existe plusieurs anciennes structures ?
Dans le cas du cabinet d’architectes, il fallait gérer les trois structures successives. La solution consiste à tester plusieurs motifs à la suite, du plus ancien au plus récent, et à s’arrêter au premier qui correspond :
$motifs = array(
'#^(\d{4})/(\d{2})/([a-z0-9\-]+)$#' => 3, // ancienne structure datée
'#^projets/([a-z0-9\-]+)$#' => 1, // structure intermédiaire
);
foreach ( $motifs as $motif => $index_slug ) {
if ( preg_match( $motif, $chemin, $correspondances ) ) {
$slug = $correspondances[ $index_slug ];
break;
}
}
Le piège du code de redirection
Un détail qui change tout pour le référencement : la redirection doit impérativement être un 301 (déplacement permanent), jamais un 302. Un 302 indique aux moteurs de recherche que le déplacement est temporaire, ce qui les pousse à conserver l’ancienne URL comme référence — exactement l’inverse de l’effet recherché lors d’une migration de structure. La fonction wp_safe_redirect() accepte le code en second argument, comme montré plus haut ; ne l’oubliez jamais.
Vérifier que rien ne casse pour les vraies 404
Un site qui a plusieurs années d’historique a forcément de vraies pages introuvables (liens externes cassés, fautes de frappe dans une URL partagée). Il faut donc s’assurer que la fonction ne redirige que sur un motif reconnu et un article réellement trouvé, jamais par défaut. C’est pour cette raison que chaque étape de la fonction retourne (return) sans rediriger dès qu’une condition échoue, laissant WordPress afficher sa page 404 normale dans tous les autres cas.
- Documentez chaque ancien motif de permalien dans un commentaire, avec un exemple d’URL réelle.
- Testez avec
curl -Ipour vérifier le code de retour exact (301, pas 302, pas 200). - Purgez les anciennes URL de la Search Console une fois la redirection en place et validée, pour accélérer la mise à jour de l’index.
Sur un projet avec plusieurs migrations successives, je garde toujours une trace écrite des motifs d’URL abandonnés, même après la mise en place des redirections : c’est la seule documentation fiable le jour où une nouvelle refonte doit encore composer avec un historique de trois structures différentes.
Notre verdict
Reconstruire une ancienne URL par motif plutôt que de la stocker ligne par ligne change complètement l’échelle du problème : que l’historique compte dix ou dix mille anciennes adresses, le code reste identique, et la maintenance se limite à documenter les motifs plutôt qu’à gérer une base de correspondances qui grossit sans fin. C’est une approche qui demande un peu plus de rigueur au départ, mais qui tient dans la durée.
