Aller au contenu

Migrer WordPress de Bluehost vers cPanel : l'export manuel et la bascule

Bluehost a remplacé cPanel par son propre Account Manager sur la plupart des forfaits. Ce guide vous montre comment reconnaître l'interface que vous avez et migrer WordPress de Bluehost vers cPanel à la main, avec le site validé sur votre serveur avant tout changement DNS.

Ce guide s’adresse à l’administrateur ou au développeur qui déménage un site WordPress de Bluehost vers un serveur cPanel/WHM qu’il contrôle, et il couvre le déménagement au complet. Le hic, c’est que Bluehost a remplacé cPanel par son propre tableau de bord Account Manager sur la plupart des forfaits. L’outil de transfert de WHM n’a donc aucune archive de compte à aller chercher. La réponse courte est de commencer par identifier l’interface qu’affiche votre compte, puis de déplacer vous-même les fichiers et la base par un des trois chemins. Ensuite vous reconstruisez le compte cPanel, recréez les boîtes courriel, corrigez les URL stockées dans la base et faites émettre le certificat à la main. À la fin, le site est servi par votre propre serveur, testé sur son vrai nom d’hôte avant qu’un seul enregistrement DNS ne bouge.

Ce que vous allez accomplir

  • Une réponse claire sur l’interface Bluehost de votre compte, et sur le chemin d’export que ça vous laisse.
  • Une copie complète des fichiers et de la base sur votre compte cPanel, vérifiée plutôt que présumée.
  • Le code de plateforme de Bluehost retiré, à commencer par l’extension « must-use » du cache de page Endurance. WordPress charge ces extensions automatiquement et aucun bouton de l’admin ne les désactive.
  • Chaque boîte courriel recréée sur cPanel avant le déplacement des enregistrements MX. MX veut dire mail exchanger, l’enregistrement DNS qui nomme le serveur recevant le courriel du domaine.
  • Un certificat AutoSSL valide couvrant tous les noms d’hôte servis par le site, émis avant la bascule.

Prérequis

Côté Bluehost, il vous faut l’identifiant du compte qui possède l’hébergement, pas seulement un compte administrateur WordPress. Deux constats dans le tableau de bord décident de votre chemin. Le premier est l’existence d’une page Advanced remplie d’icônes de style cPanel. Le second est l’accès SSH offert par votre forfait, c’est-à-dire un shell distant sur le serveur, que vous confirmez en vous connectant plutôt qu’en lisant une liste de fonctionnalités.

Côté destination, il vous faut un compte cPanel pour le domaine, une base MySQL et son utilisateur, un accès SSH et wp sur la machine. wp, c’est WP-CLI, l’outil WordPress en ligne de commande.

Alignez la version de PHP avant de copier quoi que ce soit. Relevez-la dans le sélecteur PHP du tableau de bord, puis réglez la même version dans MultiPHP Manager de cPanel. Un site en PHP 8.2 qui atterrit sur un compte réglé à 7.4 échoue d’une façon qui ressemble à un téléversement corrompu. Pendant que vous êtes dans le panneau, notez chaque boîte courriel et chaque redirection du domaine, parce que vous vous servirez de cette liste deux fois.

Abaissez ensuite le TTL des enregistrements A et AAAA du domaine à 300, au moins 24 heures d’avance. TTL veut dire time to live, le nombre de secondes pendant lesquelles un résolveur peut garder une réponse en cache. Abaisser un TTL de 86400 secondes deux heures avant la bascule ne change rien, puisque l’ancienne valeur est encore en cache. Si l’éditeur de zone de Bluehost refuse une valeur aussi basse, déplacez l’hébergement DNS une semaine d’avance chez un fournisseur qui l’accepte. Le plan d’abaissement du TTL avant bascule donne le calendrier.

Comment ça marche

