Redirections génériques : comment elles fonctionnent et comment les configurer

Une redirection générique est une règle unique qui correspond à de nombreuses URL selon un modèle et les envoie ailleurs. Au lieu d’énumérer 4 000 anciennes adresses une par une, vous écrivez quelque chose comme « tout ce qui se trouve sous /blog/ va vers le même chemin sur le nouveau domaine » et vous laissez le serveur faire le reste. Ce guide couvre les deux sens que les gens confondent (les jokers DNS et les redirections HTTP), les modèles qui fonctionnent pour Apache et NGINX, les erreurs SEO qui coûtent des positions, et les cas où une couche de redirection gérée est le meilleur choix.

Ce qu’est réellement une redirection générique#

Le mot « générique » recouvre trois choses différentes, et les résultats de recherche les mélangent librement.

Redirections génériques (par modèle). Une règle avec un espace réservé. L’espace réservé peut signifier « n’importe quels caractères après ce point » (correspondance par préfixe), « n’importe quels caractères avant ce point » (correspondance par suffixe) ou un segment capturé réutilisé dans la destination. Exemples typiques : /old-blog/* vers /blog/*, ou *.olddomain.com vers newdomain.com.

Enregistrements DNS génériques. Un enregistrement avec un astérisque dans l’étiquette la plus à gauche, comme *.example.com, répond aux requêtes pour des sous-domaines qui n’ont pas leur propre enregistrement. AWS documente le fonctionnement des astérisques dans les noms d’enregistrements^[1], et le point clé ici est que le DNS décide seulement quel serveur répond. La redirection elle-même est une opération HTTP qui se produit après la résolution DNS, sur le serveur qui reçoit la requête.

Interdiction des jokers au niveau du registre. Le troisième usage concerne les registres des domaines de premier niveau : les opérateurs n’ont pas le droit de synthétiser des réponses pour des domaines inexistants. C’est une règle pour les registres, pas quelque chose que vous configurez sur votre propre site.

Ainsi, une configuration générique complète pour les sous-domaines nécessite généralement deux couches : un enregistrement DNS générique pour que chaque sous-domaine atteigne votre serveur, et une règle côté serveur qui décide où chaque requête doit aller.

Les modèles que vous utiliserez réellement#

La plupart des besoins réels relèvent de six modèles.

La différence entre les deux premières lignes est celle qui compte le plus. Conserver le chemin maintient une pertinence un-à-un, ce qui est souhaitable lorsque le nouveau site reproduit l’ancien. Supprimer le chemin n’est approprié que lorsqu’aucune page équivalente n’existe.

Redirections génériques sur Apache (.htaccess)#

Une question fréquente consiste à savoir comment rediriger tout ce qui suit un certain chemin via .htaccess. Sur Apache, c’est le rôle de mod_rewrite. La documentation Apache de mod_rewrite^[2] décrit RewriteRule et les indicateurs qui vont avec, y compris R pour la redirection.

Une redirection de préfixe qui conserve le reste du chemin :

<code class="language-apache">RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]
</code>

Les parenthèses capturent tout ce qui suit old-section/, et $1 l’insère dans la destination. L arrête le traitement des règles suivantes, ce qui évite des correspondances doubles accidentelles.

Une redirection de tout le domaine qui conserve les chemins et les chaînes de requête :

<code class="language-apache">RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</code>

Quelques points piègent souvent les gens :

• L’ordre compte. Les règles s’exécutent de haut en bas. Placez les règles spécifiques au-dessus des règles générales, sinon la règle générique engloutit tout.
• Échappez les points. Un . non échappé dans une expression régulière correspond à n’importe quel caractère.
• Testez d’abord avec une redirection 302. Les navigateurs mettent agressivement en cache les 301. Utilisez R=302 pendant les tests, puis passez à 301 lorsque la règle fonctionne.
• Prenez le serveur en compte. .htaccess fonctionne uniquement sur Apache. Si votre hébergeur utilise NGINX, le fichier est ignoré.

Redirections génériques sur NGINX#

NGINX gère les noms d’hôte via server_name. Le guide du serveur web NGINX^[3] explique qu’un nom de serveur peut être un nom exact, un joker avec un astérisque au début ou à la fin, ou une expression régulière, et que les noms exacts l’emportent sur les jokers lorsque plusieurs correspondent.

Rediriger chaque sous-domaine d’un ancien domaine vers le nouveau :

<code class="language-nginx">server {
    listen 80;
    server_name .old-domain.com;
    return 301 https://new-domain.com$request_uri;
}
</code>

Le point initial correspond à la fois à old-domain.com et à n’importe quel sous-domaine. $request_uri conserve le chemin et la chaîne de requête d’origine, donc les liens profonds fonctionnent toujours.

Pour un préfixe de chemin à l’intérieur d’un site :

<code class="language-nginx">location ~ ^/old-section/(.*)$ {
    return 301 /new-section/$1;
}
</code>

Préférez return à rewrite pour les redirections simples. C’est plus clair et moins coûteux à évaluer.

Choisir le code de statut#

Le code que vous renvoyez indique aux navigateurs et aux moteurs de recherche comment traiter la redirection.

• 301 (déplacé de façon permanente) et 308 (redirection permanente) indiquent que la ressource a une nouvelle adresse permanente. La référence MDN pour 301^[4] décrit les navigateurs suivant automatiquement l’en-tête Location.
• 302 et 307 sont temporaires. Utilisez-les pour des tests A/B, de courtes promotions ou des pages de maintenance.

La recommandation de Google est que les redirections permanentes aident à consolider les URL dupliquées et signalent que la nouvelle URL doit être indexée^[5], tandis que les redirections temporaires conservent la priorité d’indexation de la page source. Si le changement est à long terme, utilisez un code permanent. Une règle générique laissée en 302 après une migration est une erreur discrète et courante.

Ce que le trafic RedirHub montre sur les codes permanents et temporaires#

Dans un échantillon de six heures des requêtes de redirection servies par l’edge de RedirHub le 22 octobre 2026, 42,2 % provenaient de bots. Parmi les requêtes provenant de personnes, 82,3 % ont reçu un 301 ou 308, 1,3 % un 302 ou 307, et moins de 0,03 % une erreur (4xx ou 5xx).

Les codes permanents dominent, donc une règle générique restée sur un code temporaire après une migration ressort comme l’exception à auditer. Les parts ne comptent que les personnes (bots exclus), proviennent du journal d’accès des redirections plutôt que d’une enquête, et excluent les plus gros comptes afin qu’aucun client unique ne les fausse. Sur RedirHub, les redirections de domaine avec 301, 302, 307 et 308 sont incluses dans Core, Pro et Enterprise, tandis que les redirections de sous-domaine génériques sont incluses dans Pro et Enterprise uniquement.

Erreurs SEO que les règles génériques rendent faciles#

Parce qu’une seule règle touche des milliers d’URL, une règle erronée endommage des milliers de pages d’un coup.

Tout envoyer vers la page d’accueil#

Le fourre-tout paresseux, /* vers /, paraît propre et perd en pertinence. Un visiteur qui a cliqué sur un lien vers un guide précis atterrit sur une page d’accueil générique et repart. Les moteurs de recherche peuvent aussi considérer des redirections massives vers une page non pertinente comme une soft 404. Redirigez vers l’équivalent le plus proche et n’utilisez une catégorie parente plus large que lorsqu’aucun équivalent n’existe.

Créer des chaînes#

Supposons que http://old.com/page redirige vers https://old.com/page, qui redirige vers https://www.old.com/page, qui redirige vers https://new.com/page. Cela fait trois sauts. La documentation de Google indique que Googlebot peut suivre un nombre limité de sauts et que les redirections directes sont préférées^[5], car les chaînes ajoutent de la latence et peuvent ralentir l’indexation. Écrivez la règle de façon à ce que la première réponse pointe déjà vers l’URL finale, avec le protocole, l’hôte et le chemin corrigés en une seule fois.

Oublier la chaîne de requête et les fragments#

Les paramètres de campagne, comme les balises UTM, accompagnent souvent les anciens liens. Vérifiez si votre règle préserve la chaîne de requête là où vous le souhaitez. Dans Apache, une redirection vers une URL absolue conserve la chaîne de requête d’origine, sauf indication contraire, comme l’explique la documentation Apache. Dans NGINX, $request_uri l’inclut, tandis que $uri ne l’inclut pas.

Confondre www et sans www#

Choisissez un hôte canonique et redirigez l’autre vers celui-ci. Les recommandations de Google sur la consolidation des URL dupliquées^[6] indiquent que les redirections constituent un signal fort de votre version préférée, et l’un ou l’autre choix convient tant que vous restez cohérent. Si vous avez besoin d’un guide pas à pas, notre note sur la redirection de non-www vers www l’explique.

Supprimer les règles trop tôt#

Google indique que les redirections peuvent être considérées comme un signal de canonicalisation, et non comme un ordre absolu, et qu’il peut toujours choisir une autre URL canonique en fonction d’autres facteurs, comme l’explique sa documentation sur la canonicalisation^[7]. En pratique, conservez les redirections permanentes en place pendant au moins un an après un changement, et plus longtemps pour les URL qui continuent à recevoir des liens externes.

Un processus sûr pour une migration par wildcard#

1. Inventoriez les anciennes URL. Extrayez-les de votre sitemap, des journaux serveur, des analyses et d’un crawl. La documentation de Google sur les changements de site^[8] insiste sur l’importance d’associer chaque ancienne URL à sa nouvelle destination.
2. Regroupez-les par modèle. La plupart des sites se ramènent à quelques règles wildcard, plus une liste plus réduite d’exceptions ponctuelles.
3. Rédigez d’abord les exceptions. Les correspondances individuelles doivent être placées au-dessus des règles wildcard afin qu’elles soient prioritaires.
4. Testez avec de vraies URL. Exécutez un échantillon de plusieurs centaines d’anciennes URL, y compris les plus inhabituelles, et vérifiez le code d’état, la destination finale et le nombre de sauts. Un outil de vérification des redirections affiche chaque saut et chaque code d’état pour une seule URL.
5. Lancez avec des codes permanents. Passez du 302 au 301 une fois les tests validés.
6. Surveillez. Observez les erreurs d’exploration, les 404 et le trafic par section pendant des semaines. Corrigez les lacunes avec de nouvelles règles, pas en modifiant à la hâte les anciennes.

Google note également que les grands sites peuvent migrer par sections afin de tester l’effet, tandis que les petits sites obtiennent souvent de meilleurs résultats en migrant tout d’un coup. Pour la planification côté domaine, notre guide de changement de domaine SEO couvre ce qu’il faut vérifier avant et après le changement.

Quand les fichiers serveur cessent d’être pratiques#

Modifier .htaccess ou une configuration NGINX convient pour un seul site que vous contrôlez. Cela devient pénible quand :

• Vous possédez des dizaines de domaines, certains stationnés, d’autres hérités, d’autres encore achetés pour une campagne.
• Le marketing doit changer une destination, mais les modifications nécessitent un développeur et un déploiement.
• Votre site fonctionne sur une plateforme sans accès à la configuration du serveur.
• Les règles de redirection se trouvent à quatre endroits (CMS, CDN, serveur, registraire) et personne ne sait laquelle l’emporte.

L’ordre compte aussi. Comme MDN l’explique^[9], la redirection est déclenchée par l’envoi par le serveur d’une réponse 3xx avec un en-tête Location, donc elle se produit avant l’envoi de tout contenu de page. Les astuces côté client comme JavaScript ou le méta-refresh sont un dernier recours quand vous ne pouvez pas accéder à la couche serveur. Une couche de redirection dédiée vous maintient au bon niveau sans nécessiter d’accès au serveur.

La vitesse est l’autre coût du fait de quitter la couche serveur, et il est faible : le temps médian jusqu’au premier octet de RedirHub était de 18 ms, contre 11 ms pour le plus rapide des 26 fournisseurs, mesuré depuis Washington, D.C., Francfort et Tokyo (benchmark de vitesse de redirection RedirHub, 18–25 octobre 2026^[10]).

Notre point de vue#

La plupart des problèmes de redirection que nous voyons ne concernent pas la syntaxe. Ils concernent la propriété. Une règle est écrite une fois par la personne qui travaillait sur le projet, reste dans un fichier de configuration, puis des années plus tard, plus personne ne se souvient pourquoi /promo/* pointe là où il pointe. Ensuite, un domaine expire, une brochure imprimée ou un code QR continue d’envoyer les gens vers une page morte, et la correction nécessite un ticket.

Nous avons conçu RedirHub autour de l’idée que les liens et les redirections doivent se trouver sur votre propre domaine et rester sous votre contrôle, avec le SSL pris en charge pour vous, plutôt que de dépendre d’un raccourcisseur partagé ou d’une pile de fichiers serveur. Notre conseil pour les règles génériques est le même quel que soit l’outil que vous utilisez : écrivez le motif le plus précis qui fait le travail, pointez-le directement vers l’URL finale, gardez une liste des exceptions et révisez les règles selon un calendrier. Traitez les redirections comme des actifs à long terme, car les liens disséminés sur le web survivront à la conception actuelle de votre site.

Gérer les redirections génériques et de domaine sans fichiers de configuration#

RedirHub vous permet de gérer les redirections de domaine et les liens de marque sur vos propres domaines, avec SSL et analyses, et de modifier les destinations sans toucher aux supports imprimés. Si vous migrez un site, notre service de migration de site web et notre service de redirection 301 pour les migrations SEO sont conçus pour cette tâche. Les offres sont publiées sur la page des tarifs : Core est à 49 $ par mois et Pro à 119 $ par mois. Enterprise est fixé par contrat. Les redirections de sous-domaines génériques (redirections de sous-domaine attrape-tout) sont incluses uniquement dans Pro et Enterprise, tandis que les redirections de domaine, le transfert de chemin et le transfert de paramètres de requête sont inclus dans Core, Pro et Enterprise.

Référence rapide : DNS générique versus redirection générique#

Autre détail DNS pour les configurations multi-domaines : un CNAME ne peut pas se trouver à l’apex de la zone (le simple example.com), alors que certains fournisseurs proposent des enregistrements de type alias qui le peuvent. AWS l’explique dans sa comparaison des enregistrements alias et non alias^[11]. Si vous pointez des domaines nus vers un service de redirection, vérifiez quel type d’enregistrement votre fournisseur DNS prend en charge à l’apex.

Exemple concret : une refonte de marque avec trois sous-domaines#

Imaginez une entreprise qui passe de acme-tools.com à acme.com. Elle a un blog, un site d’assistance sur help.acme-tools.com, et quelques sous-domaines régionaux comme uk.acme-tools.com.

Un plan clair ressemble à ceci :

1. Ajoutez un enregistrement DNS wildcard sur l’ancien domaine afin que tout sous-domaine, y compris ceux dont personne ne se souvient, atteigne la couche de redirection.
2. Créez d’abord des règles explicites : help.acme-tools.com/* vers support.acme.com/*, et uk.acme-tools.com/* vers acme.com/uk/*.
3. Ajoutez une règle générale : *.acme-tools.com/* vers acme.com/*, comme solution de secours.
4. Ajoutez la règle racine : acme-tools.com/* vers acme.com/*.
5. Renvoyez un 301 pour toutes, avec HTTPS dans la destination afin qu’il n’y ait qu’une seule étape.
6. Testez 200 anciennes URL issues du sitemap et des analytics, puis vérifiez-les à nouveau après une semaine.

Les règles explicites protègent les sections ayant des structures différentes, et la règle de secours attrape les cas isolés. Sans cet ordre, la règle de secours aplatirait le site d’assistance dans les chemins du domaine principal, où rien ne correspond.