Redirection 301 vs 302 : comprendre les différences, l'impact SEO et réussir sa migration de domaine

Par CaptainDNS
Publié le 16 mars 2026

Schéma comparatif des redirections 301 et 302 avec impact SEO, transfert de PageRank et checklist de migration de domaine

TL;DR

301 = redirection permanente, transfère 100 % du ranking SEO vers la destination
302 = redirection temporaire, Google continue d'indexer l'URL source
Une migration de domaine nécessite des 301 sur chaque URL, pas seulement la racine
Les codes 307 et 308 existent pour préserver la méthode HTTP (POST, PUT)
CaptainDNS Redirect Hosting gère les 301/302 avec HTTPS automatique

Changer de nom de domaine, fusionner deux sites, passer de HTTP a HTTPS : toutes ces opérations reposent sur les redirections HTTP. Mal configurées, elles entrainent une perte de 30 a 50 % du trafic organique dans les semaines qui suivent la migration. Bien configurées, elles transmettent l'intégralité de votre autorité SEO vers la nouvelle destination.

La question "faut-il utiliser une 301 ou une 302 ?" revient constamment dans les forums SEO et les discussions entre développeurs. La réponse dépend du contexte, mais les conséquences d'un mauvais choix sont réelles : Google indexe la mauvaise URL, le PageRank se dilue, les backlinks perdent leur valeur. Selon une étude Moz réalisée sur 30 000 domaines, 12 % des migrations de domaine utilisent des redirections 302 au lieu de 301, causant une perte moyenne de trafic organique deux fois plus élevée que les migrations correctement configurées.

Ce guide couvre les 4 codes de redirection HTTP, explique en détail l'impact SEO de chacun, et fournit une checklist complète pour réussir une migration de domaine. Que vous gériez un site vitrine ou un portail de 50 000 pages, les principes restent les memes.

Dernière précision : ce guide traite des redirections cote serveur (status codes HTTP). Les redirections JavaScript ou les balises meta refresh ne sont pas abordées ici car elles posent des problèmes fondamentaux pour le crawl et l'indexation. Pour les cas d'usage marketing (vanity URLs, link tracking, QR codes), un guide complémentaire est disponible dans la section "Guides connexes" en fin d'article.

Les 4 codes de redirection HTTP

Le protocole HTTP définit quatre codes de redirection principaux. Chacun communique une intention différente au navigateur et aux moteurs de recherche.

301 Moved Permanently

Le code 301 signifie que la ressource a été déplacée de facon permanente vers une nouvelle URL. Le serveur répond avec un en-tete Location contenant la destination.

HTTP/1.1 301 Moved Permanently
Location: https://captaindns.com/fr/tools

Comportement du navigateur : le navigateur met en cache la redirection et redirige automatiquement les futures requetes vers la destination, sans repasser par le serveur d'origine. Ce cache persiste meme après fermeture du navigateur.

Défini dans la RFC 7231, section 6.4.2, le code 301 permet aux clients HTTP de transformer une requete POST en GET lors de la redirection. Ce comportement, hérité des premières implémentations HTTP, est la raison pour laquelle le code 308 a été créé.

302 Found

Le code 302 signifie que la ressource est temporairement disponible a une autre URL. Le serveur répond de la meme facon :

HTTP/1.1 302 Found
Location: https://captaindns.com/fr/maintenance

Comportement du navigateur : le navigateur ne met pas en cache la redirection. Chaque requete repasse par le serveur d'origine, qui peut renvoyer une destination différente ou cesser de rediriger.

Défini dans la RFC 7231, section 6.4.3, le code 302 a une histoire compliquée. Dans HTTP/1.0, il signifiait "Moved Temporarily". Les navigateurs ont historiquement transformé les requetes POST en GET lors d'une 302, ce qui ne correspondait pas a la spécification. Le code 303 (See Other) a été créé pour formaliser ce comportement, et le code 307 pour préserver la méthode HTTP.

307 Temporary Redirect

Le code 307 est l'équivalent strict de la 302, mais avec une garantie : la méthode HTTP est préservée. Si le client envoie un POST, la redirection renvoie un POST vers la destination.

HTTP/1.1 307 Temporary Redirect
Location: https://captaindns.com/api/v2/submit

Ce code est défini dans la RFC 7231, section 6.4.7. Il est utilisé principalement pour les formulaires et les API REST ou la préservation de la méthode est critique. Pour les redirections de pages web classiques (GET), la différence entre 302 et 307 est nulle.

308 Permanent Redirect

Le code 308 est l'équivalent strict de la 301, mais avec la meme garantie que le 307 : la méthode HTTP est préservée.

HTTP/1.1 308 Permanent Redirect
Location: https://captaindns.com/api/v2/submit

Défini dans la RFC 7238, le code 308 est le choix correct pour les redirections permanentes d'API ou la méthode HTTP doit etre conservée. Pour les redirections de pages web (GET), 301 et 308 sont fonctionnellement identiques.

Tableau comparatif des 4 codes

Code	Type	Méthode HTTP préservée ?	Cache navigateur ?	Transfert SEO ?
301	Permanent	Non (POST peut devenir GET)	Oui	Oui (100 %)
302	Temporaire	Non (POST peut devenir GET)	Non	Partiel (Google indexe la source)
307	Temporaire	Oui	Non	Partiel (meme comportement que 302)
308	Permanent	Oui	Oui	Oui (meme comportement que 301)

En pratique, pour les redirections de pages web (requetes GET), seuls les codes 301 et 302 sont pertinents. Les codes 307 et 308 sont réservés aux contextes techniques ou la préservation de la méthode HTTP est nécessaire.

Tableau comparatif des 4 codes de redirection HTTP (301, 302, 307, 308) montrant les différences de type, méthode HTTP, cache et transfert SEO

Redirections côté serveur vs JavaScript

Les codes 301, 302, 307 et 308 sont des redirections côté serveur : le serveur envoie un en-tete HTTP Location et le navigateur suit immédiatement. Mais il existe aussi des redirections côté client, implémentées en JavaScript ou via une balise meta refresh.

Redirections côté serveur (HTTP) : Google les détecte et les suit immédiatement lors du crawl. Le transfert de signal SEO est fiable et rapide. C'est la méthode recommandée par Google Search Central pour tout changement d'URL.

Redirections JavaScript (window.location, window.location.replace) : Google doit d'abord télécharger la page HTML, exécuter le JavaScript dans son moteur de rendu (basé sur Chromium), puis découvrir la redirection. Ce processus ajoute un délai significatif. Google classe cette méthode comme un dernier recours, a utiliser uniquement quand la redirection côté serveur est impossible.

Redirections meta refresh (<meta http-equiv="refresh" content="0;url=...">) : Google peut les suivre, mais les déconseille formellement. Le comportement est similaire a une redirection JavaScript : la page doit etre téléchargée et analysée avant que la redirection soit détectée.

Méthode	Détection par Google	Transfert SEO	Cas d'usage
Côté serveur (301/302)	Immédiate	Complet (301) ou partiel (302)	Migrations, changements d'URL
JavaScript	Après rendu	Incertain, souvent partiel	SPA (Single Page Applications)
Meta refresh	Après téléchargement	Déconseillé par Google	Aucun cas recommandé

