Changer hébergeur WordPress sans perdre votre référencement
Pour changer hébergeur WordPress sans perte de référencement, migrez d’abord sur un clone testé, basculez le DNS proprement et contrôlez robots, sitemaps et redirections. Réduisez le TTL avant la bascule, activez le SSL et forcez le bon couple www/HTTPS. Vérifiez ensuite les 404, le fichier robots.txt et le canonical, puis surveillez les logs.
Contexte et préparation : poser le cadre SEO avant toute action
Sur le terrain, les pertes SEO lors d’une migration d’hébergeur viennent rarement du serveur lui-même. Elles viennent d’un détail humain : un noindex oublié, une redirection mal réglée, un robots.txt trop strict, ou un sitemap non servi. Avant de toucher au site, je réalise un mini-audit d’état initial pour avoir une ligne de base et pouvoir comparer après bascule.
Si vous débutez avec WordPress, la formation WordPress débutant vous donne le vocabulaire et les réflexes techniques utiles pour aborder ces opérations sereinement.
- Lister les URL principales qui génèrent du trafic et les modèles d’URL (articles, catégories, pages produits).
- Ouvrir le site en navigation privée et vérifier l’affichage, le canonical, le hreflang éventuel et les balises noindex.
- Repérer la version de l’URL publique à conserver: avec ou sans www, en HTTPS.
- Noter les pages d’erreur personnalisées, le mécanisme de cache actuel et les règles de redirection existantes.
- Identifier les dépendances externes sensibles: passerelles de paiement, webhooks, envois d’e-mails.
Ne changez pas de nom de domaine en même temps que d’hébergeur. Si le sujet du TLD vous travaille, clarifiez-le d’abord en lisant ce point de vue sur choisir un .fr ou un .com.
Changer hébergeur WordPress : le plan de migration pas à pas
- Choisir le nouvel hébergeur et l’offre adaptée. Prenez une offre qui correspond à votre usage réel, pas à une promesse marketing. Si vous hésitez entre mutualisé, VPS ou infogéré, cet article aide à trancher selon votre profil : mutualisé, VPS ou infogéré.
- Préparer l’environnement technique. Créez un espace vierge avec la même version majeure de PHP et des modules courants, une base de données et un accès SFTP. Notez les identifiants et préparez un utilisateur avec des droits restreints pour les opérations.
- Réduire le TTL côté DNS avant la bascule. Dans votre zone DNS chez le registraire, abaissez le TTL des enregistrements qui vont bouger afin de raccourcir la période de propagation. Faites-le en amont pour que les caches se vident à temps.
- Geler le contenu le temps de cloner. Bloquez les mises à jour et les publications, suspendez les imports, mettez en pause les tâches planifiées lourdes. Sur un e‑commerce, prévoyez un créneau de bascule où vous pouvez stopper temporairement les commandes pour éviter des paniers divergents.
- Exporter fichiers et base proprement. Côté fichiers, copiez tout le dossier wp-content et le cœur WordPress. Côté base, exportez en UTF‑8 en vérifiant l’intégrité. Vous pouvez passer par SFTP + un export SQL, par un outil de sauvegarde, ou par la ligne de commande si vous maîtrisez WP‑CLI.
- Importer sur le nouveau serveur. Chargez les fichiers, créez la base, importez le SQL puis adaptez wp-config.php aux nouveaux identifiants. Laissez l’ancien site en ligne sans y toucher pour l’instant.
- Contrôler les URL et chemins. Si le domaine ne change pas, le couple siteurl/home doit rester identique. Faites un search‑replace uniquement si vous corrigez des schémas HTTP vers HTTPS ou des chemins internes. Travaillez sur une copie, car les données sérialisées exigent une méthode compatible.
- Tester le clone en privé. Utilisez le fichier hosts local ou l’URL de prévisualisation fournie par l’hébergeur pour valider le rendu, les formulaires, le panier et l’administration. Vérifiez que l’indexation est désactivée sur l’environnement de test pour éviter un doublon dans l’index.
- Activer le SSL/TLS et forcer HTTPS. Installez un certificat valide et configurez une redirection serveur en 301 vers la version HTTPS. Corrigez les contenus mixtes et assurez-vous que la version avec ou sans www est consolidée vers une seule variante.
- Régler le cache. Paramétrez le cache serveur et le cache WordPress de façon équivalente ou meilleure qu’avant la migration. Purgez entièrement puis parcourez les pages clés pour réchauffer le cache.
- Basculer le DNS. Modifiez l’enregistrement A ou CNAME de votre domaine pour pointer vers le nouveau serveur. Ne touchez pas aux MX si vous ne migrez pas la messagerie. Gardez l’ancien hébergement opérationnel le temps que tout le monde bascule.
- Contrôler après bascule et nettoyer. Surveillez les 404, corrigez les redirections manquantes, servez un sitemap à jour et validez le robots.txt. Vérifiez que le canonical pointe bien sur la bonne variante et que les métriques de performance restent stables.
Erreurs fréquentes observées : lancer la bascule DNS sans SSL prêt, oublier de forcer la variante www/non‑www, laisser le « Décourager les moteurs de recherche » actif, ou casser les règles de cache côté serveur.
Si vous envisagez aussi de renommer le site, faites d’abord un choix pérenne puis migrez. Ce guide sur choisir un nom de domaine qu’on ne regrettera pas vous évite d’empiler deux chantiers sensibles à la fois.
Les points qui cassent le référencement sans qu’on s’en aperçoive
- Basculer toute la racine vers l’accueil au lieu de reproduire l’arborescence de redirections. Résultat : perte des signaux d’URL et cannibalisation.
- Passer en 302 « temporaire » par facilité. Pour une variante canonique, une 301 cohérente est attendue.
- Laisser un noindex hérité de l’environnement de test, soit via un plugin SEO, soit via l’option native de WordPress.
- Publier un robots.txt trop restrictif sur le nouveau serveur, ou interdire /wp‑content/ et les sitemaps par erreur.
- Changer la structure des permaliens par inadvertance, ou forcer une barre oblique finale alors qu’elle n’existait pas avant.
- Oublier la redirection entre www et non‑www, et se retrouver avec deux variantes accessibles.
- Laisser l’ancien serveur accessible par IP ou sous‑domaine technique et indexable, créant un doublon.
- Laisser des liens absolus internes en HTTP non mis à jour, générant du contenu mixte et des ressources bloquées.
- Casser les en‑têtes Cache‑Control/Etag, ce qui ralentit le site et peut réduire la fréquence d’exploration.
- Déplacer brutalement l’hébergement sur un autre continent quand l’audience est locale. Voyez ce que cela implique pour le géoréférencement et les moteurs génératifs.
Pour les multisites, testez chaque site du réseau et ses fichiers robots/sitemaps spécifiques. Ne généralisez pas un réglage d’instance qui invaliderait des sous‑sites.
DNS, e‑mails et SSL : ce qu’il faut ajuster et ce qu’il faut laisser
La plupart des incidents SEO post‑migration viennent d’une zone DNS modifiée trop largement. Modifiez uniquement ce qui pointe le Web, laissez la messagerie intacte si elle n’est pas concernée et vérifiez que le certificat couvre exactement le ou les domaines servis.
| Enregistrement | Rôle | Action lors du changement d’hébergeur | Risque SEO si erreur |
|---|---|---|---|
| A | Pointe vers une adresse IPv4 | Mettre à jour vers la nouvelle IP du serveur Web | Site inaccessible ou versions concurrentes si mal synchronisé |
| AAAA | Pointe vers une adresse IPv6 | Aligner si le nouveau serveur gère IPv6 | Incohérence d’accès selon les réseaux des visiteurs |
| CNAME | Alias vers un autre nom | Mettre à jour la cible si vous utilisez un alias pour le Web | Appels vers l’ancien hébergeur, contenus obsolètes |
| MX | Serveurs de messagerie | Ne pas modifier si vous ne migrez pas les e‑mails | Aucun impact SEO, mais risques de perte de mails si changé |
| TXT (SPF, DKIM, DMARC) | Authentification e‑mail | Laisser en l’état sauf migration de l’envoi d’e‑mails | Aucun impact direct SEO, mais délivrabilité des notifications |
| NS | Serveurs de noms | Éviter de les changer pour une simple migration d’hébergeur | Propagation large et risques de zone incomplète |
| TXT (vérifications) | Propriétés de services | Vérifier les jetons de services analytiques et de suivi | Perte de données de suivi, diagnostics plus difficiles |
Ne touchez pas aux serveurs de noms si vous n’êtes pas obligé. Un simple ajustement des enregistrements de la zone existante suffit amplement dans la majorité des migrations.
Installez le certificat SSL/TLS côté nouveau serveur et testez l’accès en HTTPS avant la bascule publique. Sur WordPress, vérifiez que l’URL du site est bien en HTTPS et que la redirection serveur consolide les variantes.
Contrôles après bascule : check‑list de vérification rapide
- Requête HTTP vers l’URL sans www et en HTTP : reçoit‑elle bien une redirection permanente unique vers la bonne variante ?
- Page d’accueil et pages profondes chargent‑elles sans contenu mixte ?
- Les principales URL retournent‑elles un code 200, et les anciennes URL obsolètes un 301 bien ciblé ?
- Le fichier robots.txt est‑il accessible et ne bloque‑t‑il pas l’essentiel du site ?
- Le sitemap XML est‑il servi, propre, et référencé dans le robots.txt ?
- Les logs d’erreurs et d’accès ne montrent‑ils pas un pic inhabituel de 404/500 ?
- Le back‑office fonctionne‑t‑il normalement (médias, permaliens, éditeur, mises à jour) ?
- Le cache se régénère‑t‑il sans erreur, et la vitesse perçue reste‑t‑elle stable ?
Si vous avez plusieurs références internes au même sujet, évitez les redirections en chaîne. Une redirection claire et courte garde les signaux et réduit l’overhead côté serveur.
Pour monter en compétence au‑delà de ce guide, parcourez aussi les formations WordPress proposées et choisissez le format adapté à votre niveau.
Questions fréquentes
Puis‑je changer d’hébergeur et de nom de domaine en même temps ?
Techniquement oui, mais je le déconseille fortement si vous tenez à votre trafic actuel. Séparez les chantiers : stabilisez l’hébergement d’abord, puis travaillez le changement d’adresse avec un plan de redirections exhaustif, en vous appuyant sur ce guide pour choisir un nom de domaine qu’on ne regrettera pas.
Faut‑il prévenir Google lors de la migration d’hébergeur ?
Si le domaine ne change pas, il n’y a rien de formel à déclarer. Servez un sitemap propre, gardez des codes de réponse cohérents et assurez une version canonique claire ; cela suffit à maintenir l’exploration dans un rythme normal.
Que faire si des 404 apparaissent après la bascule ?
Identifiez les URL manquantes via les logs et rebranchez des redirections ciblées vers l’équivalent le plus pertinent. Vérifiez aussi les liens absolus internes et les références d’images, souvent sources de 404 silencieuses après un déplacement de fichiers.
Aller plus loin avec la formation WordPress débutant
Ce tutoriel vous donne une méthode fiable et les contrôles essentiels ; en formation, nous pratiquons ces opérations en direct sur un environnement de test et vous repartez avec une checklist adaptée à votre site. Le programme complet est détaillé sur la page de la formation WordPress débutant.
