Migrer WordPress d'Hostinger vers cPanel : l'export manuel et la bascule

Ce guide s’adresse à l’administrateur ou au développeur qui déménage un site WordPress d’Hostinger vers un serveur cPanel/WHM qu’il contrôle. Hostinger utilise son propre panneau de contrôle, appelé hPanel, donc il n’existe aucune archive de compte au format cPanel que l’outil de transfert de WHM pourrait aller chercher. La réponse courte est que vous déplacez vous-même les fichiers, la base et le courriel, par une de trois routes. La route qui vous reste dépend de l’accès SSH offert par votre forfait, SSH étant un shell distant sur le serveur. À la fin, le site répond sur 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 décision claire sur la route d’export que votre forfait Hostinger 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.
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.
Le code de plateforme d’Hostinger retiré, y compris toute extension « must-use » injectée par le panneau. Une extension « must-use » est chargée par WordPress à chaque requête, sans aucun bouton pour la désactiver dans l’admin.
Les réglages de LiteSpeed Cache et les règles .htaccess revus en fonction du serveur web que votre machine cPanel fait tourner.

Prérequis

Côté Hostinger, il vous faut l’identifiant du compte qui possède l’hébergement, pas seulement un compte administrateur WordPress. Un seul constat décide de votre route d’export : est-ce que le forfait vous donne SSH. Hostinger l’offre sur ses forfaits affaires et infonuagiques, et les forfaits partagés d’entrée de gamme peuvent ne pas l’inclure. Confirmez-le en vous connectant, pas en lisant un tableau 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, documenté dans la référence des commandes WP-CLI.

Alignez la version de PHP avant de copier quoi que ce soit. Relevez-la dans l’écran de configuration PHP d’hPanel, 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. Gérer un saut de version PHP pendant une migration couvre les cas où les versions ne peuvent pas concorder.

Notez chaque boîte courriel, chaque alias et chaque redirection du domaine pendant que vous êtes encore dans hPanel. Hostinger vend le courriel comme un produit distinct, sous les noms Hostinger Email et Titan, donc les boîtes et leur contenu ne voyagent pas avec les fichiers et la base. Décidez tout de suite si le courriel suit le site vers cPanel ou reste où il est. C’est cette décision qui cause le plus de douleur dans ce genre de déménagement.

Abaissez ensuite à 300 le TTL des enregistrements A, AAAA et MX du domaine, 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.

Comment ça marche

Une migration déplace trois choses : les fichiers, la base et les enregistrements DNS qui y dirigent les visiteurs. Autour s’ajoute tout ce que l’ancien hébergeur a enroulé autour du site. Chez Hostinger, c’est hPanel plus un serveur web LiteSpeed, et ni l’un ni l’autre n’emballe votre compte comme WHM s’y attend. L’outil de sauvegarde d’hPanel vous donne un ZIP de vos fichiers et, séparément, un dump SQL. Ni l’un ni l’autre n’est une archive cpmove, le paquet de compte au format cPanel que l’outil de transfert restaure, donc chaque morceau voyage seul.

Schéma de décision montrant comment l'accès SSH du forfait Hostinger choisit entre la sauvegarde hPanel, une extension de migration et un export SSH avec WP-CLI, puis le travail manuel commun aux trois

Les routes ne diffèrent que par la façon dont les octets quittent Hostinger. La route A n’exige qu’un navigateur et fonctionne sur tous les forfaits, au prix d’archives à décompresser à la main. La route B 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 et laisser une archive qui a l’air complète sans l’être. La route C est la plus propre quand le forfait a SSH, parce qu’un dump WP-CLI plus un tar de wp-content pèse peu et se vérifie avant de partir.

