Migration WordPress : le guide complet pour ne pas perdre son SEO Pascal Malapert

Migrer un site WordPress est l’une des opérations les plus risquées pour son référencement. Un changement d’hébergeur mal géré, un changement de domaine sans redirections, ou une mise à jour des URLs incomplète peuvent faire disparaître des mois de travail SEO en quelques heures. Les guides de migration WordPress abondent sur le web, mais presque aucun ne traite la dimension SEO sérieusement : comment préserver ses positions, ses backlinks, son autorité de domaine et son indexation à travers une migration.

Ce guide couvre l’ensemble du processus, du choix du bon moment pour migrer jusqu’au suivi des positions post-migration, avec un focus particulier sur les étapes que la plupart des tutoriels ignorent.

Pourquoi et quand migrer son site WordPress

Une migration WordPress peut désigner plusieurs opérations différentes selon le contexte. Il est important de bien identifier ce que vous faites avant de commencer, parce que les implications SEO varient considérablement selon le type de migration.

Les différents types de migration

Changement d’hébergeur, même domaine : vous déplacez votre site vers un meilleur hébergeur sans changer l’URL. C’est la migration la moins risquée pour le SEO si elle est bien exécutée : les URLs ne changent pas, les backlinks restent valides, Google ne voit pas de changement d’adresse.
Changement de domaine, même contenu : vous gardez votre site intact mais changez son adresse (ex : de monsite.com vers monsite.fr, ou après un rebranding). C’est la migration la plus impactante pour le SEO : Google doit réapprendre que votre nouveau domaine est l’équivalent de l’ancien.
Migration locale vers serveur en ligne : vous avez développé votre site en local (XAMPP, Local by Flywheel, MAMP) et vous le mettez en production. C’est techniquement similaire à un changement d’hébergeur mais sans historique SEO préexistant à préserver.
Migration de CMS vers WordPress : vous venez d’un autre CMS (Prestashop, Shopify, Wix, Joomla) et vous migrez vers WordPress. C’est une migration complexe qui implique de recréer toute l’architecture des URLs et de gérer les redirections depuis l’ancien système.
Changement d’hébergeur avec changement de domaine simultané : le scénario le plus risqué, à éviter si possible. Changer les deux en même temps multiplie les points de défaillance et complique le diagnostic en cas de problème.

Quand migrer

Le moment de la migration a un impact direct sur son risque SEO. Quelques règles de bon sens :

Évitez de migrer pendant vos périodes de trafic élevé : si votre site a des pics de trafic saisonniers (fêtes, rentrée, été selon votre activité), ne migrez pas pendant ces périodes. Un problème post-migration pendant votre peak season peut coûter très cher.
Ne migrez pas pendant une mise à jour algorithmique Google : si vous observez des fluctuations inhabituelles de positions dans la Search Console, attendez que les positions se stabilisent avant de migrer. Impossible de distinguer l’impact de la migration de l’impact de l’algorithme si les deux coïncident.
Planifiez la migration un jour où vous avez du temps pour surveiller : ne migrez pas un vendredi soir si vous n’êtes pas disponible le week-end. Les premières heures post-migration sont critiques pour détecter les problèmes d’indexation ou de configuration.

Checklist SEO avant de commencer la migration

C’est l’étape que tous les guides de migration sautent. Avant de toucher quoi que ce soit, vous devez capturer l’état SEO actuel de votre site. Ces données de référence sont indispensables pour détecter et diagnostiquer les problèmes post-migration, et pour mesurer si la migration a eu un impact sur vos positions.

Capturer l’état SEO de référence

Export Google Search Console : allez dans Rapports > Performance > Résultats de recherche et exportez les données des 3 derniers mois (clics, impressions, CTR, position par requête et par page). Ce fichier est votre référence pour comparer les positions avant et après migration.
Crawl complet avec Screaming Frog : lancez un crawl de l’ensemble du site avant migration. Exportez la liste de toutes les URLs indexables, les balises title, les meta descriptions, les H1, les canoniques et les redirections existantes. Ce rapport vous permet de vérifier que toutes les pages importantes sont bien présentes sur le nouveau serveur après migration.
Export des backlinks : dans Ahrefs ou Semrush, exportez la liste de tous les backlinks pointant vers votre site, avec leurs URLs de destination. Si votre migration implique un changement d’URLs, cette liste vous indique quelles pages reçoivent des liens externes et ne doivent donc pas perdre leur contenu ou leur redirection.
Capture des positions clés : notez les positions actuelles de vos 10 à 20 pages les plus importantes sur leurs mots-clés principaux. Ces chiffres vous permettront de vérifier rapidement si la migration a causé des chutes de positions dans les jours suivants.
Vérification du sitemap XML actuel : sauvegardez l’URL de votre sitemap XML et vérifiez qu’il est bien soumis dans Google Search Console. Vous en aurez besoin pour resoumettre après migration.

