Migration SEO du site : comment déménager sans perdre vos positions

TL;DR : Une migration préserve la visibilité SEO si chaque ancienne URL à valeur a une destination pertinente, si des redirections permanentes côté serveur la pointent directement, et si Google peut explorer et indexer la page de remplacement. Faites l’inventaire et le benchmark du site existant avant le lancement. Construisez une matrice de redirections 1 :1, mettez à jour les liens internes et les balises canoniques, soumettez de nouveaux sitemaps, puis surveillez le croisement entre l’indexation ancienne et nouvelle. Pour les changements de domaine, utilisez l’outil Change of Address, pas les migrations HTTP→HTTPS ni les changements d’hébergement.

La première question à se poser en SEO lors d’une migration de site n’est pas « quel plugin installer ». C’est plutôt celle-ci : est-ce que les utilisateurs et Google verront des URL différentes après le déplacement ?

Google Search Central distingue les migrations en déplacements de site avec changements d’URL et déplacements de site sans changements d’URL. Cette distinction détermine la majorité du travail. Les changements de domaine, les migrations HTTP→HTTPS, la modification des chemins, et les consolidations de domaines appartiennent au premier groupe. Passer d’un hébergeur à un autre ou migrer vers un CDN tout en conservant toutes les URL visibles relève du second.

Nous avons mené nous-mêmes une migration de domaine quand notre équipe à deux (Lida et moi) a déplacé SEOJuice d’seojuice.io vers seojuice.com en janvier 2026. Le déplacement de l’application n’était pas le point qui me préoccupait. Le vrai risque, c’était de démontrer que chaque ancienne URL arrivait bien à la bonne page de remplacement, que le nouveau site ne dépendait pas de liens internes utilisant l’ancien domaine, et que Google remplaçait, plutôt que de simplement « découvrir », des URL.

Cette distinction compte. « Le nouveau site est en ligne » est un jalon d’infrastructure. Ce n’est pas une preuve que la migration a fonctionné.

Qu’est-ce qui compte comme une migration SEO de site ?

Une migration SEO de site est un changement suffisamment important pour modifier la façon dont les moteurs de recherche accèdent, explorent (crawl) ou indexent un site web. Un nouveau domaine est l’exemple évident, mais plusieurs projets moins spectaculaires exigent les mêmes garde-fous.

• Changement de domaine : passer vers un autre domaine lors d’un rebranding, d’une acquisition ou d’un changement de domaine de premier niveau (TLD).
• HTTP vers HTTPS : le protocole fait partie de l’URL. C’est donc une migration avec changements d’URL, même si le hostname reste identique.
• Changement de plateforme ou de CMS : une nouvelle plateforme peut modifier les chemins, les paramètres, la pagination, la gestion de la casse, ou les slashs de fin. Traitez-le comme une migration avec changements d’URL si les URL résultantes diffèrent.
• Refonte ou restructuration : une refonte visuelle n’est pas automatiquement une migration. Elle le devient si les chemins, slugs, éléments de navigation, canoniques, contenus rendus ou l’indexabilité changent.
• Consolidation de domaines : fusionner plusieurs domaines ou hostnames dans un seul nécessite un inventaire et un plan de redirections distincts pour chaque source.
• Déplacement d’hébergement ou de CDN : si les URL visibles côté utilisateur restent identiques, il s’agit surtout d’une opération DNS et d’infrastructure, pas d’un projet de redirection.

J’éviterais de combiner ces changements sauf si la contrainte business est plus forte que le risque diagnostic. Les recommandations de Google sont nettes : « Ne changez qu’une seule chose à la fois. » Une modification simultanée du domaine, du CMS, du design et de la taxonomie vous donne quatre causes plausibles pour chaque page d’atterrissage perdue (et en réalité plus encore une fois que le rendu et les templates entrent dans l’équation).

Avant le lancement : inventaire d’abord, migration ensuite

Construisez un inventaire solide des anciennes URL