Le risque principal des redirections JavaScript : si le rendu de la page échoue (erreur JS, timeout, ressource bloquée), Google ne voit tout simplement pas la redirection. La page source reste indexée, la destination est ignorée. Pour les Single Page Applications (SPA) ou la redirection côté serveur est techniquement impossible, le JavaScript est le seul recours, mais il faut alors tester régulièrement que Googlebot détecte bien la redirection (via l'outil d'inspection d'URL dans Search Console).

Comment les navigateurs traitent les redirections ?

Quand un navigateur reçoit un code de redirection, il effectue automatiquement une nouvelle requete vers l'URL indiquée dans l'en-tete Location. Ce processus est transparent pour l'utilisateur : il ne voit qu'un léger délai de chargement.

Pour les redirections 301, le navigateur stocke la correspondance dans un cache local. Les visites suivantes vers l'ancienne URL sont redirigées directement par le navigateur, sans contacter le serveur d'origine. Ce cache est persistant : il survit a la fermeture du navigateur et n'est vidé que lors d'un effacement manuel du cache ou de l'expiration définie par les en-tetes Cache-Control.

Pour les redirections 302, le navigateur ne met pas en cache la correspondance. Chaque visite vers l'ancienne URL déclenche une requete vers le serveur d'origine, qui peut répondre différemment a chaque fois. C'est ce comportement qui rend la 302 adaptée aux redirections dynamiques (géolocalisation, tests A/B, campagnes temporaires).

Cette différence de cache a un impact direct sur les performances. Une 301 économise une requete réseau a chaque visite ultérieure. Une 302 ajoute systématiquement la latence d'un aller-retour HTTP supplémentaire.

Les autres codes de statut HTTP a connaitre

Trois autres codes HTTP sont parfois confondus avec les redirections :

200 OK : la page existe et renvoie du contenu. Pas de redirection. Si la page affiche "Vous allez etre redirigé...", c'est une redirection côté client (JavaScript ou meta refresh), pas une redirection HTTP.
404 Not Found : la page n'existe pas. Si vous supprimez une page sans configurer de redirection, les visiteurs et Googlebot reçoivent une 404. Les backlinks vers cette page perdent toute valeur.
410 Gone : la page a été supprimée définitivement et ne sera pas remplacée. Google traite le 410 comme un signal fort pour retirer la page de l'index. Utilisez le 410 quand il n'y a pas de page de destination pertinente pour une redirection.

301 vs 302 : impact SEO détaillé

C'est la section la plus importante de ce guide. La différence technique entre 301 et 302 semble mineure (permanente vs temporaire), mais les conséquences SEO sont significatives. Comprendre ces différences est essentiel avant de configurer la moindre redirection.

Transfert de PageRank et d'autorité

Le PageRank est le score d'autorité que Google attribue a chaque page en fonction des liens entrants. Quand un site A fait un lien vers votre page, il lui transmet une fraction de son propre PageRank.

Avec une 301 : Google transfère 100 % du PageRank de l'ancienne URL vers la nouvelle. Ce n'a pas toujours été le cas. Avant 2016, Google appliquait une pénalité de 15 % sur le PageRank transmis via une 301. Depuis une mise a jour confirmée par Gary Illyes de l'équipe Google Search, cette pénalité a été supprimée. Une 301 transfère désormais l'intégralité de l'autorité.

Avec une 302 : Google ne transfère pas le PageRank vers la destination. La logique est simple : si la redirection est temporaire, l'URL source est censée revenir. Google conserve donc l'autorité sur l'URL source. Le problème survient quand une 302 reste en place pendant des mois ou des années. Google finit par la traiter comme une 301 de facto, mais le délai est imprévisible et la période de transition cause une perte de ranking.

Indexation et canonicalisation

Le choix 301 vs 302 détermine quelle URL Google affiche dans ses résultats :

Avec une 301 : Google supprime l'ancienne URL de son index et indexe la destination. Les résultats de recherche affichent la nouvelle URL. Ce processus prend généralement quelques jours a quelques semaines selon la fréquence de crawl.

Avec une 302 : Google continue d'indexer l'URL source et l'affiche dans ses résultats. La destination est connue de Google, mais elle n'est pas considérée comme la version canonique. Résultat : vos visiteurs voient l'ancienne URL dans Google, cliquent, sont redirigés vers la nouvelle page, mais les signaux SEO (backlinks, ancienneté, autorité) restent attachés a l'ancienne URL.

Cache navigateur et comptage des visites

La 301 est mise en cache par le navigateur. Apres la première visite, le navigateur redirige directement vers la destination sans contacter le serveur d'origine. Conséquence : vous ne pouvez pas suivre le nombre de redirections, car les visites suivantes ne passent plus par votre serveur.

La 302 n'est pas mise en cache. Chaque visite passe par le serveur d'origine, qui peut compter les requetes, logger les informations du visiteur, et meme changer la destination a la volée. C'est pour cette raison que les vanity URLs et les liens de tracking utilisent des 302.

Chaines de redirection : la perte silencieuse

Une chaine de redirection se produit quand une URL redirige vers une deuxième URL, qui elle-meme redirige vers une troisième, et ainsi de suite. Chaque saut dans la chaine consomme une requete de crawl et ajoute de la latence.

Google suit les chaines de redirection, mais avec des limites. John Mueller a confirmé que Googlebot suit généralement 5 redirections avant d'abandonner. Au-dela, la page finale n'est ni crawlée ni indexée.

Meme en dessous de 5 sauts, chaque redirection intermédiaire dilue potentiellement le signal SEO. La recommandation est de limiter toute chaine a 2 sauts maximum : la source redirige vers la destination finale, point.

Vous pouvez vérifier la présence de chaines de redirection sur vos pages avec le Page Crawl Checker.

Mythes vs réalité

Mythe : la 302 pénalise le SEO. Réalité : la 302 ne pénalise pas directement le SEO. Elle n'est tout simplement pas conçue pour transférer l'autorité. Google n'applique pas de sanction, mais il indexe la mauvaise URL et conserve l'autorité au mauvais endroit. Le résultat ressemble a une pénalité, mais c'est un problème de configuration.

Mythe : une 301 fait perdre du PageRank. Réalité : depuis 2016, une 301 transfère 100 % du PageRank. Cette information a été confirmée par Google a plusieurs reprises. L'ancienne pénalité de 15 % n'existe plus.

Mythe : Google traite les 302 de longue durée comme des 301. Réalité : c'est partiellement vrai. Google peut, après une longue période, décider de traiter une 302 comme une 301. Mais le délai est imprévisible (semaines, mois) et pendant la transition, votre SEO souffre. Ne comptez pas sur ce comportement. Utilisez le bon code des le départ.

Mythe : les redirections côté client (JavaScript, meta refresh) sont équivalentes. Réalité : non. Google peut suivre les redirections JavaScript, mais avec un délai supplémentaire (le rendu de la page doit etre effectué par le moteur de rendu). Les meta refresh sont déconseillées par Google. Seules les redirections côté serveur (301, 302, 307, 308) sont traitées immédiatement et de facon fiable.

Mythe : les 301 sont instantanées pour le SEO. Réalité : non. Après avoir configuré une 301, Google doit re-crawler l'ancienne URL, découvrir la redirection, puis mettre a jour son index. Ce processus prend de quelques jours a plusieurs semaines selon la fréquence de crawl de votre site. Les pages avec beaucoup de trafic et de backlinks sont re-crawlées plus rapidement que les pages profondes avec peu de visites.

HTTPS et redirections : un prérequis indispensable

Le serveur qui héberge les redirections doit impérativement supporter HTTPS. Si un backlink pointe vers https://ancien.captaindns.com/page et que le serveur de redirection ne supporte que HTTP, le navigateur affichera une erreur de certificat au lieu de la redirection.

Avec CaptainDNS Redirect Hosting, le certificat TLS est généré et renouvelé automatiquement via Let's Encrypt. Aucune configuration manuelle n'est nécessaire. Le serveur de redirection répond en HTTPS sur tous les domaines configurés.

Pour les configurations manuelles sur votre propre serveur (Nginx, Apache, Caddy), assurez-vous que :

Le certificat TLS couvre tous les domaines sources (ancien domaine, variantes www, sous-domaines).
Le renouvellement du certificat est automatisé (Let's Encrypt avec certbot ou acme.sh).
Les redirections HTTP vers HTTPS sont configurées en plus des redirections de domaine.

301, canonical ou les deux ? Choisir la bonne approche

Les redirections 301 et les balises rel=canonical sont deux outils qui servent un objectif similaire : indiquer a Google quelle URL est la version préférée. Mais ils fonctionnent de facon très différente et ne s'utilisent pas dans les memes situations.

Quand utiliser une 301 au lieu d'un canonical tag ?

La distinction est simple : la 301 redirige physiquement le visiteur, le canonical ne le fait pas.

Une redirection 301 supprime l'accès a l'URL source. Le visiteur qui tape l'ancienne URL est envoyé automatiquement vers la destination. L'ancienne page n'est plus accessible. C'est le choix correct quand l'URL source n'a plus de raison d'exister.

Un canonical tag (rel=canonical) laisse les deux URLs accessibles. Le visiteur peut toujours accéder a l'URL source et voir son contenu. Le canonical est une indication a Google : parmi ces deux pages au contenu identique ou similaire, voici celle que tu dois indexer. Google peut suivre cette indication ou l'ignorer.

Critère	Redirection 301	Canonical tag
Le visiteur est redirigé ?	Oui	Non, les deux pages sont accessibles
Signal pour Google	Directive forte (obligatoire)	Indication (suggestion, peut etre ignorée)
Les deux URLs existent ?	Non, seule la destination est accessible	Oui, les deux restent en ligne
Transfert de PageRank	100 % vers la destination	Google consolide les signaux sur l'URL canonique
Cas d'usage principal	URL supprimée, migration, changement définitif	Contenu dupliqué, paramètres d'URL, versions paginées

En résumé : si l'ancienne URL ne sert plus a rien, utilisez une 301. Si l'ancienne URL a une raison d'exister (version imprimable, page avec paramètres de tri, variante régionale), utilisez un canonical.

Combiner 301 et canonical

Après une migration de domaine, Google recommande d'utiliser les deux signaux ensemble quand c'est possible. La 301 redirige physiquement les visiteurs et les bots. Le canonical tag sur la page de destination renforce le signal en confirmant que cette URL est bien la version préférée.

Concrètement, après avoir configuré vos redirections 301 depuis l'ancien domaine vers le nouveau, ajoutez sur chaque page de destination un canonical tag qui pointe vers elle-meme :

<link rel="canonical" href="https://captaindns.com/fr/tools" />

Ce double signal est particulièrement utile quand votre contenu est accessible via plusieurs chemins (ancien domaine redirigé, variante www, version HTTP). Google reçoit un message cohérent de toutes les sources : la destination est bien l'URL canonique.

La combinaison 301 + canonical n'est pas obligatoire, mais elle accélère la convergence dans l'index Google et réduit le risque que Google choisisse la mauvaise URL comme version canonique pendant la période de transition.

Quand utiliser une 301 ?

La 301 est le choix par défaut pour toute redirection définitive. Voici les cas d'usage les plus fréquents.

Migration de domaine définitive

Vous changez de nom de domaine. L'ancien domaine ne sera plus utilisé pour du contenu. Chaque URL de l'ancien domaine doit etre redirigée en 301 vers son équivalent sur le nouveau domaine.

ancien-site.captaindns.com/blog/article-1
→ 301 → captaindns.com/fr/blog/article-1

Consolidation de plusieurs domaines

Vous possédez plusieurs domaines (variantes orthographiques, extensions pays, domaines marketing) et souhaitez concentrer l'autorité SEO sur un seul.

captaindns.fr → 301 → captaindns.com
captaindns.de → 301 → captaindns.com

Changement d'URL permanent

Refonte du site, changement de CMS, nouvelle architecture d'URLs. Les anciennes URLs n'existent plus et ne reviendront pas.

captaindns.com/products/dns-check
→ 301 → captaindns.com/fr/tools/dns/test-propagation

Passage HTTP vers HTTPS

Le passage de HTTP a HTTPS est permanent. Toutes les URLs HTTP doivent etre redirigées en 301 vers leur équivalent HTTPS.

http://captaindns.com/fr/tools
→ 301 → https://captaindns.com/fr/tools

Naked domain vers www (ou inversement)

Vous choisissez une version canonique de votre domaine. L'autre version redirige en 301.

www.captaindns.com → 301 → captaindns.com

ou inversement :

captaindns.com → 301 → www.captaindns.com

Tableau récapitulatif : cas d'usage 301

Situation	Exemple	Pourquoi 301 ?
Migration de domaine	ancien.captaindns.com vers captaindns.com	Le domaine source ne servira plus de contenu
Consolidation multi-domaines	captaindns.fr vers captaindns.com	Concentrer l'autorité SEO sur un domaine unique
Changement d'URL (refonte)	/products/ vers /fr/tools/	L'ancienne structure d'URL est abandonnée
HTTP vers HTTPS	http:// vers https://	Le passage au HTTPS est définitif
www vs non-www	www.captaindns.com vers captaindns.com	Une seule version canonique du domaine

Quand utiliser une 302 ?

La 302 est le choix correct quand la redirection est temporaire : vous prévoyez de rétablir l'URL source dans son état d'origine.

Campagnes marketing temporaires

Vous créez une vanity URL pour une campagne limitée dans le temps. La redirection sera désactivée a la fin de la campagne.

promo.captaindns.com → 302 → captaindns.com/fr/pricing
(pendant la campagne de mars 2026)

Tests A/B

Vous redirigez une fraction du trafic vers une variante de page pour tester un nouveau design ou un nouveau contenu. La redirection sera retirée une fois le test terminé.

Maintenance planifiée

Votre site est en maintenance. Vous redirigez temporairement le trafic vers une page d'information. Le site reviendra a son état normal après la maintenance.

captaindns.com/fr/tools → 302 → captaindns.com/fr/maintenance

Géolocalisation et détection de langue

Vous redirigez les visiteurs vers une version localisée de votre site en fonction de leur adresse IP ou de la langue de leur navigateur. La redirection est conditionnelle et ne doit pas etre mise en cache, car un meme utilisateur pourrait visiter depuis un autre pays.

captaindns.com → 302 → captaindns.com/fr/ (visiteur francais)
captaindns.com → 302 → captaindns.com/en/ (visiteur anglais)

Redirections conditionnelles (mobile/desktop)

Vous redirigez les visiteurs mobiles vers une version dédiée. Cette pratique est de moins en moins courante (le responsive design l'a largement remplacée), mais elle existe encore sur certains sites.

Tableau récapitulatif : cas d'usage 302

Situation	Exemple	Pourquoi 302 ?
Campagne marketing	promo.captaindns.com vers landing page	Redirection temporaire, sera désactivée
Test A/B	50 % du trafic vers variante B	Test limité dans le temps
Maintenance	Site vers page maintenance	Le site reviendra
Géolocalisation	Racine vers version locale	Conditionnelle, ne doit pas etre mise en cache
Mobile redirect	Site vers version mobile	Conditionnelle selon le device

Migration de domaine : la checklist complète

Checklist de migration de domaine en 5 étapes : audit des URLs, configuration des redirections 301, pointage DNS, Search Console et monitoring sur 90 jours

La migration de domaine est l'opération la plus risquée en SEO. Voici la checklist complète pour minimiser les pertes.

Avant la migration : audit et inventaire

1. Lister toutes les URLs indexées

Exportez la liste complète des URLs indexées depuis Google Search Console (rapport "Pages"). Complétez avec un crawl complet de votre site (Screaming Frog, Sitebulb ou tout autre crawler).

L'objectif : avoir un inventaire exhaustif de chaque URL qui reçoit du trafic ou des backlinks.

2. Identifier les pages a forte valeur

Classez vos URLs par trafic organique (Google Analytics) et par nombre de backlinks (Ahrefs, Moz, Semrush). Les 20 % de pages qui génèrent 80 % du trafic sont votre priorité absolue. Toute erreur de redirection sur ces pages aura un impact immédiat et visible.

3. Créer le plan de redirection 1:1

Chaque URL de l'ancien domaine doit correspondre a une URL sur le nouveau domaine. Pas de redirection générique vers la homepage. Un tableau simple suffit :

URL source	URL destination	Statut
ancien.captaindns.com/	captaindns.com/fr/	A configurer
ancien.captaindns.com/blog/article-1	captaindns.com/fr/blog/article-1	A configurer
ancien.captaindns.com/contact	captaindns.com/fr/contact	A configurer

Si certaines pages n'ont pas d'équivalent sur le nouveau domaine, redirigez-les vers la page la plus pertinente (pas la homepage par défaut).

4. Vérifier le contenu du nouveau domaine

Avant d'activer les redirections, assurez-vous que chaque page de destination existe et fonctionne. Une redirection 301 vers une page 404 est pire que pas de redirection du tout : Google voit une page d'erreur et déclasse l'URL.

5. Sauvegarder les données existantes

Avant toute modification, exportez un snapshot complet :

Export CSV de toutes les URLs indexées depuis Search Console
Export des positions de recherche (Semrush, Ahrefs ou autre outil de tracking)
Export des backlinks de l'ancien domaine
Screenshot des statistiques de trafic organique des 90 derniers jours

Ces données serviront de référence pour mesurer l'impact de la migration et détecter les anomalies après le basculement.

Configurer les redirections 301

5. Mettre en place les redirections sur chaque URL

La règle fondamentale : chaque URL doit etre redirigée individuellement. Rediriger uniquement la racine (ancien.captaindns.com vers captaindns.com) ne suffit pas. Les pages profondes, les articles de blog, les fiches produits doivent chacun avoir leur propre redirection.

Si votre nouveau site conserve la meme structure d'URL, vous pouvez utiliser une règle de path forwarding. Le chemin de l'ancienne URL est automatiquement ajouté a la destination :

ancien.captaindns.com/* → 301 → captaindns.com/*

Avec CaptainDNS Redirect Hosting, activez l'option "Path forwarding" pour transmettre automatiquement le chemin de l'URL source vers la destination.

6. Gérer les 4 variantes de chaque URL

Chaque URL existe potentiellement en 4 versions :

http://ancien.captaindns.com/page
https://ancien.captaindns.com/page
http://www.ancien.captaindns.com/page
https://www.ancien.captaindns.com/page

Les 4 versions doivent aboutir a la meme destination. Oublier une variante, c'est laisser des backlinks sans redirection.

Vérifier le DNS

7. Configurer les enregistrements DNS

Pour que les redirections fonctionnent, le domaine source doit résoudre vers le serveur de redirection. Si vous utilisez CaptainDNS Redirect Hosting, créez un enregistrement CNAME ou A/AAAA pointant vers le service de redirection.

8. Vérifier la propagation DNS

Après avoir modifié les enregistrements DNS, vérifiez que la propagation est effective dans toutes les régions avec le test de propagation DNS. La propagation complète peut prendre de quelques minutes a 48 heures selon le TTL précédent.

Google Search Console : outil Change of Address

9. Déclarer le changement dans Google Search Console

Google fournit un outil dédié dans Search Console : "Change of Address" (Paramètres > Changement d'adresse). Cet outil :

Vérifie que les redirections 301 sont correctement configurées
Accélère la mise a jour de l'index Google
Transfère les signaux de l'ancien domaine vers le nouveau

Prérequis : les deux domaines (ancien et nouveau) doivent etre vérifiés dans Google Search Console.

10. Soumettre le nouveau sitemap

Soumettez le sitemap XML du nouveau domaine dans Google Search Console. Vérifiez que toutes les URLs du sitemap renvoient un code 200. Supprimez le sitemap de l'ancien domaine une fois la migration terminée et l'index mis a jour.

Monitoring post-migration

11. Surveiller le trafic organique (30/60/90 jours)

Une baisse temporaire du trafic organique (10 a 20 %) est normale dans les 2 a 4 semaines suivant une migration. Au-dela, il y a un problème. Surveillez :

Semaine 1-2 : Google commence a crawler le nouveau domaine. Le trafic peut baisser de 10 a 30 %.
Semaine 3-4 : le trafic devrait se stabiliser et commencer a remonter.
Mois 2-3 : le trafic devrait retrouver son niveau pré-migration, voire le dépasser si le nouveau site est de meilleure qualité.

12. Vérifier les erreurs dans Search Console

Consultez le rapport "Pages" dans Google Search Console pour identifier les erreurs 404, les erreurs de redirection et les problèmes d'indexation. Corrigez immédiatement les URLs qui retournent des erreurs.

13. Monitorer les backlinks

Vérifiez que les backlinks de l'ancien domaine sont bien redirigés vers le nouveau. Utilisez Ahrefs ou un outil similaire pour identifier les backlinks qui retournent une erreur 404 au lieu d'une redirection 301.

14. Vérifier les positions de recherche

Suivez vos mots-clés stratégiques dans un outil de suivi de positions (Semrush, Ahrefs, Sistrix). Comparez les positions avant et après migration. Un mot-clé qui chute de plus de 10 positions après 4 semaines indique probablement une erreur de redirection sur la page correspondante.

Créez un tableau de suivi avec vos 50 mots-clés les plus importants :

Mot-clé	Position avant	Position J+7	Position J+30	Position J+90
redirection dns	5	8	6	4
test propagation dns	3	7	4	3
vérification email spf	12	18	14	11

Une remontée progressive est le signe que la migration se déroule correctement. Une stagnation a J+30 nécessite une investigation (redirections manquantes, contenu modifié, problèmes techniques).

Durée de maintien des redirections

14. Combien de temps maintenir les redirections ?

Google recommande de maintenir les redirections 301 de facon permanente si possible. En pratique :

Minimum 6 mois : en dessous, Google n'a pas eu le temps de re-crawler toutes vos pages et de mettre a jour son index.
Recommandé 1 an : la grande majorité des signaux SEO auront été transférés.
Idéal : permanent : tant que l'ancien domaine est actif, les redirections doivent fonctionner. Des backlinks sur des sites tiers continueront de pointer vers l'ancien domaine pendant des années.

Si vous laissez expirer l'ancien domaine, les redirections cessent évidemment de fonctionner. Les backlinks qui pointaient vers l'ancien domaine retourneront une erreur DNS. C'est pourquoi il est recommandé de conserver l'ancien domaine et de renouveler son enregistrement aussi longtemps que possible.

Un risque supplémentaire existe : si votre ancien domaine expire et qu'un tiers le rachète, il peut récupérer les backlinks qui pointaient encore vers l'ancien domaine. Dans le meilleur des cas, il affiche du contenu sans rapport. Dans le pire des cas, il exploite la réputation de vos anciens backlinks pour héberger du contenu malveillant ou du spam. Renouvelez l'enregistrement de votre ancien domaine pendant au moins 3 ans après la migration.

Planning semaine par semaine

Une migration de domaine se prépare plusieurs semaines a l'avance. Voici un calendrier type pour structurer les étapes et éviter les oublis.

Semaine	Action	Vérification
S-4	Audit complet des URLs, inventaire des backlinks	Liste exhaustive exportée
S-3	Configurer les redirections 301 sur le serveur	Tester chaque redirection avec curl
S-2	Déclarer le nouveau domaine dans Search Console	Vérification de propriété validée
S-1	Derniers tests, backup sitemap de l'ancien domaine	Toutes les redirections fonctionnent
J-0	Activer les redirections, soumettre le Change of Address	Vérifier les premières heures en temps réel
S+1	Monitorer l'indexation et le trafic quotidiennement	Search Console et Analytics consultés chaque jour
S+4	Premier bilan a 30 jours	Comparaison trafic avant et après migration
S+8	Deuxième bilan a 60 jours	Stabilisation attendue du trafic organique
S+12	Bilan final a 90 jours	Décision : conserver ou ajuster les redirections

Ce calendrier est indicatif. Pour les sites volumineux (plusieurs milliers de pages), prévoyez une semaine supplémentaire pour l'audit et le mapping des URLs.

Cas réel : migration HTTP vers HTTPS

Le passage de HTTP a HTTPS est la migration la plus fréquente. Google considère HTTP et HTTPS comme deux sites distincts. Chaque URL HTTP doit etre redirigée en 301 vers son équivalent HTTPS.

Le processus est identique a un changement de domaine classique :

Obtenir un certificat TLS pour votre domaine (Let's Encrypt, ou tout autre fournisseur)
Configurer le serveur pour répondre en HTTPS
Rediriger chaque URL HTTP en 301 vers HTTPS (pas uniquement la homepage)
Mettre a jour les liens internes pour pointer vers les URLs HTTPS
Déclarer la version HTTPS dans Google Search Console
Soumettre le sitemap avec les URLs HTTPS

Erreur courante : ne rediriger que la homepage HTTP vers HTTPS et oublier les pages internes. Résultat : les pages profondes restent accessibles en HTTP, Google les considère comme des doublons, et l'autorité SEO est fragmentée entre les deux versions.

Point important : Google Search Console traite HTTP et HTTPS comme des propriétés distinctes. Vous devez soumettre les deux versions (propriété HTTP et propriété HTTPS) pour avoir une vue complète de l'indexation pendant la transition. Utilisez l'outil Change of Address pour accélérer le processus.

Impact sur le crawl budget et les Core Web Vitals

Les redirections n'affectent pas uniquement l'indexation et le transfert d'autorité. Elles ont aussi un impact mesurable sur deux aspects techniques du SEO : le budget de crawl et les performances de chargement.

Crawl budget et redirections

Googlebot dispose d'un budget de crawl limité pour chaque site : un nombre de pages qu'il peut explorer dans un intervalle de temps donné. Ce budget dépend de la taille du site, de sa popularité et de la capacité du serveur a répondre rapidement.

Chaque redirection consomme une unité de ce budget. Quand Googlebot rencontre une 301, il compte une requete pour l'URL source (qui retourne la redirection) puis une deuxième requete pour la destination. Une chaine de 3 redirections consomme donc 4 requetes pour une seule page de contenu.

Pour les petits sites (quelques centaines de pages), l'impact est négligeable. Pour les sites volumineux avec des milliers de redirections actives, la consommation de crawl budget peut devenir significative. Googlebot passe du temps a suivre des redirections au lieu de crawler du contenu nouveau.

Recommandations :

Minimisez le nombre de redirections sur les pages a fort trafic et a forte valeur SEO
Éliminez les chaines de redirections en pointant directement vers la destination finale
Après une migration, une fois l'index mis a jour (6 a 12 mois), les redirections consomment moins de crawl budget car Googlebot apprend progressivement les nouvelles URLs

Impact sur les Core Web Vitals

Les Core Web Vitals sont les métriques de performance utilisateur mesurées par Google : LCP (Largest Contentful Paint), INP (Interaction to Next Paint) et CLS (Cumulative Layout Shift). Ces métriques influencent le ranking depuis 2021.

Chaque redirection ajoute un aller-retour réseau (RTT) entre le navigateur et le serveur. En pratique, cela représente 100 a 300 ms supplémentaires par saut, selon la latence réseau et la localisation géographique du visiteur.

Impact par métrique :

LCP : directement affecté. Le temps de chargement du contenu principal augmente de 100 a 300 ms par redirection. Sur mobile avec une connexion lente, l'impact peut dépasser 500 ms par saut.
CLS : aucun impact. Les redirections se produisent avant l'affichage de la page, elles ne causent pas de décalages visuels.
INP : aucun impact. Les redirections n'affectent pas la réactivité de la page une fois chargée.

Bonne nouvelle : les redirections 301 mises en cache par le navigateur n'ont aucun impact sur les Core Web Vitals après la première visite. Le navigateur redirige localement, sans aller-retour réseau. C'est un argument supplémentaire en faveur des 301 par rapport aux 302 pour les redirections permanentes.

Pour mesurer l'impact réel des redirections sur vos Core Web Vitals, utilisez Chrome DevTools (onglet Performance) ou les données de terrain dans Google Search Console (rapport Core Web Vitals).

Erreurs courantes qui détruisent le SEO

Utiliser 302 au lieu de 301 pour une migration

C'est l'erreur la plus fréquente. Un développeur configure des redirections 302 "temporaires" pour une migration définitive. Résultat : Google continue d'indexer l'ancien domaine, le PageRank n'est pas transféré, et le nouveau domaine part de zéro en termes d'autorité.

Le correctif est simple : changez toutes les redirections 302 en 301. L'effet n'est pas immédiat (Google doit re-crawler les URLs), mais le transfert d'autorité finira par s'effectuer.

Rediriger toutes les URLs vers la homepage

Vous redirigez ancien.captaindns.com/blog/article-1, ancien.captaindns.com/blog/article-2 et ancien.captaindns.com/contact vers captaindns.com. Google considère ces redirections comme des soft 404 : le contenu de la page de destination ne correspond pas a ce que l'ancienne URL promettait.

Résultat : Google ignore ces redirections et déclasse les URLs. Les backlinks qui pointaient vers vos articles de blog perdent leur valeur, car ils redirigent vers une page sans rapport.

La solution : une redirection 1:1. Chaque ancienne URL redirige vers la page équivalente sur le nouveau domaine. Si une page n'a pas d'équivalent exact, redirigez-la vers la page thématiquement la plus proche. Par exemple, un article de blog supprimé peut etre redirigé vers un article connexe qui traite du meme sujet, ou vers la page de catégorie correspondante.

Chaines de redirections

Situation typique : lors d'une première migration, site-v1.captaindns.com a été redirigé vers site-v2.captaindns.com. Lors d'une deuxième migration, site-v2.captaindns.com a été redirigé vers captaindns.com. Résultat : une chaine a 3 sauts.

site-v1.captaindns.com → 301 → site-v2.captaindns.com → 301 → captaindns.com

Chaque saut ajoute de la latence et consomme une requete de crawl. Au-dela de 5 sauts, Googlebot abandonne. Meme a 3 sauts, le signal SEO se dilue.

Corrigez en mettant a jour les anciennes redirections pour pointer directement vers la destination finale :

site-v1.captaindns.com → 301 → captaindns.com
site-v2.captaindns.com → 301 → captaindns.com

Boucles de redirection

Une boucle de redirection se produit quand l'URL A redirige vers l'URL B, qui redirige vers l'URL A. Le navigateur affiche l'erreur ERR_TOO_MANY_REDIRECTS. Le crawler Google abandonne immédiatement.

Les boucles sont souvent causées par des conflits entre règles de redirection. Exemples classiques :

Le serveur redirige http vers https, et un plugin redirige https vers http.
Le serveur redirige www vers non-www, et le CDN redirige non-www vers www.
Deux règles de redirection se chevauchent dans le fichier .htaccess ou la configuration Nginx.

La solution : testez chaque URL dans un navigateur en mode incognito et vérifiez les en-tetes de réponse avec curl -I ou le Page Crawl Checker.

Oublier les variantes www, non-www, HTTP, HTTPS

Un site accessible via 4 URLs différentes (http://, https://, http://www., https://www.) doit rediriger les 3 variantes non canoniques vers la version choisie.

Oublier une variante signifie que les backlinks pointant vers cette version ne sont pas redirigés. Ils retournent soit une erreur, soit une page non canonique que Google peut indexer comme doublon.

Vérifiez systématiquement les 4 combinaisons pour chaque domaine impliqué dans la migration.

Voici un exemple concret de test pour un domaine :

curl -I http://captaindns.com/fr/tools       → doit retourner 301 vers https://captaindns.com/fr/tools
curl -I http://www.captaindns.com/fr/tools    → doit retourner 301 vers https://captaindns.com/fr/tools
curl -I https://www.captaindns.com/fr/tools   → doit retourner 301 vers https://captaindns.com/fr/tools
curl -I https://captaindns.com/fr/tools       → doit retourner 200 (URL canonique)

Supprimer les redirections trop tot

Certaines équipes suppriment les redirections 301 après quelques semaines, pensant que Google a eu le temps de mettre a jour son index. En réalité, Google ne re-crawle pas toutes les pages au meme rythme. Les pages profondes avec peu de backlinks peuvent ne pas etre re-crawlées avant plusieurs mois.

De plus, les backlinks sur des sites tiers sont hors de votre controle. Un article de blog publié en 2020 qui fait un lien vers votre ancien domaine continuera de générer des clics pendant des années. Si la redirection est supprimée, ces visiteurs atterrissent sur une erreur 404 ou, pire, sur un domaine racheté par un tiers.

Ne pas monitorer après la migration

La migration est en place, les redirections fonctionnent, le sitemap est soumis. Travail terminé ? Non. Sans monitoring, vous ne détecterez pas les problèmes qui apparaissent dans les semaines suivantes :

Pages 404 sur le nouveau domaine (contenu supprimé ou URL mal configurée)
Redirections cassées (certificat expiré, serveur de redirection en panne)
Indexation bloquée (robots.txt trop restrictif sur le nouveau domaine)
Baisse anormale du trafic sur certaines sections du site

Consultez Google Search Console chaque semaine pendant les 3 premiers mois. Configurez des alertes sur les baisses de trafic significatives dans Google Analytics.

Ignorer les emails et newsletters qui contiennent des liens vers l'ancien domaine

Vos emails marketing, vos newsletters archivées et vos documents PDF contiennent des liens vers l'ancien domaine. Ces liens continueront d'etre cliqués pendant des mois, voire des années. Si les redirections ne sont pas en place, vos abonnés atterrissent sur des erreurs.

Faites l'inventaire de tous les canaux qui diffusent des liens vers votre domaine : signatures email, templates de newsletters, brochures PDF, présentations PowerPoint, profils de réseaux sociaux. Mettez a jour les liens quand c'est possible, mais comptez sur les redirections pour tout ce que vous ne pouvez pas modifier (emails déja envoyés, PDF déja téléchargés).

N'oubliez pas les liens dans les applications mobiles, les intégrations partenaires et les widgets embarqués sur des sites tiers. Ces sources sont souvent invisibles dans les audits de backlinks mais génèrent un trafic significatif.

Utiliser des redirections JavaScript au lieu de redirections serveur

Certaines équipes implémentent des redirections via meta refresh ou window.location au lieu de configurer des redirections côté serveur. Ce choix est problématique pour le SEO.

Les redirections JavaScript nécessitent que le moteur de recherche télécharge la page HTML, exécute le JavaScript, puis découvre la redirection. Google peut le faire (son crawler utilise un moteur de rendu basé sur Chromium), mais avec un délai significatif. Les autres moteurs de recherche (Bing, Yandex) ne suivent pas toujours les redirections JavaScript.

Résultat concret : pendant la période de transition, l'indexation est plus lente, le transfert de signal SEO est incertain, et certains bots ne voient tout simplement pas la redirection. Si vous avez accès a la configuration du serveur (Nginx, Apache, Caddy, CDN), utilisez toujours des redirections HTTP côté serveur. Réservez le JavaScript aux cas ou la redirection serveur est techniquement impossible, comme les Single Page Applications hébergées sur un CDN statique.

Ne pas informer Google via Search Console

L'outil Change of Address dans Google Search Console est conçu spécifiquement pour accélérer les migrations de domaine dans l'index Google. Pourtant, de nombreuses migrations sont effectuées sans utiliser cet outil.

Sans le Change of Address, Google doit découvrir la migration par lui-meme en crawlant l'ancien domaine et en suivant les redirections. Ce processus peut prendre plusieurs semaines, voire plusieurs mois pour les sites volumineux. Pendant ce temps, l'ancien domaine reste dans l'index et le nouveau domaine n'hérite pas encore de toute l'autorité.

Avec le Change of Address, Google reçoit un signal explicite : l'ancien domaine a migré vers le nouveau. Google vérifie que les redirections 301 sont en place, puis accélère la mise a jour de son index. L'outil est disponible dans Search Console, section Paramètres, puis Changement d'adresse. Les deux domaines (ancien et nouveau) doivent etre vérifiés dans Search Console.

Cas d'usage concrets avec CaptainDNS

Migration de sous-domaine vers le domaine principal

Vous hébergez votre blog sur blog.captaindns.com et décidez de le rapatrier sur captaindns.com/fr/blog pour consolider l'autorité SEO.

Configuration :

Créez une redirection 301 avec path forwarding sur blog.captaindns.com
Destination : captaindns.com/fr/blog
Activez le transfert de chemin pour que blog.captaindns.com/article-1 redirige vers captaindns.com/fr/blog/article-1

Résultat : les backlinks vers le blog, qui renforçaient uniquement le sous-domaine, bénéficient désormais au domaine principal. L'autorité de domaine se concentre sur une seule entité au lieu d'etre dispersée.

Points d'attention :

Mettez a jour les liens internes du site principal pour pointer vers les nouvelles URLs (/fr/blog/...) et non vers l'ancien sous-domaine.
Mettez a jour le sitemap pour inclure les URLs du blog sous le domaine principal.
Si le blog avait son propre profil Search Console, déclarez le changement d'adresse.

Consolidation de plusieurs sous-domaines

Vous possédez shop.captaindns.com, docs.captaindns.com et status.captaindns.com. Vous décidez de tout regrouper sous captaindns.com.

Configuration :

Sous-domaine	Destination	Path forwarding
shop.captaindns.com	captaindns.com/fr/pricing	Oui
docs.captaindns.com	captaindns.com/fr/docs	Oui
status.captaindns.com	captaindns.com/fr/status	Non (page unique)

Chaque sous-domaine est configuré en 301 avec CaptainDNS Redirect Hosting. Le path forwarding préserve la structure d'URL pour les deux premiers sous-domaines.

Bénéfice SEO : au lieu de répartir l'autorité de domaine sur 4 entités distinctes (domaine principal + 3 sous-domaines), toute l'autorité est consolidée sur le domaine principal. Les backlinks acquis par la documentation ou la boutique renforcent désormais l'ensemble du site.

Piège a éviter : si vos sous-domaines avaient des certificats TLS distincts, assurez-vous que le certificat du domaine principal couvre aussi les chemins de destination. Un certificat wildcard (*.captaindns.com) simplifie la gestion.

Refonte avec changement de structure d'URLs

Vous passez d'une structure plate (captaindns.com/dns-check) a une structure hiérarchique (captaindns.com/fr/tools/dns/test-propagation).

Ce cas nécessite un plan de redirection 1:1, car la structure change complètement. Le path forwarding ne suffit pas.

Ancienne URL	Nouvelle URL
captaindns.com/dns-check	captaindns.com/fr/tools/dns/test-propagation
captaindns.com/spf-check	captaindns.com/fr/tools/email-authentication/spf-check
captaindns.com/dkim-check	captaindns.com/fr/tools/email-authentication/dkim-check

Créez une redirection 301 individuelle pour chaque URL. Pas de raccourci possible.

Passage CMS avec nouvelles URLs

Vous migrez de WordPress (captaindns.com/2025/03/mon-article) vers un CMS headless avec des URLs propres (captaindns.com/fr/blog/mon-article).

Le changement de CMS modifie souvent la structure des URLs de blog. Les permalinks WordPress incluent la date, le nouveau CMS utilise un slug simple. Chaque ancienne URL WordPress doit etre redirigée en 301 vers la nouvelle URL.

captaindns.com/2025/03/mon-article → 301 → captaindns.com/fr/blog/mon-article
captaindns.com/2025/04/autre-article → 301 → captaindns.com/fr/blog/autre-article

Exportez la liste complète des permalinks WordPress et mappez chacun vers la nouvelle URL avant de couper l'ancien CMS.

Astuce : si votre nouveau CMS utilise les memes slugs que WordPress (le titre de l'article en minuscules avec des tirets), vous pouvez créer une règle de réécriture qui supprime le préfixe date et ajoute le préfixe /fr/blog/. Cela réduit considérablement le travail de mapping pour les sites avec des centaines d'articles.

Internationalisation et redirection par langue

Vous lancez des versions localisées de votre site. L'URL /tools/dns-check devient /fr/tools/dns-check, /en/tools/dns-check, /de/tools/dns-check, etc.

Pour les anciennes URLs sans préfixe de langue, deux approches :

Approche 1 : redirection 301 vers la locale par défaut

Redirigez les anciennes URLs vers la version de la langue principale :

captaindns.com/tools/dns-check → 301 → captaindns.com/fr/tools/dns-check

Simple a configurer, mais les visiteurs anglophones qui avaient un backlink vers /tools/dns-check atterrissent sur la version française.

Approche 2 : redirection 302 avec détection de langue

Redirigez les anciennes URLs vers la version localisée en fonction de l'en-tete Accept-Language du navigateur. Utilisez une 302 car la redirection est conditionnelle :

captaindns.com/tools/dns-check → 302 → captaindns.com/fr/tools/dns-check (visiteur FR)
captaindns.com/tools/dns-check → 302 → captaindns.com/en/tools/dns-check (visiteur EN)

Plus complexe a configurer, mais offre une meilleure expérience utilisateur. Assurez-vous d'implémenter les balises hreflang sur les pages de destination pour aider Google a comprendre la structure multilingue.

Plan d'action recommandé

Auditer vos URLs existantes : exportez la liste des pages indexées depuis Google Search Console et identifiez les pages a forte valeur (trafic, backlinks).
Choisir le bon code de redirection : migration permanente = 301. Campagne temporaire = 302. En cas de doute, posez-vous la question : l'ancienne URL reviendra-t-elle un jour ? Si non, utilisez une 301.
Créer le plan de redirection 1:1 : chaque ancienne URL doit correspondre a une URL de destination. Pas de redirection générique vers la homepage.
Configurer les redirections : utilisez le Redirect Hosting CaptainDNS pour créer les redirections 301/302 avec HTTPS automatique et transfert de chemin.
Vérifier la propagation DNS : confirmez que les enregistrements DNS pointent vers le serveur de redirection avec le test de propagation DNS.
Déclarer le changement dans Google Search Console : utilisez l'outil "Change of Address" et soumettez le nouveau sitemap.
Monitorer pendant 90 jours : suivez le trafic organique, les erreurs de crawl et les positions dans Search Console. Corrigez immédiatement les problèmes détectés.

Configurez vos redirections maintenant : utilisez le Redirect Hosting CaptainDNS pour créer des redirections 301/302 avec HTTPS automatique et transfert de chemin.

FAQ

Quelle est la différence entre une redirection 301 et 302 ?

La 301 est une redirection permanente : elle indique aux navigateurs et aux moteurs de recherche que l'URL a définitivement changé. La 302 est une redirection temporaire : elle indique que l'URL actuelle est temporairement accessible a une autre adresse. La différence principale pour le SEO est que la 301 transfère l'autorité (PageRank) vers la destination, alors que la 302 conserve l'autorité sur l'URL source.

Une redirection 302 pénalise-t-elle le SEO ?

Non, la 302 ne pénalise pas le SEO au sens strict. Google n'applique pas de sanction. Le problème est que Google continue d'indexer l'URL source et n'y transfère pas l'autorité. Si vous utilisez une 302 pour une migration permanente, Google indexe la mauvaise URL et votre nouveau domaine ne bénéficie pas des backlinks. Ce n'est pas une pénalité, mais le résultat est similaire : perte de trafic organique.

Combien de temps faut-il maintenir les redirections après une migration ?

Minimum 6 mois, recommandé 1 an, idéal permanent. Google a besoin de temps pour re-crawler toutes vos pages et mettre a jour son index. Les backlinks sur des sites tiers continueront de pointer vers l'ancien domaine pendant des années. Tant que l'ancien domaine est enregistré, les redirections devraient rester actives.

Que se passe-t-il si j'utilise une 302 au lieu d'une 301 ?

Google continue d'indexer l'ancienne URL et ne transfère pas le PageRank vers la destination. Votre nouveau domaine ne bénéficie pas de l'autorité accumulée par l'ancien. Avec le temps, Google peut finir par traiter la 302 comme une 301, mais le délai est imprévisible. Le correctif est de remplacer toutes les 302 par des 301. Google re-crawlera les URLs et mettra a jour son index.

Les redirections en chaine affectent-elles le SEO ?

Oui. Chaque saut dans une chaine de redirection consomme une requete de crawl et ajoute de la latence. Googlebot suit généralement jusqu'a 5 redirections avant d'abandonner. Au-dela, la page finale n'est ni crawlée ni indexée. Meme en dessous de 5 sauts, le signal SEO peut se diluer. Limitez toute chaine a 2 sauts maximum et corrigez les anciennes redirections pour pointer directement vers la destination finale.

Comment vérifier qu'une redirection fonctionne correctement ?

Plusieurs méthodes. En ligne de commande, utilisez curl -I URL pour afficher les en-tetes de réponse HTTP et vérifier le code de statut (301 ou 302) et l'en-tete Location. Dans un navigateur, ouvrez les outils développeur (onglet Réseau) et observez la chaine de requetes. Vous pouvez aussi utiliser le Page Crawl Checker pour vérifier les redirections et détecter les chaines.

Faut-il rediriger chaque URL individuellement ?

Oui, dans l'idéal. Chaque ancienne URL doit rediriger vers la page équivalente sur le nouveau domaine (redirection 1:1). Si la structure d'URL est conservée, le path forwarding simplifie la configuration : le chemin de l'ancienne URL est transmis automatiquement a la destination. Si la structure change, vous devez mapper chaque URL manuellement.

Google suit-il les redirections JavaScript ?

Google peut suivre les redirections JavaScript, mais avec des limitations. Le contenu de la page doit d'abord etre rendu par le moteur de rendu de Google, ce qui ajoute un délai. De plus, toutes les redirections JavaScript ne sont pas détectées de facon fiable. Google recommande d'utiliser des redirections côté serveur (301, 302) pour les changements d'URL importants.

Quelle est la différence entre 301 et 308 ?

Les deux sont des redirections permanentes avec transfert complet du SEO. La différence est technique : la 301 permet au navigateur de transformer une requete POST en GET lors de la redirection, alors que la 308 préserve la méthode HTTP d'origine (un POST reste un POST). Pour les pages web classiques (requetes GET), 301 et 308 sont fonctionnellement identiques. Le code 308 est principalement utilisé pour les API.

Combien de redirections Google suit-il avant d'abandonner ?

Google suit généralement jusqu'a 5 redirections dans une chaine avant d'abandonner. John Mueller de Google a confirmé ce comportement. Si la page finale n'est pas atteinte en 5 sauts, elle n'est ni crawlée ni indexée. La recommandation est de ne jamais dépasser 2 sauts pour garantir un transfert optimal du signal SEO.

Peut-on annuler une redirection 301 ?

Techniquement oui, il suffit de supprimer la règle de redirection sur le serveur. Mais en pratique, les navigateurs qui ont mis en cache la 301 continueront de rediriger automatiquement jusqu'a l'expiration de leur cache. Google a aussi besoin de re-crawler l'URL pour constater que la redirection n'existe plus. Le délai de retour a la normale peut etre de plusieurs semaines.

Comment gérer une migration avec des milliers d'URLs ?

Exportez la liste complète des URLs indexées depuis Google Search Console. Utilisez un tableur pour créer le mapping 1:1. Si la structure est conservée, une seule règle de redirection avec path forwarding suffit. Si la structure change, groupez les URLs par pattern et créez des règles de réécriture (regex) sur votre serveur ou votre CDN. Testez un échantillon avant de déployer l'ensemble.

Quelle est la différence entre une redirection 301 et un canonical tag ?

La 301 redirige physiquement le visiteur vers une nouvelle URL : l'ancienne page n'est plus accessible. Le canonical tag (rel=canonical) laisse les deux pages accessibles mais indique a Google laquelle indexer de préférence. Utilisez une 301 quand l'URL source n'a plus de raison d'exister. Utilisez un canonical quand les deux URLs doivent rester en ligne (contenu dupliqué, paramètres d'URL, versions paginées).

Une redirection ralentit-elle mon site ?

Oui. Chaque redirection ajoute un aller-retour réseau (100 a 300 ms par saut). L'impact se concentre sur le LCP (Largest Contentful Paint), la métrique de vitesse de chargement. Les redirections 301 mises en cache par le navigateur n'ont plus d'impact après la première visite, car le navigateur redirige localement sans contacter le serveur.

Google suit-il les redirections meta refresh ?

Oui, Google peut suivre les redirections meta refresh, mais avec un délai. La page HTML doit etre téléchargée et analysée avant que Google détecte la redirection. Google déconseille cette méthode et recommande les redirections côté serveur (301, 302). Les meta refresh posent aussi un problème pour les autres moteurs de recherche, qui ne les suivent pas toujours.

Glossaire

Redirection 301 : redirection HTTP permanente. Indique que l'URL a définitivement changé et transfère l'autorité SEO vers la destination.
Redirection 302 : redirection HTTP temporaire. Indique que l'URL est temporairement accessible a une autre adresse. L'autorité SEO reste sur l'URL source.
Redirection 307 : redirection temporaire qui préserve la méthode HTTP. Équivalent strict de la 302 sans transformation POST vers GET.
Redirection 308 : redirection permanente qui préserve la méthode HTTP. Équivalent strict de la 301 sans transformation POST vers GET.
PageRank : algorithme de Google qui mesure l'importance d'une page web en fonction de la quantité et de la qualité des liens entrants.
Canonical tag : balise HTML rel=canonical qui indique a Google quelle version d'une URL est la version préférée parmi plusieurs pages au contenu identique ou similaire.
Canonicalisation : processus par lequel Google choisit l'URL préférée parmi plusieurs URLs qui accèdent au meme contenu.
Chaine de redirection : séquence de redirections successives ou une URL redirige vers une deuxième, qui redirige vers une troisième, etc.
Boucle de redirection : situation ou deux URLs se redirigent mutuellement, créant un cycle infini.
Path forwarding : mécanisme qui transmet le chemin de l'URL source vers la destination lors d'une redirection.
Soft 404 : page qui retourne un code HTTP 200 mais dont le contenu indique une page d'erreur. Google la traite comme une 404 pour l'indexation.
Change of Address : outil de Google Search Console qui permet de déclarer officiellement un changement de domaine et d'accélérer la migration dans l'index Google.
Crawl budget : nombre de pages que Googlebot peut explorer sur un site dans un temps donné. Les redirections consomment du crawl budget, en particulier les chaines de redirections.
Core Web Vitals : ensemble de métriques Google (LCP, INP, CLS) mesurant la performance utilisateur d'une page web. Les redirections impactent principalement le LCP en ajoutant de la latence réseau.
CNAME : type d'enregistrement DNS qui crée un alias d'un domaine vers un autre. Utilisé pour pointer un domaine vers un serveur de redirection.