Vérifier les redirections existantes

Si votre site a déjà des redirections 301 en place (suite à d’anciennes migrations, des changements d’URLs, des pages supprimées), documentez-les avant de migrer. Ces redirections sont souvent configurées dans le fichier .htaccess ou via un plugin (Redirection, Rank Math, Yoast). Elles doivent être reproduites à l’identique sur le nouvel hébergeur.

Une migration qui écrase les redirections existantes génère des erreurs 404 sur des pages qui avaient du trafic ou des backlinks, ce qui peut être difficile à diagnostiquer a posteriori si vous n’avez pas de document de référence.

Sauvegarder son site WordPress avant toute migration

La sauvegarde est la première règle absolue de toute migration. Si quelque chose se passe mal pendant le processus, une sauvegarde complète vous permet de revenir à l’état initial en quelques minutes. Sans sauvegarde, un problème de migration peut devenir une catastrophe irréversible.

Ce que doit contenir une sauvegarde complète

Une sauvegarde WordPress complète comprend deux éléments distincts qui doivent être sauvegardés séparément :

Les fichiers du site : tout le contenu du dossier WordPress sur votre serveur, y compris le dossier wp-content (thèmes, plugins, médias uploadés), les fichiers wp-config.php et .htaccess, et le core WordPress. Le dossier wp-content/uploads contient tous vos médias et peut être volumineux sur les sites anciens.
La base de données : toute la structure de votre site (articles, pages, paramètres, utilisateurs, commentaires, métadonnées) est stockée dans la base de données MySQL. Une sauvegarde des fichiers sans la base de données est inutilisable pour restaurer un site fonctionnel.

Les méthodes de sauvegarde

Via un plugin de sauvegarde : c’est la méthode la plus simple. UpdraftPlus (gratuit pour les fonctionnalités de base), Jetpack Backup ou BackupBuddy permettent de créer une sauvegarde complète en quelques clics depuis le tableau de bord WordPress et de la télécharger sur votre ordinateur ou de l’envoyer vers un stockage cloud (Google Drive, Dropbox, Amazon S3).

Via le tableau de bord de votre hébergeur : la plupart des hébergeurs proposent un outil de sauvegarde intégré dans leur panel de gestion (cPanel, Plesk, interface propriétaire). Cette méthode est fiable mais les sauvegardes restent souvent sur les serveurs de l’hébergeur, ce qui pose un problème si vous migrez précisément parce que cet hébergeur a des problèmes.

Via phpMyAdmin pour la base de données : accédez à phpMyAdmin depuis votre hébergeur, sélectionnez votre base de données, et exportez-la au format SQL. Combinez cet export SQL avec un téléchargement des fichiers via FTP pour une sauvegarde manuelle complète.

Vérifier la sauvegarde avant de commencer

Une sauvegarde non vérifiée n’est pas une sauvegarde fiable. Avant de commencer la migration, vérifiez que votre sauvegarde est complète et utilisable : ouvrez l’archive pour confirmer que les fichiers sont présents, vérifiez la taille du fichier SQL de base de données pour qu’elle corresponde à ce qu’on attend d’un site de votre taille. Sur un site ancien avec beaucoup de contenu, une base de données de quelques kilo-octets est suspecte.

Stockez la sauvegarde en dehors du serveur que vous migrez : sur votre ordinateur local, sur un service cloud ou sur un hébergeur tiers. Une sauvegarde stockée sur le même serveur que celui que vous migrez ne vous protège pas en cas de problème avec ce serveur.

Migrer avec un plugin : Duplicator et All-in-One WP Migration

Les plugins de migration automatisent les étapes les plus techniques du processus : compression des fichiers, export de la base de données, remplacement des URLs et import sur le nouveau serveur. Pour la grande majorité des migrations de taille raisonnable, un plugin est la méthode la plus rapide et la moins risquée.

Duplicator

Duplicator est le plugin de migration WordPress le plus utilisé et celui que je recommande en premier. Il crée un « paquet » qui contient l’ensemble du site (fichiers + base de données) et un fichier installeur qui automatise la mise en place sur le serveur de destination.

