Un client m’a demandé un jour de « simplifier les URL » de son site d’actualités locales : il voulait passer de /categorie/actualites-communales/mon-article/ à quelque chose de plus court. La demande semblait anodine, presque cosmétique. Elle touchait en réalité à la structure de permaliens la plus délicate à modifier sur un site déjà indexé depuis plusieurs années.
Retirer la base /categorie/ (ou /category/ en anglais) des URL de taxonomie WordPress est une opération connue, mais rarement menée jusqu’au bout correctement. La partie facile prend une ligne de code. La partie difficile consiste à ne pas casser le maillage interne construit sur les anciennes URL.
Le filtre qui retire la base
WordPress expose un filtre dédié, category_rewrite_rules, mais l’approche la plus fiable consiste à intercepter la génération du lien de catégorie directement :
add_filter( 'category_link', function( $link ) {
return str_replace( '/category/', '/', $link );
} );
add_action( 'init', function() {
global $wp_rewrite;
$wp_rewrite->extra_permastructs['category']['struct'] = '/%category%';
} );Après ce changement, il faut impérativement vider les règles de réécriture, mais jamais avec flush_rewrite_rules() appelé à chaque chargement de page (une erreur que je vois encore régulièrement, qui dégrade sérieusement les performances). On la déclenche une fois, via WP-CLI :
wp rewrite flush --hardLe vrai risque : le conflit avec les pages
Sans le segment /category/, une catégorie nommée actualites-communales peut entrer en collision avec une page qui porterait le même slug. WordPress résout ce genre de conflit de façon peu prévisible selon l’ordre de chargement des règles de réécriture, et le résultat observé sur le terrain a été qu’une page statique « Actualités » créée six mois plus tôt est devenue inaccessible, remplacée dans le rendu par l’archive de catégorie du même nom.
La bonne pratique consiste à auditer tous les slugs de pages et de catégories avant de basculer, avec WP-CLI :
wp post list --post_type=page --field=post_name
wp term list category --field=slugToute collision doit être renommée d’un côté ou de l’autre avant la mise en production du nouveau filtre.
Le maillage interne : le vrai chantier
Retirer la base de catégorie change mécaniquement l’URL de sortie de get_category_link(), donc de tous les liens générés dynamiquement (menus, fils d’Ariane, widgets de catégories). Ces liens se corrigent tout seuls puisqu’ils sont générés à la volée. Le vrai problème concerne les liens internes écrits en dur dans le corps des articles au fil des années, qui pointent vers l’ancienne URL /category/... et deviendront des redirections après le changement, au lieu de liens directs.
Sur ce dossier, une recherche en base a permis de quantifier le problème avant d’agir :
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%/category/%' AND post_status='publish'"274 articles contenaient au moins un lien en dur vers l’ancienne structure. Plutôt que de les laisser passer par une redirection à chaque clic, un remplacement ciblé a été effectué avec wp search-replace, en mode simulation d’abord :
wp search-replace '/category/' '/' wp_posts --dry-run --precise
wp search-replace '/category/' '/' wp_posts --preciseLa redirection de sécurité
Même avec le maillage interne corrigé, les anciennes URL restent indexées et présentes dans des liens externes que vous ne contrôlez pas. Une règle de redirection générique dans le serveur reste indispensable :
RewriteRule ^category/(.*)$ /$1 [R=301,L]Je ne bascule jamais ce type de changement un vendredi : la fenêtre de vérification (recherche de liens cassés, contrôle Search Console) demande deux à trois jours ouvrés de suivi rapproché.
En résumé
Retirer la base de catégorie tient en une poignée de lignes de code, mais la réussite du projet se joue entièrement en amont, dans l’audit des collisions de slugs et des liens internes écrits en dur, et en aval, dans la redirection généraliste qui protège les URL indexées que vous ne maîtrisez plus.
