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, préservation du SEO, choix du CMS de remplacement. Pas de théorie — des étapes concrètes, des chiffres réels, et les pièges que personne ne mentionne.

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 headless)
• 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.

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 6 étapes de la migration

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

01

Auditer

Analyser les URLs, la structure des contenus, les médias et les redirections existantes.

02

Exporter

WP XML + images via All-in-One WP Migration. Lister tous les slugs et meta SEO.

03

Reconstruire

Créer le projet Astro, les layouts, les composants et convertir les contenus en Markdown.

04

Choisir un CMS

Configurer Decap CMS pour permettre l'édition autonome — sans toucher au code.

05

Redirections

Mapper chaque ancienne URL, configurer les 301 dans Cloudflare Pages.

06

Lancer

Déployer sur Cloudflare Pages, valider Lighthouse, soumettre à Google Search Console.

É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 vos 50 URLs à plus fort trafic organique. Ce sont vos pages critiques — celles où une erreur de redirection coûte des visiteurs.

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 : exporter 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. Plus précis que l’export XML. Nécessite un script personnalisé (Node.js + Turndown pour la conversion HTML → Markdown).

WPGraphQL — Une seule requête pour articles + catégories + meta données, contre trois appels REST. Plus efficace sur les gros sites. Le plugin WPGraphQL v2 (2026) réduit les requêtes base de données de 60 à 80%.

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.

É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 CMS pour l’édition de contenu (voir étape suivante), un moteur de recherche client-side (Pagefind), un système de commentaires (Giscus), un formulaire de contact (Formspree ou Web3Forms).

Étape 4 : la question qui tue — qui éditera le contenu ?

WordPress a un éditeur visuel. Astro a des fichiers Markdown. Si votre équipe éditoriale ne connaît pas Git, vous avez un problème.

La réponse : un CMS headless 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.

Étape 5 : les redirections — le vrai sujet

C’est ici que la plupart des migrations échouent. Chaque URL qui change sans redirection 301 perd son autorité Google. Et les URLs changent presque toujours : WordPress utilise souvent /2024/06/15/mon-article/, Astro typiquement /blog/mon-article/.

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) ou des règles Cloudflare. Toutes les redirections doivent être 301 (permanentes) pour transférer l’autorité.

# _redirects — Cloudflare Pages
# Format : SOURCE  DESTINATION  CODE

/category/blog/:slug   /blog/:slug   301
/author/:name          /blog         301
/?p=:id                /blog         301
/?page_id=:id          /             301

# Ancien sitemap WordPress
/sitemap_index.xml     /sitemap.xml  301
/wp-sitemap.xml        /sitemap.xml  301

Vérification : crawlez votre ancien sitemap avec un outil (Screaming Frog, curl en batch) et vérifiez que chaque URL renvoie un 301 vers la bonne destination. 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 6 : lancer et surveiller

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

Bien exécutée, la migration produit l’effet inverse : les gains de performance (Core Web Vitals au vert) commencent à pousser le trafic organique à la hausse dès le deuxième mois.

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.

---

Vous avez un site WordPress et vous vous reconnaissez dans cet article ? Composez votre projet dans le configurateur — le prix est déjà là.