TL;DR: Nous avons migré seojuice.io vers seojuice.com en janvier 2026. Le trafic a chuté de 40% la première semaine. En moins de 2 mois, nous sommes passés de 694 impressions/jour à 7 853. Cet article détaille chaque erreur que j'ai faite, chaque correctif appliqué, et la chronologie exacte de la reprise pour t'éviter de revivre nos pires moments.
En janvier 2026, j'ai déplacé SEOJuice du domaine .io vers le .com. Les raisons étaient simples : le .com inspire davantage confiance, il est plus facile à mémoriser, et j'en avais assez d'expliquer ce que signifie ".io" à des prospects non techniques.
Je savais que ça allait faire mal. J'ai accompagné des dizaines de clients sur des migrations de domaine. J'ai lu toute la documentation Google sur le sujet. Je pensais que nous étions prêts.
Nous ne l'étions pas.
Jour 1 : les impressions ont chuté de 40%. Au troisième jour, certaines de nos pages les plus performantes avaient complètement disparu de l'index. Notre mot-clé principal — celui qui générait 30% du trafic organique — est passé de la 4e position à plus aucune présence dans le classement.
Voilà la chronologie réelle de ce qui s'est passé :
| Période | Impressions/jour | Clics/jour | Ce qui se passait |
|---|---|---|---|
| Avant migration | 694 | 31 | Base de référence sur le domaine .io |
| Semaine 1 | ~420 | 14 | Chute initiale. Google indexe encore les anciennes URL |
| Semaines 2-3 | ~580 | 22 | Propagation des redirections. Anciennes et nouvelles URL cohabitent dans l'index |
| Semaines 4-6 | 1 200 | 48 | La reprise commence. Le nouveau domaine gagne du terrain |
| Mois 2 | 4 100 | 165 | Nous dépassons l'ancienne base. Les améliorations de contenu commencent à produire leurs effets |
| Mois 3 (maintenant) | 7 853 | 312 | 11 fois les impressions d'origine. Reprise complète + croissance |
La reprise ne s'explique pas seulement par le temps qu'il a fallu à la migration pour se stabiliser. Nous avons profité de cette migration pour corriger des années de dette technique accumulée, améliorer la qualité du contenu et restructurer notre maillage interne. Mais la migration elle-même était la partie la plus délicate — et c'est sur elle que cet article se concentre.
Voici la checklist que j'aurais aimé suivre avec plus de rigueur. Nous en avons fait la majorité, mais les éléments ratés nous ont coûté plusieurs semaines de reprise.
| Avant la migration | Pendant la migration | Après la migration |
|---|---|---|
| Crawler tout l'ancien site et exporter toutes les URL | Déployer des redirections 301 pour chaque URL | Vérifier les redirections avec un crawl complet |
| Établir une table de redirection complète (ancienne URL → nouvelle URL) | Mettre à jour les balises canoniques vers le nouveau domaine | Soumettre le nouveau sitemap dans GSC |
| Exporter les données Google Search Console | Mettre à jour les liens internes vers le nouveau domaine | Utiliser l'outil Change of Address dans GSC |
| Documenter tous les backlinks (source + URL cible) | Mettre à jour sitemap.xml avec les nouvelles URL | Surveiller la couverture d'indexation chaque jour pendant 2 semaines |
| Configurer le nouveau domaine dans GSC et dans l'outil d'analyse | Mettre à jour robots.txt sur le nouveau domaine | Vérifier les erreurs de crawl dans GSC |
| Informer les partenaires de backlinks clés du changement | Vérifier le certificat SSL sur le nouveau domaine | Demander la mise à jour des backlinks aux principaux sites référents |
| Tester les redirections sur l'environnement de préproduction | Mettre à jour les profils sociaux et les annuaires | Conserver les redirections de l'ancien domaine pendant 12+ mois |
À retenir
L'élément le plus important : garde l'ancien domaine en redirection pendant au moins 12 mois. Google recommande de maintenir les redirections au moins 180 jours, mais plus longtemps, c'est mieux. De notre côté, nous gardons seojuice.io en redirection indéfiniment — il n'y a aucune bonne raison de ne pas le faire.
C'est la cause n°1 des échecs de migration. Chaque URL de l'ancien domaine doit avoir une redirection 301 vers son équivalent sur le nouveau domaine. Pas vers la page d'accueil. Pas vers une redirection générique. Vers la page équivalente exacte.
Lance un crawl de l'ancien domaine. Pour chaque URL, vérifie qu'elle redirige bien en 301 vers la bonne nouvelle URL. Utilise notre outil de vérification des liens cassés ou Screaming Frog avec un import de liste d'URL. Si tu vois des 404, des 302 ou des chaînes de redirection, le problème est là.
Pour Apache (.htaccess) :
# Redirect entire old domain to new domain (preserving paths)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.io [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]
# Individual page redirects (when URL structure changed)
Redirect 301 /old-blog/post-slug https://newdomain.com/blog/post-slug/
Redirect 301 /services/old-page https://newdomain.com/solutions/new-page/Pour Cloudflare (Redirect Rules) :
# Cloudflare Redirect Rule (Single Redirect)
# Match: hostname equals "olddomain.io"
# Then: Dynamic redirect to https://newdomain.com + URI Path
# Status: 301 (Permanent)
# For Cloudflare Bulk Redirects (CSV format):
olddomain.io/blog/old-post,https://newdomain.com/blog/new-post,301
olddomain.io/about,https://newdomain.com/about/,301Pour Nginx :
server {
server_name olddomain.io www.olddomain.io;
return 301 https://newdomain.com$request_uri;
}"Tu dois absolument mettre en place des redirections, au moins pour les pages importantes. Sans ça, tu te retrouves avec un mélange d'anciennes et de nouvelles URL dans les résultats de recherche, et les anciennes URL enverront le trafic vers ta page 404. L'idéal, ce sont des redirections permanentes côté serveur — 308 ou 301. Évite les redirections JavaScript."
Après avoir déployé les redirections, vérifie chaque URL de ton ancien sitemap. La réponse doit être une seule 301 vers la bonne nouvelle URL. Fais attention aux chaînes de redirection (301 → 301 → 200) — elles diluent le link equity et ajoutent de la latence.
C'est celui qui nous a piégés. Nous avions mis en place des redirections externes impeccables, mais nous avions oublié de mettre à jour les liens internes dans le contenu du blog. Des centaines de liens internes pointaient encore vers seojuice.io, ce qui créait des sauts de redirection inutiles à chaque chargement de page.
Crawl le nouveau site et filtre tous les liens internes qui contiennent l'ancien domaine. Cherche aussi la chaîne de l'ancien domaine dans ta base de données ou ton CMS.
Fais un search-and-replace sur toute ta base de données. Dans WordPress :
# Using WP-CLI (recommended approach)
wp search-replace 'https://olddomain.io' 'https://newdomain.com' --all-tables --dry-run
# Review output, then run without --dry-run:
wp search-replace 'https://olddomain.io' 'https://newdomain.com' --all-tables
# Also catch http:// variants
wp search-replace 'http://olddomain.io' 'https://newdomain.com' --all-tablesRelance un crawl du site. Zéro lien interne ne doit faire référence à l'ancien domaine.
Si ton sitemap.xml liste encore des URL de l'ancien domaine, tu envoies à Google le message « ce sont mes pages » pendant que tes redirections disent « en fait, va plutôt là-bas ». Ces signaux contradictoires ralentissent la réindexation.
Ouvre https://newdomain.com/sitemap.xml et vérifie chaque URL. Si certaines commencent par l'ancien domaine, ton sitemap n'est pas à jour.
Vérifie GSC → Sitemaps. Le statut doit afficher « Succès » avec le bon nombre d'URL.
Les balises canoniques sont faciles à oublier parce qu'elles sont invisibles pour les utilisateurs. Mais si elles pointent encore vers l'ancien domaine, tu dis à Google que l'ancien domaine est la version « officielle » — ce qui contredit directement tes redirections.
Affiche le code source de plusieurs pages du nouveau site. Cherche <link rel="canonical" et vérifie que le href utilise le nouveau domaine.
Fais un contrôle sur 10-20 pages issues de différents templates (homepage, article de blog, catégorie, produit). Chaque balise canonique doit référencer le nouveau domaine.
Même avec des redirections et des balises canoniques parfaites, Google met du temps à traiter un changement de domaine. C'est normal. Chez nous, la réindexation a pris environ 3 semaines pour la majorité des pages et 6 semaines pour la longue traîne.
Dans GSC, va dans Indexation → Pages. Surveille le nombre de pages « Indexées » sur la nouvelle propriété. Il doit monter régulièrement. S'il stagne ou baisse, quelque chose bloque le crawl.
"Mets à jour l'adresse URL dans Google Search Console pendant la migration, pas avant — Google a besoin de contenu sur le nouveau site pour pouvoir le traiter. Tu dois t'attendre à des changements visibles dans la façon dont ton contenu apparaît dans la recherche, clairement à court terme. Même si tu gères parfaitement les changements d'URL, tu verras des variations."
Suis chaque jour : le nombre de pages indexées dans GSC, les statistiques de crawl, et le ratio entre les URL de l'ancien et du nouveau domaine qui apparaissent dans les résultats de recherche (cherche site:newdomain.com et site:olddomain.io).
Tes backlinks pointent vers l'ancien domaine. Avec des redirections 301, Google transmet la majeure partie (mais pas la totalité) du link equity vers la nouvelle URL. La perte est faible lien par lien, mais elle s'accumule quand tu as des centaines de backlinks.
Exporte ton profil de backlinks depuis Ahrefs, Semrush ou GSC. Vérifie combien pointent encore vers l'ancien domaine par rapport au nouveau. Trois mois après la migration, le ratio devrait commencer à basculer vers le nouveau domaine.
Surveille ton profil de backlinks chaque mois. Le pourcentage de backlinks pointant directement vers le nouveau domaine doit augmenter avec le temps. Utilise notre outil de vérification de l'autorité de domaine pour suivre le transfert d'autorité.
Les études montrent qu'une migration de domaine peut prendre entre 30 jours et 523 jours pour récupérer complètement. L'écart est énorme, parce que tout dépend de la qualité d'exécution. Voilà à quoi ressemble une migration bien menée, semaine après semaine :
| Période | Ce qui est normal | Ce qui doit t'alerter |
|---|---|---|
| Semaine 1 | Baisse de trafic de 20-40%. Fluctuations de positions sur les mots-clés clés. Les anciennes URL apparaissent encore dans les SERP | Baisse de trafic de 70%+. Désindexation complète. Erreurs 404 dans GSC |
| Semaines 2-3 | Le trafic se stabilise. Les URL du nouveau domaine remplacent les anciennes dans l'index. Les positions reviennent | Le trafic continue de baisser. La couverture d'indexation n'augmente pas. Erreurs de redirection dans GSC |
| Semaines 4-6 | Le trafic se rapproche du niveau d'avant migration. La plupart des pages sont réindexées. Les positions se stabilisent | Toujours sous 50% de la base. Beaucoup de pages non indexées. Les erreurs de crawl augmentent |
| Mois 2-3 | Reprise complète ou dépassement de la base. Toutes les pages importantes sont indexées sur le nouveau domaine | Des pages importantes ne sont toujours pas indexées. Les positions ne reviennent pas sur les mots-clés clés |
| Mois 6+ | L'ancien domaine apparaît à peine dans les SERP. Les backlinks se mettent à jour progressivement. La longue traîne est totalement revenue | L'ancien domaine apparaît encore sur beaucoup de requêtes. Les métriques d'autorité baissent |
Si ta migration a déraillé et que tu vois des signaux rouges, corrige ces points dans cet ordre :
La partie la plus difficile d'une migration, c'est de savoir quand la baisse est normale et quand quelque chose est réellement cassé.
Attends encore un peu si :
Panique (et corrige immédiatement) si :
À retenir
Une baisse de trafic de 20-40% en semaine 1 est normale et attendue. Une baisse de 70%+, ou toute baisse qui ne commence pas à se résorber d'ici la semaine 3, signifie qu'il y a un problème technique. Vérifie les redirections, robots.txt et les balises canoniques dans cet ordre.
Avec le recul sur notre propre migration, voilà ce que je changerais :
Google recommande au moins 180 jours. Moi, je recommande pour toujours, ou au moins tant que le coût de renouvellement du domaine reste négligeable. Il n'y a aucun inconvénient à garder les redirections actives, et les anciens backlinks continueront à transmettre de l'autorité via la redirection.
301 (permanente). Toujours. Une 302 dit à Google que le déplacement est temporaire, ce qui veut dire que Google garde les anciennes URL dans l'index et ne transfère pas complètement le link equity. Pour un changement de domaine permanent, la 301 est le seul bon choix. John Mueller mentionne aussi la 308 comme équivalente à la 301.
Temporairement, oui. La plupart des sites voient une baisse de trafic de 20-40% pendant la première semaine. Si l'exécution est propre, la reprise commence en 2-4 semaines. Les études montrent que 83% des migrations de domaine bien exécutées récupèrent complètement en moins de 6 mois. Les 17% qui n'y arrivent pas ont généralement des problèmes techniques persistants (redirections cassées, problèmes de balises canoniques).
Google le déconseille fortement. Change une seule chose à la fois. Déplace d'abord le domaine, laisse-le se stabiliser pendant 2-3 mois, puis restructure les URL. Faire les deux en même temps rend presque impossible le diagnostic quand quelque chose tourne mal.
Pas les reconstruire, mais les mettre à jour. Les redirections 301 transmettent la majeure partie du link equity, donc tes backlinks existants comptent toujours. Mais contacter tes principaux référents pour qu'ils mettent les liens à jour directement (et supprimer ainsi le saut de redirection) permet de préserver davantage d'autorité et d'améliorer l'efficacité du crawl.
L'outil Change of Address dans Google Search Console indique explicitement à Google que ton site a été déplacé d'un domaine à un autre. Il n'est pas strictement obligatoire — Google peut comprendre un changement de domaine avec les seules redirections 301 — mais il accélère nettement le processus. Il transfère les signaux de l'ancien vers le nouveau, incite Google à crawler davantage le nouveau domaine, et continue de fonctionner pendant 180 jours. Utilise-le.
Toute migration de domaine fait mal. Même celles qui sont parfaitement exécutées. Google doit recrawler, retraiter et réattribuer la confiance à un nouveau domaine. Et ça prend du temps.
La différence entre une migration qui récupère en 3 semaines et une autre qui prend un an, c'est la qualité d'exécution : des tables de redirection complètes, des liens internes mis à jour, des balises canoniques propres, et l'outil Change of Address dans GSC. Il n'y a ni raccourci ni solution miracle.
Nous nous en sommes sortis plus forts parce que nous avons traité la migration comme une opportunité de corriger tout ce qui n'allait déjà pas. Si tu t'apprêtes à migrer, fais pareil. Nettoie ta dette technique, améliore ton contenu et corrige ton maillage interne pendant que tu y es. Tu vas déjà subir la douleur — autant ressortir de l'autre côté avec un meilleur site.
no credit card required
No related articles found.