Changer d’hébergeur WordPress sans perdre son référencement : la méthode complète, phase par phase

Changer d’hébergeur WordPress : ce que Google voit réellement

Changer d’hébergeur WordPress ne fait pas perdre de positions en soi. Google n’indexe pas un hébergeur : il indexe des URL, leur contenu et leurs codes de réponse. Si l’adresse de chaque page, ses redirections et son certificat HTTPS sont identiques avant et après, le moteur ne voit qu’un changement d’adresse IP. Google documente ce cas comme un « déplacement de site sans modification des URL ».

Le risque vient des erreurs commises pendant l’opération : pages en 404 ou 500 pendant plusieurs jours, copie de test indexée sur une URL temporaire, réglage « noindex » oublié, coupure HTTPS au moment de la bascule DNS.

Ce guide suit l’ordre chronologique d’une migration : préparation, copie, test, bascule DNS, vérifications, résiliation. Les gestes génériques d’export, d’import et de restauration sont déjà détaillés dans le guide pour sauvegarder, migrer et restaurer un site ; ici, l’accent est mis sur WordPress et sur ce qui protège le référencement. Comptez en général quelques heures de travail, étalées sur trois à sept jours à cause du délai DNS.

Phase 1 : préparer la migration sans rien modifier sur le site

Cette phase ne touche pas au site en production : elle fige un état de référence.

Inventaire technique

1. Notez la version de WordPress, la version PHP, le thème et les extensions (Outils > Santé du site > Informations), ainsi que le poids de wp-content/uploads et de la base.
2. Listez les services tiers qui dépendent de l’adresse IP du serveur : paiement, API, CDN, liste blanche chez un partenaire.
3. Exportez la zone DNS complète (A, AAAA, CNAME, MX, TXT) : c’est votre plan de retour. Décidez si les boîtes e-mail migrent ou restent chez l’ancien prestataire.

État de référence SEO

1. Dans Search Console, exportez le rapport « Pages » et les requêtes des trois derniers mois.
2. Lancez un crawl complet (Screaming Frog, par exemple) et conservez la liste des URL avec leur code HTTP.
3. Copiez le fichier robots.txt, l’adresse du sitemap XML et les redirections 301 (export CSV depuis Redirection, Rank Math ou Yoast, ou règles du .htaccess).

Abaisser le TTL des enregistrements DNS

Le TTL fixe la durée pendant laquelle les résolveurs gardent en cache l’adresse IP du site, souvent 3 600 ou 86 400 secondes. Réduisez-le à 300 secondes sur les enregistrements A et AAAA du domaine et de www, au moins 48 heures avant la bascule. Le guide pour configurer les DNS d’un domaine explique chaque type d’enregistrement et où modifier le TTL.

Où trouver les accès chez OVH, o2switch et Ionos

Pour migrer un site WordPress vers un autre hébergeur, il vous faut trois accès chez l’hébergeur de départ : fichiers, base de données et zone DNS. Les intitulés évoluent, la logique reste la même.

Phase 2 : copier les fichiers et la base de données

Le site reste en ligne pendant la copie. Gelez seulement les modifications de contenu : pas de nouvel article, commentaires fermés.

1. Téléchargez les fichiers par SFTP ou via une archive générée par l’ancien panneau. Le dossier qui compte est wp-content, avec wp-config.php et .htaccess. Comparez le nombre de fichiers et le poids avec la source.
2. Exportez la base depuis phpMyAdmin (format SQL, jeu de caractères utf8mb4) ou, avec un accès SSH :

   mysqldump -u utilisateur -p --single-transaction --default-character-set=utf8mb4 nom_base > site.sql

3. Créez la base de destination dans Plesk (Bases de données > Ajouter une base) avec un utilisateur dédié, puis importez le fichier SQL.
4. Envoyez les fichiers dans le dossier du domaine (généralement httpdocs), par SFTP ou par transfert serveur à serveur en SSH au-delà de quelques gigaoctets.
5. Adaptez wp-config.php : DB_NAME, DB_USER, DB_PASSWORD et DB_HOST (localhost sur Plesk). Conservez le préfixe de table et les clés de sécurité.
6. Alignez la version PHP dans Plesk sur celle de l’ancien hébergeur ; la montée de version viendra après.

Le domaine ne changeant pas, aucun remplacement d’URL en base n’est nécessaire : siteurl et home restent identiques, ce qui rend l’opération sûre pour le référencement. Les extensions Duplicator, All-in-One WP Migration ou UpdraftPlus automatisent ces étapes sur un site modeste, mais atteignent leurs limites sur les gros catalogues de médias.

Phase 3 : tester la copie sur une URL temporaire ou avec le fichier hosts

La copie doit être testée comme si elle était en production. Deux méthodes existent ; la seconde est à privilégier pour WordPress.

URL temporaire

