Migrer de WordPress vers Astro : étape par étape.

Votre site WordPress rame. Vous le savez. Vos visiteurs aussi — et Google encore plus vite qu’eux. La question n’est plus pourquoi, mais comment en sortir sans casser votre référencement.

On couvre ici la migration complète : export du contenu, reconstruction sous Astro, redirections, suivi après la bascule. Pas de théorie — des étapes concrètes, des chiffres réels, et à chaque étape ce qu’on a fait sur un site dont vous pouvez vérifier les redirections vous-même.

Ce que vous allez perdre (et gagner)#

Soyons honnêtes : migrer de WordPress vers Astro, ce n’est pas juste changer de moteur. C’est changer de philosophie.

Ce que vous perdez :

• L’éditeur visuel Gutenberg (remplacé par un CMS comme Decap)
• Les plugins tout-en-un (formulaires, SEO, cache, galeries)
• La communauté de support WordPress (mais Astro grandit vite)

Ce que vous gagnez :

• Un site qui charge en moins d’une seconde — par construction, pas par optimisation
• Zéro JavaScript envoyé au navigateur par défaut
• Aucun serveur à maintenir, aucun plugin à mettre à jour
• Un coût d’infrastructure mensuel de 0 EUR
• La propriété totale de votre code (dans votre dépôt Git)

La question n’est pas “est-ce mieux ?”. C’est “est-ce mieux pour votre cas ?”. On y revient en fin d’article.

Les chiffres, pas les promesses#

Les résultats ci-dessous consolident six migrations réelles, documentées et sourcées. La colonne Astro4B reflète les mesures sur les sites que nous avons livrés :

Sources : Kashif Aziz (2026), mfyz.com, Pascal Cescato (DEV.to), Kiwop Agency, Perel Web Studio, Devaradise.

Un cas parlant : Kiwop Agency a mesuré +28% de taux de clic organique (CTR) et un score Lighthouse de 97 après migration vers Astro + Payload CMS. Perel Web Studio a constaté +142% de trafic organique en trois mois.

Un cas mesuré : Marrakech City Guide#

Marrakech City Guide est le guide de voyage que publie notre fondateur, Pierre-Marie Coupry. Il tournait sous WordPress quand une mise à jour de Google, en février 2026, a fait passer ses impressions de 920 à 300 par jour. On l’a migré vers Astro et remis en ligne le 17 juillet 2026, avec une nouvelle arborescence, des contenus réécrits et une version anglaise. C’est précisément ce qu’on déconseille d’habitude : tout changer d’un coup.

Voici ce que la migration a représenté côté redirections :

Chaque ancienne adresse mène à la page qui reprend son sujet, pas à une rubrique : /comment-shabiller-a-marrakech-4544 arrive sur /fr/preparer/que-mettre-valise/, /place-jemaa-el-fna-832 sur /fr/lieux/jemaa-el-fna/. Vous pouvez le vérifier vous-même : curl -I sur l’ancienne adresse renvoie la redirection et sa destination.

La migration explique l’absence de creux : les impressions repartent dès le surlendemain de la bascule, parce qu’aucune adresse indexée n’a été perdue. La croissance qui suit vient de l’ensemble du chantier, arborescence, réécriture, version anglaise et pages nouvelles. Et une limite à garder en tête : le site partait d’un plancher. Une erreur de redirection coûte beaucoup plus cher à un site en bonne santé qu’à un site à 3 clics par jour.

La courbe complète sur douze mois est sur notre page refonte WordPress.

Avant de commencer#

Trois conditions pour que la migration se passe bien : une sauvegarde complète, un inventaire des URLs existantes, et une liste des redirections à prévoir. Les URL, c’est la seule chose qui peut faire perdre du référencement si elle est mal gérée.

Les 5 étapes de la migration#

Cette séquence est celle qu’on applique sur chaque projet de migration chez Astro4B, et celle de notre offre de refonte. L’ordre compte : ne passez pas à l’étape suivante sans avoir validé la précédente.

Étape 1 : auditer avant de toucher à quoi que ce soit#

La migration commence avant la première ligne de code. Ouvrez Google Search Console et exportez toutes les pages qui reçoivent des impressions, pas seulement celles qui reçoivent des clics. Une page sans clic aujourd’hui peut être celle qui se classe demain. Sur Marrakech City Guide, l’inventaire a donné 188 anciennes adresses à traiter.

Votre checklist d’audit :

• Nombre total de pages et articles publiés
• Plugins actifs et leur équivalent Astro (formulaires, analytics, search, commentaires)
• Champs personnalisés (ACF, Custom Fields) — les exporter demande un script dédié
• Structure des URLs actuelle (date-based /2024/06/slug/ ou flat /slug/)
• Meta descriptions et titres Yoast/Rank Math (ils ne sont pas dans l’export standard)

