Migrer un site WordPress vers un VPS : checklist et redirections 301

Passer d'un hébergement mutualisé à un VPS infogéré est souvent l'étape qui débloque un site WordPress devenu trop lent ou trop à l'étroit. Bien menée, la migration est invisible pour les visiteurs et ne coûte rien au SEO. Mal menée, elle coûte des positions Google, des emails perdus et plusieurs heures de support client.

Cette checklist couvre la migration complète : préparation, transfert, redirections, DNS, post-migration. Le focus est sur les 301, qui sont la clé de préservation du référencement quand l'URL ou la structure change.

Avant la migration : l'inventaire

La première faute est de migrer sans inventaire. On découvre alors après coup qu'un plugin de cache était actif, qu'un cron tournait, qu'une base externe alimentait un widget. Quelques minutes d'audit évitent des heures de débogage.

• Liste des plugins actifs avec versions, et identification de ceux qui touchent au stockage (cache, CDN, optimisation images).
• Thème et thème enfant : noter les modifications faites en dehors de la base (fichiers PHP custom, snippets dans functions.php).
• Structure des permaliens dans Réglages > Permaliens. Notez le format exact (/%postname%/, /%category%/%postname%/, etc.).
• Redirections existantes : export du plugin Redirection ou screenshot des règles dans .htaccess. Ces redirections doivent être reportées.
• Configuration DNS actuelle : A, AAAA, MX, CNAME, TXT (SPF, DKIM, vérifications de domaine). Faites une capture complète chez votre bureau d'enregistrement.
• Comptes emails si la messagerie est sur le même hébergement : liste des boîtes, alias, redirections, mots de passe.
• Tâches cron : WP-Cron, ou cron système externe qui ping wp-cron.php.

J-3 : préparation du VPS et baisse du TTL

La propagation DNS est le facteur qui ralentit le plus une migration. Le bon réflexe : 24 à 48 h avant le jour J, abaisser le TTL des enregistrements A et AAAA à 300 secondes (5 minutes). Au moment du basculement, le DNS se propagera en quelques minutes au lieu de plusieurs heures.

En parallèle, sur le VPS :