Deux morceaux façonnés par Hostinger traversent avec les fichiers, peu importe la route. Le premier est l’extension maison du panneau, installée sur chaque nouveau site qu’il construit. Le second est la configuration de LiteSpeed Cache, qui convient à un serveur web LiteSpeed et ne sert à rien sur un Apache. La plupart des serveurs cPanel roulent EA4, pour EasyApache 4, la version d’Apache de cPanel. Les autres hébergeurs à panneau maison ont la même forme, et migrer WordPress de SiteGround vers cPanel couvre celui-là.

Marche à suivre

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

Confirmez SSH, puis choisissez votre route. Essayez la connexion avec l’hôte, le port et l’utilisateur que montre la section SSH d’hPanel :
```
ssh -p SSHPORT USER@HOSTNAME 'wp --info'
```
Un shell qui fonctionne affiche le bloc de version de WP-CLI, qui commence par OS: et se termine par WP-CLI version:. Prenez la route C. Si la connexion est refusée, ou si le forfait n’affiche aucune section SSH, prenez la route A avec l’outil de sauvegarde d’hPanel et son export de base. Ne prenez la route B que si la route A est bloquée elle aussi.
Faites l’inventaire du site pendant qu’il est encore chez Hostinger. Avec SSH :
```
wp core version
wp core verify-checksums
wp plugin list --status=active --fields=name,title,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é. Gardez la sortie de pwd : les répertoires personnels d’Hostinger ressemblent à /home/u123456789/domains/example.com/public_html, 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 de phpMyAdmin pour le reste.
Exportez la base. Avec SSH :
```
wp db export hostinger.sql --add-drop-table
```
Attendez-vous à Success: Exported to 'hostinger.sql'. Sans WP-CLI, utilisez l’export de base d’hPanel, ou l’écran Export de phpMyAdmin avec l’option qui ajoute les instructions DROP TABLE. Dans les deux cas, vérifiez la fin du fichier :
```
tail -3 hostinger.sql
```
Il doit se terminer sur une instruction complète, pas au milieu d’un INSERT. Un dump tronqué s’importe sans se plaindre et perd en silence la fin de votre plus grosse table. Pour un fichier gzip, faites gunzip -c hostinger.sql.gz | tail -3.
Empaquetez les fichiers. Depuis la racine du site, en SSH :
```
tar -czf ~/hostinger-files.tar.gz wp-content wp-config.php .htaccess
```
Les fichiers du noyau ne valent pas le déplacement, puisque l’étape 6 en télécharge une copie propre. tar n’affiche rien quand ça marche, donc comparez ls -lh ~/hostinger-files.tar.gz à l’espace disque qu’hPanel rapporte. Sur la route A, le ZIP de sauvegarde remplace cette étape ; sur la route B, l’archive de l’extension.
Déplacez 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 USER@HOSTNAME:hostinger.sql USER@HOSTNAME:hostinger-files.tar.gz ~/
```
scp affiche une ligne de progression par fichier, chacune se terminant à 100%. Lancez-le sous l’utilisateur du compte cPanel. En root, chaque fichier appartient à root et WordPress ne peut plus écrire dans wp-content. Sur la route A, téléversez les deux fichiers par le gestionnaire de fichiers de cPanel.
Reconstruisez le site sur cPanel. Créez d’abord la base et son utilisateur dans l’assistant de base MySQL de cPanel, et notez les trois valeurs. Ensuite :
```
cd ~/public_html
wp core download --version=WPVERSION --skip-content
tar -xzf ~/hostinger-files.tar.gz -C ~/public_html
wp db import ~/hostinger.sql
```
Remplacez la version par celle 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 'hostinger.sql'.
Réécrivez les identifiants de base dans wp-config.php. Les valeurs d’Hostinger dans le fichier que vous avez copié pointent vers une base que ce serveur n’a pas. Remplacez-les par celles que cPanel vous a données à l’étape 6 :
```
wp config set DB_NAME CPUSER_wpdb
wp config set DB_USER CPUSER_wpuser
wp config set DB_PASSWORD 'THEPASSWORD'
wp config set DB_HOST localhost
wp db check
```
Chaque config set répond Success: Updated the constant ... in the 'wp-config.php' file. wp db check rapporte ensuite OK pour chaque table, ce qui prouve que les identifiants fonctionnent et que l’import a bien atterri.
Retirez le code de plateforme d’Hostinger. Listez d’abord ce qui est là, puisque l’ensemble varie selon la façon dont le site a été bâti :
```
wp plugin list --fields=name,title,status
ls -1 wp-content/mu-plugins/
```
Tout ce dont le titre nomme Hostinger est du code de panneau, pas du code de site. Retirez-le par le slug affiché dans la colonne name :
```
wp plugin deactivate PLUGINSLUG
wp plugin delete PLUGINSLUG
```
Ces commandes répondent Success: Deactivated 1 of 1 plugins. et Success: Deleted 1 of 1 plugins. Les fichiers de wp-content/mu-plugins/ n’ont aucun interrupteur dans l’admin, donc effacez-les avec rm -f. Lisez chacun d’abord, parce qu’un développeur peut y avoir mis du vrai code de site.
Décidez du sort de LiteSpeed Cache. Trouvez ce que votre destination fait tourner :
```
curl -sI --resolve example.com:443:NEWIP https://example.com/ | grep -i '^server:'
```
Une réponse server: LiteSpeed veut dire que l’extension a encore un serveur à qui parler, alors gardez-la et videz ses réglages une fois. Une réponse server: Apache veut dire que son cache n’a plus rien derrière lui, alors désactivez-la et nettoyez les règles qu’elle a écrites :
```
wp plugin deactivate litespeed-cache
grep -n "LSCACHE\|LiteSpeed" ~/public_html/.htaccess
ls -l wp-content/advanced-cache.php wp-content/object-cache.php
```
Le grep vous donne les numéros de ligne de chaque bloc. Effacez chaque bloc de son marqueur # BEGIN jusqu’à son marqueur # END correspondant, et rien à l’extérieur. Effacez ensuite tout fichier advanced-cache.php ou object-cache.php que le ls trouve, puisque les deux appellent des services de cache que ce serveur ne fait pas tourner.
Créez les boîtes courriel maintenant, avant que les MX bougent. Partez de la liste faite dans les prérequis. Créez chaque adresse dans l’écran Comptes de messagerie de cPanel avec la même partie locale, puis ajoutez les redirections. Copiez le courriel pendant que l’ancien fournisseur le détient encore :
```
imapsync --host1 OLDIMAPHOST --user1 you@example.com --password1 OLDPASS --host2 localhost --user2 you@example.com --password2 NEWPASS
```
Prenez comme --host1 le serveur entrant que nomme la page de réglages de votre fournisseur de courriel. imapsync se termine par un sommaire de transfert et une ligne Detected 0 errors. Pour deux ou trois boîtes, ajouter les deux comptes à un logiciel de courriel de bureau et glisser les dossiers fonctionne aussi.
Validez sur un nom d’hôte temporaire avant de toucher au DNS. Le schéma ci-dessous montre où cette étape se place dans la séquence.