Une migration déplace trois choses : les fichiers, la base et les enregistrements DNS qui y dirigent les visiteurs. Par-dessus s’ajoute tout ce que l’ancien hébergeur a enroulé autour du site, et l’enveloppe de Bluehost est plus épaisse que la moyenne. Sur les forfaits qui utilisent l’Account Manager, le panneau est un logiciel maison de Bluehost. Il offre un gestionnaire de fichiers, des outils de base et des sauvegardes, mais aucune archive de compte cPanel. Rien ne se restaure tout seul, donc chaque morceau voyage séparément.

Schéma de décision montrant comment distinguer un compte Bluehost hérité de type cPanel d'un compte Account Manager, puis les trois chemins d'export et le travail manuel commun aux trois

Les chemins ne diffèrent que par la façon dont les octets quittent Bluehost. Le chemin A n’exige rien de plus qu’un navigateur et fonctionne sur tous les forfaits, au prix d’archives à décompresser à la main. Le chemin B est le plus propre quand le forfait inclut SSH : un dump WP-CLI plus un tar de wp-content pèse bien moins qu’une sauvegarde de compte complète. Le chemin C couvre Duplicator, All-in-One WP Migration et compagnie, qui s’exécutent dans PHP. Sur un gros site, cet export peut buter sur memory_limit ou max_execution_time et laisser une archive qui a l’air complète sans l’être.

Le code de Bluehost traverse avec les fichiers quel que soit le chemin, et rien de tout ça ne fonctionne sur votre serveur.

Tableau associant chaque morceau de code de plateforme Bluehost au fichier où il vit et au geste à poser sur cPanel

Le morceau qui compte le plus est endurance-page-cache.php, que Bluehost installe dans wp-content/mu-plugins/. WordPress charge les extensions « must-use » à chaque requête et n’offre aucun moyen de les désactiver depuis l’admin, donc celle-ci continue de tourner après le déménagement. Hors de Bluehost, elle met en cache dans un dossier que rien ne sert et réécrit un .htaccess que vous essayez de contrôler. L’extension Bluehost et, sur les vieilles installations, mojo-marketplace-wp-plugin appellent toutes deux des services que votre compte n’a plus.

Marche à suivre

