Migrer un site WordPress vers Astro sans casser le référencement

Migrer un site WordPress vers Astro sans perdre son référencement est faisable et c’est même la migration la plus rentable que je fais chez mes clients en 2026. Le secret tient en quatre étapes méthodologiques rigoureuses. Cartographier l’existant, mapper les redirections 301, migrer le contenu en Markdown structuré, et vérifier le résultat sur 90 jours. Voici la méthode complète, basée sur les trois migrations que j’ai conduites depuis 2024.

Pourquoi migrer en 2026

Le WordPress en 2026 reste utilisable, mais traîne quatre fardeaux qui justifient une migration pour beaucoup d’activités.

Performance dégradée. Un WordPress moyen avec 10 plugins charge en 4 à 7 secondes sur mobile en 4G. Un site Astro statique se charge en moins d’une seconde. Ce différentiel impacte directement le SEO depuis l’introduction des Core Web Vitals comme facteur de classement Google.

Surface d’attaque sécurité. Chaque plugin est une porte d’entrée potentielle. WordPress et ses extensions cumulent environ 90 pour cent des vulnérabilités web reportées chaque mois sur les bases CVE. Un site Astro statique, sans backend dynamique, élimine cette surface.

Coût opérationnel cumulé. Hébergement WordPress correct (OVH Pro Plus ou similaire), licences plugins premium, maintenance des mises à jour, sauvegardes, ça finit à 30 à 80 euros par mois récurrents. Un Astro sur Netlify, c’est 0 à 20 euros par mois avec moins de risques.

Édition lourde. L’admin WordPress est devenue lente, surchargée d’options, peu agréable. Beaucoup de mes clients préfèrent éditer un Markdown sur Git ou via une UI légère type Decap ou Tina.

Quand ne PAS migrer

Restons honnête. WordPress reste pertinent dans trois cas.

E-commerce avec catalogue dynamique. WooCommerce, malgré ses défauts, fait le boulot avec un écosystème mature de gateways de paiement, livraison, comptabilité. Sauf à migrer vers Shopify (qui a ses propres limites), gardez WooCommerce.

Blog très actif avec plusieurs rédacteurs non-techniques. Si vous avez une équipe rédactionnelle de 5 personnes qui publient quotidiennement et qui n’aiment pas Git, l’overhead pour maintenir un workflow Astro proprement peut excéder le gain.

Site institutionnel avec besoin d’extensibilité par des non-développeurs. Mairies, associations, où des gens veulent installer un plugin de calendrier ou de quiz sans appeler un dev. WordPress reste le bon outil.

Dans tous les autres cas (sites vitrines, sites métier, sites portfolio, sites SaaS marketing, sites éditoriaux avec rédacteurs techniques), la migration vers Astro est généralement le bon mouvement en 2026.

La méthode en quatre étapes

Voici exactement ce que je fais sur chaque migration. Pas de variation improvisée, pas de “on verra en cours de route”.

Étape 1 : Cartographier l’existant (1 semaine)

Avant d’écrire la moindre ligne de code Astro, je cartographie le site WordPress existant. Concrètement, voici ce que j’audite et que je consigne dans un tableau partagé avec le client.

Inventaire des URLs. Toutes les pages publiques du site. Pour un WordPress, ça se fait avec un crawl Screaming Frog SEO Spider (version gratuite jusqu’à 500 URLs, payante au-delà). Export en CSV.

Trafic et positions par URL. Connexion à Google Search Console et Google Analytics (ou Plausible si déjà installé). J’identifie les URLs qui captent du trafic, leurs requêtes-clés, leur position moyenne. Ce sont elles qu’on protégera en priorité.

Backlinks par URL. Ahrefs ou Semrush si le client a accès, sinon une recherche manuelle des backlinks principaux via Google (“site:domaine.fr inurl:…”). Toute URL avec backlinks doit absolument être préservée en redirection 301.

Contenu rédactionnel à conserver. Articles, pages, témoignages, FAQ. J’extrais le contenu via l’export XML natif de WordPress, ou via un script qui pull la base MySQL si l’export XML pose problème.

Médias. Images, vidéos, PDFs. J’extrais tout du dossier wp-content/uploads/ et je les renomme proprement (kebab-case, sans dates dans le chemin).

Plugins critiques. Liste des plugins actifs, identification de ceux qui doivent être remplacés (formulaires, SEO, mailing list, etc.).

Livrable de cette étape, un document de cartographie de 5 à 20 pages selon l’ampleur du site, partagé avec le client pour validation.

Étape 2 : Mapper les redirections 301 (3 à 5 jours)

C’est l’étape la plus déterminante pour le SEO post-migration, et c’est celle que la plupart des prestataires bâclent. Le principe est simple, chaque ancienne URL publique du site WordPress doit avoir une cible définie sur le nouveau site Astro.

Trois cas de figure.

Cas A : l’URL est conservée à l’identique. Aucune action nécessaire, l’URL continue de fonctionner après migration.

Cas B : l’URL change. Création d’une redirection 301 dans netlify.toml (ou _redirects) qui pointe l’ancienne URL vers la nouvelle. Exemple typique, /2024/03/15/article-bonjour-monde/ (URL WordPress par défaut avec dates) devient /blog/bonjour-monde/ sur Astro.

Cas C : l’URL n’existe plus sur le nouveau site. Création d’une redirection 301 vers une page parent pertinente, JAMAIS vers la home si on peut éviter. Une redirection vers la home est lue par Google comme un “soft 404” et pénalise.

Je prépare un fichier redirects-map.csv avec deux colonnes (ancienne URL, nouvelle URL) que je valide avec le client. Ce fichier devient ensuite la source pour générer le netlify.toml.