Pointez votre propre machine vers le nouveau serveur sans rien changer de public :
```
curl -o /dev/null -s -w '%{http_code} %{time_total}s\n' --resolve example.com:443:NEWIP https://example.com/
curl -sI --resolve example.com:443:NEWIP https://example.com/wp-login.php | head -1
```
Les deux doivent répondre 200. --resolve envoie la requête à NEWIP tout en demandant encore example.com, donc vous voyez ce qu’un visiteur verra après la bascule. Pour naviguer dans un fureteur, ajoutez la même correspondance à votre fichier hosts. Faites aussi émettre le certificat dans cette fenêtre, par la validation DNS d’AutoSSL, parce que la validation HTTP ne peut pas passer tant que le domaine ne résout pas ici. Le portail de documentation de cPanel l’explique.
Corrigez les chemins stockés, et les URL seulement si le domaine change. La plupart des déménagements gardent le domaine. Les URL dans la base sont donc déjà bonnes et vous devriez les laisser tranquilles. Le chemin absolu de l’étape 2, lui, change. Faites d’abord un essai à blanc :
```
wp search-replace '/home/u123456789/domains/example.com/public_html' '/home/CPUSER/public_html' --all-tables --dry-run --report-changed-only
wp search-replace '/home/u123456789/domains/example.com/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. --precise garde les tableaux sérialisés valides quand un remplacement change la longueur d’une chaîne, parce que WP-CLI désérialise en PHP au lieu de passer par du SQL brut. Faire un search-replace pendant une migration couvre le changement de domaine.
Gelez, synchronisez le delta, puis déplacez le DNS. Mettez le site Hostinger 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, importez, refaites l’étape 12, puis videz :
```
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 dans la base. Ça compte, parce que l’étape 9 a découpé un morceau de ce fichier. Changez maintenant les MX d’abord, puis les A et AAAA.