Étapes avec Duplicator :

Installez et activez Duplicator sur le site à migrer
Dans Duplicator > Packages, créez un nouveau package. Duplicator analyse votre site et vous signale les éventuels problèmes (taille des fichiers, configuration serveur) avant de créer l’archive
Une fois le package créé, téléchargez les deux fichiers générés : l’archive .zip et le fichier installer.php
Sur le nouveau serveur, créez une nouvelle base de données vide et notez les identifiants (nom de la base, utilisateur, mot de passe)
Uploadez les deux fichiers Duplicator à la racine du nouveau serveur via FTP ou le gestionnaire de fichiers de l’hébergeur
Accédez à votrenouveaudomaine.fr/installer.php depuis votre navigateur et suivez les 4 étapes de l’installeur en renseignant les identifiants de la nouvelle base de données
Duplicator extrait l’archive, importe la base de données et remplace automatiquement les anciennes URLs par les nouvelles dans toute la base

Limite de la version gratuite : Duplicator Free est limité aux sites dont l’archive ne dépasse pas 500 Mo environ. Au-delà, des erreurs de timeout peuvent survenir pendant la création du package. Duplicator Pro (à partir de 69$/an) lève cette limite et ajoute des fonctionnalités de sauvegarde planifiée.

All-in-One WP Migration

All-in-One WP Migration est populaire pour sa simplicité d’utilisation : l’export se fait en un clic depuis le tableau de bord WordPress et génère un fichier .wpress contenant l’ensemble du site. L’import sur le nouveau site se fait aussi en un clic depuis l’interface du plugin.

Attention à la limite de taille : la version gratuite d’All-in-One WP Migration limite l’import à 512 Mo. Pour les sites plus volumineux, vous devez soit augmenter la limite PHP upload_max_filesize sur votre serveur (pas toujours possible en mutualisé), soit acheter l’extension qui lève cette limite (69$). C’est la principale critique de ce plugin : la limite gratuite est souvent atteinte sur des sites réels.

Migrate Guru

Migrate Guru est une alternative gratuite sans limite de taille, développée par les créateurs de BlogVault. Il fonctionne différemment des deux précédents : au lieu de créer une archive locale, il transfère les données directement de serveur à serveur via ses propres serveurs cloud. Cela le rend particulièrement efficace pour les gros sites mais nécessite que les deux serveurs (source et destination) soient accessibles pendant la migration.

Vérifications SEO après migration par plugin

Une fois la migration par plugin terminée, plusieurs vérifications SEO sont prioritaires avant de pointer le DNS vers le nouveau serveur :

Vérifiez que les URLs du site affichent bien le bon domaine dans les réglages WordPress (Réglages > Général : Adresse WordPress et Adresse du site)
Testez quelques pages importantes pour vérifier qu’elles s’affichent correctement et sans erreur
Vérifiez que le fichier .htaccess est bien présent et contient les règles de réécriture WordPress (mod_rewrite)
Régénérez les permaliens (Réglages > Permaliens > Enregistrer) pour s’assurer que la structure d’URL est bien active sur le nouveau serveur

Migrer manuellement : FTP et base de données SQL

La migration manuelle est plus longue et plus technique qu’une migration par plugin, mais elle reste indispensable à connaître pour deux raisons : les plugins de migration échouent parfois sur les très gros sites ou les configurations serveur atypiques, et comprendre ce que fait un plugin de migration vous permet de diagnostiquer les problèmes quand quelque chose ne fonctionne pas comme prévu.

Étape 1 : télécharger les fichiers du site via FTP

Connectez-vous à votre serveur actuel via un client FTP (FileZilla est le plus utilisé, gratuit et disponible sur tous les systèmes). Naviguez jusqu’au répertoire racine de votre site WordPress (généralement public_html, www ou htdocs selon l’hébergeur) et téléchargez l’intégralité du dossier sur votre ordinateur.

Quelques points d’attention pendant le téléchargement :

Assurez-vous d’afficher les fichiers cachés dans FileZilla (Serveur > Forcer l’affichage des fichiers cachés) pour ne pas rater le fichier .htaccess qui est caché par défaut et contient les règles de réécriture WordPress indispensables
Le dossier wp-content/uploads peut être très volumineux sur les sites anciens avec beaucoup de médias. Si votre connexion est lente, commencez le téléchargement le soir pour le laisser tourner pendant la nuit
Ne modifiez aucun fichier pendant le téléchargement : toute modification en cours de transfert peut corrompre la cohérence entre les fichiers et la base de données

