Qu’est-ce qu’une redirection 301?

Name: Référence Numérique
Price range: $$

Vous changez le nom de domaine, vous refaites le site, vous consolidez deux pages en une seule : et votre agence parle de « mettre des 301 ».

31 mars 2026 · 9 min de lecture

Vous changez le nom de domaine, vous refaites le site, vous consolidez deux pages en une seule : et votre agence parle de « mettre des 301 ». Ce code est au cœur de toute migration propre, mais il reste rarement expliqué.

La réponse courte : Une redirection 301, c’est un signal HTTP qui dit au navigateur et aux moteurs de recherche « cette page a déménagé pour toujours à cette nouvelle adresse ». Quand Google la rencontre, il transfère quasiment tout le poids SEO de l’ancienne URL vers la nouvelle, et met à jour son index dans les semaines suivantes. C’est l’outil canonique pour ne rien perdre lors d’un changement d’URL.

Ce qu’il faut comprendre

HTTP prévoit plusieurs types de redirections, mais seules deux concernent vraiment le SEO :

301 : Déplacé de façon permanente. Google transfère l’équité SEO (backlinks, autorité) vers la nouvelle URL. L’ancienne URL disparaît progressivement de l’index.
302 : Déplacé temporairement. Google garde l’ancienne URL indexée, suppose que le déplacement est provisoire, et ne transfère pas le poids SEO.

Utiliser une 302 à la place d’une 301 est une des erreurs de migration les plus fréquentes. Le trafic continue parce que l’utilisateur est redirigé, mais au fil des mois Google continue d’afficher l’ancienne URL dans les résultats : avec le contenu caché derrière la redirection. Résultat : double indexation, signaux dilués, perte de positions.

Sur les sites qu’on récupère après une migration ratée, le pattern est presque toujours le même : la carte de redirections n’a pas été préparée avant la mise en ligne, des URLs à fort trafic retombent en 404, et les positions s’effondrent dans les semaines qui suivent. Chaque ancienne URL qui retourne un 404 au lieu d’une 301 est un signal SEO perdu.

Notre position : les redirections 301 sont la partie la plus sous-pensée de toute migration de site. Une seule 301 manquante sur une URL à fort trafic peut vaporiser des mois d’autorité accumulée. Le coût de bâtir la carte de redirections avant la migration est trivial comparé au coût de la récupération après : qui implique souvent de reconstruire des liens externes que l’on ne contrôle plus. La règle qu’on applique systématiquement : aucune migration ne part en production tant que la carte d’URLs anciennes → nouvelles n’est pas validée à 100 %, ligne par ligne.

Quand utiliser une 301

Changement de nom de domaine (ancien-site.ca → nouveau-site.ca)
Refonte de structure d’URL (/services/seo/ → /referencement-naturel-seo/)
Migration HTTP → HTTPS (redirections automatiques mais à vérifier)
Fusion de pages (deux articles proches consolidés en un seul)
Suppression d’une page qui avait des backlinks (rediriger vers la page thématiquement la plus proche)

Concrètement, voici comment faire

Faites l’inventaire des anciennes URLs. Exportez-les depuis Google Search Console → Indexation → Pages. Toutes les URLs qui reçoivent du trafic ou qui ont des backlinks doivent être redirigées, pas juste les plus importantes.
Mappez chaque ancienne URL vers une nouvelle. Jamais tout vers la homepage : ça dilue le poids SEO et frustre les utilisateurs. Une ancienne /services/referencement-local-quebec/ doit aller vers /referencement-naturel-seo/ ou l’équivalent thématique le plus proche, pas vers /.
Implémentez les redirections. Sur WordPress : Rank Math → Redirections, ou Redirection (plugin gratuit). Sur un serveur Apache : dans .htaccess. Sur Nginx : dans le bloc server.
Testez avec curl -I. Commande dans le terminal : curl -I https://exemple.ca/ancienne-url/ doit retourner HTTP/2 301 + un header Location: vers la nouvelle URL. Un 302 signifie que la redirection est configurée comme temporaire.
Soumettez le sitemap mis à jour à Google Search Console pour accélérer le recrawl. Google prend entre deux et huit semaines pour migrer l’index complètement.