Valider 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 retourner 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 visité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 devrait afficher 200, ou 301 là où vous redirigez exprès. Vérifiez ensuite la résolution, le certificat et le routage du courriel depuis l’extérieur :

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 retourner l’adresse de votre serveur cPanel, la deuxième votre hôte de courriel, et la troisième HTTP/2 200 sans avertissement de certificat. Envoyez ensuite un vrai message à chaque boîte et répondez-y, puis exercez le courriel envoyé par le site avec une réinitialisation de mot de passe et un formulaire de contact. La surveillance des 72 premières heures après migration liste la suite à surveiller.

Dépannage

Le courriel rebondit ou disparaît juste après la bascule. Les boîtes n’existaient pas quand les MX ont bougé, donc le courriel arrive sur un serveur qui n’a nulle part où le mettre. Si les MX pointent encore vers Titan ou un autre fournisseur, cPanel traite le domaine comme un mail exchanger local et avale le message. Réglez Remote Mail Exchanger dans l’écran de routage du courriel de cPanel.

Le ZIP de sauvegarde d’hPanel refuse de se restaurer dans WHM. C’est normal. C’est une archive ordinaire de vos fichiers plutôt qu’un paquet de compte cpmove, donc l’outil de transfert n’en fait rien. Décompressez-la vous-même dans ~/public_html et importez le dump SQL séparément, comme le décrivent les étapes 6 et 7.

Toutes les pages sauf l’accueil retournent 404. Les règles de réécriture ont disparu, en général parce que la modification du .htaccess à l’étape 9 a emporté le bloc WordPress avec les blocs LiteSpeed. Lancez wp rewrite flush --hard, confirmez que le bloc entre # BEGIN WordPress et # END WordPress réapparaît dans ~/public_html/.htaccess, et vérifiez que le compte autorise les surcharges.

Un écran blanc, ou un avertissement sur une classe de cache manquante. Un fichier drop-in de l’ancienne pile est encore en place, souvent wp-content/object-cache.php ou wp-content/advanced-cache.php. Les deux se chargent avant vos extensions et les deux appellent des services que ce serveur ne fait pas tourner. Effacez-les, puis rechargez.

Quand ce n’est pas la bonne approche

Si vous partez parce que le site semblait lent et que personne ne veut prendre en charge la performance, sachez ce que vous laissez derrière. Hostinger fait tourner LiteSpeed avec un cache de page au niveau du serveur, donc un thème qui paraissait 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.

Si le courriel du domaine, c’est le gagne-pain, coupez le déménagement en deux. Migrez le site web, laissez les boîtes chez Titan ou Hostinger Email, et réglez le domaine à Remote Mail Exchanger. Ça sort la voie la plus risquée de la bascule, et le courriel peut suivre plus tard.

Si le domaine est aussi enregistré chez Hostinger et que vous comptez déplacer 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éménagez 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.