Étape 2 : exporter la base de données via phpMyAdmin

Connectez-vous à phpMyAdmin depuis le panel de votre hébergeur actuel. Sélectionnez votre base de données WordPress dans la liste de gauche, puis cliquez sur l’onglet « Exporter ». Choisissez la méthode « Rapide » et le format SQL, puis cliquez sur « Exécuter ». phpMyAdmin génère un fichier .sql qui contient toute la structure et les données de votre base.

Sur les bases de données volumineuses (plusieurs centaines de Mo), l’export via phpMyAdmin peut timeout. Dans ce cas, utilisez l’outil WP-CLI depuis le terminal de votre hébergeur si vous avez un accès SSH :

wp db export backup.sql --add-drop-table

Cette commande génère un fichier SQL complet avec les instructions de suppression des tables existantes avant leur recréation, ce qui évite les conflits lors de l’import sur le nouveau serveur.

Étape 3 : préparer le nouveau serveur

Sur votre nouvel hébergeur, créez une nouvelle base de données MySQL vide et un utilisateur avec tous les privilèges sur cette base. Notez précisément les informations de connexion : nom de la base de données, nom d’utilisateur, mot de passe, et nom du serveur de base de données (souvent localhost mais pas toujours selon l’hébergeur).

Installez une version vierge de WordPress sur le nouveau serveur ou uploadez simplement les fichiers de votre site via FTP. Si vous uploadez les fichiers de votre site directement (sans passer par une installation WordPress vierge), assurez-vous que le dossier de destination est vide avant de commencer le transfert.

Étape 4 : modifier le fichier wp-config.php

Avant d’uploader les fichiers sur le nouveau serveur, ouvrez le fichier wp-config.php dans un éditeur de texte et mettez à jour les informations de connexion à la base de données pour qu’elles correspondent aux identifiants de la nouvelle base :

define('DB_NAME', 'nom_nouvelle_base');
define('DB_USER', 'utilisateur_nouvelle_base');
define('DB_PASSWORD', 'mot_de_passe_nouvelle_base');
define('DB_HOST', 'localhost');

Uploadez ensuite l’ensemble des fichiers via FTP vers le répertoire racine du nouveau serveur.

Étape 5 : importer la base de données

Dans phpMyAdmin du nouveau serveur, sélectionnez la base de données vide que vous venez de créer et cliquez sur « Importer ». Sélectionnez le fichier .sql exporté précédemment et lancez l’import. Cette opération peut prendre quelques minutes selon la taille de la base.

Si l’import échoue à cause de la limite de taille de fichier PHP (upload_max_filesize), plusieurs solutions existent : augmenter cette limite dans la configuration PHP de l’hébergeur, utiliser l’import en ligne de commande via WP-CLI, ou diviser le fichier SQL avec un outil comme BigDump.

Mise à jour des URLs en base de données

C’est l’étape la plus critique d’une migration avec changement de domaine et celle qui génère le plus d’erreurs si elle est mal faite. Toutes les URLs de votre ancien domaine sont stockées dans la base de données WordPress : dans les contenus des articles et des pages, dans les paramètres du site, dans les métadonnées, dans les options des plugins. Si ces URLs ne sont pas mises à jour vers le nouveau domaine, votre site affichera des erreurs, des ressources manquantes et des liens cassés.

Pourquoi un simple rechercher-remplacer en SQL ne suffit pas

La base de données WordPress contient des données sérialisées : des tableaux PHP encodés sous forme de chaînes de caractères avec des compteurs de longueur intégrés. Une opération de rechercher-remplacer classique en SQL modifie le texte mais ne met pas à jour les compteurs de longueur, ce qui corrompt les données sérialisées et génère des erreurs d’affichage parfois difficiles à diagnostiquer.

Il faut utiliser un outil qui gère correctement la sérialisation PHP lors du remplacement des URLs.

Méthode 1 : Search Replace DB (interconnectit)

Search Replace DB est un script PHP gratuit développé par l’équipe Interconnect/it, spécifiquement conçu pour les migrations WordPress. Il gère la désérialisation et la re-sérialisation des données PHP pendant le remplacement.