Tout ce qui précède le gel de l’étape 11 est une répétition que vous pouvez refaire. Tout ce qui suit est en direct.

  1. Identifiez votre interface. Connectez-vous et cherchez une page Advanced avec des groupes d’icônes de style cPanel. Si elle est là, ouvrez Backup ou Backup Wizard et regardez s’il existe une sauvegarde complète du compte. Une vraie se télécharge sous un nom de la forme backup-09.10.2026_04-00-00_bhuser.tar.gz, et ce fichier-là est le seul qui se restaure dans WHM :

    /usr/local/cpanel/scripts/restorepkg /home/backup-09.10.2026_04-00-00_bhuser.tar.gz

    Lancez-la en root. Elle journalise chaque étape et se termine en nommant le compte créé. Confirmez-le :

    whmapi1 accountsummary user=CPUSER

    La commande renvoie un bloc de champs qui se termine par result: 1. Si le tableau de bord n’offre qu’un zip de vos fichiers, ou aucune sauvegarde complète, vous êtes sur le chemin manuel, soit tout le reste de cet article.

  2. Faites l’inventaire pendant que le site est encore sur Bluehost. Avec SSH :

    wp core version
    wp core verify-checksums
    wp plugin list --status=active --fields=name,version
    ls -1 wp-content/mu-plugins/
    wp db size --tables --size_format=mb
    pwd

    Notez la version du noyau, parce que vous réinstallerez exactement celle-là. verify-checksums affiche Success: WordPress installs verify against checksums., et tout ce qu’il signale est un fichier du noyau modifié dont il faut tenir compte. Gardez la sortie de pwd : les répertoires personnels de Bluehost ressemblent à /home/BHUSER/public_html, ou /home1/BHUSER/public_html sur les vieux serveurs, et cette chaîne est stockée dans votre base. Sans SSH, lisez la version sous Tableau de bord puis Mises à jour, et servez-vous du gestionnaire de fichiers et de phpMyAdmin pour le reste.

  3. Exportez la base. Avec SSH :

    wp db export bh-bulk.sql --add-drop-table

    Attendez-vous à Success: Exported to 'bh-bulk.sql'. Sans WP-CLI, ouvrez phpMyAdmin, choisissez la base, puis Exporter, puis Personnalisé, et cochez « Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT ». Dans les deux cas, vérifiez la fin du fichier :

    tail -3 bh-bulk.sql

    Elle doit se terminer sur une instruction complète, pas au milieu d’un INSERT. Un dump tronqué s’importe sans broncher et perd silencieusement la fin de votre plus grosse table. Pour un fichier gzip, utilisez gunzip -c bh-bulk.sql.gz | tail -3.

  4. Empaquetez les fichiers. Depuis la racine du site, en SSH :

    tar -czf ~/bh-files.tar.gz wp-content wp-config.php .htaccess

    Les fichiers du noyau ne valent pas le transfert, puisque l’étape 6 en télécharge une copie neuve. tar n’affiche rien quand ça marche, alors comparez ls -lh ~/bh-files.tar.gz à l’espace disque annoncé par le tableau de bord. Sur le chemin A, le compresser-puis-télécharger du gestionnaire de fichiers remplace cette étape ; sur le chemin C, c’est l’archive de l’extension.

  5. Transférez l’archive vers le serveur cPanel. Tirez plutôt que pousser, en lançant ceci sur la destination sous l’utilisateur du compte cPanel :

    scp -P SSHPORT BHUSER@BHHOST:bh-bulk.sql BHUSER@BHHOST:bh-files.tar.gz ~/

    Prenez SSHPORT et BHHOST dans le panneau SSH du tableau de bord. scp affiche une ligne de progression par fichier, chacune se terminant à 100%. Ne le lancez jamais en root, sinon le problème de propriété de la section Dépannage devient le vôtre.

  6. Reconstruisez le compte et restaurez dedans. Créez d’abord la base et son utilisateur dans l’assistant MySQL de cPanel, puis inscrivez ces identifiants dans wp-config.php une fois le fichier en place. Ceux de Bluehost ne fonctionneront pas ici.

    cd ~/public_html
    wp core download --version=WPVERSION --skip-content
    tar -xzf ~/bh-files.tar.gz -C ~/public_html
    wp db import ~/bh-bulk.sql

    Remplacez par la version de l’étape 2. --skip-content laisse wp-content vide pour que l’archive le remplisse. Attendez-vous à Success: WordPress downloaded. puis Success: Imported from 'bh-bulk.sql'.

  7. Retirez le code de plateforme de Bluehost. Listez d’abord ce qui est là, parce que l’ensemble varie selon l’âge du compte :

    ls -1 wp-content/mu-plugins/
    wp plugin list --fields=name,status

    Retirez ensuite les morceaux que la liste a révélés :

    rm -f wp-content/mu-plugins/endurance-page-cache.php
    rm -rf wp-content/endurance-page-cache
    wp plugin deactivate bluehost-wordpress-plugin
    wp plugin delete bluehost-wordpress-plugin

    Ces commandes renvoient Success: Deactivated 1 of 1 plugins. et Success: Deleted 1 of 1 plugins. Si l’une des extensions n’a jamais été installée, WP-CLI avertit qu’il ne la trouve pas, et c’est très bien. Nettoyez maintenant les fichiers qui contiennent le reste :

    grep -n "WP_CACHE\|ndurance" wp-config.php .htaccess
    ls -l wp-content/object-cache.php wp-content/advanced-cache.php

    Le grep vous donne les numéros de ligne de define('WP_CACHE', true); dans wp-config.php et de tout bloc Endurance dans .htaccess. Supprimez la constante, et supprimez ce bloc de son marqueur BEGIN à son marqueur END. Le ls doit répondre No such file or directory deux fois ; un drop-in de cache objet qui survit pointe vers un service que ce serveur ne fait pas tourner.

  8. Réécrivez les URL et les chemins dans la base. Faites d’abord une simulation, avec la chaîne exacte que pwd vous a donnée à l’étape 2 :

    wp search-replace '/home1/BHUSER/public_html' '/home/CPUSER/public_html' --all-tables --dry-run --report-changed-only

    Lisez les décomptes par table et la ligne finale Success: N replacements to be made, puis lancez la même commande pour de vrai :

    wp search-replace '/home1/BHUSER/public_html' '/home/CPUSER/public_html' --all-tables --precise

    --all-tables parcourt toutes les tables, y compris celles qu’une extension a créées sous un autre préfixe et que le balayage par défaut saute. --precise force WP-CLI à désérialiser et resérialiser en PHP au lieu d’utiliser le chemin SQL brut plus rapide, ce qui garde les tableaux sérialisés valides quand un remplacement change la longueur d’une chaîne. La référence WP-CLI de search-replace documente chaque option.

  9. Créez les boîtes courriel maintenant, avant le déplacement du MX. À partir de la liste des prérequis, créez chaque adresse dans l’écran Comptes de messagerie de cPanel avec la même partie locale. Ajoutez aussi les redirections et les répondeurs. Rapatriez ensuite le courrier pendant que Bluehost le détient encore et que le MX y pointe toujours :

    imapsync --host1 mail.example.com --user1 you@example.com --password1 OLDPASS --host2 localhost --user2 you@example.com --password2 NEWPASS

    Utilisez comme --host1 le serveur entrant que nomment les réglages de courriel du tableau de bord. imapsync se termine par un résumé du transfert et une ligne Detected 0 errors. Pour deux ou trois boîtes, ajouter les deux comptes à un logiciel de courriel IMAP et glisser les dossiers fait tout aussi bien l’affaire.

  10. Faites émettre le certificat, puis testez sur le vrai nom d’hôte. AutoSSL est le service de certificats gratuit de cPanel. Il prouve que vous contrôlez le domaine par HTTP ou par DNS. La validation HTTP ne peut pas réussir tant que le domaine ne résout pas vers le nouveau serveur. Prenez donc la voie DNS : ajoutez l’enregistrement TXT demandé pendant que Bluehost sert encore le trafic. Le portail de documentation de cPanel couvre les options de DCV, DCV voulant dire domain control validation, la validation du contrôle du domaine.

    uapi SSL installed_hosts | grep -i domains
    curl -sI --resolve example.com:443:NEWIP https://example.com/ | head -1

    Le domaine apex, www et chaque sous-domaine doivent apparaître dans la sortie de la première commande. La seconde envoie la requête à NEWIP tout en demandant example.com, donc vous voyez ce que verra un visiteur une fois le DNS déplacé. Attendez-vous à HTTP/2 200 et à aucun avertissement de certificat.

  11. Gelez, synchronisez le delta, puis déplacez le DNS. Mettez le site Bluehost en mode maintenance pour qu’aucune commande, aucun commentaire et aucune soumission de formulaire n’arrive après votre export final. Refaites les étapes 3 et 4, réimportez, relancez la paire de search-replace, puis changez les enregistrements A et AAAA. Ne déplacez le MX dans la même passe que si l’étape 9 est terminée.

  12. Videz les règles de réécriture.

    wp rewrite flush --hard
    wp cache flush

    Attendez-vous à Success: Rewrite rules flushed. et Success: The cache was flushed. La forme --hard réécrit le bloc WordPress dans .htaccess, pas seulement la copie en base. Ça compte ici, parce que l’étape 7 a retiré un morceau du .htaccess fourni par Bluehost.

