Migrer Wordpress Vers Hostinger : Guide Complet

Changer d'hébergeur fait peur pour une seule raison : pendant quelques heures, votre site existe à deux endroits à la fois. Une migration WordPress vers Hostinger n'a rien de sorcier sur le papier — une copie de fichiers, une copie de base — mais elle pardonne mal l'improvisation : les erreurs se voient en production, sur un site vivant et indexé.

Voici la migration telle qu'elle se déroule vraiment : ce qu'on sauvegarde avant de toucher à quoi que ce soit, les trois façons de déplacer le site, le piège des URL stockées en dur dans la base, la bascule DNS sans coupure visible, et ce qu'on contrôle ensuite. Rien d'exotique : juste l'ordre des opérations, qui est à peu près la seule chose qui compte.

La sauvegarde complète : la seule étape non négociable

Avant tout, deux archives. Les fichiers d'abord : l'intégralité du répertoire WordPress — le cœur, wp-config.php, le dossier wp-content avec vos thèmes, vos extensions et votre médiathèque, sans oublier les fichiers cachés comme le .htaccess, que les clients FTP omettent volontiers d'afficher. La base ensuite : un export SQL complet, depuis phpMyAdmin, en ligne de commande avec mysqldump, ou via l'outil de sauvegarde de votre hébergeur.

Deux archives, parce qu'un site WordPress est un objet à deux moitiés. Les fichiers sans la base donnent un site vide ; la base sans les fichiers, des articles qui pointent vers des images inexistantes. Prenez-les au même moment, sinon vous restaurerez un état incohérent.

Non négociable, pour une raison simple : tant que l'ancien hébergement tourne, vous croyez avoir un filet. Le jour où vous résiliez — et vous finirez par résilier, c'était le but — ce filet disparaît. Téléchargez les deux archives sur votre propre machine et ouvrez-les pour vérifier qu'elles sont complètes : une sauvegarde jamais testée n'est pas une sauvegarde, c'est une intention.

Trois voies pour déplacer le site vers Hostinger

La première, la plus confortable : l'outil de migration proposé par l'hébergeur. Vous fournissez les accès à l'hébergement de départ, l'outil récupère fichiers et base, puis réinstalle l'ensemble côté destination. À privilégier si votre site est standard. Cela suppose que l'ancien hébergeur autorise les connexions nécessaires et que le volume reste raisonnable : les médiathèques de plusieurs dizaines de gigaoctets font échouer les transferts automatisés.

La deuxième : une extension de migration installée dans WordPress. Vous empaquetez le site depuis l'ancien hébergement, vous récupérez une archive, vous la déployez sur le nouveau. L'avantage est réel — ces extensions gèrent elles-mêmes la réécriture des adresses et la sérialisation, ce qui neutralise le piège décrit juste après. La contrainte l'est tout autant : elles travaillent en PHP, donc sous la limite de temps d'exécution et de mémoire du serveur de départ. Sur un gros site, l'export s'interrompt en cours de route.

La troisième : la méthode manuelle, FTP ou SFTP pour les fichiers, export puis import SQL pour la base. La plus fiable, et la seule qui fonctionne encore quand les deux autres ont échoué. Elle suppose que vous sachiez créer une base côté destination, éditer wp-config.php pour y renseigner les nouveaux identifiants, et importer un dump volumineux : au-delà de quelques dizaines de mégaoctets, phpMyAdmin refuse souvent le fichier et il faut passer par la ligne de commande.

Aucune n'est meilleure dans l'absolu : un site vitrine part en automatique, une grosse boutique au thème sur mesure se migre à la main.

Le piège des URL stockées en dur dans la base

Voici l'erreur qui coûte le plus de temps. WordPress ne stocke pas ses adresses en relatif : l'URL absolue de votre site est écrite en dur des milliers de fois dans la base — dans les options, le contenu des articles, les liens des images, les réglages des extensions. Si vous changez de domaine en même temps, ou si vous travaillez d'abord sur l'adresse temporaire du nouvel hébergement, il faut réécrire tout cela.

Le réflexe est de lancer un chercher-remplacer sur le fichier SQL. C'est précisément ce qu'il ne faut pas faire. WordPress stocke une partie de ses données sérialisées : des tableaux PHP convertis en chaînes qui indiquent, avant chaque valeur, sa longueur exacte. Remplacer une adresse par une autre plus courte ou plus longue laisse une longueur déclarée fausse. PHP n'arrive alors plus à désérialiser et la donnée est perdue en silence : réglages de thème réinitialisés, widgets vides, options d'extensions envolées.

Le pire, c'est que le site continue de s'afficher : on cherche du côté du serveur alors que le mal est en base. La parade : n'utiliser qu'un outil qui recalcule les longueurs. WP-CLI le fait nativement avec sa commande de recherche-remplacement, comme les scripts de search-replace prévus pour WordPress et les extensions de migration sérieuses. Ne remplacez jamais une adresse à la main dans un dump, sauf les options siteurl et home, qui ne sont pas sérialisées.

Les enregistrements DNS et le délai de propagation