Cas limites : ce qui casse en pratique

Quatre patterns qu’on rencontre régulièrement quand on récupère un site après migration :

Cas 1 : Chaînes 301 → 301 → 301 qui saignent l’équité

/ancien-blog/article → /blog/article-renomme → /blogue/article-renomme → /blogue/article-final. À chaque saut, Google perd du signal : et certains outils de crawl s’arrêtent après deux ou trois redirections. Sur les sites qu’on récupère, on trouve souvent des chaînes de 4 à 6 redirections accumulées sur 5-10 ans de migrations successives, sans que personne ait jamais nettoyé. Fix : rediriger directement de la première URL vers la dernière, et supprimer les sauts intermédiaires.

Cas 2 : 302 laissées en place « temporairement » depuis des années

Très commun avec les plugins WordPress configurés à la va-vite ou avec les redirections faites côté Cloudflare en mode « test ». La page reste fonctionnelle pour l’utilisateur, mais Google maintient l’ancienne URL indexée : et n’attribue jamais l’équité à la nouvelle. Symptôme : la nouvelle URL ne ranke pas malgré un contenu identique ou meilleur que l’ancienne. Fix : curl -I sur les anciennes URLs, et reconfigurer en 301 partout où on trouve un 302.

Cas 3 : Variantes avec/sans barre oblique finale non redirigées

/services/seo et /services/seo/ peuvent être traitées comme deux URLs distinctes par Google. Si la migration a redirigé l’une mais pas l’autre, la moitié du trafic continue d’arriver sur une URL non gérée. Fix : s’assurer que le serveur force une seule version canonique (avec ou sans /) et redirige l’autre.

Cas 4 : Migration HTTP → HTTPS partielle

Un site migré vers HTTPS avec le certificat actif, mais sans redirection 301 côté serveur. Résultat : http://exemple.ca/page reste accessible et indexable en parallèle de https://exemple.ca/page. Google voit deux versions du même contenu : duplication, signaux dilués. Fix : redirection 301 forcée HTTP → HTTPS au niveau serveur, et HSTS configuré pour les requêtes futures.

Code et config : exemples réels

Apache : bloc `.htaccess` pour redirections 301

À placer dans le .htaccess à la racine du site. Le bloc RewriteEngine doit être actif (typiquement déjà le cas avec WordPress) :

<IfModule mod_rewrite.c>
RewriteEngine On

# Forcer HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Forcer absence de barre oblique finale (ou inverse selon votre canonique)
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 [L,R=301]

# Redirections individuelles (mappées une par une)
Redirect 301 /services/seo-quebec /referencement-naturel-seo
Redirect 301 /ancien-article /blogue/nouvel-article
Redirect 301 /pdf/brochure-2023.pdf /ressources/brochure
</IfModule>

À noter : Redirect (Apache) accepte des chemins absolus, pas des regex. Pour des patterns complexes, utiliser RewriteRule.

Nginx : directive `return 301` dans le bloc `server`

À placer dans le fichier de configuration du server :

server {
    listen 443 ssl http2;
    server_name exemple.ca;

    # Redirections individuelles
    location = /services/seo-quebec {
        return 301 https://exemple.ca/referencement-naturel-seo;
    }

    location = /ancien-article {
        return 301 https://exemple.ca/blogue/nouvel-article;
    }

    # Redirection regex pour anciennes structures
    location ~ ^/old-blog/(.*)$ {
        return 301 https://exemple.ca/blogue/$1;
    }

    # ... reste de la config
}

# Bloc séparé pour HTTP → HTTPS
server {
    listen 80;
    server_name exemple.ca www.exemple.ca;
    return 301 https://exemple.ca$request_uri;
}

return 301 est plus performant que rewrite ... permanent en Nginx (évite une réécriture inutile).

WordPress : alternative sans toucher au serveur

Pour les contextes où on n’a pas accès au serveur (hébergement mutualisé), les modules de redirections de Rank Math ou le plugin Redirection (gratuit) gèrent les 301 dans la base de données WordPress :

