Pourquoi migrer vers WordPress ou changer d’hébergeur en 2025
La migration d’un site web — qu’il s’agisse de passer d’un CMS propriétaire vers WordPress, de changer d’hébergeur pour de meilleures performances, ou de restructurer complètement votre présence en ligne — est l’une des opérations techniques les plus critiques pour une entreprise. Mal exécutée, elle peut détruire en quelques jours un référencement naturel construit sur des années. Bien menée, elle préserve intégralement votre positionnement et peut même l’améliorer grâce à de meilleures performances techniques.
Les raisons légitimes de migrer sont nombreuses : votre plateforme actuelle (Wix, Jimdo, Squarespace, un CMS propriétaire) limite vos possibilités de personnalisation et de SEO. Votre hébergeur actuel est trop lent, trop cher, ou ne répond plus à vos besoins de trafic. Votre site nécessite une refonte qui implique un changement de structure URL. Vous fusionnez plusieurs sites en un seul. Vous passez d’un sous-domaine à un domaine propre. Chaque scénario comporte des risques spécifiques pour votre référencement.
Ce guide couvre les deux cas de migration les plus fréquents pour les PME et indépendants : la migration CMS (passage vers WordPress depuis une autre plateforme) et la migration d’hébergeur (même WordPress, nouveau serveur). Dans les deux cas, l’objectif est identique — transférer votre site sans perdre une seule position dans Google, sans casser un seul lien, et sans interrompre l’expérience de vos visiteurs.
Préparation : l’inventaire complet avant toute action
Audit de l’existant : ce que vous devez cartographier
Avant de toucher quoi que ce soit, documentez exhaustivement l’état actuel de votre site. Cette cartographie sera votre référence de contrôle après migration — si quelque chose ne fonctionne plus, vous saurez exactement ce qui a changé.
Inventaire des URLs indexées — Utilisez Google Search Console (section « Pages ») pour lister toutes les URLs que Google connaît. Exportez cette liste complète en CSV. Complétez avec un crawl Screaming Frog (version gratuite : 500 URLs) ou Sitebulb de votre site actuel. Vous devez connaître chaque URL qui génère du trafic, pas seulement vos pages principales. Un vieil article de blog qui reçoit 50 visites/mois est aussi important qu’une page service.
Cartographie des positions SEO — Notez vos positions actuelles sur vos mots-clés stratégiques. Utilisez Google Search Console (rapport « Performances » → filtrer par page) ou un outil de suivi de positions (SE Ranking, Semrush, Ahrefs). Cette baseline vous permettra de détecter toute régression post-migration. Exportez les données des 3 derniers mois pour avoir une référence fiable.
Inventaire des backlinks — Les liens entrants vers votre site sont un capital SEO critique. Exportez votre profil de backlinks via Google Search Console (section « Liens ») ou Ahrefs/Majestic. Identifiez les pages qui reçoivent le plus de liens externes — ce sont vos pages les plus fragiles en cas de migration car changer leur URL sans redirection 301 détruirait toute leur autorité SEO.
Liste des fonctionnalités actives — Formulaires de contact, e-commerce, espace membre, newsletter, redirections existantes, fichier robots.txt, sitemap XML, balises canoniques, scripts d’analytics, pixels publicitaires, intégrations tierces (Google Maps, réservation, chat). Chaque élément devra être recréé ou migré sur le nouveau site.
Mesure des performances actuelles — Temps de chargement (GTmetrix, PageSpeed Insights), trafic organique mensuel (Analytics), taux de conversion actuels. Ces données serviront de benchmark post-migration pour confirmer que tout fonctionne aussi bien (ou mieux) qu’avant.
Le plan de redirections : votre assurance anti-catastrophe SEO
Si vos URLs changent pendant la migration (ce qui est presque toujours le cas lors d’un changement de CMS), chaque ancienne URL doit pointer vers la nouvelle URL correspondante via une redirection 301 (permanente). C’est LA règle non négociable d’une migration sans perte SEO. Une redirection 301 transfère entre 90% et 99% de l’autorité SEO de l’ancienne URL vers la nouvelle.
Construisez votre mapping de redirections dans un tableau à deux colonnes :
Colonne A : URL ancienne (exacte, avec le slash final ou sans selon votre configuration). Colonne B : URL nouvelle correspondante. Chaque ligne représente une redirection à implémenter.
Règles critiques pour votre plan de redirections :
Chaque ancienne URL doit avoir une correspondance — Pas d’URL orpheline. Si une page n’a pas d’équivalent sur le nouveau site, redirigez-la vers la page la plus proche thématiquement (la catégorie parente, une page similaire) — jamais vers la page d’accueil sauf en dernier recours.
Redirection 1-pour-1, pas de chaînes — L’URL A doit rediriger directement vers l’URL B finale. Évitez les chaînes de redirections (A → B → C) qui diluent l’autorité SEO et ralentissent le chargement.
Conservez les mêmes URLs si possible — La meilleure redirection est celle qui n’a pas besoin d’exister. Si vous pouvez conserver la même structure d’URL sur le nouveau site (/services/creation-site-web reste /services/creation-site-web), faites-le. Moins de redirections = moins de risques.
Testez chaque redirection avant le lancement — Une seule redirection manquante sur une page à fort trafic peut représenter des centaines de visiteurs perdus par jour. Vérifiez chaque ligne de votre tableau avec un outil comme Screaming Frog (mode « List » pour tester une liste d’URLs).
Choix du moment : quand migrer pour minimiser l’impact
Le timing d’une migration n’est pas anodin. Google met 2 à 6 semaines pour traiter complètement une migration (crawl des nouvelles URLs, suivi des redirections, mise à jour de l’index). Pendant cette période de transition, des fluctuations de positions sont normales.
Évitez vos périodes de forte activité — Un e-commerce ne migre pas en novembre-décembre. Un site de location saisonnière ne migre pas en juin. Choisissez une période creuse où une baisse temporaire de visibilité a un impact minimal sur votre activité.
Évitez les vendredis et veilles de week-end — Si un problème critique survient après la migration, vous devez pouvoir intervenir immédiatement. Migrez un mardi ou mercredi matin pour avoir la semaine devant vous.
Prévoyez une fenêtre de maintenance — Informez vos clients fidèles et votre équipe que le site sera momentanément indisponible (généralement 1 à 4 heures pour une migration d’hébergeur, potentiellement un jour pour un changement de CMS complet avec vérification).
Migration vers WordPress depuis un autre CMS : guide pas à pas
Étape 1 : Installer et configurer WordPress sur le nouvel hébergement
Avant de transférer quoi que ce soit, votre environnement WordPress doit être prêt à recevoir le contenu. Installez WordPress sur votre nouvel hébergeur (ou un sous-domaine temporaire pour travailler sans impacter le site actuel).
Choix de l’hébergeur — Pour une migration, privilégiez un hébergeur qui offre : un environnement de staging (copie de test), un support technique réactif pour les migrations, des performances éprouvées (o2switch, Infomaniak, Kinsta, ou un VPS chez OVH/Scaleway pour les sites à fort trafic). Certains hébergeurs proposent même un service de migration assistée gratuit ou inclus dans l’offre.
Configuration WordPress de base — Structure des permaliens (configurez-la AVANT d’importer du contenu pour éviter les problèmes de redirections internes), paramètres de lecture (page d’accueil statique ou dynamique), fuseau horaire, langue du site. Installez immédiatement les plugins essentiels : un plugin SEO (Rank Math ou Yoast), un plugin de redirection (Redirection ou Rank Math intégré), un plugin de cache (WP Rocket ou LiteSpeed Cache), et un plugin de sécurité (Wordfence ou Sucuri).
Thème et structure — Installez et configurez votre thème WordPress. Recréez la structure de navigation (menus) pour qu’elle corresponde à votre architecture de site prévue. Si vous refondez le design en même temps que la migration, finalisez le design AVANT de migrer le contenu — ne migrez pas vers un site à moitié construit.
Étape 2 : Migrer le contenu (textes, images, médias)
La migration du contenu est la partie la plus volumineuse et la plus risquée. Selon votre CMS d’origine, plusieurs méthodes s’offrent à vous :
Migration depuis Wix — Wix n’offre pas d’export natif propre. Deux options : copier-coller manuellement chaque page (viable pour les petits sites de moins de 20 pages), ou utiliser un outil d’extraction comme CMS2CMS (payant, automatisé) qui récupère le contenu et le formate pour WordPress. Les images doivent être téléchargées manuellement ou via l’outil. Vérifiez particulièrement le formatage des textes — les styles Wix ne se traduisent pas toujours proprement en HTML WordPress.
Migration depuis Squarespace — Squarespace offre un export XML partiel (pages et articles de blog). Importez-le via Outils → Importer dans WordPress. Les images, les formulaires, les pages produits et les galeries ne sont PAS inclus dans l’export et doivent être migrés manuellement. Vérifiez chaque page après import pour corriger le formatage.
Migration depuis Joomla ou Drupal — Des plugins WordPress dédiés existent (FG Joomla to WordPress, FG Drupal to WordPress) qui importent articles, catégories, tags, et images. Ils fonctionnent bien pour le contenu textuel mais nécessitent souvent un nettoyage post-import (shortcodes non compatibles, mise en forme cassée).
Migration depuis un CMS propriétaire ou un site statique — Aucun outil automatisé ne fonctionnera. La migration est manuelle : export du contenu en CSV ou copie directe, puis import dans WordPress via WP All Import (plugin payant mais puissant pour les imports en masse) ou création manuelle des pages. Pour les images, téléchargez-les toutes depuis l’ancien serveur et uploadez-les dans la médiathèque WordPress.
Vérification post-import indispensable — Après l’import, parcourez CHAQUE page pour vérifier : le formatage du texte (pas de code HTML résiduel visible), les images (toutes présentes et correctement dimensionnées), les liens internes (mis à jour vers les nouvelles URLs), les caractères spéciaux et accents (encodage UTF-8 correct), les métadonnées SEO (title, meta description récupérés ou à recréer).
Étape 3 : Implémenter les redirections 301
Avec votre plan de redirections préparé à l’étape de préparation, implémentez chaque redirection. Plusieurs méthodes selon votre hébergement :
Via le fichier .htaccess (serveur Apache) — La méthode la plus fiable et la plus performante. Ajoutez vos règles de redirection directement dans le fichier .htaccess à la racine de votre WordPress. Format : Redirect 301 /ancienne-url https://votresite.fr/nouvelle-url pour les redirections simples, ou des règles RewriteRule pour les patterns plus complexes (changement de structure globale).
Via le plugin Redirection (WordPress) — Plus facile à gérer via l’interface admin, idéal pour les non-techniciens. Le plugin gère les redirections via PHP plutôt que .htaccess (légèrement moins performant mais parfaitement fonctionnel pour des sites de taille moyenne). Avantage : log des 404, monitoring des redirections, import CSV de votre liste de redirections.
Via Rank Math (si vous l’utilisez comme plugin SEO) — Rank Math intègre un module de redirection performant. Avantage : il détecte automatiquement les 404 et propose de créer des redirections. Idéal si vous utilisez déjà Rank Math — pas besoin d’un plugin supplémentaire.
Via le .htaccess pour les redirections en masse — Si votre ancienne structure était /blog/2023/article-titre et que la nouvelle est /article-titre, une seule règle RewriteRule avec regex couvre des centaines de pages d’un coup. Exemple : RewriteRule ^blog/[0-9]{4}/(.*)$ /$1 [R=301,L]. Cette approche nécessite une bonne maîtrise des expressions régulières mais économise un temps considérable sur les gros sites.
Étape 4 : Configurer le SEO technique sur WordPress
WordPress n’est pas optimisé pour le SEO out-of-the-box. Configurez ces éléments AVANT de mettre le nouveau site en production :
Plugin SEO (Rank Math ou Yoast) — Configurez les balises title et meta description de chaque page (reprenez celles de l’ancien site si elles fonctionnaient, ou améliorez-les). Configurez le sitemap XML (activez-le dans les paramètres du plugin). Configurez les balises canoniques (automatiques avec ces plugins). Configurez le fichier robots.txt via le plugin.
Structure des permaliens — Configurez-la selon votre plan de migration. Si vos anciennes URLs étaient /nom-de-la-page, configurez WordPress en « Nom de l’article » pour les articles et vérifiez les slugs de vos pages statiques. ATTENTION : ne changez JAMAIS la structure des permaliens après avoir publié du contenu — ça casse toutes les URLs internes.
Sitemap XML — Vérifiez que votre nouveau sitemap contient toutes vos pages importantes et aucune page inutile (pages auteur vides, pages d’archives, pages de tags non pertinentes). Soumettez le nouveau sitemap dans Google Search Console.
Balises hreflang (si site multilingue) — Si votre ancien site avait des versions linguistiques, reproduisez les balises hreflang sur le nouveau site pour éviter toute confusion de Google sur la langue cible de chaque page.
Données structurées (Schema.org) — Si votre ancien site avait des données structurées (FAQ, Organisation, LocalBusiness, Article), recréez-les sur WordPress via Rank Math ou un plugin dédié comme Schema Pro.
Migration d’hébergeur (même WordPress, nouveau serveur)
Méthode 1 : Migration via plugin (la plus simple)
Pour une migration WordPress vers WordPress (même version, même CMS, juste un changement de serveur), les plugins de migration automatisent 90% du processus :
All-in-One WP Migration (gratuit jusqu’à 512MB) — Le plus simple. Il exporte l’intégralité de votre site (base de données, fichiers, thème, plugins, uploads) en un seul fichier. Vous importez ce fichier sur le nouveau serveur et tout est en place. Limitation : la version gratuite limite la taille d’import à 512MB. Au-delà, vous avez besoin de l’extension payante (69$) ou d’une autre méthode.
Duplicator (gratuit) — Plus technique mais plus puissant. Il crée un « package » (archive + installateur). Vous uploadez les deux fichiers sur le nouveau serveur, lancez l’installateur via navigateur, et il reconfigure automatiquement la base de données avec les nouvelles informations serveur (URL, préfixes). Idéal pour les sites plus volumineux.
UpdraftPlus (gratuit) — Normalement un plugin de backup, mais il permet aussi la migration. Sauvegardez votre site, installez UpdraftPlus sur le nouveau serveur, et restaurez la sauvegarde. Simple et fiable si vous l’utilisez déjà pour vos backups.
Service de migration de l’hébergeur — De nombreux hébergeurs (Kinsta, SiteGround, Cloudways, o2switch) proposent une migration gratuite ou assistée. Vous leur donnez accès à votre ancien hébergement, et ils transfèrent tout. C’est souvent la méthode la moins risquée car gérée par des professionnels de l’infrastructure.
Méthode 2 : Migration manuelle (contrôle total)
Pour les développeurs ou les situations complexes (site très volumineux, multisite, configuration serveur spécifique), la migration manuelle offre un contrôle total :
1. Export de la base de données — Via phpMyAdmin sur l’ancien serveur, exportez votre base de données WordPress en SQL. Choisissez le format SQL, compression gzip pour les grosses bases. Vérifiez que l’export est complet (toutes les tables préfixées wp_ ou votre préfixe personnalisé).
2. Téléchargement des fichiers — Via FTP ou le gestionnaire de fichiers de votre hébergeur, téléchargez l’intégralité du dossier WordPress (wp-content principalement : thèmes, plugins, uploads). Le dossier wp-content/uploads peut peser plusieurs GB sur les sites avec beaucoup d’images — prévoyez le temps de transfert.
3. Upload sur le nouveau serveur — Installez un WordPress vierge sur le nouveau serveur. Uploadez vos fichiers wp-content (remplacez le wp-content du WordPress vierge). Importez votre base de données via phpMyAdmin sur le nouveau serveur.
4. Mise à jour du fichier wp-config.php — Modifiez les informations de connexion à la base de données (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) pour correspondre au nouveau serveur. C’est l’erreur la plus courante des migrations manuelles — une mauvaise information de connexion = écran blanc.
5. Rechercher-Remplacer dans la base de données — Si votre domaine change (http → https, www → non-www, ou domaine différent), utilisez l’outil Search-Replace DB (de Interconnect/IT) ou WP-CLI (wp search-replace 'ancien-domaine.fr' 'nouveau-domaine.fr') pour mettre à jour toutes les URLs dans la base de données. CRITIQUE : une simple requête SQL de remplacement ne suffit pas car WordPress sérialise certaines données — seul un outil qui gère la sérialisation fonctionne correctement.
Méthode 3 : Migration avec changement de domaine
Si votre migration implique aussi un changement de nom de domaine (ancien-site.fr → nouveau-site.fr), des étapes supplémentaires sont nécessaires pour préserver votre SEO :
Redirections 301 du domaine entier — Configurez votre ancien domaine pour rediriger toutes ses URLs vers les URLs correspondantes du nouveau domaine. Cela nécessite de conserver l’ancien domaine actif pendant au minimum 6 à 12 mois (les redirections doivent rester en place le temps que Google transfère complètement l’autorité).
Outil « Changement d’adresse » dans Google Search Console — Google fournit un outil spécifique pour signaler un changement de domaine. Ajoutez les deux domaines (ancien et nouveau) dans Search Console, vérifiez-les, puis utilisez l’outil de changement d’adresse. Cela accélère significativement le traitement par Google.
Mise à jour des backlinks (si possible) — Contactez les sites qui font des liens vers vous pour leur demander de mettre à jour l’URL. Ce n’est pas toujours possible (articles anciens, annuaires), mais pour vos partenaires et vos mentions sur des sites que vous connaissez, un email suffit souvent.
Mise à jour des citations locales — Si vous avez une fiche Google Business Profile, des inscriptions sur des annuaires ou des profils sur des plateformes, mettez à jour l’URL de votre site partout. La cohérence est importante pour le SEO local.
La bascule DNS : le moment critique
Comprendre le fonctionnement DNS
Le DNS (Domain Name System) est le système qui dit « quand un visiteur tape votresite.fr, envoyez-le vers le serveur IP xxx.xxx.xxx.xxx ». Lors d’une migration d’hébergeur, vous devez modifier ce pointage pour diriger votre domaine vers le nouveau serveur. Cette modification s’appelle le « changement DNS » ou la « bascule DNS ».
Le point critique : la propagation DNS prend entre 1 et 48 heures (généralement 2 à 6 heures en pratique). Pendant cette période, certains visiteurs verront l’ancien site et d’autres le nouveau, selon leur fournisseur d’accès et son cache DNS. Cela signifie que pendant quelques heures, les deux versions du site doivent être fonctionnelles.
Procédure de bascule optimale
1. Réduisez le TTL à l’avance — Le TTL (Time To Live) est la durée pendant laquelle les serveurs DNS gardent en cache votre configuration. Par défaut, il est souvent à 86400 secondes (24h). Réduisez-le à 300 secondes (5 minutes) au moins 48 heures AVANT la migration. Ainsi, lors de la bascule, le nouveau pointage se propagera en quelques minutes au lieu de plusieurs heures.
2. Dernière synchronisation du contenu — Juste avant la bascule, re-exportez la base de données de l’ancien site et importez-la sur le nouveau. Cela garantit que tout contenu ajouté pendant la préparation (nouveaux commentaires, commandes, formulaires) est bien sur le nouveau serveur.
3. Modifiez les enregistrements DNS — Changez les enregistrements A (et AAAA pour IPv6) pour pointer vers l’IP du nouveau serveur. Si vous utilisez Cloudflare ou un autre CDN, la bascule est quasi-instantanée (Cloudflare gère ses propres DNS avec un TTL très court).
4. Vérification immédiate — Testez votre site immédiatement après la bascule. Utilisez un outil comme whatsmydns.net pour vérifier la propagation DNS depuis différents endroits du monde. Naviguez sur le site comme un utilisateur : pages principales, formulaires, images, liens internes.
5. Certificat SSL — Si vous utilisez Let’s Encrypt ou un certificat lié à l’hébergeur, vous devrez regénérer le certificat SSL sur le nouveau serveur APRÈS la bascule DNS (Let’s Encrypt nécessite que le domaine pointe déjà vers le serveur pour vérification). Pendant les quelques minutes entre la bascule et la génération du certificat, le site peut afficher un avertissement HTTPS — c’est temporaire.
Le mode maintenance : protégez vos données pendant la bascule
Si votre site reçoit des soumissions de formulaires, des commandes e-commerce, ou des inscriptions, la période de propagation DNS crée un risque de perte de données : un visiteur qui est encore sur l’ancien serveur envoie un formulaire, mais vous ne consultez que le nouveau serveur.
Solutions :
Mode maintenance sur l’ancien site — Dès la bascule DNS effectuée, activez un mode maintenance sur l’ancien site (« Site en cours de migration, de retour dans 2 heures »). Cela empêche les soumissions sur l’ancien serveur et informe les visiteurs encore routés vers l’ancien.
Double réception des formulaires — Configurez vos formulaires pour envoyer les notifications par email plutôt que de stocker uniquement en base de données. Ainsi, même si le formulaire est soumis sur l’ancien serveur, vous recevez l’email.
Gel du contenu — Ne publiez aucun nouveau contenu pendant les 24 heures suivant la bascule. Concentrez-vous uniquement sur la vérification que tout fonctionne correctement.
Vérification post-migration : la checklist des 72 premières heures
Vérifications immédiates (H+0 à H+2)
Navigation globale — Parcourez toutes les pages principales de votre site. Vérifiez que chaque page s’affiche correctement, que le menu fonctionne, que les images sont présentes. Testez sur desktop ET mobile.
Formulaires — Soumettez un test dans chaque formulaire de votre site (contact, devis, newsletter). Vérifiez que vous recevez bien les notifications email et que les données sont stockées correctement dans WordPress.
HTTPS — Vérifiez que toutes les pages sont bien en HTTPS (cadenas vert dans le navigateur). Si certaines pages affichent un avertissement « contenu mixte » (mixed content), c’est que des ressources (images, scripts) sont encore appelées en HTTP. Corrigez via Search-Replace dans la base de données (http:// → https://).
Redirections — Testez un échantillon de vos anciennes URLs (au minimum les 20 plus importantes en termes de trafic et de backlinks). Vérifiez qu’elles redirigent bien vers les bonnes nouvelles URLs avec un code 301 (utilisez un outil comme httpstatus.io ou l’extension Chrome Redirect Path).
Vitesse — Testez la vitesse du nouveau site via GTmetrix et PageSpeed Insights. Comparez avec vos mesures d’avant migration. Si le nouveau site est plus lent, identifiez la cause (cache non configuré, images non optimisées, serveur mal paramétré).
Vérifications dans les 24 heures (H+2 à H+24)
Google Search Console — Soumettez votre nouveau sitemap XML. Vérifiez qu’il n’y a pas d’erreurs d’exploration signalées. Si vous avez changé de domaine, utilisez l’outil de changement d’adresse. Surveillez les erreurs 404 qui commencent à apparaître — chacune est une redirection manquante à corriger.
Tous les liens internes — Lancez un crawl complet de votre nouveau site avec Screaming Frog ou un outil similaire. Identifiez : les liens internes cassés (pointant vers des 404), les liens pointant vers des redirections (à corriger directement vers la destination finale), les ressources manquantes (images, CSS, JS en erreur).
Google Analytics / Tag Manager — Vérifiez que votre tracking fonctionne (données en temps réel dans GA4). Confirmez que les événements de conversion se déclenchent correctement. Si vous avez migré de Universal Analytics vers GA4, c’est aussi le moment de vérifier la configuration.
Robots.txt et Sitemap — Vérifiez que votre robots.txt ne bloque pas accidentellement le crawl de Google (erreur classique : un « Disallow: / » laissé par le mode développement). Vérifiez que votre sitemap XML est accessible et ne contient pas d’anciennes URLs.
Emails transactionnels — Si votre site envoie des emails (confirmations de formulaire, e-commerce), vérifiez qu’ils partent bien depuis le nouveau serveur. Les paramètres SMTP peuvent nécessiter une reconfiguration si vous avez changé d’hébergeur.
Vérifications à une semaine (J+7)
Positions SEO — Comparez vos positions actuelles avec votre baseline d’avant migration. Des fluctuations de 2-3 positions sont normales dans les 2 premières semaines. Une chute de plus de 10 positions sur un mot-clé stratégique signale un problème (redirection manquante, contenu différent, problème technique).
Trafic organique — Dans Google Analytics, comparez le trafic de cette semaine avec les semaines précédant la migration. Une baisse de 5 à 15% est acceptable et temporaire. Une baisse de plus de 30% indique un problème significatif à diagnostiquer d’urgence.
Erreurs 404 dans Search Console — Google commence à crawler vos anciennes URLs et à signaler les 404. Chaque erreur rapportée est une redirection que vous avez oubliée — corrigez-la immédiatement. La première semaine est critique car Google reçoit ses premières erreurs de crawl.
Indexation — Vérifiez que Google commence à indexer vos nouvelles URLs (Search Console → Couverture). Si les nouvelles pages restent en « Découverte – actuellement non indexées » après une semaine, il peut y avoir un problème de crawlabilité ou de qualité perçue.
Résoudre les problèmes courants post-migration
Chute de trafic organique importante (>30%)
Si votre trafic organique chute brutalement après migration, procédez par élimination :
Vérifiez le robots.txt — Cause n°1 des catastrophes post-migration. Un « Disallow: / » dans robots.txt bloque tout le crawl de Google. Accédez à votresite.fr/robots.txt et vérifiez qu’il n’y a pas de blocage non intentionnel.
Vérifiez les balises noindex — Certains thèmes ou plugins WordPress ajoutent une balise <meta name= »robots » content= »noindex »> en mode développement. Vérifiez Réglages → Lecture dans WordPress : la case « Demander aux moteurs de recherche de ne pas indexer ce site » ne doit PAS être cochée.
Vérifiez les redirections — Vos anciennes URLs bien positionnées redirigent-elles correctement ? Testez vos 20 pages les plus importantes. Si elles retournent un 404, implémentez d’urgence les redirections manquantes.
Vérifiez le contenu — Le contenu de vos pages clés est-il identique à l’avant-migration ? Une migration qui perd du contenu (texte tronqué, sections manquantes) peut entraîner une réévaluation négative par Google.
Vérifiez les canoniques — Les balises canonical pointent-elles vers les bonnes URLs ? Une canonical qui pointe vers l’ancienne URL (sur l’ancien domaine ou l’ancien CMS) dit à Google de ne pas indexer la nouvelle page.
Pages qui se retrouvent en double indexation
Après migration, il est fréquent que Google indexe temporairement à la fois les anciennes URLs et les nouvelles — surtout si les anciennes ne sont pas redirigées ou si les redirections tardent à être suivies.
Solutions : vérifiez que TOUTES les anciennes URLs redirigent en 301 (pas en 302 — les 302 sont temporaires et Google peut choisir de garder l’ancienne URL en index). Soumettez votre nouveau sitemap ne contenant QUE les nouvelles URLs. Utilisez l’outil « Demande de suppression d’URL » dans Search Console pour les anciennes URLs qui persistent dans l’index après 4+ semaines.
Perte de performances (vitesse dégradée)
Si votre nouveau site est plus lent qu’avant :
Cache non configuré — C’est la cause n°1. Installez et configurez un plugin de cache (WP Rocket, LiteSpeed Cache, W3 Total Cache). Sans cache, WordPress génère chaque page dynamiquement à chaque visite — beaucoup plus lent qu’un site statique ou caché.
Images non optimisées — Si vous avez migré les images sans les ré-optimiser, elles sont peut-être trop lourdes pour le nouveau serveur. Utilisez ShortPixel ou Imagify pour compresser en masse toutes vos images de la médiathèque WordPress.
Hébergeur sous-dimensionné — Si votre ancien hébergeur était performant et que vous êtes passé sur une offre d’entrée de gamme, les ressources serveur peuvent être insuffisantes. Vérifiez le temps de réponse serveur (TTFB) — s’il dépasse 600ms, votre hébergement est le goulot d’étranglement.
Trop de plugins actifs — Chaque plugin ajoute des requêtes. Après migration, désactivez les plugins non essentiels et testez la vitesse sans eux. Identifiez les plugins les plus lourds avec le plugin Query Monitor ou P3 Profiler.
Formulaires et fonctionnalités cassées
Problèmes courants post-migration liés aux formulaires et intégrations :
Emails non envoyés — Le nouveau serveur peut nécessiter une configuration SMTP spécifique. Installez WP Mail SMTP et configurez un envoi via un service tiers (Brevo, SendGrid, le SMTP de votre hébergeur). Le mail natif de WordPress (wp_mail via PHP mail) est souvent bloqué ou filtré comme spam par les hébergeurs.
Formulaires qui ne soumettent pas — Vérifiez que le plugin de formulaire est bien actif et à jour sur le nouveau serveur. Si vous utilisez reCAPTCHA, les clés API sont liées au domaine — regénérez-les si le domaine a changé.
Intégrations tierces cassées — Google Maps (clé API liée au domaine), pixels publicitaires (Facebook, Google Ads), chat en direct, outils de réservation — chaque intégration utilisant une configuration liée au domaine ou à l’URL doit être mise à jour. Découvrez comment l’IA peut faciliter vos futures évolutions techniques.
Bonnes pratiques pour une migration sans stress
Toujours avoir un plan de rollback
Avant de lancer la migration, assurez-vous de pouvoir revenir en arrière en moins de 30 minutes si quelque chose tourne mal. Concrètement :
Conservez l’ancien site intact — Ne supprimez jamais l’ancien site/hébergement avant d’avoir confirmé que tout fonctionne sur le nouveau (minimum 1 mois, idéalement 3 mois). L’ancien site est votre filet de sécurité — un simple changement DNS vous ramène à l’état fonctionnel en quelques minutes.
Backup complet du nouveau site avant la bascule — Si le nouveau site a un problème après la bascule, vous devez pouvoir le restaurer à son état « prêt à basculer » sans tout recommencer.
Documentation de la procédure — Notez chaque étape réalisée et chaque paramètre modifié. En cas de problème, vous saurez exactement ce qui a été fait et pourrez identifier plus facilement la source du dysfonctionnement.
Communiquer avec Google pendant la migration
Google fournit des outils pour faciliter le traitement d’une migration. Utilisez-les :
Google Search Console — Outil de changement d’adresse (si changement de domaine) — Signale officiellement à Google que votre site a déménagé. Accélère le transfert de signaux de classement. Disponible dans Paramètres → Changement d’adresse.
Soumission du nouveau sitemap — Soumettez-le immédiatement après la migration. Cela dit à Google « voici mes nouvelles URLs, crawlez-les en priorité ». Si l’ancien sitemap était soumis, retirez-le de Search Console.
Inspection d’URL — Utilisez l’outil d’inspection d’URL de Search Console pour demander l’indexation de vos pages les plus importantes immédiatement après la migration. Limité à quelques dizaines de demandes par jour, priorisez vos pages à plus fort trafic.
Surveillance des erreurs — Consultez Search Console quotidiennement pendant les 2 premières semaines. Les rapports d’erreurs de crawl vous indiquent en temps quasi-réel les problèmes que Google rencontre sur votre nouveau site.
Le calendrier type d’une migration réussie
J-30 : Préparation — Inventaire complet, plan de redirections, choix du nouvel hébergeur, réduction du TTL DNS. Début de construction du nouveau site sur un environnement de staging.
J-14 : Construction et tests — Site finalisé sur staging, contenu migré, redirections configurées. Tests de performance, vérification des formulaires, QA complète.
J-7 : Pré-bascule — Dernière synchronisation de contenu, vérification finale du plan de redirections, backup de l’ancien ET du nouveau site, communication équipe.
Jour J : Bascule — Changement DNS le matin (mardi ou mercredi), vérifications immédiates, correction des problèmes détectés, soumission sitemap, mode maintenance sur l’ancien.
J+1 à J+7 : Surveillance active — Vérification quotidienne Search Console, correction des 404, monitoring des positions, tests utilisateur.
J+30 : Bilan — Comparaison des métriques pré/post migration. Si tout est stable ou en amélioration, la migration est réussie. Vous pouvez remonter le TTL DNS à sa valeur normale.
FAQ : Migration de site WordPress et changement d’hébergeur
Combien de temps Google met-il pour digérer une migration de site ?
Pour une migration simple (changement d’hébergeur, même URLs) : 24 à 72 heures pour retrouver un fonctionnement normal, les redirections étant traitées au fil du crawl pendant 1 à 2 semaines. Pour une migration complexe (changement de CMS avec nouvelles URLs et redirections) : comptez 2 à 6 semaines pour une stabilisation complète des positions. Les sites à fort trafic avec un crawl fréquent de Google récupèrent plus vite que les petits sites crawlés moins souvent. Pendant la transition, des fluctuations de 2-5 positions sont normales et ne doivent pas vous alarmer.
Faut-il refaire le design en même temps que la migration ?
C’est tentant mais risqué. Idéalement, séparez les deux opérations : migrez d’abord avec un design identique ou très similaire, vérifiez que le SEO est stable, PUIS refondez le design 1 à 2 mois plus tard. Pourquoi ? Si vous changez tout en même temps (CMS, URLs, design, contenu) et que votre trafic chute, vous ne saurez pas quelle modification est responsable. En séparant, vous isolez les variables. Exception : si l’ancien design est non-responsive ou a des problèmes techniques bloquants, la refonte simultanée se justifie car elle améliore des facteurs SEO techniques.
Puis-je migrer mon site seul ou faut-il un développeur ?
Pour une migration simple d’hébergeur (même WordPress, même domaine) avec un plugin comme All-in-One WP Migration : un non-technicien peut gérer seul si le site est petit (<500MB, pas d’e-commerce). Pour une migration de CMS (Wix/Squarespace vers WordPress) ou un changement de domaine : l’intervention d’un développeur ou d’un consultant SEO est fortement recommandée. Le risque de perdre votre référencement sur une erreur technique (redirections mal configurées, canonical incorrectes, robots.txt bloquant) est trop élevé pour l’économie d’un prestataire professionnel.
Que faire si mon ancien hébergeur ne permet pas les redirections 301 ?
Certaines plateformes propriétaires (Wix, Squarespace en plan basique) ne permettent pas de configurer des redirections 301 de manière fine. Solutions : si vous gardez le même domaine, les redirections sont configurées sur le NOUVEAU serveur (via .htaccess ou plugin WordPress) et non sur l’ancien — pas de problème. Si vous changez de domaine et que l’ancien domaine est sur une plateforme limitée, vous devrez transférer le domaine vers un registrar qui permet de configurer les redirections DNS-level ou de pointer le domaine vers un petit serveur qui ne fait que les redirections. En dernier recours, utilisez les redirections de la plateforme (Squarespace les permet en offre Business) même si elles sont limitées.
Mes images vont-elles perdre leur référencement Google Images ?
Oui, si les URLs des images changent sans redirection. Les images ont leur propre positionnement dans Google Images, avec des URLs spécifiques. Si vos images étaient sur anciensite.fr/wp-content/uploads/image.jpg et sont maintenant sur nouveausite.fr/wp-content/uploads/image.jpg, redirigez les anciennes URLs d’images également. La bonne nouvelle : si vous gardez le même domaine et la même structure de dossier uploads, les URLs des images ne changent pas et il n’y a rien à faire.
Conclusion : la migration est un investissement, pas un risque
Une migration de site bien planifiée et bien exécutée n’est pas un danger pour votre référencement — c’est une opportunité d’amélioration. Un meilleur hébergeur augmente vos performances techniques (facteur de classement). WordPress vous donne des outils SEO supérieurs à la plupart des plateformes propriétaires. Une nouvelle structure d’URL plus propre améliore la compréhension de votre site par Google.
La clé est dans la préparation : un inventaire exhaustif, un plan de redirections complet, et une vérification méthodique post-migration. Les migrations qui échouent sont celles qui sont improvisées — pas celles qui sont planifiées. Suivez la checklist de ce guide, testez chaque étape, et votre site retrouvera (voire dépassera) ses positions en quelques semaines. Besoin d’un accompagnement professionnel pour votre migration WordPress ? Contactez Site Web Montpellier pour un audit de pré-migration gratuit.
Parlons de votre projet
Décrivez votre activité en deux lignes. Vous recevez un devis gratuit et détaillé sous 48 h — c’est Noham qui vous répond.
Contact
Envie de créer votre site web ?
Et si on parlait de votre projet ?
