add_rewrite_rule( '^guide/([^/]+)/?$', 'index.php?guide=$matches[1]', 'top' ) : cette ligne, ajoutée au hook init pour proposer des URL de la forme /guide/nom-du-guide/ plus courtes que la structure native en /type-contenu/nom-du-guide/, fonctionnait parfaitement à l’affichage. Le navigateur affichait bien la nouvelle URL raccourcie, le contenu s’affichait sans erreur 404, et rien ne laissait supposer un problème.
Le problème est apparu dans le code source de la page elle-même : la balise <link rel="canonical">, générée automatiquement par la fonction rel_canonical() de WordPress via le hook wp_head, continuait d’afficher l’ancienne URL longue, celle que la règle de réécriture était censée remplacer. Deux URL techniquement valides coexistaient donc pour un même contenu, chacune revendiquant l’autre comme copie canonique.
Pourquoi la règle de réécriture ne suffit pas
La fonction add_rewrite_rule() agit à un niveau précis du traitement d’une requête WordPress : elle indique au système comment interpréter une URL entrante et la faire correspondre à une requête interne, via les variables de requête ajoutées avec add_rewrite_tag(). Elle ne modifie en rien la fonction get_permalink(), qui reste construite selon la structure de permaliens définie dans les réglages de WordPress, celle affichée dans Réglages > Permaliens.
rel_canonical() appelle en interne get_permalink() pour déterminer l’URL canonique à afficher. Tant que cette structure de permaliens native n’a pas elle-même été modifiée pour refléter le nouveau format, la fonction continuera de produire l’ancienne URL, quelle que soit la règle de réécriture ajoutée par ailleurs pour accepter également la nouvelle forme en entrée.
Le piège du flush_rewrite_rules()
Face à ce blocage, le réflexe naturel consiste à appeler flush_rewrite_rules(), en pensant régénérer l’ensemble des règles et corriger au passage l’URL canonique. Ce réflexe ne résout rien : cette fonction régénère la table interne des règles de réécriture stockée en base, celle qui sert à interpréter les requêtes entrantes, mais elle ne touche pas à la structure de permaliens configurée par l’administrateur, seule source utilisée par get_permalink().
La correction correcte
Deux approches distinctes permettent de sortir de ce conflit, selon l’objectif réellement recherché :
- Si le format court doit devenir la structure officielle, la modifier directement dans Réglages > Permaliens à l’aide d’une structure personnalisée, ce qui met à jour
get_permalink()et doncrel_canonical()du même mouvement. - Si le format court ne doit rester qu’un alias d’accès, filtrer directement la sortie de
rel_canonical()via le filtreget_canonical_url, en reconstruisant explicitement l’URL souhaitée plutôt que de laisser la fonction native s’en charger.
Exemple de filtre ciblé
add_filter( 'get_canonical_url', function( $canonical_url, $post ) {
if ( 'guide' === $post->post_type ) {
return home_url( '/guide/' . $post->post_name . '/' );
}
return $canonical_url;
}, 10, 2 );
Vérifier la cohérence après correction
Une fois le filtre en place, comparer l’URL affichée dans la barre d’adresse et celle présente dans la balise canonical du code source suffit à confirmer la correction. L’outil d’inspection d’URL de Search Console reste la vérification la plus fiable, puisqu’il affiche explicitement l’URL canonique retenue par Google, qui doit désormais correspondre à l’URL réellement servie.
Une règle de réécriture change la façon dont une URL entre dans WordPress. Elle ne change jamais, seule, la façon dont WordPress la fait ressortir.
En résumé
Ajouter une règle de réécriture pour accepter un nouveau format d’URL en entrée ne suffit jamais à harmoniser l’URL canonique en sortie. Ces deux mécanismes reposent sur des fonctions distinctes de l’API WordPress, l’une pour l’interprétation des requêtes, l’autre pour la structure de permaliens. Les confondre revient à afficher une URL courte à l’utilisateur tout en revendiquant une URL longue auprès des moteurs de recherche.