Vérifier que ça fonctionne

Environ une heure après la bascule, vérifiez de l’intérieur :

wp option get siteurl
wp option get home
wp db check
wp core verify-checksums

Les deux options doivent renvoyer le domaine final, wp db check doit rapporter OK sur chaque table, et les sommes de contrôle doivent concorder. Mettez ensuite vos vingt URL les plus fréquentées dans un fichier et balayez-les :

while read -r u; do code=$(curl -o /dev/null -s -w '%{http_code}' "$u"); echo "$code $u"; done < top-urls.txt

Chaque ligne doit afficher 200, ou 301 là où vous redirigez volontairement. Confirmez ensuite la résolution, le TLS et l’acheminement du courriel :

dig +short example.com @1.1.1.1
dig +short MX example.com @1.1.1.1
curl -sI https://example.com/ | head -1

La première doit renvoyer l’adresse de votre serveur cPanel depuis un résolveur public, la deuxième votre serveur de courriel prévu, et la troisième HTTP/2 200 sans erreur de certificat. Envoyez ensuite un vrai message à chaque boîte et répondez-y. Exercez aussi le courriel envoyé par le site : une réinitialisation de mot de passe, un formulaire de contact, une confirmation de commande. Surveillez le journal d’erreurs et Search Console pendant 72 heures.