Plesk peut exposer le site sous une adresse provisoire, mais WordPress enregistre l’URL du site en base : il faut remplacer siteurl et home, puis les remettre avant la bascule. Une erreur laisse des liens vers l’adresse provisoire, que Google peut indexer comme un doublon.

Fichier hosts (méthode recommandée)

Vous indiquez à votre ordinateur que le domaine répond déjà sur la nouvelle adresse IP, sans toucher aux DNS publics ni à la base. Ajoutez une ligne dans /etc/hosts (macOS, Linux) ou C:\Windows\System32\drivers\etc\hosts (Windows) :

203.0.113.10  votredomaine.fr www.votredomaine.fr

Remplacez l’adresse par celle indiquée dans votre Espace client, videz le cache DNS du poste et ouvrez le site : vous naviguez sur la copie avec les vraies URL, pendant que le reste du monde voit l’ancien serveur.

Ce qu’il faut vérifier sur la copie

• L’accueil, puis les dix pages les plus visitées selon Search Console ; une erreur 404 généralisée signale un .htaccess manquant.
• La connexion à l’administration, l’envoi d’un média, les formulaires et, pour WooCommerce, une commande en mode test.
• Une dizaine de redirections 301 avec curl -I : code 301 et bonne destination.
• /robots.txt et sitemap XML identiques à l’original ; journal d’erreurs PHP de Plesk vide.

Phase 4 : basculer les DNS sans coupure ni erreur HTTPS

La bascule est l’étape la plus courte, mais c’est là qu’une migration hébergement sans perte SEO se gagne ou se perd. L’ordre des opérations compte.

1. Régler le certificat avant la bascule

Let’s Encrypt vérifie que le domaine pointe vers le serveur demandeur (validation HTTP-01) : tant que les DNS désignent l’ancien hébergeur, Plesk ne peut pas l’émettre. Deux options :

• Importer le certificat existant avec sa clé privée depuis l’ancien hébergeur et l’installer dans Plesk (Certificats SSL/TLS). Le site répond en HTTPS dès la première requête. C’est la méthode à retenir si le site envoie un en-tête HSTS : les navigateurs refusent alors toute connexion non sécurisée.
• Émettre Let’s Encrypt juste après la bascule, en incluant www ; avec un TTL à 300 secondes, la fenêtre d’avertissement dure quelques minutes. Le guide pour activer HTTPS et corriger un certificat SSL détaille l’émission et les erreurs courantes.

2. Synchroniser une dernière fois

Pour un blog peu actif, la copie de la phase 2 suffit. Pour une boutique ou un site à commentaires, réexportez la base juste avant la bascule, réimportez-la, puis passez l’ancien site en maintenance : ce qui serait écrit sur l’ancien serveur pendant la propagation serait perdu.

3. Modifier les enregistrements

1. Dans la zone DNS, remplacez l’adresse des enregistrements A (et AAAA s’ils existent) du domaine nu et de www par celle du nouvel hébergement.
2. Laissez MX et TXT (SPF, DKIM, vérification Google) intacts si les e-mails restent chez l’ancien prestataire. S’ils migrent, modifiez MX et SPF dans la même opération.
3. Si le domaine est géré chez un autre bureau d’enregistrement, la modification se fait chez lui, sans obligation de le déplacer. Un transfert de domaine vers NovaHoster peut se faire plus tard, à froid.

Vérifiez la propagation avec dig votredomaine.fr A depuis plusieurs réseaux. Pendant la propagation, les deux serveurs servent le même contenu : c’est invisible pour Google.

Phase 5 : vérifications post-bascule et suivi du référencement

Dans les 24 heures

1. Rejouez le crawl de la phase 1 et comparez les codes HTTP URL par URL. Toute URL passée de 200 à 404, ou de 301 à 200, se corrige le jour même.
2. Contrôlez avec curl -I la chaîne http:// vers https:// puis vers la version avec ou sans www, en un seul saut si possible.
3. Dans Search Console, inspectez cinq URL représentatives (« Tester l’URL en ligne »), ouvrez le rapport robots.txt et resoumettez le sitemap, à la même adresse qu’avant.
4. Filtrez les journaux d’accès Apache dans Plesk sur les codes 404 et 5xx.
5. Testez l’envoi d’un formulaire : si le serveur d’envoi a changé, complétez le SPF du domaine.

Dans les semaines suivantes

Suivez le rapport « Pages » pendant trois à quatre semaines. Une légère fluctuation pendant quelques jours est habituelle ; une baisse qui s’installe s’explique presque toujours par une URL en erreur ou un blocage. Aucune démarche de « changement d’adresse » n’est à faire dans Search Console : cet outil est réservé aux migrations de nom de domaine.

Les six invariants qui protègent le SEO quand on change d’hébergeur WordPress

Tout ce qui précède se résume à six éléments à conserver strictement identiques, à relire avant de résilier l’ancien contrat.