Votre plan de redirections ne peut protéger que les URL incluses. Explorez (crawl) le site existant, puis combinez ce crawl avec les sitemaps XML, les exports de Search Console, les pages d’atterrissage vues dans l’analytics, les données de backlinks quand elles sont disponibles et les logs serveur. Chaque source « voit » une portion différente du site.

Un crawler trouve les pages liées, mais peut manquer les « orphelines ». Un sitemap peut exclure des anciennes URL qui continuent à bien se positionner. Les analytics ne montreront pas les pages sans visites récentes. Les logs peuvent révéler des requêtes vers des fichiers et des chemins legacy absents de la navigation actuelle. « Complet » est un mot inconfortable ici (je me contente généralement d’un inventaire reconcilié de manière indépendante).

Gardez dans le périmètre les assets non HTML quand ils ont une valeur SEO ou des liens externes. Les PDFs, guides téléchargeables, images et pages de campagnes anciennes sont faciles à omettre, précisément parce qu’ils n’apparaissent pas dans un crawl de pages « normales ».

Capturez un point de référence en dehors du système remplacé

Exportez le trafic organique des pages d’atterrissage, les requêtes et performances de pages importantes, les informations d’URL indexées, les URL les mieux classées, ainsi que les résultats de crawl actuels. Segmentez les données par répertoire ou par type de page. Un seul chiffre de trafic global du site est trop imprécis pour diagnostiquer une migration.

Si le trafic baisse de 12 %, ce chiffre ne vous apprend presque rien. Si un répertoire de produits disparaît pendant que le blog reste stable, vous tenez une piste utile. Vérifiez d’abord les redirections de ce répertoire, les templates, les balises canoniques et les directives d’indexation.

J’ai sauté le travail de baseline parce que le lancement semblait urgent. Cela a peut-être fait gagner une heure, mais a rendu le diagnostic ultérieur plus lent et moins certain. Ce n’était pas un échange malin.

Mettez en correspondance chaque ancienne URL avec son remplacement le plus proche

Google Search Central donne l’instruction centrale :

Une cartographie de redirections envoie chaque ancienne URL vers son équivalent final réel, en correspondance directe :

# 1:1 redirect map (Nginx) - old URL to its closest new equivalent
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: never mass-redirect everything to the homepage
# location / { return 301 /; }   # this creates soft 404s

« Une fois que vous avez la liste des anciennes URL, décidez vers où chacune doit rediriger. »

Créez une cartographie avec une ligne par ancienne URL. Indiquez la destination visée, le code de réponse attendu, le type de page, le statut de migration et toute raison de mise au rebut. Priorisez les URL qui reçoivent des visites organiques ou des liens externes, mais ne prenez pas « prioriser » comme un feu vert pour ignorer la longue traîne.

La destination doit préserver l’intention. Une ancienne page produit doit mener vers le même produit ou son successeur réel. Un article migré doit mener vers cet article. La home page n’est pas un substitut universel.

Conservez les chemins existants autant que possible. Chaque URL inchangée supprime une règle de redirection, une décision de mapping et un point de défaillance potentiel. Les équipes réécrivent souvent les slugs lors d’une refonte parce que les nouvelles versions paraissent plus propres. Je demanderais quel problème mesurable cette « cleanup » résout avant d’accepter le risque de migration.

Décidez ce qui ne doit pas être redirigé

Un mapping 1 :1 ne signifie pas que chaque page supprimée doit être « forcée » quelque part. Si une page n’a pas d’équivalent et pas de successeur utile, un vrai 404 ou 410 peut être plus clair qu’une redirection sans pertinence.

Cela demande un jugement éditorial, pas une formule de tableur. Rediriger un produit abandonné vers son modèle de remplacement peut être utile. Rediriger une page d’événement supprimée vers un index d’événements sans rapport ne le sera probablement pas. La pertinence d’abord.

Préparez le remplacement pour le crawl

Importez le contenu, configurez HTTPS, préparez le fichier robots.txt destiné à la production, vérifiez les propriétés Search Console concernées, puis contrôlez les directives d’indexation au niveau de chaque page. Validez les balises canoniques, hreflang lorsqu’il est utilisé, les URL de structured data, la pagination et les sitemaps XML par rapport au hostname de production.

