Migrer un site WordPress sans perdre son SEO : notre checklist

Pourquoi on a fini par quitter WordPress ?

Notre propre site tournait sur WordPress depuis des années, sur un hébergement mutualisé classique. Ça faisait le travail, mais l’addition s’alourdissait doucement : plugins à maintenir, mises à jour de sécurité en continu, temps de chargement qui se dégradait à mesure qu’on ajoutait des extensions, et un couplage fort entre le contenu et l’infrastructure d’hébergement qu’on ne maîtrisait plus vraiment. On construit et on opère des applications pour nos clients toute la journée — il devenait absurde de laisser notre propre vitrine tourner sur une stack qu’on n’aurait jamais recommandée à personne.

La bascule vers un site statique généré (Astro, dans notre cas) résout le problème à la racine : plus de base de données à sécuriser, des pages qui se chargent en quelques dizaines de millisecondes, et un déploiement qu’on contrôle de bout en bout. Mais changer de moteur de site sans perdre des années de référencement, ça ne s’improvise pas.

La checklist qui protège le SEO pendant une migration

Trois règles non négociables avant de basculer le DNS :

1. Garder le domaine. On ne change jamais de nom de domaine en même temps qu’on change de plateforme — cumuler les deux migrations, c’est cumuler les risques. Le domaine reste l’ancre de toute l’autorité accumulée.
2. Des redirections 301 exhaustives et testées, pas approximatives. Chaque URL indexée de l’ancien site doit pointer explicitement vers son équivalent le plus proche sur le nouveau. Une redirection générique de tout vers la page d’accueil est le meilleur moyen de perdre le classement d’une page qui rankait bien depuis trois ans. On a extrait la liste complète des URLs connues de Google Search Console avant de couper l’ancien site, et testé chaque redirection une par une après bascule.
3. Sitemap et Search Console à jour dès le jour J. Le nouveau sitemap XML doit être généré et soumis dès la mise en ligne — pas une semaine après. Plus l’écart entre la bascule technique et la resoumission est court, plus vite les moteurs redécouvrent la nouvelle structure.

Faut-il bloquer les robots d’indexation IA ?

Non — et c’est une erreur qu’on voit de plus en plus souvent par excès de prudence. Une partie croissante du trafic qualifié arrive désormais via des réponses générées par des assistants IA plutôt que par un clic classique sur un résultat de recherche. Bloquer ces crawlers dans le robots.txt par réflexe de sécurité revient à se couper d’un canal de découverte qui ne fait que grossir. Sauf raison métier précise, on les laisse passer au même titre que les moteurs de recherche traditionnels.

Le piège qu’on n’avait pas vu venir

Tout était prêt côté application. Ce qui nous a fait perdre une soirée entière, c’est un détail DNS hérité : un enregistrement AAAA (IPv6) résiduel, oublié sur l’ancien hébergement mutualisé, qui continuait de répondre aux challenges de validation lors de la génération du certificat TLS du nouveau serveur. Résultat : des échecs de validation incompréhensibles tant qu’on n’avait pas pensé à vérifier l’enregistrement AAAA en plus de l’enregistrement A classique — la plupart des autorités de certification préfèrent IPv6 quand il est présent, y compris s’il pointe vers la mauvaise machine.

La leçon est simple mais facile à oublier : avant toute bascule DNS, on vérifie systématiquement les deux familles d’enregistrements (A et AAAA), sur tous les sous-domaines concernés, pas seulement celui qu’on pense modifier. Un vieux mutualisé qui traîne peut saboter une migration sans qu’aucune erreur n’apparaisse côté application.

Et après la bascule, tout est instantané ?

Non plus. Même une migration technique parfaitement propre — redirections exhaustives, sitemap à jour, aucune erreur 404 — s’accompagne d’une période de flottement de quelques jours à quelques semaines dans les résultats de recherche. Les extraits enrichis et les liens de site (sitelinks) affichés sous le résultat principal peuvent disparaître temporairement le temps que les moteurs recalculent leur confiance dans la nouvelle structure. C’est normal, ça ne présage rien de la santé SEO à moyen terme, et paniquer à J+3 ne sert à rien : on surveille, on ne panique pas, et on laisse les moteurs refaire leur travail.

Ce qu’on retient

Une migration WordPress vers un site plus léger n’est pas un projet risqué pour le SEO — à condition de traiter le référencement comme un livrable du projet, pas comme un effet de bord. Domaine conservé, redirections exhaustives et testées une par une, sitemap soumis le jour J, crawlers IA non bloqués, et une vérification DNS complète (A et AAAA) avant toute bascule. Le reste — la période de flottement — se gère avec de la patience, pas avec de l’inquiétude.