Migrer de WordPress vers Astro : ce qui change vraiment (et ce qui casse)
La plupart des sites WordPress ne démarrent pas lents. Ils le deviennent - un plugin à la fois, une mise à jour de thème à la fois, jusqu’à ce qu’une page essentiellement composée de texte envoie un mégaoctet de JavaScript qu’elle n’utilise jamais. À un moment, le vrai correctif n’est pas un énième plugin de cache ; c’est une architecture différente. Pour les sites de contenu, Astro est de plus en plus cette architecture. Voici ce qu’implique réellement un passage, sans l’évangélisme des frameworks.
Pourquoi les équipes migrent au départ
Le motif est presque toujours la performance. WordPress rend les pages côté serveur à chaque requête et empile par-dessus des scripts de plugins, donc une installation type traîne un bagage dont un site marketing n’a pas besoin : jQuery, multiples feuilles de style de plugins, runtime de page-builder, embeds tiers bloquants. Ce bagage apparaît sous forme de mauvais Core Web Vitals - LCP lent, interactivité bloquée, TTFB élevé.
Astro prend le parti inverse. Il rend vos pages en HTML statique au moment du build et n’envoie aucun JavaScript sauf si un composant précis en a vraiment besoin. Le résultat n’est pas un WordPress un peu plus rapide - c’est un profil de performance structurellement différent, car il n’y a simplement aucun runtime de framework à télécharger sur une page qui n’en a pas besoin.
Ce qui se transfère proprement
La migration fait moins peur qu’il n’y paraît, car l’essentiel de ce qui compte se transfère directement :
- Le contenu. Les articles WordPress s’exportent en Markdown, exactement ce que consomment les collections de contenu d’Astro. Chaque article devient un fichier
.mdavec un frontmatter pour le titre, la date et les balises méta. - La structure d’URL. Astro peut reproduire à l’identique votre schéma de permaliens (
/blog/nom-article/), la chose la plus importante pour préserver les classements. - Les métadonnées. Balises titre, méta-descriptions et balises canoniques passent dans le frontmatter et la logique de gabarit - souvent plus propres que la version pilotée par plugin qu’elles remplacent.
Ce qui casse vraiment (et comment l’éviter)
Toute migration de plateforme échoue de la même façon : non parce que la nouvelle plateforme est pire, mais parce que les URL changent et que les redirections sont oubliées. Les pièges précis :
| Piège | Prévention |
|---|---|
Décalage de slash final (/article vs /article/) | Choisir une convention et rediriger l’autre en 301 |
Perte des URL héritées de type ?p=123 | Mapper les anciens permaliens à paramètres vers les nouveaux chemins |
| URL d’archives auteur/catégorie/tag | Recréer ou rediriger les archives qui avaient des liens entrants ou du trafic |
| Chemins d’images qui changent | Garder les chemins d’images identiques, ou rediriger l’ancienne médiathèque |
| Méta-descriptions perdues | Vérifier que chaque article migré a gardé sa description dans le frontmatter |
Le processus sûr : explorez d’abord le site WordPress en ligne, exportez chaque URL indexée, et traitez cette liste comme le contrat que le nouveau site doit honorer. Tout ce qui s’y trouve conserve son URL exacte ou reçoit une redirection 301 vers son nouvel emplacement. Ratez cette étape et vous verrez les classements chuter pendant un mois le temps que Google redécouvre votre site - une blessure auto-infligée qui n’a rien à voir avec Astro.
Formulaires, recherche et les manques « mais WordPress le faisait »
Un site statique ne peut pas exécuter du PHP côté serveur comme WordPress, donc quelques fonctionnalités demandent un remplacement délibéré plutôt qu’un plugin :
- Les formulaires de contact passent à un endpoint de formulaire - une petite fonction serverless ou un service de formulaire - au lieu d’un plugin WordPress. Plus léger et plus sûr, mais c’est une décision, pas un défaut.
- La recherche interne utilise soit un index côté client (parfait pour des centaines d’articles), soit un service de recherche hébergé (mieux pour des milliers).
- Les commentaires, si vous en avez besoin, passent à un service tiers puisqu’il n’y a pas de base de données WordPress pour les stocker.
- L’édition non technique est la vraie considération. Si les rédacteurs ont besoin d’une interface façon wp-admin, associez Astro à un CMS headless pour que l’expérience de rédaction reste familière tandis que la façade reste statique.
Aucun de ces points n’est rédhibitoire, mais prétendre qu’ils n’existent pas fait caler les migrations à mi-chemin.
Le compromis honnête
Astro l’emporte nettement sur la performance, la surface de sécurité (pas de PHP, pas de base de données, pas de vulnérabilités de plugins) et le coût d’hébergement (des fichiers statiques sont peu coûteux à servir). WordPress l’emporte sur l’étendue des plugins et la familiarité de l’éditeur prêt à l’emploi. La décision se ramène à ce qu’est réellement votre site :
- Un site de contenu ou marketing - blog, services, études de cas - est proche du candidat idéal pour Astro. C’est là que le gain de performance est le plus grand et la perte de fonctionnalités la plus faible.
- Une application complexe - adhésion, e-commerce à forte logique dynamique, workflows très dépendants de plugins - mérite un examen plus poussé avant de s’engager.
Si votre site est surtout des pages et des articles qui s’affichent pareil pour chaque visiteur, vous laissez de la vitesse sur la table en les rendant à chaque requête.
Voyez l’écart sur votre propre site
Avant de décider, mesurez. Passez votre site WordPress actuel dans notre outil gratuit et notez le LCP, le TTFB et le temps de blocage - ce sont les métriques qu’une reconstruction statique bouge le plus. C’est la base honnête pour comparer toute migration.
Vérifiez la performance de votre site actuel →
Vous envisagez une reconstruction ?
Nous migrons les sites WordPress de contenu vers Astro avec la carte de redirections faite en premier, les URL préservées, et les Core Web Vitals comme critère d’acceptation - pas un après-coup. L’avant/après est généralement l’argument le plus facile que nous ayons à faire.
Publié par l’Équipe Ingénierie Runkexpert. Dernière mise à jour le 26/07/2026.