Copier le site ne le rend pas visible. Tant que les enregistrements DNS de votre domaine pointent vers l'ancienne machine, les visiteurs continuent d'y arriver. La bascule consiste à modifier ces enregistrements : soit les serveurs de noms du domaine chez votre registrar, soit uniquement l'enregistrement A — et l'AAAA en IPv6 — pour le faire pointer vers la nouvelle adresse IP.

Ce changement n'est jamais instantané. Chaque enregistrement porte une durée de vie, le TTL, pendant laquelle les résolveurs du monde entier ont le droit de garder l'ancienne réponse en cache. Le levier existe : abaisser le TTL de la zone plusieurs jours avant la migration, puis le remonter ensuite. Tous les fournisseurs d'accès n'honorent pas scrupuleusement ces valeurs : prévoyez large et ne résiliez rien tant que du trafic atterrit encore sur l'ancien serveur — ses journaux d'accès vous diront quand la bascule est finie.

La fenêtre de bascule : tester avant de basculer

La bonne pratique tient en une phrase : ne touchez pas à vos DNS avant d'avoir vu le site fonctionner sur le nouvel hébergement. C'est facile, grâce au fichier hosts de votre ordinateur — /etc/hosts sous macOS et Linux, C:\Windows\System32\drivers\etc\hosts sous Windows. Il associe manuellement un nom de domaine à une adresse IP, uniquement pour votre machine. Vous y ajoutez une ligne avec l'IP de destination et votre domaine : votre navigateur charge le site depuis Hostinger pendant que le reste du monde continue de voir l'ancien.

Vous disposez d'une vraie répétition générale : le site tourne sur son domaine définitif, avec les bonnes adresses en base, sans que rien n'ait été engagé publiquement. Naviguez, testez le back-office, passez une commande. Quand tout est propre, basculez les DNS, puis retirez la ligne du fichier hosts pour revérifier en visiteur ordinaire — sinon vous verrez le nouveau site quoi qu'il arrive, y compris si la bascule a échoué.

Dernier point : gelez les contenus. Entre la copie de la base et la bascule, tout ce qui s'écrit sur l'ancien site — article, commande, commentaire — sera perdu, puisque c'est l'ancienne base qui l'enregistre. Sur un blog, on décale les publications de quelques heures ; sur une boutique, on prévoit une courte fenêtre de maintenance.

Le certificat SSL et les e-mails, les deux grands oubliés

Un certificat SSL est lié à un serveur, pas au domaine dans l'absolu : celui qui protégeait votre site chez l'ancien hébergeur ne vous suit pas. Il faut en émettre un nouveau côté Hostinger, et l'émission ne peut aboutir qu'une fois les DNS pointés vers la nouvelle machine — la validation vérifie justement que le domaine résout vers elle. Prévoyez donc un court intervalle après la bascule où le site répond sans certificat valide, et n'activez la redirection forcée vers HTTPS qu'une fois le certificat actif.

Les e-mails sont l'oubli classique, celui qu'on découvre quand un client s'étonne de ne plus rien recevoir. Si vos adresses sont hébergées chez l'ancien prestataire, changer les serveurs de noms du domaine casse la réception d'un coup : les enregistrements MX repartent de zéro dans la nouvelle zone. Deux options, à trancher avant la bascule. Soit vous migrez aussi la messagerie, en recréant les boîtes côté Hostinger et en rapatriant les messages par IMAP avant de couper. Soit vous la laissez où elle est et vous recopiez à l'identique les MX, SPF, DKIM et DMARC dans la nouvelle zone — les oublier, c'est voir ses messages partir en indésirables.

Ce qu'on vérifie une fois la bascule faite

Dans cet ordre. Les permaliens d'abord : réenregistrez les réglages depuis l'administration pour régénérer le .htaccess, cause numéro un des 404 en masse après une migration. Les images ensuite : si elles ne s'affichent plus, c'est soit un chemin resté sur l'ancienne adresse en base, soit un dossier uploads transféré incomplètement ou mal permissionné. Puis les formulaires de contact, dont l'envoi dépend du nouveau serveur et échoue souvent en silence. Enfin les redirections en place et les liens internes, à repasser au crawler.

Côté référencement, assurez-vous que le site reste indexable — un environnement de préproduction laisse parfois traîner un blocage des moteurs de recherche jamais retiré — et surveillez la couverture d'indexation les jours suivants. Si le tri dans le thème et les extensions fait partie de vos chantiers d'après-migration, on en parle dans notre guide complet et dans notre comparatif dédié. Gardez enfin l'ancien hébergement actif deux à quatre semaines : c'est votre seule marche arrière si un problème apparaît tardivement.

Si votre hébergeur n'est pas encore arrêté

Tout ce qui précède décrit une migration vers Hostinger. Si votre choix n'est pas encore fait et que la localisation de vos données pèse dans la décision, Infomaniak est l'alternative européenne à regarder : hébergeur suisse, propriétaire de ses datacentres, avec une migration WordPress assistée par ses équipes. Ce n'est pas l'hébergeur décrit ici et la procédure ci-dessus ne le concerne pas — mais la méthode, elle, ne change pas d'un hébergeur à l'autre.