Migration WordPress vers Astro : ce que vous perdez et ce que vous gagnez

Votre site WordPress a sept ou huit ans, il empile une vingtaine de plugins, chaque mise à jour fait craindre une page blanche et le score de vitesse ne décolle plus. Quelqu'un vous a parlé d'Astro. La question n'est pas de savoir si l'outil est rapide, il l'est. La vraie question est ce qu'une migration WordPress vers Astro implique pour vos contenus, votre référencement et les fonctionnalités dont votre équipe se sert chaque jour.

Derrière le mot migration se cachent deux réalités très différentes. D'un côté, un chantier préparé, inventorié et chiffré. De l'autre, un changement de vitrine qui laisse derrière lui des pages introuvables, des formulaires muets et un trafic en chute. Voici comment faire la différence.

La vitesse est rarement la vraie raison du départ

Quand un dirigeant me parle de quitter WordPress, il commence presque toujours par la lenteur. En creusant, la vitesse n'est qu'un symptôme. Le vrai problème est ailleurs.

Les motifs qui reviennent le plus souvent :

• La maintenance subie. Le cœur de WordPress, le thème et chaque plugin ont leur propre rythme de mises à jour. Une extension abandonnée par son éditeur peut bloquer tout le reste.
• La surface d'attaque. Selon le rapport annuel de Patchstack, 91 % des 11 334 vulnérabilités découvertes dans l'écosystème WordPress en 2025 concernaient des plugins, pas le cœur du CMS. Plus il y en a, plus il faut surveiller.
• La dépendance à un constructeur de pages. Un site monté avec Elementor ou Divi est lié à ces outils. Les désactiver, c'est casser la mise en page.
• Le coût caché. Licences de plugins premium, hébergement dimensionné pour compenser la lourdeur, heures passées à corriger après une mise à jour.

Astro répond à ces points par son architecture. Par défaut, il génère des pages HTML statiques au moment de la construction du site. Pas de base de données interrogée à chaque visite, pas de PHP exécuté sur le serveur, très peu de JavaScript envoyé au navigateur. Ce qui n'existe pas en production ne peut ni ralentir ni être piraté.

La maintenance ne disparaît pas pour autant. Si vous ajoutez un CMS headless comme Strapi, c'est une application à héberger, mettre à jour et sécuriser. La différence est qu'elle se concentre sur une seule brique, qui n'a pas besoin d'être exposée à vos visiteurs, au lieu de se disperser sur vingt plugins.

J'ai détaillé ce raisonnement dans un article sur pourquoi je préfère Astro et Strapi à WordPress pour un site vitrine. Mais un bon motif de départ ne suffit pas : il faut savoir ce qui vous attend de l'autre côté.

Que deviennent les plugins lors d'une migration vers Astro ?

Il faut distinguer trois couches : le contenu, la mise en page et les fonctionnalités. Elles ne se transfèrent pas du tout de la même manière.

Le contenu se récupère bien. Articles, pages, catégories, auteurs et médias s'exportent via le fichier XML natif de WordPress ou via son API REST. Ils sont ensuite convertis en fichiers Markdown, gérés par les collections de contenu d'Astro, ou importés dans un CMS headless comme Strapi. Le texte brut passe sans difficulté. Le travail commence avec ce qui l'entoure : shortcodes, blocs propres à un plugin, images insérées avec des tailles codées en dur.

La mise en page se reconstruit. Rien ne se convertit automatiquement depuis Elementor, Divi ou un thème premium. Chaque gabarit devient un composant Astro écrit proprement. C'est l'occasion d'en réduire le nombre : un site WordPress compte souvent une dizaine de variantes de pages là où trois ou quatre modèles suffiraient.

Les plugins disparaissent, leurs fonctions se réexaminent une par une. Il n'existe pas de catalogue d'extensions équivalent. Certains plugins deviennent inutiles : cache, optimisation, pare-feu applicatif n'ont plus de raison d'être sur un site statique. D'autres se remplacent par quelques lignes de code : les balises title et meta gérées par Yoast passent dans les gabarits, le sitemap est produit par l'intégration officielle d'Astro, et le multilingue géré par WPML ou Polylang passe par le routage i18n natif d'Astro. Le reste demande une vraie décision.