Les sites de préproduction (staging) sont souvent protégés via robots.txt, des directives noindex, une authentification, ou une combinaison des deux. Ces protections ne doivent pas « fuiter » vers la production. Si des pages restent absentes après le lancement, les vérifications décrites dans Pourquoi mon site n’apparaît-il pas sur Google ? couvrent les contrôles robots, les directives noindex et l’outil d’inspection d’URL.

Sur un site de grande taille, migrez d’abord une section si l’architecture le permet. Google recommande de « déplacer d’abord seulement une partie du site pour tester tout effet sur le trafic et l’indexation ». Un déploiement progressif n’est pas toujours possible, mais il vaut la peine d’y penser avant d’accepter un basculement « tout ou rien ».

Pendant le lancement : faites en sorte que chaque signal soit cohérent

Utilisez des redirections directes et permanentes côté serveur

Google recommande « des redirections permanentes côté serveur depuis les anciennes URL vers les nouvelles URL, comme indiqué dans votre mapping ». Si vous n’êtes pas familier avec le fonctionnement des redirections, lisez d’abord Qu’est-ce qu’une redirection ?. Notre comparaison entre les redirections 301 et 302 détaille plus précisément la décision entre permanent et temporaire.

Comme le dit Patrick Stox, auteur principal du chapitre SEO du Web Almanac :

« Assurez-vous que vos redirections renvoient 301 ou 308 plutôt que 302 ou 307 si vous effectuez un déplacement permanent et que vous voulez que les URL soient indexées sur le nouveau site plutôt que sur l’ancien. »

Le code de statut n’est pas un détail de cérémonie. La documentation Google sur les redirections explique ce qui se passe avec une redirection permanente : « Googlebot suit la redirection, et le pipeline d’indexation utilise la redirection comme signal indiquant que la destination doit être canonique. »

Chaque ancienne URL doit pointer directement vers sa destination finale. Évitez les chaînes ancienne→intermédiaire→finale. Testez les boucles causées par le chevauchement des règles HTTPS, www, slash de fin, CDN, serveur et application.

Puis inspectez la réponse en conditions réelles plutôt que de vous fier au fichier de configuration. Une règle peut être correcte « isolément » et pourtant entrer en conflit avec une autre couche. C’est là que j’arrête de faire confiance à la feuille de migration (et, pour être honnête, à ma mémoire) et que je crawl la production.

Ne redirigez pas en masse des pages vers la home page

Google prévient explicitement :

« Ne redirigez pas de nombreuses anciennes URL vers une seule destination URL non pertinente, par exemple la page d’accueil du nouveau site. »

Une redirection « massive » vers la home page masque un travail de mapping manquant ; elle ne le remplace pas. Les moteurs de recherche et les utilisateurs s’attendaient à une ressource précise. Envoyer chaque requête vers une page générique détruit cette relation.

Si beaucoup d’URL partagent un successeur légitime, un mapping de type « plusieurs vers une seule » peut avoir du sens. Plusieurs URL produit en doublon peuvent, par exemple, aboutir toutes à la page produit canonique. Le problème, c’est l’irrélevance, pas la « mathématique ».

Mettre à jour les liens internes, les canoniques et les références générées

Les redirections sont une infrastructure de secours. Elles ne doivent pas devenir le système de linking interne du nouveau site.

Mettez à jour la navigation, les breadcrumbs, les liens vers les articles, les modules de contenu « similaire », les balises canoniques, les références hreflang, les structured data, les entrées de sitemap et les références d’assets pour utiliser directement les URL finales. L’instruction de Google est claire : « Modifiez les liens internes du nouveau site, des anciennes URL vers les nouvelles URL. »

D’après ce que nous observons sur les sites suivis via SEOJuice, les anciens liens au niveau des templates ont plus d’impact que des liens éditoriaux isolés, parce qu’un composant obsolète peut reproduire la même dépendance de redirection sur des centaines de pages. Vérifiez d’abord les templates, puis le contenu du corps de page.

