Une URL change, mais les liens qui pointent vers l’ancienne ne disparaissent pas par magie. Pour éviter les erreurs 404 et accompagner une migration, une redirection 301 indique aux navigateurs et aux moteurs de recherche que la page a déménagé de façon permanente. Sous Apache, RedirectMatch permet de créer ces règles à partir d’expressions régulières, pratiques lorsqu’un dossier entier ou une série d’adresses suit le même motif.
Le piège, c’est qu’une règle trop large peut envoyer des pages au mauvais endroit, voire créer une boucle. Ce guide montre comment lire la syntaxe, choisir entre RedirectMatch et mod_rewrite, puis vérifier le résultat sans transformer le fichier .htaccess en terrain miné. Les exemples conviennent aux sites hébergés sur Apache ; sur Nginx, la configuration se fait autrement.
En bref
- RedirectMatch appartient au module mod_alias et applique une expression régulière au chemin demandé.
- Les parenthèses capturent une partie du chemin, réutilisable avec $1 dans l’adresse de destination.
- Une règle précise doit précéder une règle générale pour éviter les correspondances inattendues.
- Après modification du fichier .htaccess, vérifie le code HTTP, la destination et l’absence de boucle.
RedirectMatch dans Htaccess : comprendre la syntaxe avant de rediriger
Le fichier .htaccess permet d’ajuster certains réglages Apache à l’échelle d’un répertoire, sans modifier directement la configuration principale du serveur. Il doit être pris en charge par l’hébergement et les directives concernées doivent être autorisées. Si une modification provoque une erreur 500, le journal d’erreurs Apache est souvent le premier endroit à consulter.
La forme générale est RedirectMatch 301 motif destination. Le motif est une expression régulière appliquée au chemin de l’URL, tandis que 301 précise qu’il s’agit d’une redirection permanente. Contrairement à Redirect, qui sert surtout aux correspondances simples, RedirectMatch peut reconnaître des variantes grâce aux expressions régulières.
Dans un fichier .htaccess situé à la racine, une règle pour un chemin précis peut ressembler à ceci :
RedirectMatch 301 ^/ancienne-page.html$ https://www.exemple.fr/nouvelle-page.html
Les caractères ^ et $ encadrent le chemin complet : la règle ne doit donc correspondre qu’à cette adresse exacte. Le point dans .html est précédé d’une barre oblique inversée, car un point non échappé signifie « n’importe quel caractère » dans une expression régulière.
Les parenthèses servent à capturer une portion variable. Dans l’exemple ci-dessous, le contenu correspondant à (.*) est réutilisé avec $1 dans l’URL cible :
RedirectMatch 301 ^/ancien-dossier/(.*)$ https://www.exemple.fr/nouveau-dossier/$1
Cette règle déplace les chemins du dossier tout en conservant leur suite. Attention : sous cette forme, elle vise les adresses commençant par /ancien-dossier/ avec une barre oblique après le nom. Tester aussi l’adresse sans barre oblique finale permet de repérer ce genre de détail avant la mise en ligne.
Exemples de configuration pour une redirection 301 concrète
Pour une page déplacée, une directive Redirect suffit souvent et se lit plus facilement qu’une regex. RedirectMatch prend son intérêt quand plusieurs URL partagent une structure ou quand une migration impose de conserver les chemins. Dans les deux cas, indique explicitement le code 301 : sans statut, la directive Redirect utilise par défaut une redirection temporaire.
Pour déplacer un répertoire et garder les chemins internes, utilise une règle comme celle-ci :
RedirectMatch 301 ^/guides/(.*)$ https://www.exemple.fr/ressources/$1
Une ancienne adresse telle que /guides/htaccess-debuter devient alors /ressources/htaccess-debuter. La query string, c’est-à-dire les paramètres après le point d’interrogation, est généralement conservée si la destination n’en définit pas une nouvelle. RedirectMatch examine le chemin, pas ces paramètres : il ne permet donc pas de faire une correspondance sur ?id=123 comme si cette partie faisait partie du chemin.
Pour un changement de domaine en conservant l’arborescence, le motif peut capturer tout le chemin :
RedirectMatch 301 ^/(.*)$ https://www.nouveau-domaine.fr/$1
Cette règle est très large. Elle ne doit être utilisée que sur l’ancien domaine et après vérification de la configuration, sinon elle risque de rediriger des requêtes qui n’étaient pas concernées. Pour forcer HTTP vers HTTPS sur le même domaine, il faut plutôt s’appuyer sur mod_rewrite, qui peut tester le protocole :
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Sur une infrastructure avec proxy ou répartiteur de charge, la détection HTTPS peut dépendre de la façon dont le serveur reçoit le protocole d’origine. Ne copie donc pas cette règle à l’aveugle : valide son comportement dans l’environnement réel, surtout si le certificat TLS est terminé en amont du serveur Apache.
| Besoin | Directive adaptée | Point à contrôler |
|---|---|---|
| Une page précise | Redirect 301 | Chemin source et destination exacte |
| Un répertoire avec conservation des chemins | RedirectMatch 301 | Capture $1 et barre oblique finale |
| Une condition liée au protocole ou à l’hôte | mod_rewrite | Conditions HTTPS et proxy |
Ordre des règles de redirection : éviter les chaînes et les boucles
Une règle de redirection n’est pas isolée : Apache la traite avec les autres directives du fichier. Si une même URL correspond à plusieurs règles, l’ordre et la portée des motifs influencent le résultat. Place les exceptions précises avant les motifs généraux, puis documente brièvement les changements pour que la prochaine personne qui ouvre le fichier comprenne leur raison d’être.
Exemple classique : une ancienne page /contact redirige vers /contactez-nous, mais une règle globale renvoie ensuite cette dernière vers une autre adresse qui revient finalement à /contact. Le navigateur suit les redirections jusqu’à rencontrer une boucle. Les chaînes sont également à éviter : si A mène à B, puis B à C, remplace autant que possible les règles pour envoyer A directement vers C.
Avant d’éditer en production, conserve une copie du fichier et prépare un tableau de correspondance entre anciennes et nouvelles URL. Pour une refonte, cette liste peut venir d’un crawl du site, d’un export du CMS ou des pages connues dans les outils de suivi. Chaque ancienne page doit aboutir à un contenu réellement pertinent ; rediriger en masse toutes les URL vers l’accueil ne remplace pas une migration réfléchie.
Quelques habitudes limitent les mauvaises surprises :
- Commencer par une sauvegarde ou un commit Git du fichier .htaccess.
- Échapper les caractères spéciaux des motifs, notamment le point dans une extension.
- Vérifier que la destination existe et répond avec le statut attendu.
- Mettre à jour les liens internes et le sitemap au lieu de compter uniquement sur les redirections.
Pour une page supprimée sans équivalent, une réponse 404 ou 410 peut être plus honnête qu’une redirection vers une page sans rapport. La redirection permanente sert à signaler un déplacement, pas à masquer toutes les pages retirées du site.
Tester RedirectMatch et mesurer l’effet sur le référencement SEO
Une configuration qui « semble marcher » dans un navigateur mérite tout de même une vérification du code de réponse et de l’en-tête Location. Avec curl, la commande curl -I https://www.exemple.fr/ancienne-page affiche les en-têtes HTTP. Le résultat attendu pour une redirection permanente comporte un statut 301 et une destination cohérente ; ajoute l’option -L pour suivre toute la chaîne et repérer plusieurs étapes.
Tu peux également tester une liste d’URL avec un crawler, puis contrôler les pages importantes dans les journaux du serveur et dans les rapports de la Search Console. Une baisse temporaire du trafic peut apparaître pendant une migration, mais aucune règle ne garantit un transfert chiffré ou immédiat de la visibilité. Google doit explorer les nouvelles URL et comprendre les correspondances ; annoncer un pourcentage fixe de « jus SEO » serait trompeur.
Une redirection bien ciblée aide à préserver les liens entrants et à éviter une page introuvable. Elle ne compense toutefois ni un contenu cible faible, ni une architecture confuse, ni des liens internes encore tournés vers les anciennes adresses. Pour suivre les codes HTTP et les bonnes pratiques, les redirections d’URL en PHP sont une autre approche à comparer lorsque Apache ne gère pas directement la logique souhaitée.
Si le serveur renvoie une erreur 500 après l’ajout d’une règle, retire temporairement le bloc concerné et consulte les journaux avant de réessayer. Un motif mal formé ou une directive interdite dans ce contexte peut empêcher Apache de servir le site. Pour apprendre à mettre en place une redirection côté PHP, compare bien les implications : le code applicatif intervient plus tard dans le traitement de la requête qu’une règle au niveau du serveur.
FAQ sur RedirectMatch et les redirections 301 en .htaccess
RedirectMatch conserve-t-il les paramètres d’URL ?
Les paramètres de requête ne font pas partie du chemin analysé par RedirectMatch. Lorsqu’aucune nouvelle query string n’est indiquée dans la destination, ils sont généralement transmis. Teste le comportement exact avec une requête curl ou un outil de vérification HTTP.
Peut-on utiliser RedirectMatch sur un serveur Nginx ?
Non, le fichier .htaccess est propre à Apache. Nginx utilise sa propre configuration, généralement définie dans les blocs server et location.
Combien de temps conserver une redirection permanente ?
Garde-la tant que des visiteurs, des liens externes ou des moteurs peuvent encore demander l’ancienne adresse. Après une migration, vérifie les statistiques et les erreurs avant de retirer une règle.
Pourquoi une règle RedirectMatch ne fonctionne-t-elle pas ?
Contrôle le module mod_alias, la syntaxe, le chemin réellement reçu et les autorisations Apache pour .htaccess. Vérifie aussi qu’une règle précédente ou le cache ne masque pas le résultat attendu.