Un point souvent oublié : l'interface d'édition. Votre équipe rédige aujourd'hui dans l'éditeur WordPress. Sans CMS headless comme Strapi, modifier une page voudra dire passer par un développeur. Ce choix se fait avant le début du chantier, pas après.

Comment ne pas perdre son SEO pendant une refonte ?

Le référencement naturel ne se perd pas à cause d'Astro. Il se perd à cause d'URL qui changent sans redirection et de balises oubliées en route. C'est le point où un chantier bâclé coûte le plus cher.

La méthode tient en quatre étapes :

• Inventorier toutes les URL existantes. Un crawl avec Screaming Frog, croisé avec l'export des pages dans Google Search Console, donne la liste réelle. WordPress génère des adresses que personne n'a en tête : pages d'archives par date, étiquettes, pages de fichiers joints, flux RSS, pagination.
• Conserver la structure quand elle est saine. Si vos articles vivent sous /blog/nom-article/, Astro peut reproduire exactement ce chemin. Changer d'URL n'est justifié que si l'ancienne structure pose un vrai problème, comme des dates dans les adresses ou des catégories imbriquées.
• Rediriger chaque URL qui change en 301. Une table de correspondance ancienne adresse vers nouvelle adresse, page par page. Pas de redirection globale vers la page d'accueil : Google la traite comme une page disparue. Attention à un piège technique : sur un site statique, les redirections déclarées dans la configuration d'Astro produisent de simples pages de rafraîchissement, pas de vraies 301. Les redirections se configurent donc au niveau de l'hébergeur ou du serveur.
• Reporter chaque signal de page. Title, meta description, hiérarchie des titres, textes alternatifs des images, balise canonique, données structurées. Ce que Yoast ou Rank Math faisait en arrière plan doit être écrit explicitement.

Après la mise en ligne, soumettez le nouveau sitemap dans Search Console et surveillez le rapport des pages en erreur 404. D'expérience, de légères variations de positions sont courantes juste après une bascule. Une chute qui dure signale presque toujours une redirection manquante.

Formulaires, recherche, espace client : le dynamique ne disparaît pas, il change d'adresse

Un site statique ne veut pas dire un site figé. Il veut dire que chaque fonction dynamique doit être pensée explicitement, au lieu d'être confiée à un plugin.

Les formulaires. Contact Form 7 ou Gravity Forms reposent sur le PHP de WordPress. Avec Astro, deux options : une route rendue à la demande, Astro permettant de désactiver la génération statique page par page avec l'adaptateur de votre hébergeur, ou un service tiers qui reçoit les envois. Dans les deux cas, la protection anti-spam se met en place dès le départ, avec un champ piège ou Cloudflare Turnstile.

La recherche interne. Plus de requête en base de données. Pagefind construit un index au moment de la génération du site et l'interroge dans le navigateur. Pour un site vitrine ou un blog de quelques centaines de pages, le résultat est rapide et ne demande aucun serveur.

L'espace client. C'est la limite à regarder en face. Connexion, comptes, documents personnels, historique de commandes : tout cela demande un serveur, une base de données et une authentification sérieuse. Astro sait le faire en mode serveur, mais il ne s'agit plus d'une migration. C'est le développement d'une application, avec son propre budget.

Même prudence pour le commerce en ligne. Un WooCommerce avec gestion de stock, variantes et règles de livraison ne se transpose pas dans Astro en quelques jours. Dans ce cas, je conseille souvent de séparer les sujets : la vitrine et le blog passent sur Astro, la boutique reste sur une plateforme dédiée. Et si votre site repose surtout sur des plugins métier difficiles à remplacer, rester sur un WordPress bien entretenu peut être la décision la plus rationnelle.