Téléchargez le script depuis interconnectit.com
Uploadez le dossier du script à la racine de votre nouveau site via FTP
Accédez à votresite.fr/search-replace-db/ depuis votre navigateur
Renseignez les identifiants de la base de données, l’ancienne URL dans le champ « Search for » et la nouvelle URL dans le champ « Replace with »
Faites d’abord un « Dry run » (simulation) pour voir combien de remplacements seraient effectués avant de lancer l’opération réelle
Lancez le remplacement puis supprimez impérativement le dossier du script de votre serveur : le laisser accessible publiquement est une faille de sécurité grave

Méthode 2 : WP-CLI

Si vous avez accès SSH à votre serveur, WP-CLI propose une commande de search-replace qui gère nativement la sérialisation PHP :

wp search-replace 'https://ancien-domaine.fr' 'https://nouveau-domaine.fr' --skip-columns=guid

Le paramètre --skip-columns=guid évite de modifier la colonne guid des posts, qui est un identifiant unique permanent qui ne doit pas être changé même lors d’un changement de domaine.

Méthode 3 : plugin Velvet Blues Update URLs

Pour ceux qui n’ont pas accès à phpMyAdmin ou SSH, le plugin Velvet Blues Update URLs effectue le même travail depuis le tableau de bord WordPress. Il est gratuit, simple à utiliser, et gère la sérialisation PHP correctement. Activez-le, renseignez l’ancienne et la nouvelle URL, lancez la mise à jour, puis désactivez et supprimez le plugin.

Les URLs à vérifier après le remplacement

Après avoir lancé le search-replace, vérifiez manuellement que les URLs ont bien été mises à jour dans les endroits critiques :

Réglages > Général dans le tableau de bord WordPress : « Adresse WordPress » et « Adresse du site » doivent afficher le nouveau domaine
Quelques articles et pages en frontal pour vérifier que les liens internes et les images pointent vers le bon domaine
Le code source d’une page (clic droit > Afficher le code source) pour vérifier l’absence d’URLs hardcodées vers l’ancien domaine dans les scripts et les styles
Les options des plugins SEO (Rank Math, Yoast) pour vérifier que les URLs du sitemap et des données structurées sont bien mises à jour

Changement DNS et propagation

Le changement DNS est l’étape qui rend votre site accessible sur le nouveau serveur pour les visiteurs du monde entier. C’est une opération simple techniquement mais qui mérite d’être planifiée soigneusement pour minimiser la période de transition pendant laquelle certains visiteurs voient encore l’ancienne version du site.

Comment fonctionne la propagation DNS

Quand vous changez les enregistrements DNS de votre domaine pour pointer vers le nouveau serveur, ce changement ne se répercute pas instantanément partout dans le monde. Chaque résolveur DNS (les serveurs qui traduisent un nom de domaine en adresse IP) conserve en cache les anciennes informations pendant une durée définie par le TTL (Time To Live) de l’enregistrement. La propagation complète peut prendre entre 15 minutes et 48 heures selon les hébergeurs et les TTL configurés.

Pendant cette période de propagation, certains visiteurs voient l’ancienne version du site, d’autres la nouvelle. Ce n’est pas un problème pour la grande majorité des sites, mais cela signifie que vous ne pouvez pas modifier l’ancien site pendant cette période sous peine de créer des incohérences.

Réduire le TTL avant la migration

Si vous avez accès à la configuration DNS de votre domaine (chez votre registrar ou votre hébergeur actuel), réduisez le TTL de vos enregistrements DNS à 300 secondes (5 minutes) au moins 24 heures avant la migration. Quand vous changerez effectivement les enregistrements pour pointer vers le nouveau serveur, la propagation sera beaucoup plus rapide car les résolveurs mettront à jour leur cache toutes les 5 minutes au lieu de toutes les 24 heures.

Tester le nouveau site avant de changer le DNS

Avant de basculer le DNS, vous pouvez tester que le nouveau site fonctionne correctement en modifiant le fichier hosts de votre ordinateur pour forcer la résolution du domaine vers la nouvelle adresse IP, uniquement sur votre machine. Cette technique vous permet de naviguer sur le nouveau site comme si le DNS était déjà propagé, sans impacter les visiteurs réels.

Sur Mac et Linux, le fichier hosts se trouve dans /etc/hosts. Sur Windows, dans C:\Windows\System32\drivers\etc\hosts. Ajoutez une ligne :

NOUVELLE_IP_SERVEUR votresite.fr www.votresite.fr

Après avoir vérifié que tout fonctionne, supprimez cette ligne du fichier hosts avant de changer le DNS.

Procéder au changement DNS