Ce dernier point est le piège le plus fréquent. Les meta descriptions vivent dans la table wp_postmeta, pas dans le fichier d’export XML. Si vous les perdez, vous perdez vos snippets Google.

Étape 2 : reprendre le contenu#

Trois méthodes, chacune avec ses forces :

Export XML + conversion Markdown — La plus courante. WordPress > Outils > Exporter génère un fichier WXR. L’outil wordpress-export-to-markdown (npm) le convertit en fichiers Markdown avec frontmatter. Rapide, fiable, mais ne capture ni les champs ACF ni les meta Yoast.

API REST WordPress — Requêtez /wp-json/wp/v2/posts pour récupérer les articles avec leurs métadonnées complètes. Si Yoast est actif, chaque réponse contient un champ yoast_head_json avec le titre et la description de la page : c’est le moyen le plus simple de ne pas les perdre. Nécessite un script personnalisé (Node.js + Turndown pour la conversion HTML → Markdown).

WPGraphQL — Une seule requête pour articles, catégories et métadonnées, contre plusieurs appels REST. Plus efficace sur les gros sites.

Pour un site de moins de 100 pages, l’export XML suffit largement. Au-delà, l’API REST ou WPGraphQL évitent les oublis.

Les images : téléchargez le dossier wp-content/uploads/ en entier. Réorganisez-le sous public/images/ et réécrivez les chemins dans vos fichiers Markdown. Le composant <Image> d’Astro se charge de l’optimisation (WebP, responsive, anti-CLS) au build.

La reprise peut aussi être l’occasion de réécrire, comme sur Marrakech City Guide. Mais c’est alors un chantier éditorial qui s’ajoute au chantier technique, avec son propre calendrier.

Étape 3 : reconstruire sous Astro#

Astro structure le contenu via les Content Collections : vos articles sont des fichiers Markdown dans src/content/blog/, validés par un schéma Zod au build. Une erreur dans le frontmatter ? Le build échoue. Pas de surprise en production.

Chaque article a un frontmatter typé :

title: "Mon article"
description: "La meta description, 160 caractères max"
date: 2026-06-08
category: Migration
tags: [wordpress, astro]
readingTime: "8 min de lecture"

Ce qu’Astro fait nativement (sans plugin) :

• Sitemap XML (@astrojs/sitemap)
• Flux RSS (@astrojs/rss)
• Optimisation d’images (astro:assets)
• Support Markdown et MDX
• Pagination via paginate() dans getStaticPaths()

Ce qu’il faut ajouter : un outil d’édition des contenus (voir ci-dessous), un moteur de recherche client-side (Pagefind), un système de commentaires (Giscus), un formulaire de contact (Formspree ou Web3Forms).

Un site qui met 4 secondes à charger ne se migre pas. Il se reconstruit.

Le gain de performance est visible dès le premier déploiement.

Qui éditera le contenu ?

WordPress a un éditeur visuel. Astro a des fichiers Markdown. Si votre équipe éditoriale ne connaît pas Git, il lui faut un CMS qui se branche sur Astro. Le marché est large — voici les options selon votre profil :

Decap CMS — Gratuit, open-source, basé sur Git. L’éditeur travaille dans le navigateur, les fichiers sont commités directement dans le dépôt. Idéal pour les équipes techniques ou les blogs avec peu de contributeurs. C’est notre choix chez Astro4B.

Storyblok — Éditeur visuel proche de WordPress, intégration Astro native. À partir de 99 EUR/mois. Le meilleur compromis pour les équipes habituées à un éditeur WYSIWYG.

Sanity — Schémas entièrement personnalisables, collaboration en temps réel. Tier gratuit viable en production. Pour les équipes dev qui veulent un contrôle total.

TinaCMS — Éditeur visuel + Git-based. Le meilleur des deux mondes, mais encore jeune.

Le critère de choix est simple : si vos éditeurs sont techniques (ou prêts à apprendre), Decap CMS. S’ils veulent cliquer comme dans WordPress, Storyblok.

Reste une option qu’on vous proposera ailleurs : garder WordPress comme simple back-office et faire lire ses contenus par Astro. C’est faisable, mais vous conservez alors un serveur WordPress à mettre à jour et à sécuriser, c’est-à-dire ce que la migration devait supprimer. On ne la propose pas.

Étape 4 : les redirections, le vrai sujet#

C’est ici que la plupart des migrations échouent. Chaque URL indexée qui change sans redirection perd ce qu’elle avait acquis dans Google. Et les URLs changent presque toujours : WordPress utilise souvent /2024/06/15/mon-article/, Astro typiquement /blog/mon-article/.

Trois règles, qui sont aussi celles du guide de Google sur les migrations de site :