Combien de temps dure une migration WordPress vers Astro ?

Cela dépend moins du nombre de pages que du nombre de gabarits et de fonctionnalités. Un blog de quatre cents articles bâti sur deux modèles se migre plus vite qu'un site de trente pages qui en utilise quinze, chacune avec son plugin.

Pour donner des ordres de grandeur :

• Site vitrine d'une quinzaine de pages, trois ou quatre gabarits, un formulaire de contact : 3 à 5 semaines.
• Site vitrine avec blog de plusieurs centaines d'articles, recherche interne et CMS headless : 6 à 10 semaines.
• Site multilingue avec de nombreux gabarits et des fonctions dynamiques à reconstruire : 2 à 4 mois.

Avant de demander un devis, rassemblez les réponses à ces questions :

• Combien de types de pages distincts compte le site, au-delà du nombre total de pages ?
• Quels plugins sont actifs, et que fait réellement chacun d'eux ?
• Quelles fonctions dynamiques sont indispensables : formulaires, recherche, filtres, espace membre, multilingue avec WPML ou Polylang ?
• Qui modifie le site, à quelle fréquence, et avec quelles compétences ?
• Le contenu doit-il être migré tel quel, ou trié et réécrit en partie ?
• Les URL actuelles sont-elles propres, ou faut-il une table de redirections importante ?

Un chantier se découpe ensuite en phases visibles : audit de l'existant, maquettes, intégration des gabarits, migration du contenu, redirections, recette, mise en ligne.

C'est cet inventaire qui structure un projet de développement Astro, où le chiffrage part des gabarits et des fonctions à reconstruire plutôt que d'un nombre de pages. Le poste le plus souvent sous-estimé reste le nettoyage du contenu : shortcodes orphelins, images en double, pages oubliées que personne n'ose supprimer.

Mesurer la vitesse après la mise en ligne, et pas seulement le jour J

Un score de 100 sur Lighthouse le soir de la mise en ligne ne prouve pas grand chose. Il mesure une page, sur une machine, à un instant donné. Ce qui compte, c'est ce que vivent vos visiteurs réels.

Mesurez avant de migrer. Notez les valeurs actuelles des Core Web Vitals sur vos pages principales : LCP pour l'affichage du contenu principal, INP pour la réactivité aux clics, CLS pour la stabilité visuelle. Sans point de départ, impossible de prouver un gain.

Distinguez données de laboratoire et données terrain. PageSpeed Insights affiche les deux. Les données terrain proviennent du rapport d'expérience utilisateur de Chrome et portent sur une fenêtre glissante de 28 jours. Il faut donc attendre plusieurs semaines pour voir l'effet complet de la bascule dans Search Console.

Surveillez les scripts tiers. C'est là que les gains s'évaporent. Google Tag Manager chargé de dix balises, widget de chat, bandeau cookies lourd, vidéo YouTube intégrée en haut de page : chacun peut ramener un site Astro au niveau de l'ancien WordPress. Je recommande de lister chaque script ajouté et de vérifier s'il justifie son poids.

Contrôlez aussi l'indexation. Pages couvertes dans Search Console, erreurs 404 en baisse. Un site rapide que Google n'indexe plus correctement n'a rien gagné. Pour aller plus loin sur ce que la performance change côté business, j'y consacre un article dédié à Astro et à la réalité du terrain.

Ce que vous perdez, ce que vous gagnez

Une refonte, pas une traduction

Une bascule réussie vers Astro se prépare comme une refonte : inventaire des contenus, décision sur chaque fonctionnalité, plan de redirections, mesure avant et après. Traiter le projet comme une simple conversion technique, c'est garantir les pages perdues et les formulaires qui ne répondent plus.

Avant même de parler de framework, la question utile porte sur l'existant. Combien d'heures de maintenance, de licences de plugins et de demandes de contact perdues sur des pages lentes votre site actuel vous coûte-t-il déjà, sans que personne ne l'ait jamais chiffré ?