Une fois que vous avez vérifié le bon fonctionnement du site sur le nouveau serveur, procédez au changement DNS depuis l’interface de votre registrar ou de votre gestionnaire DNS :

Mettez à jour l’enregistrement A du domaine principal (votresite.fr) avec la nouvelle adresse IP
Mettez à jour l’enregistrement A du sous-domaine www (www.votresite.fr) ou configurez un CNAME vers le domaine principal
Si vous utilisez Cloudflare, mettez à jour l’adresse IP dans le tableau de bord Cloudflare (pas chez votre registrar)
Notez l’heure exacte du changement : cela vous permettra de corréler les données de trafic et de positions avec la migration

Surveiller la propagation

Utilisez des outils comme dnschecker.org ou whatsmydns.net pour visualiser en temps réel la propagation DNS depuis différentes localisations géographiques. Quand la majorité des serveurs DNS dans le monde pointent vers la nouvelle adresse IP, la migration est effectivement active pour la plupart de vos visiteurs.

Gardez l’ancien serveur actif et accessible pendant au moins 48 heures après le changement DNS. Ne supprimez pas les fichiers ni la base de données de l’ancien hébergeur tant que la propagation n’est pas complète et que vous avez vérifié que le nouveau site fonctionne correctement.

Vérifications SEO post-migration

Les vérifications post-migration sont l’étape la plus souvent bâclée. Beaucoup de webmasters vérifient que leur site « s’affiche bien » et s’arrêtent là. Mais les problèmes SEO d’une migration mal exécutée peuvent mettre des semaines à apparaître dans les données de la Search Console, et certains sont silencieux : pas d’erreur visible, mais des signaux négatifs envoyés à Google.

Vérifications techniques immédiates

HTTPS fonctionnel : vérifiez que le certificat SSL est bien installé sur le nouveau serveur et que toutes les pages sont accessible en HTTPS. La présence de contenu mixte (ressources HTTP sur une page HTTPS) génère des avertissements dans Chrome et des signaux négatifs pour le SEO. Utilisez l’extension Chrome HTTPS Everywhere ou l’outil SSL Checker pour détecter les problèmes de contenu mixte.
Redirections www et non-www : votre site doit être accessible sur une seule version canonique, avec une redirection 301 de l’autre vers la version principale. Si www.votresite.fr et votresite.fr renvoient tous les deux du contenu sans redirection, Google voit deux versions distinctes du site.
Robots.txt accessible : visitez votresite.fr/robots.txt pour vérifier que le fichier est présent et ne contient pas de Disallow: / qui bloquerait tout le crawl. Certains plugins de mise en maintenance ou de développement ajoutent cette directive automatiquement et l’oublient après migration.
Sitemap XML accessible : vérifiez que votre sitemap est accessible à son URL habituelle et qu’il contient bien les URLs du nouveau domaine. Un sitemap qui référence encore les URLs de l’ancien domaine perturbe le crawl de Google.
Pages noindex non voulues : vérifiez dans les réglages de votre plugin SEO et dans Réglages > Lecture que l’option « Demander aux moteurs de recherche de ne pas indexer ce site » n’est pas cochée. Cette option est parfois activée pendant le développement et oubliée après la mise en ligne.

Lancer un nouveau crawl Screaming Frog

Relancez Screaming Frog sur le nouveau site après migration et comparez les résultats avec le crawl de référence effectué avant migration. Vérifiez :

Toutes les URLs importantes du crawl de référence sont bien présentes dans le nouveau crawl (aucune page importante n’a disparu)
Aucune page importante ne renvoie une erreur 404 ou 500
Les balises title, meta descriptions et H1 sont identiques ou améliorées par rapport au crawl de référence
Les redirections existantes avant migration sont bien présentes et fonctionnelles
Aucune chaîne de redirection n’a été créée involontairement pendant la migration

Mettre à jour Google Search Console

Si votre migration implique un changement de domaine, vous devez impérativement utiliser l’outil de changement d’adresse de Google Search Console. Cet outil indique à Google que votre ancien domaine a été remplacé par le nouveau, ce qui accélère le transfert de l’autorité SEO et des signaux accumulés.

Ajoutez le nouveau domaine comme propriété dans Google Search Console et vérifiez-le
Dans la propriété de l’ancien domaine, allez dans Paramètres > Changement d’adresse et sélectionnez le nouveau domaine
Google Search Console vérifie que les redirections 301 sont en place avant d’autoriser l’opération
Soumettez le sitemap XML dans la nouvelle propriété
Surveillez le rapport de couverture de l’index dans les jours suivants pour détecter les erreurs d’indexation