Rank Math → Redirections : interface visuelle, supporte regex, log des redirections déclenchées (utile pour détecter les 404 résiduelles à mapper).
Plugin Redirection (par John Godley) : gratuit, plus léger, idéal si on n’utilise pas Rank Math.

Compromis : ces solutions ajoutent un appel base de données par requête. Pour un site à fort trafic, mieux vaut consolider en .htaccess ou Nginx une fois la liste stabilisée.

Vérifier le bon code de réponse avec `curl`

# Vérifier qu'une redirection retourne bien un 301
curl -I https://exemple.ca/ancienne-url/

# Suivre toute la chaîne de redirections (pour détecter les chaînes 301→301→301)
curl -ILk https://exemple.ca/ancienne-url/

# Vérifier en lot depuis un fichier urls.txt (une URL par ligne)
while read url; do
  echo "$url -> $(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$url")"
done < urls.txt

Sortie attendue : HTTP/2 301 + un seul header Location: vers la nouvelle URL. Tout 302, 307, ou chaîne de plus d’un saut est à corriger.

Spécificité du marché québécois

Deux angles propres au Québec francophone qui changent l’approche des redirections :

Cohérence OQLF des slugs après refonte. Beaucoup de sites refaits passent d’un slug en anglais (/services/seo/) à un slug en français (/referencement-naturel-seo/) dans une même migration. Si les anciennes URLs en anglais ne sont pas redirigées, on perd à la fois le trafic existant et la cohérence linguistique imposée par l’OQLF pour les contenus destinés au public québécois. Les deux concerns convergent : les 301 préservent le SEO et assurent la conformité linguistique en redirigeant l’usager vers la version conforme.
Vacuum francophone et coût de la récupération. Au Québec, sur la majorité des requêtes B2B, les positions gagnées sont relativement stables : il y a peu de concurrence francophone bien optimisée. Mais l’envers : quand on perd ces positions à cause de 301 manquantes, les récupérer demande de reconstruire des liens depuis des sources francophones rares. Le coût de récupération est nettement plus élevé en français qu’en anglais, où l’écosystème de liens éditoriaux est plus dense. Conséquence directe : préparer la carte de redirections AVANT la migration vaut encore plus cher au Québec qu’ailleurs.

À éviter

Chaîner plusieurs redirections. /page-A → /page-B → /page-C fait perdre du signal à chaque saut et ralentit le chargement. Toujours rediriger directement A → C.
Rediriger en masse vers la homepage. Google traite ces redirections comme des soft-404 : elles ne transfèrent pas l’équité SEO. Mappez page par page vers un équivalent thématique.
Laisser les redirections actives ad vitam. Une fois l’ancienne URL sortie de l’index Google (2-6 mois après la 301), les redirections restent en place par sécurité. Mais si après trois ans plus personne ne les atteint, elles deviennent du bruit dans le .htaccess.
Rediriger HTTP vers HTTPS par les paramètres du certificat SSL seulement. Doublez avec une vraie 301 côté serveur : certains outils de crawl ne suivent pas les redirections SSL natives.
Lancer la migration sans valider la carte de redirections ligne par ligne. Une carte de redirections n’est pas un livrable optionnel : c’est le filet de sécurité qui empêche la migration de devenir un événement SEO catastrophique.

Sources

Google Search Central : Redirections et recherche Google (consulté le 2026-04-27)
MDN Web Docs : 301 Moved Permanently (consulté le 2026-04-27)
Apache HTTP Server : mod_rewrite Reference (consulté le 2026-04-27)
Nginx : rewrite module documentation (consulté le 2026-04-27)
Office québécois de la langue française : Politique linguistique : référence pour la cohérence linguistique des URLs (consulté le 2026-04-27)

Voir aussi

Checklist audit SEO pour PME : vérifier les redirections fait partie de tout audit technique
Qu’est-ce qu’une balise canonical? : ne pas confondre canonical et redirection 301

Vous voulez améliorer votre visibilité en ligne ?

Un audit gratuit de votre site — sans engagement, sous 48 h.

Obtenir mon audit gratuit →