Générateur de redirections .htaccess
Génère des règles de redirection Apache .htaccess et Nginx pour le HTTPS, l'hôte canonique, les slashs finaux et les déplacements d'anciennes URL.
Ce générateur de redirections .htaccess écrit les règles Apache pour les parties d'une migration qui comptent vraiment : forcer le HTTPS, verrouiller un hôte canonique (www ou non-www), nettoyer les fichiers index, choisir si les slashs finaux restent ou partent, et faire pointer les anciennes URL vers les nouvelles. Il te donne aussi l'équivalent Nginx, une matrice de redirection qui montre vers quoi chaque URL d'exemple aboutit, et une liste d'avertissements qui signale les erreurs classiques, comme laisser un 302 sur un déplacement définitif, activer add-slash et remove-slash en même temps, ou envoyer des anciennes URL sans rapport vers la page d'accueil. L'ordre compte parce que .htaccess s'exécute à chaque requête : les déplacements précis d'abord, puis l'hôte et le HTTPS, puis la politique de slash. Tout tourne dans ton navigateur. Lis les règles, sauvegarde, teste en préprod, puis déploie.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur de redirections Apache .htaccess et Nginx pour URL canoniques et migrations
Une seule ligne foireuse dans un .htaccess m'a déjà mis tout un site hors ligne. Alors oui, je comprends le stress. Dis simplement à cet outil ton domaine et ce que tu veux vraiment : forcer le HTTPS, choisir entre www et non-www, régler la question des slashs en fin d'URL, nettoyer les fichiers index qui traînent, faire pointer les anciennes URL vers les nouvelles. Il écrit les règles Apache. Tu récupères aussi la version Nginx et une petite matrice qui montre quelle URL redirige vers quoi, plus des avertissements, comme ça tu peux lire ce que le serveur s'apprête à faire avant que quoi que ce soit ne touche à la prod.
Ces règles touchent toutes les URL du site. Fais une sauvegarde d'abord. Teste sur un environnement de préprod si tu peux, puis une fois en ligne, passe quelques pages clés dans un vérificateur de redirections, juste pour être sûr.
Ce que fait ce générateur de redirections .htaccess
Ce générateur de redirections .htaccess construit les règles Apache pour les trucs que tu migres pour de vrai : forcer le HTTPS, verrouiller un hôte canonique, ranger les fichiers index, choisir si les slashs restent ou partent, et faire pointer les anciennes URL vers les nouvelles. Tu as aussi la version Nginx, plus une matrice et une liste d'avertissements, parce que je préfère que tu lises ce que le serveur va faire plutôt que de le découvrir en prod. Ce que tu veux est tout bête. Quelqu'un tombe sur l'ancienne URL, il atterrit sur la version finale, point. Un seul saut. Les ennuis commencent quand les règles s'empilent et se mettent à se battre entre elles, et comme .htaccess s'exécute à chaque requête, l'ordre dans lequel tu écris les règles change vraiment ce qui ressort à l'autre bout.
Comment tester ses règles de redirection
Ma petite checklist, vite fait. Tu tapes la page d'accueil. Tu tapes une URL que tu as déplacée. Tu essaies une page avec le slash final, puis sans. Tu balances un vieux fichier index, deux ou trois URL de sitemap, quelques pages qui te tiennent vraiment à cœur. Déplacement définitif ? Tu veux un 301, presque toujours. Un 302 fait l'affaire tant que tu tâtonnes encore, mais franchement, n'en laisse pas un sur un déplacement canonique : les moteurs de recherche lisent ça comme « bof, ça pourrait revenir en arrière ». Ensuite, une fois en ligne, va corriger tes liens internes pour que les gens ne passent pas par une redirection juste pour cliquer sur ton propre site.
- Les déplacements d'URL précis passent en premier, bien avant les règles canoniques générales.
- Les règles d'hôte canonique ne devraient pas se battre avec ce que WordPress ou ton CDN fait déjà.
- Les redirections HTTPS doivent se déclencher une fois. Pas un http vers https vers www en petite chaîne.
- La politique de slash final doit être d'accord avec tes réglages de permaliens WordPress. Sinon, boucle.
- La config Nginx vit dans des blocs server. Ça ne va jamais dans .htaccess, jamais.
Les erreurs de redirection les plus courantes
La grosse erreur que je vois revenir : balancer toutes les anciennes URL sur la page d'accueil. Ça paraît propre. Sauf que tu jettes toute la pertinence à la poubelle, et Google lit ça plus ou moins comme un soft 404. Ensuite la chaîne, http vers https vers non-www vers www, qui n'est rien d'autre que de la latence que tu refiles à chaque visiteur pour rien. Laisse un 302 sur un déplacement définitif et les moteurs continuent de se demander si l'ancienne URL va revenir. Active add-slash et remove-slash en même temps et tu t'es fabriqué une boucle garantie. Et éditer un .htaccess sans sauvegarde ? Une faute de frappe, et tout le site renvoie une 500 jusqu'à ce que tu répares. C'est peut-être juste moi, mais celle-là me semble pire que toutes les autres réunies. Demande-moi comment je le sais.
Questions fréquentes
Je dois utiliser un 301 ou un 302 ?
Déplacement définitif, nettoyage canonique, ancienne URL partie pour de bon ? Utilise un 301. Garde le 302 pour quand tu veux vraiment dire que c'est temporaire et que tu vas la remettre.
Je peux utiliser ces règles sur Nginx ?
Celles d'Apache ? Non. Syntaxe complètement différente. Je te génère les deux versions, mais chacune ne marche que sur son propre serveur. Colle des règles Apache dans une config Nginx et il n'en sortira rien de bon.
Mes liens internes doivent-ils encore pointer vers les anciennes URL ?
Non. Garde les redirections en place, elles sont là pour rattraper les vieux liens et les favoris. Mais tes propres liens internes et tes sitemaps doivent viser directement les URL finales. Pourquoi envoyer tes visiteurs faire un détour à travers ton propre site ?
Quelle est la différence entre un 301 et un 302 dans un .htaccess ?
R=301, c'est permanent. Ça transfère ton classement vers la nouvelle URL, c'est donc celui que tu veux pour du contenu déplacé. R=302, c'est temporaire, ce qui veut dire que la valeur reste garée sur l'URL d'origine. Va chercher le 301, sauf si tu as une vraie raison de ne pas le faire.
Pourquoi ma redirection .htaccess provoque-t-elle une boucle ?
Presque toujours, c'est une règle qui réécrit une URL en quelque chose qui correspond à nouveau à cette même règle. Du coup elle se déclenche encore et encore. À l'infini. La solution : ajouter une condition qui exclut l'état dans lequel tu es déjà, par exemple ne rediriger que quand le HTTPS est vraiment désactivé, au lieu de le faire à chaque requête.