# o2switch vers Infomaniak : une migration WordPress sans perte de classement > Changer d'hébergeur mutualisé français impose une méthode précise pour ne perdre ni URL ni positionnement : étapes, pièges DNS et vérifications avant bascule. - Auteur : WordPress Développement - Publié le : 2022-11-09 - Mis à jour le : 2022-11-09 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/o2switch-infomaniak-migration-wordpress-sans-perte-classement/ ## L’essentiel - Copier avant de couper, jamais l'inverse - Vérifier chaque redirection avant la bascule DNS - Surveiller le classement pendant deux semaines après migration o2switch et Infomaniak partagent un point commun rare chez les hébergeurs mutualisés grand public : tous deux publient des caractéristiques techniques précises plutôt que des formules marketing vagues, ce qui facilite la comparaison. Le choix entre les deux hébergeurs ne fait pas l'objet de cet article — il est déjà tranché ailleurs — mais la façon de migrer un site WordPress existant de l'un vers l'autre sans casser la moindre URL indexée mérite une méthode à part entière. Le cas traité ici concerne un site d'agence avec un historique de référencement de plusieurs années, où la moindre perte de position sur des requêtes déjà bien classées se traduit directement par une perte de trafic qualifié. La migration devait donc être invisible, aussi bien pour les visiteurs que pour les robots d'indexation. ## Étape 1 : préparer l'environnement cible sans toucher au DNS La première règle, souvent négligée par excès de prudence inversée, consiste à tout préparer chez le nouvel hébergeur avant de toucher au moindre enregistrement DNS. Un compte Infomaniak a été créé, avec la même version de PHP que celle utilisée chez o2switch, vérifiée au préalable via `phpversion()` pour éviter tout écart de compatibilité avec les extensions installées. ## Étape 2 : copier la base et les fichiers avec WP-CLI > L'essentiel à retenir : Copier avant de couper, jamais l'inverse ; Vérifier chaque redirection avant la bascule DNS ; Surveiller le classement pendant deux semaines après migration Le transfert du site s'est fait entièrement en ligne de commande, plus fiable qu'un export/import par interface graphique sur un site de plusieurs gigaoctets de médias. ``` wp db export sauvegarde-avant-migration.sql --allow-root rsync -avz --exclude 'wp-content/cache' /home/o2switch/public_html/ user@infomaniak:/home/clients/site/public_html/ wp db import sauvegarde-avant-migration.sql --allow-root wp search-replace 'https://exemple.fr' 'https://exemple.fr' --all-tables --dry-run ``` La dernière ligne peut sembler inutile puisque le domaine ne change pas — c'est justement le point : contrairement à une migration avec changement de nom de domaine, ici seul l'hébergeur change. Le `search-replace` en mode `--dry-run` sert uniquement à vérifier qu'aucune URL absolue ne pointe encore vers une adresse IP ou un sous-domaine technique propre à o2switch, ce qui arrive plus souvent qu'on ne le pense sur des installations anciennes. ## Étape 3 : tester le site cible via le fichier hosts Avant toute bascule DNS, le site copié chez Infomaniak a été testé en modifiant temporairement le fichier `hosts` du poste de travail, pour faire pointer le nom de domaine vers la nouvelle adresse IP sans que cela n'affecte les visiteurs réels. Cette étape a permis de repérer une extension de cache incompatible avec la configuration Nginx par défaut d'Infomaniak, corrigée avant la bascule plutôt qu'après. ## Étape 4 : abaisser le TTL DNS quarante-huit heures avant Deux jours avant la bascule effective, le TTL (durée de vie) des enregistrements DNS du domaine a été abaissé à 300 secondes, contre 3 600 ou 86 400 secondes en configuration habituelle. Cette précaution réduit le délai de propagation lors du changement réel d'adresse IP, sans pour autant l'annuler complètement : certains résolveurs DNS intermédiaires ignorent le TTL annoncé et conservent leur propre cache pendant 24 à 48 heures, un délai qu'aucune configuration côté client ne permet de raccourcir. ## Étape 5 : basculer et vérifier immédiatement Le jour de la bascule, l'enregistrement A du domaine a été modifié pour pointer vers l'adresse IP d'Infomaniak. Les vérifications suivantes ont été menées dans l'heure suivante : 1. Contrôle du code de retour HTTP de la page d'accueil et de dix URL profondes représentatives, avec `curl -I`. 2. Vérification que le certificat TLS s'est bien généré automatiquement côté Infomaniak pour le domaine désormais pointé chez lui. 3. Contrôle du fichier `robots.txt` et du sitemap XML, pour s'assurer qu'aucune règle de blocage n'a été réintroduite par erreur lors de la copie. 4. Soumission d'une inspection d'URL dans la Search Console sur la page d'accueil, pour vérifier que Google la voit bien servie par la nouvelle infrastructure. ## Étape 6 : surveiller le classement deux semaines durant Un temps de chargement légèrement modifié après migration peut, à la marge, influencer le classement sur certaines requêtes concurrentielles. Le suivi des positions dans la Search Console a donc été maintenu quotidiennement pendant deux semaines après la bascule, sans qu'aucune variation significative n'ait été constatée sur ce projet, signe que la migration avait préservé l'ensemble des signaux techniques attendus par les robots. > Un principe qui a fait ses preuves sur plusieurs migrations similaires : ne jamais couper l'ancien hébergement avant d'avoir observé au moins une semaine complète de trafic stable sur le nouveau. ## Pour aller plus loin Cette méthode, appliquée entre o2switch et Infomaniak, reste transposable à n'importe quel couple d'hébergeurs mutualisés français conservant le même nom de domaine. Le facteur déterminant n'est pas tant l'hébergeur cible que la rigueur de la préparation : copier avant de couper, tester avant de basculer, et surveiller après coup plutôt que de considérer la migration terminée dès que le site s'affiche correctement.