1. Une 301 par ancienne URL, vers son équivalent exact. Pas vers une rubrique, pas vers l’accueil. Google le dit sans détour : rediriger en masse vers une même destination « pourrait être considéré comme une erreur de type soft 404 ».
2. Une 410 pour ce qui disparaît. Une page que vous ne reprenez pas doit le dire : le code 410 signale une suppression définitive. Sur Marrakech City Guide, 37 anciennes pages sont parties en 410.
3. Des redirections conservées au moins un an, toujours selon Google. Le plus simple est de ne jamais les retirer.

Les redirections à ne pas oublier :

• Chaque article et page (évidemment)
• Le flux RSS : /feed/ → /rss.xml
• Les archives paginées : /page/2/, /page/3/…
• Les pages auteur et catégorie
• Les URLs de médias (images) si elles changent
• Les trailing slashes — une source de doublons silencieux

Configuration : un fichier _redirects à la racine (Cloudflare Pages, Netlify). Sur Cloudflare Pages, la documentation de Cloudflare fixe trois limites. Le fichier ne lit pas les paramètres d’URL, donc une règle comme /?p=123 ne se déclenche jamais. Il accepte au plus 2 000 redirections fixes et 100 dynamiques. Et il ne renvoie que des codes de redirection : pour une 410, il faut une fonction ou un Worker.

# _redirects — Cloudflare Pages
# Format : SOURCE  DESTINATION  CODE

# Une ligne par ancienne URL, vers son équivalent exact
/2024/06/15/mon-article/   /blog/mon-article/      301
/a-propos-de-nous/         /a-propos/              301

# Un motif seulement quand l'équivalence est mécanique
/category/blog/:slug/      /blog/:slug/            301

# Flux et sitemap WordPress
/feed/                     /rss.xml                301
/sitemap_index.xml         /sitemap-index.xml      301
/wp-sitemap.xml            /sitemap-index.xml      301

Les adresses en ?p=123 posent rarement problème : WordPress les redirige déjà vers les permaliens, et elles sont peu souvent indexées. Vérifiez dans Search Console avant d’y consacrer du temps.

Vérifiez sur la production, pas sur votre tableau. Le fichier de correspondance bouge pendant le chantier. Sur Marrakech City Guide, 60 des 140 redirections prévues ont fini vers une autre page que celle du tableau initial, et 11 adresses promises à la suppression ont finalement été redirigées. Une fois en ligne, testez chaque ancienne URL (curl -I en boucle, ou Screaming Frog en mode liste) et comparez ce que le site renvoie à ce que vous attendez. Un seul 404 sur une page à fort trafic peut annuler des semaines de travail.

« La migration d’un site WordPress de 50 pages vers Astro prend en général 2 à 4 semaines, dont une semaine de tests SEO avant la bascule DNS. »

— Estimation Astro4B, basée sur 8 migrations réalisées en 2025–2026

Étape 5 : mettre en ligne et suivre#

Le jour du lancement, soumettez votre nouveau sitemap dans Google Search Console et Bing Webmaster Tools. Puis surveillez.

Protocole de suivi :

• Semaine 1 — Vérification quotidienne : erreurs de crawl, pages en 404, désindexations
• Semaines 2-4 — Vérification hebdomadaire : positions, impressions, CTR
• Mois 2 — Bilan complet : trafic organique vs baseline pré-migration

Timeline de récupération réaliste :

• URLs identiques + 301 en place : fluctuation légère semaines 1-2, récupération sous 30 jours
• Changement de structure d’URLs avec 301 : 30 à 60 jours
• Migration bâclée (redirections manquantes) : -40 à -60% de trafic organique en semaine 1

Google prévient lui-même que la visibilité peut fluctuer pendant une migration, et qu’il faut compter quelques semaines pour un site de taille moyenne. Sur Marrakech City Guide, avec une structure entièrement nouvelle et toutes les adresses indexées redirigées, les impressions sont reparties dès le surlendemain.

Bien exécutée, une migration ne fait rien perdre. Elle ne fait rien gagner non plus à elle seule : ce qui fait monter le trafic ensuite, c’est ce que vous changez à la faveur de la migration, structure, contenus et vitesse.

Quand ne PAS migrer#

On vend des sites Astro. Mais pas à n’importe quel prix.

Astro excelle sur les sites de contenu : vitrines, blogs, sites marketing, portfolios. Pour un SaaS avec dashboard, un marketplace, ou un site transactionnel complexe, d’autres frameworks (Next.js, Remix) sont plus adaptés.

Si vous ne savez pas dans quelle catégorie vous êtes, c’est probablement le bon moment pour en parler.

Questions fréquentes#

Vous avez un site WordPress et vous vous reconnaissez dans cet article ? On peut refaire votre site WordPress avec Astro, reprise du contenu et redirections comprises. Le prix est déjà dans le configurateur.