• Stack web prête : Apache ou Nginx, PHP en version compatible (WordPress 6.x recommande PHP 8.2+), MariaDB ou MySQL.
• Certificat TLS pré-installé ou prêt à être émis (Let's Encrypt, ZeroSSL).
• Accès SSH avec clé publique, sudo nominatif.
• Sauvegarde automatisée déjà configurée (snapshot, BorgBackup, Restic ou équivalent).

J-1 : copie initiale

Faites une première passe de copie « à froid » pendant que le site reste en production sur l'ancien hébergement. Cela permet de tester sur le VPS avec un nom de domaine temporaire ou en modifiant son fichier hosts local.

1. Export base de données : mysqldump --single-transaction --quick --add-drop-table sur la base WordPress.
2. Copie des fichiers : rsync -avz de tout le répertoire WordPress (wp-content en priorité pour les médias, wp-config.php à réadapter).
3. Import sur le VPS : création de la base, import du dump, ajustement de wp-config.php (DB_HOST, DB_USER, DB_PASSWORD, sels).
4. Test local via /etc/hosts : pointer son poste vers la nouvelle IP pour valider que tout fonctionne avant le basculement.

Jour J : bascule

Le timing : préférer une plage creuse (nuit, dimanche). Couper les commentaires et les commandes (mode maintenance via plugin ou bannière) pendant la fenêtre.

1. Re-synchronisation incrémentale : nouveau rsync et nouveau mysqldump pour rattraper les contenus créés entre la copie initiale et maintenant.
2. Mise à jour DNS : changement des A/AAAA vers la nouvelle IP. Le TTL étant à 300, la propagation est rapide.
3. Réémission TLS sur le VPS si ce n'est pas déjà fait, en pointant Let's Encrypt vers le nouveau serveur.
4. Vérification HTTP : tester en navigation privée, depuis 4G, depuis un outil comme dnschecker.org pour confirmer la propagation.
5. Vidange du cache : WordPress (plugin de cache), CDN si présent, OPcache PHP, navigateurs internes.

Les redirections 301 : pourquoi et comment

Si la migration ne change pas les URLs, vous n'avez rien à rediriger. C'est rare. Dans la pratique, on profite presque toujours de la migration pour :

• passer de HTTP à HTTPS (si ce n'était pas déjà fait) ;
• migrer de www.exemple.fr à exemple.fr (ou l'inverse) ;
• nettoyer les URLs (anciennes catégories, slugs hérités d'un autre CMS) ;
• changer la structure de permaliens.

Une redirection 301 (HTTP Moved Permanently) indique aux moteurs de recherche que la nouvelle URL remplace définitivement l'ancienne. Google transmet la quasi-totalité de l'autorité de l'URL d'origine vers la cible. Sans 301, vous repartez de zéro sur les pages renommées.

Implementation .htaccess (Apache)

Pour les redirections de masse, le .htaccess est plus performant qu'un plugin. Règle d'or : les directives custom passent avant le bloc # BEGIN WordPress.

# Forcer HTTPS et non-www
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^(.*)$ https://exemple.fr/$1 [R=301,L]

# Anciennes URLs vers nouvelles
Redirect 301 /ancienne-page/ /nouvelle-page/
Redirect 301 /blog/ancien-slug/ /actualites/nouveau-slug/

# BEGIN WordPress
# ... directives WordPress standard
# END WordPress

Pour des réécritures plus complexes (motifs avec paramètres, regex), RewriteRule est plus puissant que Redirect.

Cas du changement de permaliens

Si vous passez de /?p=123 à /%postname%/, WordPress gère lui-même la redirection via le canonical. Mais dès qu'on touche à /%category%/ ou qu'on réorganise les catégories, des règles manuelles sont nécessaires. Plusieurs plugins permettent d'importer un mapping CSV (anciens slugs vers nouveaux), à vous d'en choisir un selon vos préférences.

Vérifier dans Search Console

Une fois en ligne, suivez dans la Google Search Console :

• la couverture (pages indexables / indexables à corriger) ;
• le rapport « Pages » pour repérer les 404 ou les soft 404 ;
• les améliorations Core Web Vitals (le passage en VPS améliore souvent le LCP).

Soumettez le sitemap à nouveau, et utilisez l'outil d'inspection d'URL sur quelques pages clés pour forcer un recrawl.

Post-migration : la checklist du lendemain

Les pièges classiques

• Oublier les emails : si MX et serveur web sont sur le même hébergement, basculer le DNS sans préparer la messagerie envoie tout dans le vide. Migrez les boîtes en parallèle ou laissez les MX sur l'ancien serveur en transition.
• Ne pas tester avec /etc/hosts : le test pré-migration sans bouger le DNS évite 80 % des mauvaises surprises.
• Mauvais permissions : WordPress veut typiquement 644 sur les fichiers, 755 sur les dossiers, et un propriétaire correct. Une copie en root casse souvent les uploads.
• URL en dur dans la base : si vous changez de domaine, faire un search-replace propre (WP-CLI : wp search-replace) qui gère la sérialisation PHP. Un simple SQL UPDATE casse les arrays sérialisés.
• Mixed content après passage HTTPS : un plugin de scan ou un WP-CLI search-replace HTTP->HTTPS résout la majorité des cas.

Pourquoi un VPS plutôt qu'un mutualisé

Le mutualisé reste pertinent pour les petits sites. Mais dès qu'on parle de WooCommerce, de membership, de pic de trafic lié à une newsletter ou de Core Web Vitals, le VPS apporte :

• des ressources dédiées (CPU, RAM, IO disque) non partagées avec d'autres clients ;
• la possibilité de tuner la stack (PHP-FPM, OPcache, Redis, MariaDB) selon le profil du site ;
• une isolation sécurité plus forte : les compromissions de voisins n'affectent pas votre site.

Pour aller plus loin sur les sujets connexes : Configurer SPF, DKIM et DMARC, La règle de sauvegarde 3-2-1 et Migrer du mutualisé vers un VPS.

Datacampus accompagne la migration

Chez Datacampus, on héberge des sites WordPress sur des VPS infogérés au Futuroscope, avec stack tunable, sauvegardes Borg, supervision et accompagnement humain. La migration est souvent prise en charge par notre équipe : inventaire, mise en place, redirections, suivi post-bascule. Pour discuter du cas de votre site, voir le formulaire de contact.