Si votre migration est un simple changement d’hébergeur sans changement de domaine, l’outil de changement d’adresse n’est pas nécessaire. Vérifiez simplement que la propriété GSC existante est toujours vérifiée (certaines méthodes de vérification sont liées au serveur) et resoumettre le sitemap.

Redirections 301 : préserver l’autorité et les backlinks

Les redirections 301 sont le mécanisme le plus important pour préserver le capital SEO accumulé lors d’une migration avec changement d’URLs ou de domaine. Chaque page de votre ancien site qui a des backlinks, du trafic organique ou une position établie dans Google doit avoir une redirection 301 vers sa nouvelle URL correspondante. Sans cette redirection, vous perdez l’autorité et les backlinks associés à cette page, ce qui peut prendre des mois à reconstruire.

Comment fonctionnent les redirections 301 pour le SEO

Une redirection 301 indique à Google que la page a définitivement déménagé vers une nouvelle adresse. Google transfère une grande partie (non intégralement) de l’autorité et des signaux de classement de l’ancienne URL vers la nouvelle. Ce transfert n’est pas instantané : il peut prendre plusieurs semaines pour que Google réindexe complètement la nouvelle URL et consolide les signaux de l’ancienne.

Une redirection 302 (temporaire) ne transfère pas d’autorité SEO. Si vous utilisez des redirections 302 pour une migration permanente, vous perdez les bénéfices SEO. Vérifiez toujours que vos redirections de migration utilisent bien le code 301.

Cartographier les redirections nécessaires

Avant de créer les redirections, vous devez identifier quelles URLs de l’ancien site nécessitent une redirection. Plusieurs sources d’information :

L’export des backlinks : toutes les URLs qui reçoivent des backlinks externes doivent avoir une redirection 301. Utilisez l’export Ahrefs ou Semrush réalisé pendant la checklist pré-migration pour identifier ces URLs.
Le rapport de performance GSC : les URLs qui génèrent des clics et des impressions ont de la valeur SEO et méritent une redirection vers leur équivalent sur le nouveau site.
Le crawl Screaming Frog pré-migration : la liste complète des URLs indexables du site, classées par nombre de liens internes entrants, vous indique les pages les plus importantes de l’architecture.

Mettre en place les redirections sur WordPress

Pour un changement d’hébergeur sans changement d’URLs, les redirections 301 existantes doivent simplement être reproduites à l’identique sur le nouveau serveur. Vérifiez que le plugin Redirection ou les règles .htaccess qui géraient ces redirections sont bien actifs après migration.

Pour un changement de domaine, vous devez créer les redirections depuis l’ancien domaine vers le nouveau. Ces redirections doivent être configurées sur l’ancien serveur (qui doit rester actif pour cette raison) :

Via le fichier .htaccess : la méthode la plus efficace pour les serveurs Apache. Ajoutez les règles de redirection directement dans le .htaccess de l’ancien site. Pour rediriger tout un domaine vers un nouveau domaine en préservant les chemins :
```
RewriteEngine On
RewriteRule ^(.*)$ https://nouveau-domaine.fr/$1 [R=301,L]
```
Via le plugin Redirection : le plugin WordPress Redirection permet de gérer les redirections depuis le tableau de bord. Utile pour les redirections URL par URL ou par pattern, mais moins performant que le .htaccess pour rediriger un site entier.
Via Rank Math : Rank Math intègre un gestionnaire de redirections dans l’onglet « Redirections » qui permet de créer des règles 301 et de gérer les erreurs 404 automatiquement détectées.

L’impact des backlinks sur la récupération post-migration

Même avec des redirections 301 parfaitement configurées, le transfert d’autorité depuis les backlinks n’est pas total ni immédiat. Google considère une redirection 301 comme un « signal indirect » et applique une légère réduction d’autorité par rapport à un backlink direct vers la nouvelle URL. Dans la pratique, cet impact est faible sur les sites bien établis mais peut être perceptible sur les sites avec peu de backlinks.

Si vous changez de domaine, contactez proactivement les sites qui ont des backlinks importants vers votre ancien domaine pour leur demander de mettre à jour le lien vers le nouveau domaine. Un backlink direct vers le nouveau domaine vaut toujours plus qu’un backlink via redirection. L’export Ahrefs de vos meilleurs backlinks vous donne les contacts à cibler en priorité.