Étape 3 : Migration du contenu en Markdown (2 à 3 semaines pour 50 articles)

Le contenu WordPress est extrait en HTML brut depuis l’export XML. Je le convertis en Markdown via un script Node maison qui.

1. Parse l’XML WordPress (<channel> et <item>).
2. Convertit le HTML en Markdown via Turndown.
3. Extrait les images référencées, les télécharge dans public/img/blog/, et corrige les chemins.
4. Génère le frontmatter conforme au schéma blogSchema que j’ai défini (voir l’article sur mon pipeline d’articles).
5. Calcule automatiquement wordCount et readingTimeMinutes.

Le script tourne en local, produit un dossier src/content/blog/ rempli, et je relis manuellement chaque article pour les ajustements de mise en forme (les conversions HTML vers Markdown sont rarement parfaites, particulièrement pour les blocs custom WordPress comme les “shortcodes”).

Étape 4 : Vérifications post-migration (sur 90 jours)

Une migration n’est jamais “terminée” le jour du switch DNS. Les 90 jours qui suivent demandent une vigilance précise.

J+0 (jour du switch DNS). Vérification que toutes les redirections fonctionnent. Test manuel des 20 URLs principales (celles qui captent le plus de trafic) en HTTPS et en HTTP. Soumission du nouveau sitemap dans Google Search Console et Bing Webmaster Tools.

J+1 à J+7. Crawl complet du nouveau site avec Screaming Frog pour détecter les erreurs 404 résiduelles. Toute erreur trouvée donne lieu à une nouvelle règle de redirection.

J+7 à J+30. Monitoring quotidien de Search Console. Les “Couvertures” doivent revenir au niveau d’avant migration. Les “Performance” peuvent fluctuer de 5 à 20 pour cent, c’est normal. Tout ce qui dépasse 30 pour cent de baisse exige une investigation immédiate.

J+30 à J+90. Les positions reprennent leur place, voire dépassent l’état antérieur grâce aux gains de performance. Sur ma migration de référence en mars 2024 (un client serrurier en IDF, devenu plus tard urgenceserrures.fr), le retour au niveau pré-migration a pris 4 semaines, puis le trafic organique a augmenté de 35 pour cent sur les 60 jours suivants.

Retour terrain : la migration la plus instructive

Je détaille la migration que j’ai conduite en 2024, anonymisée mais représentative.

Site initial. WordPress avec 10 plugins, thème Avada personnalisé, 32 pages dont 18 articles de blog. Lighthouse Performance mobile à 23 sur 100. LCP à 4,8 secondes.

Stratégie de migration. Reconstruction complète sur Astro 5, conservation de 100 pour cent des URLs principales, restructuration des URLs blog (suppression des dates dans le chemin) avec mapping 301 complet.

Durée. 5 semaines de A à Z, dont 3 semaines de développement et 2 semaines de cartographie et de migration de contenu.

Résultat technique. Lighthouse Performance mobile à 98 sur 100. LCP à 0,9 seconde. Page weight divisé par 12.

Résultat SEO. Sur les 4 premières semaines après migration, une baisse de trafic Search Console de 12 pour cent (transition normale). Sur les 8 semaines suivantes, retour au niveau précédent puis croissance progressive. À 6 mois, le trafic organique était supérieur de 41 pour cent à l’état pré-migration.

Résultat business. Le client a divisé son coût d’hébergement par 4, supprimé ses contrats de maintenance plugins, et regagné 4 à 6 heures par mois de gestion technique.

Les écueils que j’ai vus

Écueil 1 : oublier les images en backlink. Un client avait des images uploadées il y a des années avec des chemins WordPress du type /wp-content/uploads/2019/03/photo.jpg. Ces URLs avaient des backlinks externes (forums, autres blogs qui les avaient hotlinkées). Sans redirection 301 sur ces images, on perd les signaux SEO associés. Solution, j’ai créé un mapping spécifique pour les médias.

Écueil 2 : sous-estimer les shortcodes WordPress. Certains plugins WordPress injectent du contenu via des shortcodes du type [contact-form-7 id="42"]. Ces shortcodes ne se convertissent pas automatiquement. Solution, identification manuelle des shortcodes utilisés, remplacement par des composants Astro équivalents.

Écueil 3 : ne pas tester le sitemap après migration. Un sitemap mal généré peut faire que Google indexe encore les anciennes URLs pendant des semaines, retardant la transition. Solution, je vérifie systématiquement le nouveau sitemap dans Search Console le jour du switch et 48 heures après.

Ce qu’il faut retenir

1. Migrer un WordPress vers Astro fait gagner massivement en performance, sécurité et coût opérationnel, sans perte SEO durable si la méthode est rigoureuse.
2. La cartographie de l’existant (URLs, trafic, backlinks, contenu) est l’étape la plus déterminante. Une semaine investie ici évite des semaines de problèmes plus tard.
3. Le mapping des redirections 301 doit couvrir 100 pour cent des URLs publiques anciennes, pas seulement les “principales”. Les redirections vers la home sont à éviter sauf en dernier recours.
4. Le retour au niveau SEO pré-migration prend 4 à 8 semaines, puis le gain de performance fait grimper les positions au-dessus du précédent niveau.
5. WordPress reste préférable dans trois cas. E-commerce dynamique WooCommerce, équipe rédactionnelle non-technique, besoin d’extensibilité par des non-développeurs.

Pour discuter de la migration de votre site WordPress, le formulaire de contact permet de démarrer un cadrage. Vous pouvez aussi consulter mon offre détaillée sites internet pour le périmètre type d’une refonte.