Soumettez les sitemaps et utilisez correctement Change of Address

Soumettez le nouveau sitemap XML dans Search Console. Google indique que cela l’aide à découvrir les nouvelles URL. Conserver des sitemaps distincts pour les anciennes URL et les nouvelles URL vous donne un moyen pratique de surveiller le remplacement.

Pour un passage d’un domaine à un autre, soumettez Change of Address depuis l’ancienne propriété Search Console. L’instruction de Google, précise, consiste à soumettre des demandes pour « tous les sous-domaines et les variantes www et non-www du nom de domaine d’origine ». L’outil complète les redirections permanentes ; il ne les remplace pas.

N’utilisez pas Change of Address pour des migrations HTTP→HTTPS. Le changement HTTPS modifie l’URL, mais Google exclut expressément ce cas de l’outil. C’est aussi inutile pour un simple changement d’hébergement et pour des changements de chemin à l’intérieur du même domaine.

Après le lancement : surveillez le remplacement, pas uniquement le trafic

Une migration n’est pas terminée quand le DNS résout et que la home page s’affiche. Elle est terminée lorsque les utilisateurs et les crawlers atteignent de façon cohérente le contenu prévu, et que les nouvelles URL remplacent les anciennes URL dans l’index de Google.

Surveillez les rapports d’indexation dans Search Console, les erreurs de crawl, les classements et le trafic organique des pages d’atterrissage, en les comparant à la baseline. Google décrit clairement le schéma d’indexation attendu :

« Avec le temps, le nombre de pages indexées à partir du sitemap des anciennes URL devrait passer à zéro, avec en parallèle une hausse correspondante du nombre de pages indexées à partir des nouvelles URL. »

Ce croisement est plus utile que de rafraîchir un seul graphique de trafic. Si une section n’augmente pas côté nouveau site, inspectez ses redirections, ses balises canoniques, ses liens internes, son inclusion dans le sitemap, le contenu rendu et les directives d’indexation. Notre guide sur comment fonctionne l’indexation sur Google explique le processus de crawl et de canonicalisation derrière ce remplacement.

Un creux temporaire peut apparaître pendant que Google recrawl et ré-indexe les URL modifiées. Il n’existe pas de pourcentage universel crédible ni de délai de récupération garanti. La taille du site, la fréquence de crawl, le linking interne, la qualité des redirections et l’ampleur du changement diffèrent dans chaque cas. Dans tous les cas, une perte nette au niveau d’une page ou d’un répertoire est plus actionnable que une moyenne sectorielle.

Maintenez les redirections en fonctionnement

Google dit : « Conservez les redirections aussi longtemps que possible, généralement au moins 1 an. » Garder des redirections utiles indéfiniment peut aussi protéger les visiteurs qui utilisent des signets (bookmarks) et des liens externes vers des URL anciennes, mais que vous ne contrôlez pas.

Ne supprimez pas trop tôt le domaine ancien ni l’infrastructure de support. Une redirection qui fonctionne au moment du crawl de lancement, mais qui disparaît quelques mois plus tard, ne peut plus aider les utilisateurs ou crawlers qui tomberaient ensuite sur un ancien lien.

Les échecs que j’investiguerais en premier

Vérifiez l’accessibilité et les redirections avant de réécrire les titres ou d’accuser une mise à jour d’algorithme. Les échecs de migration sont souvent mécaniques : une page est bloquée, une redirection entre en collision avec une autre règle, ou une canonique pointe vers le mauvais host.

L’ordre compte. Corriger des métadonnées sur une URL que Google ne peut pas crawler, c’est du travail de “bureaucratie technique”.

Une migration « hébergement-only » est une opération différente

Si chaque URL visible côté utilisateur reste identique, ne créez pas un projet de redirections. Google définit ce cas comme un changement de fournisseur d’hébergement ou un passage vers un CDN sans impact sur les URL visibles.