1. Les URL : même structure de permaliens, même choix entre www et domaine nu, même barre oblique finale. Changer l’un de ces points crée une redirection sur chaque page.
2. Les redirections 301 existantes : réimportez-les dans l’extension ou recopiez les règles du .htaccess, lu par Apache sur un hébergement Plesk.
3. Le fichier robots.txt : ni remplacé par un fichier générique du panneau, ni porteur d’une ligne Disallow: / héritée d’un environnement de test.
4. Le sitemap XML : même adresse, mêmes URL. Un cache serveur peut en servir une version vide quelques minutes : ouvrez-le après la bascule.
5. HTTPS sans interruption : certificat valide pour le domaine et www, redirection HTTP vers HTTPS maintenue, aucun contenu mixte.
6. La propriété Search Console : conservée telle quelle. Si la vérification repose sur un fichier HTML ou une balise du thème, vérifiez qu’ils ont été copiés ; une vérification par enregistrement TXT survit tant que la zone DNS le garde.

Erreurs fréquentes après un changement d’hébergeur et leur correction

Symptômes les plus courants sur un site WordPress migré, cause probable et geste qui corrige.

Ce que fait la migration gratuite NovaHoster et ce qui reste à votre charge

Les phases 2 à 4 peuvent être déléguées. La migration gratuite incluse avec chaque hébergement est réalisée par des techniciens, en général sous 24 heures, pendant que le site reste en ligne chez l’ancien hébergeur.

Ce que NovaHoster prend en charge

• la copie des fichiers, de la base et des boîtes e-mail avec leur contenu, à partir des accès transmis par ticket ;
• la reconfiguration de WordPress (wp-config.php, version PHP, certificat, cache) et les tests avant bascule ;
• la bascule DNS, après votre accord, si le domaine est géré chez NovaHoster ; l’ancien hébergement reste intact.

Ce qui reste de votre côté

• ouvrir le ticket depuis l’Espace client, fournir des accès valides et geler le contenu le temps de la copie finale ;
• modifier les enregistrements DNS chez votre bureau d’enregistrement si le domaine reste ailleurs (phase 4) ;
• les vérifications Search Console de la phase 5, qui demandent l’accès à votre compte Google, puis la résiliation de l’ancien contrat.

Sur l’hébergement WordPress, le staging en un clic (dès la formule BUSINESS) prend le relais pour tester les prochaines mises à jour avant la production.

Attendez en général deux à quatre semaines après la bascule avant de clôturer l’ancien compte, le temps de lire les rapports Search Console et de garder un retour arrière possible.

Liste de contrôle finale avant de résilier l’ancien hébergement

• Crawl post-migration comparé au crawl de référence : aucun nouveau code 404, 500 ou redirection inattendue.
• Permaliens, choix www ou domaine nu et barre oblique finale identiques.
• Redirections 301 historiques réimportées et testées.
• robots.txt identique à l’original ; sitemap XML à la même adresse, resoumis dans Search Console.
• Certificat valide pour le domaine et www, redirection HTTP vers HTTPS en un saut.
• Réglage « Demander aux moteurs de ne pas indexer » décoché sur le site en production.
• Formulaires, envoi d’e-mails, SPF et DKIM testés ; MX cohérents avec l’emplacement des boîtes.
• Zone DNS hébergée hors de l’ancien contrat, TTL remonté à sa valeur habituelle.
• Sauvegardes quotidiennes vérifiées sur le nouvel hébergement, archive de l’ancien site conservée hors ligne.
• Préavis de résiliation respecté ; renouvellement du domaine traité à part.

Si une case reste vide, le support NovaHoster, joignable 7j/7 par livechat et tickets, peut reprendre le point concerné.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

• Activer HTTPS et résoudre un problème de certificat SSL sur NovaHoster — Apprenez à activer HTTPS, vérifier un certificat SSL/TLS, traiter les erreurs de domaine, de renouvellement et de contenu mixte sur…
• Ouvrir une demande de support NovaHoster qui sera traitée efficacement — Découvrez comment rédiger une demande de support NovaHoster complète et sûre pour un problème SSL, sauvegarde, migration ou restauration.
• Sauvegarder, migrer et restaurer un site hébergé chez NovaHoster — Suivez une méthode fiable pour sauvegarder vos fichiers et bases de données, migrer un site vers NovaHoster et restaurer les données sans…
• Administrer un abonnement Plesk sans interrompre son site — Découvrez une méthode fiable pour administrer un abonnement Plesk, modifier les réglages d’un domaine et limiter les risques avant chaque…
• Combien coûte un hébergement web en France en 2026 : grille de prix réaliste et coûts cachés — Prix hébergement web en France en 2026 : budget annuel HT par profil de site, prix d’appel, options facturées, TVA et liste de contrôle…

Sources techniques

[1] Google Search Central — Déplacer un site sans modifier les URL [2] Google Search Central — Redirections et recherche Google [3] WordPress.org — Moving WordPress (Advanced Administration Handbook) [4] WordPress.org — Editing wp-config.php [5] Let’s Encrypt — Challenge Types (validation HTTP-01 et DNS-01)