Search Console et suivi des positions après migration

La migration est terminée techniquement. Maintenant commence la phase de surveillance : vérifier que Google recrawle correctement le nouveau site, que les positions se stabilisent, et détecter rapidement les problèmes qui apparaissent toujours après une migration, même bien exécutée.

Surveiller Google Search Console dans les 30 premiers jours

Les 30 premiers jours après une migration sont la période la plus critique pour le SEO. Plusieurs rapports GSC méritent une surveillance quotidienne ou bihebdomadaire :

Rapport de couverture de l’index : surveillez le nombre de pages indexées et les erreurs. Une chute soudaine du nombre de pages indexées peut signaler un problème de robots.txt, de directive noindex involontaire ou d’erreurs serveur sur le nouveau hébergeur. Une augmentation des erreurs 404 indique des URLs qui n’ont pas été redirigées correctement.
Rapport de performance : comparez les clics et impressions semaine par semaine avec la période pré-migration. Une chute de 20 à 30% dans les premières semaines est normale pendant la période de réindexation. Une chute de plus de 50% persistant au-delà de 3 semaines signale un problème structurel à diagnostiquer.
Rapport d’inspection d’URL : inspectez manuellement vos 5 à 10 pages les plus importantes pour vérifier qu’elles sont bien indexées sur le nouveau domaine et que Google n’affiche pas de problèmes spécifiques.
Rapport sur les liens : vérifiez que Google continue de détecter vos backlinks externes. Après un changement de domaine, les backlinks vers l’ancien domaine apparaissent toujours dans la propriété GSC de l’ancien domaine, pas dans la nouvelle. C’est normal.

Accélérer la réindexation après migration

Google recrawlera naturellement votre site après une migration, mais vous pouvez accélérer le processus :

Soumettez à nouveau votre sitemap XML dans Google Search Console. Allez dans Indexation > Sitemaps et soumettez l’URL complète du sitemap. GSC relancera un crawl prioritaire des URLs listées dans le sitemap.
Utilisez l’outil « Inspection d’URL » pour demander manuellement l’indexation de vos pages les plus importantes. Cliquez sur « Demander l’indexation » après avoir inspecté une URL. Cette action est limitée à quelques dizaines de requêtes par jour.
Si vous avez effectué un changement d’adresse via l’outil GSC dédié, Google accélère le recrawl de l’ancien domaine pour découvrir les redirections et mettre à jour son index.

Suivi des positions avec Ahrefs ou Semrush

Google Search Console donne les positions moyennes mais avec un délai de quelques jours et une agrégation qui masque les variations URL par URL. Pour un suivi précis des positions après migration, configurez un projet Ahrefs ou Semrush avec vos mots-clés cibles et surveillez les positions quotidiennement pendant les 4 premières semaines.

Comparez les positions actuelles avec le snapshot pré-migration que vous avez réalisé dans la checklist. Une page qui était en position 5 et se retrouve en position 15 après migration mérite une investigation : vérifiez que la redirection est en place (si applicable), que la page est bien indexée dans GSC, et que son contenu n’a pas été modifié pendant la migration.

Les problèmes courants post-migration et leurs solutions

Chute de positions persistante après 4 semaines : vérifiez les balises canoniques (une canonique qui pointe vers l’ancien domaine est souvent la cause), les balises noindex involontaires, et la qualité du nouveau serveur (temps de réponse, disponibilité).
Pages 404 signalées dans GSC : identifiez les URLs concernées, vérifiez si elles ont des backlinks ou du trafic, et créez les redirections 301 manquantes.
Contenu mixte HTTPS/HTTP : utilisez l’extension Chrome « HTTPS Everywhere » ou l’outil Why No Padlock pour identifier les ressources HTTP sur des pages HTTPS et corrigez-les dans le contenu ou via une règle .htaccess.
Lenteur du nouveau serveur : mesurez le TTFB (Time To First Byte) avec GTmetrix ou WebPageTest. Si le TTFB dépasse 800ms, le problème vient de l’hébergeur, pas du contenu. Vérifiez la configuration du cache sur le nouveau serveur.

Si vous avez besoin d’un accompagnement pour préparer ou superviser une migration WordPress complexe, consultez ma page consultant SEO WordPress freelance. Et pour aller plus loin sur les bases du SEO WordPress en dehors de la migration, mon guide SEO WordPress complet couvre l’ensemble des optimisations à mettre en place une fois la migration terminée.