Dépannage

Une erreur fatale ou un avertissement mentionnant endurance s’affiche au-dessus de la page. L’extension « must-use » de l’étape 7 est encore dans wp-content/mu-plugins/. Supprimez le fichier et rechargez. Un affichage avant l’envoi des en-têtes casse aussi le Set-Cookie qui vous connecte, donc ça ressemble souvent à un échec de connexion.

Toutes les pages sauf l’accueil renvoient 404. Les règles de réécriture manquent, en général parce que la retouche du .htaccess à l’étape 7 a emporté le bloc WordPress. Lancez wp rewrite flush --hard, confirmez que le bloc réapparaît dans ~/public_html/.htaccess et vérifiez que le compte autorise les surcharges.

Les téléversements échouent en 403 et WordPress ne peut pas écrire dans wp-content. Vous avez décompressé l’archive en root, donc les fichiers appartiennent à root :

chown -R CPUSER:CPUSER ~/public_html
find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;

Le courriel rebondit ou disparaît après la bascule. Deux causes. Si les boîtes n’ont pas été créées avant le déplacement du MX, le courrier arrive sur un serveur qui n’a nulle part où le ranger. Si le MX pointe encore vers un fournisseur externe, cPanel considère le domaine comme un serveur de courriel local et avale le message. Réglez-le sur serveur de courriel distant dans l’acheminement du courriel.

L’import s’arrête sur une collation inconnue. Un dump écrit par un MySQL plus récent transporte une collation que votre destination ne connaît pas. Réécrivez-la avant l’import :

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' bh-bulk.sql

Les données sérialisées restent brisées même si search-replace s’est bien exécuté. Une extension a créé des tables que le balayage par défaut ne parcourt pas. Relancez avec --all-tables --precise. Des UPDATE SQL écrits à la main corrompent les tableaux sérialisés à tout coup, parce que les préfixes de longueur enregistrés cessent de correspondre. Search-replace sur des données sérialisées explique pourquoi.

Quand c’est la mauvaise approche

Si vous partez parce que le site paraissait lent et que personne ne veut assumer la performance, sachez ce que vous laissez derrière. Bluehost opère un cache de page au-dessus de WordPress, donc un thème qui semblait rapide là-bas était mesuré avec une bonne partie de PHP contournée. Sur un compte cPanel non infogéré, cette couche n’existe pas tant que vous ne la bâtissez pas, avec LiteSpeed Cache sur un hôte LiteSpeed ou WP Rocket sur Apache.

Si le courriel du domaine, c’est l’entreprise, séparez le déménagement en deux. Migrez le site web vers cPanel, laissez le courriel où il est et réglez le domaine sur serveur de courriel distant. Ça retire le volet le plus risqué de la bascule.

Si le domaine est aussi enregistré chez Bluehost et que vous comptez transférer l’enregistrement, ne faites pas les deux la même semaine. Un transfert de registraire a sa propre fenêtre de plusieurs jours et ses propres modes d’échec. Déplacez l’hébergement d’abord, prouvez-le, puis l’enregistrement.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.