Préparez et testez la nouvelle infrastructure, baissez le time-to-live DNS quand c’est approprié, modifiez les DNS, puis surveillez les requêtes servies par les deux environnements. Google conseille de couper l’ancienne infrastructure uniquement quand vous êtes certain que tous les utilisateurs (y compris Googlebot) reçoivent bien le bon contenu depuis la nouvelle configuration.

Pas de plan de redirections et pas de demande Change of Address parce que les URL n’ont pas bougé. Les principaux risques sont la disponibilité, les performances, la configuration DNS, les réponses serveur et les différences entre ce que la nouvelle infrastructure sert aux crawlers.

Où SEOJuice s’insère après une migration

Après avoir déplacé seojuice.io vers seojuice.com, ce dont nous avions besoin, c’était une inspection répétable du résultat en conditions réelles. Pas une énième feuille de lancement.

Le audit SEO gratuit de SEOJuice vérifie les surfaces sensibles aux migrations : robots.txt, sitemaps, balises canoniques, configuration HTTPS, redirections et liens internes. Il peut mettre en évidence des liens qui pointent encore vers l’ancien domaine, des destinations de redirection qui renvoient des erreurs, des directives noindex restantes, et des incohérences de canonique ou de HTTPS.

La frontière est importante. L’audit identifie ce qui ne va pas et où. Il n’écrit pas de règles de redirection côté serveur, ni ne soumet Change of Address à votre place. Ces étapes restent sous votre contrôle (probablement le bon endroit pour conserver les changements au niveau du domaine).

Questions fréquentes

Qu’est-ce qu’une migration SEO de site ?

Une migration SEO de site est un changement qui influence la façon dont les moteurs de recherche accèdent, explorent (crawl) ou indexent un site. Parmi les exemples : déplacer un domaine, passer de HTTP à HTTPS, changer de CMS ou de structure d’URL, consolider des domaines et changer d’hébergement. La distinction centrale est de savoir si les URL visibles changent : des URL modifiées nécessitent un mapping et des redirections.

Vais-je perdre mes classements en migrant mon site ?

Pas forcément. Les redirections permanentes aident Google à considérer la destination comme canonique et à remplacer l’ancienne URL. Une fluctuation peut survenir pendant le recrawl et la réindexation. Des pertes durables justifient généralement de vérifier les redirections manquantes, les destinations non pertinentes, les boucles, les redirections temporaires, le contenu modifié, les canoniques et l’indexation bloquée.

Les anciennes URL ont-elles besoin de redirections 1 :1 ?

Chaque ancienne URL à valeur doit être évaluée individuellement et redirigée vers son remplacement le plus proche et pertinent. N’envoyez pas des pages sans rapport vers la home page. Si aucun remplacement pertinent n’existe, un 404 ou un 410 correctement renvoyé peut être plus juste qu’une redirection trompeuse.

Quand dois-je utiliser l’outil de Change of Address de Google ?

Utilisez-le pour un passage d’un domaine à un autre. Soumettez les requêtes nécessaires pour les sous-domaines et les variantes www ou non-www de l’ancien domaine. Ne l’utilisez pas pour des changements HTTP→HTTPS, des modifications de chemins au sein d’un même domaine, ou des migrations d’hébergement et de CDN. Change of Address ne remplace pas les redirections permanentes.

Combien de temps les redirections de migration doivent-elles rester actives ?

Google recommande de conserver les redirections aussi longtemps que possible, généralement au moins un an. Garder des redirections utiles indéfiniment peut protéger les anciens signets et liens externes, tant que les destinations restent pertinentes.

Comment vérifier qu’une migration a fonctionné ?

Comparez le trafic, les classements, les URL indexées et les résultats de crawl après lancement avec la baseline. Explorez les anciennes URL pour confirmer des redirections permanentes directes, explorez le nouveau site pour repérer les liens internes obsolètes, puis inspectez les robots directives, les canoniques, les sitemaps et les réponses serveur. Dans Search Console, le nombre d’URL indexées depuis le sitemap d’origine doit baisser tandis que celui du nouveau sitemap doit augmenter.