Astro est le meilleur remplaçant de WordPress pour les sites riches en contenu en 2026 -- blog, docs, pages marketing -- car il envoie zéro JavaScript par défaut et surpasse WordPress sur Core Web Vitals de 60 à 80 points. J'ai migré une douzaine de sites WordPress vers Astro au cours des deux dernières années, allant de blogs personnels de 50 articles à des portails de documentation de 3 000 pages, et les résultats sont constamment spectaculaires : des temps de chargement infra-secondaires, des scores Lighthouse supérieurs à 95, et des factures d'hébergement qui chutent de 99 $/mois à littéralement zéro.

Ce n'est pas un guide « exportez simplement le XML et croisez les doigts ». Je vais vous parcourir le processus exact que j'utilise, y compris les pièges qui vous mordront si vous ne les prévoyez pas -- les URLs cassées, les images manquantes, les shortcodes orphelins, et la question du système de commentaires qui piège tout le monde.

Table of Contents

Pourquoi Astro au lieu de WordPress

WordPress est surconçu pour la plupart des sites de contenu. Vous exécutez PHP, MySQL, un serveur web, une couche de mise en cache, et probablement une douzaine de plugins juste pour servir ce qui est fondamentalement du contenu statique. Chaque chargement de page accède à une base de données. Chaque plugin est un trou de sécurité potentiel. Chaque mise à jour est une prière pour que rien ne se casse.

Astro inverse ce modèle. Il pré-rend vos pages en HTML statique au moment de la construction. Pas de base de données. Pas de runtime côté serveur. Pas de PHP. La sortie est du HTML pur, du CSS et -- seulement si vous optez explicitement pour cela -- du JavaScript.

Voici ce que je vois constamment lors des migrations :

Métrique WordPress (Géré) Astro (Statique) Amélioration
Lighthouse Performance 34-55 95-100 +60-80 pts
First Contentful Paint 2.8-4.2s 0.4-0.8s ~80% plus rapide
Total Blocking Time 200-800ms 0-10ms ~98% de réduction
Page Size (article blog typique) 1.5-3.5 MB 80-250 KB ~90% plus petit
Time to Interactive 4-8s 0.5-1.0s ~85% plus rapide
HTTP Requests 60-130 8-15 ~85% moins de demandes

Ce ne sont pas des cas sélectionnés. Ce sont des moyennes provenant de migrations réelles. Les sites WordPress avec des plugins de mise en cache et des CDN ne peuvent toujours pas rivaliser avec une construction Astro statique car ils font fondamentalement plus de travail par demande.

L'angle sécurité

WordPress est le CMS le plus attaqué sur Internet. Non pas parce qu'il est mauvais, mais parce qu'il est partout et qu'il a une surface d'attaque massive -- exécution PHP, accès à la base de données, téléchargements de fichiers, XML-RPC, points de terminaison de l'API REST, pages de connexion administrateur. Chaque mois apporte de nouvelles vulnérabilités de plugins.

Les sites Astro déployés sur un CDN ont essentiellement zéro surface d'attaque. Il n'y a pas de serveur à exploiter, pas de panneau d'administration à forcer, pas de base de données à injecter. Votre site est un dossier de fichiers HTML assis sur un réseau de périphérie mondial.

L'expérience développeur

Si vous avez déjà essayé de personnaliser un thème WordPress, vous connaissez la douleur : les balises de modèle PHP mélangées au HTML, la hiérarchie de modèles qui nécessite une mémorisation, les fichiers functions.php qui deviennent des monstres non maintenables, les conflits constants de plugins.

Astro utilise une architecture basée sur les composants avec un format de fichier qui ressemble à HTML avec des superpuissances. Vous pouvez utiliser les composants React, Vue, Svelte ou Solid à l'intérieur des pages Astro -- mais seulement quand vous en avez réellement besoin pour l'interactivité. Pour un blog ou un site marketing, vous probablement ne le faites pas.

---
// src/pages/blog/[...slug].astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
const { Content } = await post.render();
---

<BlogLayout title={post.data.title} description={post.data.excerpt}>
  <article>
    <h1>{post.data.title}</h1>
    <time datetime={post.data.date.toISOString()}>
      {post.data.date.toLocaleDateString()}
    </time>
    <Content />
  </article>
</BlogLayout>

C'est une page de blog entièrement dynamique. Essayez de faire cela dans WordPress avec la même clarté.

Astro vs Next.js vs Gatsby pour la migration WordPress

Astro

Astro a été construit à dessein pour les sites de contenu. Son « architecture d'îles » signifie que vous n'expédiez zéro JS sauf si un composant spécifique en a besoin. Les collections de contenu vous donnent une gestion markdown type-safe avec la validation de schéma intégrée. Les temps de compilation sont rapides, le modèle mental est simple, et vous n'avez pas besoin de comprendre React pour l'utiliser. Pour les blogs, docs et sites marketing, c'est le choix évident en 2026. Si vous explorez cet itinéraire, notre équipe de développement Astro a géré des migrations à chaque échelle.

Next.js

Next.js est un framework d'application complet. Il gère l'authentification, le rendu côté serveur, les routes API, les middlewares, et cent autres choses dont vous n'avez pas besoin pour un blog. Vous expédierez le runtime React à chaque visiteur qu'il ait besoin d'interactivité ou non (les composants serveur du routeur d'application aident, mais la ligne de base du bundle est toujours plus lourde). Next.js a du sens quand vous construisez un produit SaaS ou un site avec de la fonctionnalité dynamique lourde -- tableaux de bord utilisateur, e-commerce, fonctionnalités en temps réel. Pour une migration de contenu depuis WordPress ? C'est excessif. Cela dit, si votre site a réellement besoin de ces fonctionnalités, notre équipe Next.js peut vous aider à déterminer la bonne architecture.

Gatsby

Gatsby est effectivement en mode maintenance. Netlify l'a acquis en 2023, et le développement a ralenti à un rythme d'escargot. La couche de données GraphQL qui semblait autrefois intelligente semble maintenant être une complexité inutile. Les temps de compilation pour les gros sites sont douloureux. L'écosystème des plugins est stagnant. Je recommanderais fortement de ne pas commencer un nouveau projet Gatsby en 2026. Si vous êtes actuellement sur Gatsby, la migration vers Astro est en fait plus facile que la migration depuis WordPress car votre contenu est probablement déjà en markdown.

Fonctionnalité Astro Next.js Gatsby
JS expédié par défaut 0 KB ~85-100 KB ~70-90 KB
Collections de contenu Intégré, type-safe Configuration manuelle Couche GraphQL
Temps de compilation (1000 articles) ~30-45s ~60-90s ~120-300s
Courbe d'apprentissage Bas Moyen-Élevé Moyen
Meilleur pour Sites de contenu Applications web Projets hérités
Développement actif Très actif Très actif Minimal
Support SSR Optionnel Par défaut Limité

Plan de migration en 7 étapes

Voici le processus exact que je suis. Pas de bla-bla.

Étape 1 : Audit de votre site WordPress

Avant de toucher à du code, vous devez savoir avec quoi vous travaillez. Connectez-vous à votre administrateur WordPress et faites l'inventaire.

# Si vous avez WP-CLI installé (vous devriez)
wp post list --post_type=post --format=csv --fields=ID,post_title,post_name,post_date > posts.csv
wp post list --post_type=page --format=csv --fields=ID,post_title,post_name,post_date > pages.csv
wp plugin list --format=table
wp theme list --format=table

Documentez chaque plugin et ce qu'il fait. Vous devrez trouver des équivalents Astro ou les abandonner. Les plugins courants :

  • Yoast SEO → Gestion intégrée <head> d'Astro + @astrojs/sitemap
  • Contact Form 7 → Formspree, Formspark, ou une fonction serverless
  • WP Super Cache / W3 Total Cache → Pas nécessaire (votre site est déjà statique)
  • Wordfence / Sucuri → Pas nécessaire (pas de serveur à protéger)
  • Plugin Google Analytics → Balise de script directe ou intégration Partytown
  • WooCommerce → Snipcart, Shopify Buy Button, ou une plateforme d'e-commerce dédiée

Étape 2 : Exporter le contenu WordPress

Vous avez deux options : l'export XML ou l'API REST. Je recommande l'export XML pour la plupart des sites car il capture tout en une seule fois.

Dans l'administrateur WordPress : Tools → Export → All Content → Download Export File

Cela vous donne un fichier .xml contenant chaque article, page, commentaire, champ personnalisé, catégorie, balise et référence média.

Pour les sites plus grands (1000+ articles), l'approche API REST est plus fiable :

// scripts/export-wp.mjs
import fs from 'fs/promises';
import path from 'path';

const WP_URL = 'https://your-wordpress-site.com/wp-json/wp/v2';
const PER_PAGE = 100;

async function fetchAllPosts() {
  let page = 1;
  let allPosts = [];
  
  while (true) {
    const res = await fetch(
      `${WP_URL}/posts?per_page=${PER_PAGE}&page=${page}&_embed`
    );
    
    if (!res.ok) break;
    
    const posts = await res.json();
    if (posts.length === 0) break;
    
    allPosts = allPosts.concat(posts);
    console.log(`Fetched page ${page} (${allPosts.length} posts total)`);
    page++;
  }
  
  return allPosts;
}

const posts = await fetchAllPosts();
await fs.writeFile('wp-posts.json', JSON.stringify(posts, null, 2));
console.log(`Exported ${posts.length} posts`);

Étape 3 : Scaffold votre projet Astro

npm create astro@latest my-new-site
cd my-new-site

# Ajoutez les intégrations dont vous aurez besoin
npx astro add mdx
npx astro add sitemap
npx astro add tailwind

# Installez des dépendances supplémentaires
npm install sharp @astrojs/rss

Je recommande de commencer par une configuration minimale plutôt qu'un thème. Les thèmes ajoutent la complexité dont vous n'avez pas besoin pendant la migration. Faites d'abord fonctionner le contenu, puis stylisez-le.

Étape 4 : Convertir le contenu en Markdown

C'est là que le vrai travail commence. Vous devez convertir le contenu HTML de WordPress en markdown propre avec un frontmatter approprié.

J'utilise un script Node.js personnalisé avec turndown pour la conversion HTML-en-markdown :

npm install turndown @wordpress/block-serialization-default-parser

// scripts/convert-posts.mjs
import TurndownService from 'turndown';
import fs from 'fs/promises';
import path from 'path';

const turndown = new TurndownService({
  headingStyle: 'atx',
  codeBlockStyle: 'fenced',
});

// Gérez le HTML spécifique à WordPress
turndown.addRule('wpCaption', {
  filter: (node) => {
    return node.nodeName === 'DIV' && 
           node.className.includes('wp-caption');
  },
  replacement: (content, node) => {
    const img = node.querySelector('img');
    const caption = node.querySelector('.wp-caption-text');
    return `![${caption?.textContent || ''}](${img?.src || ''})\n`;
  },
});

const posts = JSON.parse(await fs.readFile('wp-posts.json', 'utf-8'));

for (const post of posts) {
  const slug = post.slug;
  const markdown = turndown.turndown(post.content.rendered);
  
  const frontmatter = `---
title: "${post.title.rendered.replace(/"/g, '\\"')}"
date: ${post.date}
excerpt: "${(post.excerpt.rendered || '').replace(/<[^>]*>/g, '').trim().replace(/"/g, '\\"')}"
categories: [${(post._embedded?.['wp:term']?.[0] || []).map(c => `"${c.name}"`).join(', ')}]
tags: [${(post._embedded?.['wp:term']?.[1] || []).map(t => `"${t.name}"`).join(', ')}]
featuredImage: "${post._embedded?.['wp:featuredmedia']?.[0]?.source_url || ''}"
draft: false
---`;

  const content = `${frontmatter}\n\n${markdown}\n`;
  
  await fs.mkdir('src/content/blog', { recursive: true });
  await fs.writeFile(`src/content/blog/${slug}.md`, content);
  console.log(`Converted: ${slug}`);
}

Étape 5 : Télécharger et organiser les médias

WordPress stocke les médias dans les répertoires wp-content/uploads/YYYY/MM/. Vous devez tout télécharger et mettre à jour les références.

# Rapide et sale : wget mirror du répertoire uploads
wget -r -np -nH --cut-dirs=2 -P public/uploads \
  https://your-wordpress-site.com/wp-content/uploads/

# Ensuite find-and-replace les anciennes URLs dans vos fichiers markdown
find src/content/blog -name '*.md' -exec sed -i '' \
  's|https://your-wordpress-site.com/wp-content/uploads/|/uploads/|g' {} +

Pour les migrations en production, j'utilise l'optimisation d'image d'Astro avec la bibliothèque sharp pour convertir tout en WebP et générer des tailles réactives au moment de la compilation. Cela seul peut réduire la charge utile des images de 40-60%.

Étape 6 : Construire les mises en page et les composants

Créez vos mises en page Astro pour correspondre à (ou améliorer) la structure de thème WordPress. Au minimum, vous aurez besoin de :

  • src/layouts/BaseLayout.astro -- enveloppe HTML, <head>, nav, pied de page
  • src/layouts/BlogLayout.astro -- modèle de publication unique
  • src/pages/blog/index.astro -- liste de blog avec pagination
  • src/pages/blog/[...slug].astro -- pages de publication dynamiques
  • src/pages/index.astro -- page d'accueil

Étape 7 : Tester, rediriger, déployer

Construisez localement et vérifiez tout :

npm run build
npm run preview

# Vérifiez les liens cassés
npx linkinator http://localhost:4321 --recurse

Configurez les redirections (couvertes en détail ci-dessous), configurez votre DNS et déployez. Je couvrirai les options d'hébergement dans la section de comparaison des coûts.

Exportation de données WordPress vers les collections de contenu Astro

Les collections de contenu d'Astro sont l'une de ses meilleures fonctionnalités. Elles vous donnent un accès type-safe à votre contenu markdown avec validation de schéma. Voici comment les configurer correctement pour le contenu WordPress migré.

Définir votre schéma

// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    date: z.coerce.date(),
    excerpt: z.string().optional(),
    categories: z.array(z.string()).default([]),
    tags: z.array(z.string()).default([]),
    featuredImage: z.string().optional(),
    draft: z.boolean().default(false),
  }),
});

export const collections = { blog };

La beauté de ceci : si l'un de vos articles migrés a un frontmatter manquant ou mal formé, Astro vous le dira au moment de la compilation avec un message d'erreur clair. Pas plus d'échecs silencieux.

Gérer les shortcodes WordPress

C'est le piège que la plupart des guides de migration ignorent. Si vos articles WordPress utilisent des shortcodes comme [gallery], [caption], [embed], ou des shortcodes personnalisés provenant de plugins, ils apparaîtront comme du texte brut dans votre markdown.

Vous avez trois options :

  1. Pré-traiter lors de la conversion -- Écrivez des règles regex dans votre script de conversion pour transformer les shortcodes en équivalents markdown ou HTML
  2. Utilisez MDX -- Convertissez les articles affectés en .mdx et créez des composants Astro qui remplacent les shortcodes
  3. Trouvez et remplacez manuellement -- Pour les petits sites, parfois l'approche la plus rapide
// Exemple : conversion du shortcode de galerie WordPress lors de la conversion
function convertShortcodes(content) {
  // [gallery ids="1,2,3"]
  content = content.replace(
    /\[gallery ids="([^"]+)"\]/g,
    (match, ids) => {
      const imageIds = ids.split(',');
      return imageIds.map(id => `![](/uploads/gallery/${id.trim()}.jpg)`).join('\n');
    }
  );
  
  // [youtube url="..."]
  content = content.replace(
    /\[youtube[^\]]*url="([^"]+)"[^\]]*\]/g,
    (match, url) => `<iframe src="${url}" width="560" height="315" frameborder="0"></iframe>`
  );
  
  return content;
}

Interroger le contenu

Une fois que votre contenu est dans les collections, l'interrogation est simple :

---
// src/pages/blog/index.astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

const posts = (await getCollection('blog'))
  .filter(post => !post.data.draft)
  .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
---

<BlogLayout title="Blog">
  <ul>
    {posts.map(post => (
      <li>
        <a href={`/blog/${post.slug}/`}>
          <h2>{post.data.title}</h2>
          <time>{post.data.date.toLocaleDateString()}</time>
          <p>{post.data.excerpt}</p>
        </a>
      </li>
    ))}
  </ul>
</BlogLayout>

Préservation du SEO : redirections 301, sitemap et schéma

Cette section est critique. Une migration bâclée peut détruire des années d'équité SEO du jour au lendemain. Ne sautez aucune de ces étapes.

Structure d'URL et redirections 301

WordPress utilise par défaut des URLs comme /2024/03/my-post-title/ ou /?p=123. Vous devez mapper chaque ancienne URL à son équivalent Astro.

Tout d'abord, générez une liste complète des anciennes URLs :

# Utilisant WP-CLI
wp post list --post_type=post,page --field=url > old-urls.txt

# Ou explorez le sitemap
curl -s https://your-site.com/sitemap.xml | grep -oP '<loc>\K[^<]+'

Pour Vercel, créez un vercel.json à la racine de votre projet :

{
  "redirects": [
    { "source": "/2024/03/my-old-post/", "destination": "/blog/my-old-post/", "permanent": true },
    { "source": "/:year(\\d{4})/:month(\\d{2})/:slug/", "destination": "/blog/:slug/", "permanent": true },
    { "source": "/category/:slug/", "destination": "/blog/category/:slug/", "permanent": true },
    { "source": "/feed/", "destination": "/rss.xml", "permanent": true }
  ]
}

Pour Netlify, utilisez _redirects dans votre dossier public/ :

/2024/03/my-old-post/  /blog/my-old-post/  301
/category/*            /blog/category/:splat  301
/feed/                 /rss.xml  301

Pour Cloudflare Pages, utilisez _redirects (même format que Netlify) ou Bulk Redirects dans le tableau de bord.

Génération du sitemap

L'intégration @astrojs/sitemap gère cela automatiquement :

// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://your-new-site.com',
  integrations: [sitemap()],
});

Après le déploiement, soumettez immédiatement votre nouveau sitemap dans Google Search Console. Soumettez également une demande de suppression pour les URLs qui n'existent plus et ne sont pas redirigées.

Données structurées / Balisage de schéma

Si Yoast gérait votre balisage de schéma, vous devez le reproduire. Créez un composant réutilisable :

---
// src/components/ArticleSchema.astro
const { title, date, excerpt, image, author = 'Your Name' } = Astro.props;

const schema = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": title,
  "datePublished": date,
  "description": excerpt,
  "image": image,
  "author": {
    "@type": "Person",
    "name": author
  }
};
---

<script type="application/ld+json" set:html={JSON.stringify(schema)} />

Flux RSS

N'oubliez pas vos abonnés RSS :

// src/pages/rss.xml.js
import rss from '@astrojs/rss';
import { getCollection } from 'astro:content';

export async function GET(context) {
  const posts = await getCollection('blog');
  return rss({
    title: 'Your Site',
    description: 'Your description',
    site: context.site,
    items: posts.map(post => ({
      title: post.data.title,
      pubDate: post.data.date,
      description: post.data.excerpt,
      link: `/blog/${post.slug}/`,
    })),
  });
}

Comparaison des coûts d'hébergement

C'est là que le cas commercial pour la migration devient impossible à ignorer.

Scénario d'hébergement Coût mensuel Coût annuel Remarques
WP Engine (WordPress géré) 30-60 $ 360-720 $ Plans Startup-Growth
Kinsta (WordPress géré) 35-70 $ 420-840 $ Plans Starter-Business
Flywheel (WordPress géré) 15-30 $ 180-360 $ Plans Tiny-Personal
Auto-hébergé (DigitalOcean + maintenance) 12-24 $ 144-288 $ Plus votre temps pour les mises à jour
Astro sur Vercel (Hobby) 0 $ 0 $ 100 Go de bande passante/mois
Astro sur Netlify (Gratuit) 0 $ 0 $ 100 Go de bande passante/mois
Astro sur Cloudflare Pages (Gratuit) 0 $ 0 $ Bande passante illimitée
Astro sur Vercel (Pro) 20 $ 240 $ 1 To de bande passante, fonctionnalités d'équipe

Pour la grande majorité des sites de contenu -- blogs, portfolios, sites de documentation, sites marketing -- les niveaux gratuits sur Vercel, Netlify ou Cloudflare Pages sont plus que suffisants. Vous servez des fichiers statiques à partir d'un CDN mondial. Un site recevant 100 000 pages vues par mois rayera à peine les limites du niveau gratuit.

Laissez-moi vous l'expliquer mathématiquement. Si vous payez 50 $/mois pour l'hébergement WordPress géré, c'est 600 $/an. Sur trois ans, c'est 1 800 $. Ajoutez les licences de plugins premium (Yoast Premium à 99 $/an, Elementor Pro à 59 $/an, WP Rocket à 59 $/an), et vous cherchez 800-1 000 $ annuels pour un site de contenu qui pourrait être hébergé gratuitement.

La migration elle-même est un coût unique. Si vous la gérez vous-même, c'est votre temps. Si vous embauchez une équipe comme la nôtre via nos services de développement CMS headless, le ROI se rentabilise généralement en 6 à 12 mois juste grâce aux économies d'hébergement -- sans compter les améliorations de performances et de SEO. Consultez notre page de tarification pour les spécificités.

Mais qu'en est-il des fonctionnalités dynamiques ?

L'objection la plus courante : « Mon site WordPress a des formulaires de contact, une recherche, des commentaires et du commerce électronique. »

  • Formulaires de contact : Formspree (niveau gratuit : 50 soumissions/mois), Formspark, ou une fonction serverless simple
  • Recherche : Pagefind (gratuit, s'exécute entièrement côté client, conçu pour les sites statiques) -- c'est incroyable
  • Commentaires : Giscus (gratuit, sauvegardé par GitHub), ou Disqus si vous le devez
  • E-commerce : Snipcart, Shopify Lite, ou Stripe Checkout
  • Inscriptions à la newsletter : Appels API directs à ConvertKit, Mailchimp, ou Buttondown

Aucun de ceux-ci ne nécessite un serveur. Aucun d'eux n'ajoute de coût significatif.

FAQ

Combien de temps prend la migration de WordPress à Astro ?

Pour un blog typique avec 50-200 articles, attendez 1-2 semaines de travail à temps partiel si vous le faites vous-même. La conversion de contenu prend généralement un jour de travail avec un bon script. Construire les mises en page et composants Astro prend 2-4 jours selon la complexité du design. Les tests, la configuration des redirections et le déploiement prennent un autre 1-2 jours. Pour les sites plus grands (500+ articles) ou les sites avec des types de publications personnalisées complexes et des dépendances de plugins, prévoyez 3-6 semaines. Si vous préférez le laisser à d'autres, contactez notre équipe -- nous complétions généralement les migrations en 2-4 semaines.

Astro peut-il gérer un blog WordPress avec 1000+ articles ?

Absolument. J'ai migré des sites avec plus de 3 000 articles et les temps de compilation sont restés sous 2 minutes. Les collections de contenu sont optimisées pour les ensembles de données volumineux, et puisque tout est compilé en HTML statique, il n'y a pas de pénalité de performance au runtime quelle que soit l'échelle du contenu. L'étape de compilation est le seul endroit où l'échelle est importante, et les performances de compilation d'Astro sont excellentes -- considérablement plus rapides que Gatsby ou Next.js pour le contenu statique à grande échelle.

Astro supporte-t-il les commentaires WordPress ?

Pas nativement, et honnêtement c'est une fonctionnalité, pas un bug. Les commentaires WordPress sont un aimant à spam qui nécessite une modération constante. Pour les sites Astro, les meilleures options sont : Giscus (utilise GitHub Discussions -- gratuit, pas de suivi, excellent pour les audiences de développeurs), Disqus (l'ancienne valeur sûre, a des annonces sur le niveau gratuit), Commento (axé sur la confidentialité, 5 $/mois), ou une solution personnalisée utilisant une base de données comme Turso ou Supabase avec une route API Astro. Si vous voulez préserver les commentaires WordPress existants, exportez-les et affichez-les comme contenu statique, puis utilisez l'un de ces services pour les nouveaux commentaires.

Astro est-il plus rapide que WordPress ?

C'est même pas la peine de comparer. Un site Astro statique surpassera même l'installation WordPress la plus optimisée car il élimine le goulot d'étranglement fondamental : le traitement côté serveur. WordPress doit exécuter PHP, interroger une base de données, assembler la page et l'envoyer -- pour chaque demande (sauf s'il est mis en cache). Astro pré-construit tout. Vos visiteurs reçoivent du HTML pré-rendu directement à partir d'un nœud de périphérie CDN à proximité. Les améliorations typiques sont 80-90% plus rapide les temps de chargement et 60-80 points d'amélioration de score Lighthouse.

Qu'advient-il de mon admin WordPress et de mon éditeur WYSIWYG ?

Vous perdez le panneau d'administration WordPress. Pour la plupart des développeurs, c'est un soulagement. Vous éditerez des fichiers markdown directement, ce qui est plus rapide et plus portable. Si vous avez des éditeurs de contenu non-techniques qui ont besoin d'une interface visuelle, envisagez l'approche headless : gardez WordPress en fonctionnement comme un backend de contenu et utilisez Astro comme le frontend. Ou appairez Astro avec un CMS headless comme Sanity, Contentful, Storyblok, ou Keystatic (qui dispose d'un éditeur basé sur GitHub qui est vraiment agréable). Nos services de développement CMS headless peuvent vous aider à choisir le bon backend de contenu pour votre équipe.

Mon classement Google va-t-il baisser après la migration ?

Ce ne devrait pas être le cas, et dans la plupart des cas, il s'améliore -- mais seulement si vous gérez correctement les redirections. Chaque ancienne URL doit soit encore fonctionner soit 301-rediriger vers son nouvel équivalent. Soumettez votre nouveau sitemap à Google Search Console le même jour que vous lancez. Surveillez le rapport Index Coverage pendant les 30 premiers jours. J'ai vu des sites gagner 15-30% de trafic organique dans les 2-3 mois suivant la migration, purement à cause des améliorations Core Web Vitals, puisque Google utilise les signaux d'expérience de page comme facteur de classement.

Puis-je garder WordPress comme CMS headless et utiliser Astro pour le frontend ?

Oui, et c'est une excellente approche intermédiaire. Vous gardez l'admin et l'expérience de l'éditeur WordPress mais abandonnez entièrement le frontend PHP. Astro récupère le contenu de l'API REST WordPress (ou WPGraphQL) au moment de la compilation et génère des pages statiques. Vous devez toujours héberger WordPress quelque part, donc vous n'économiserez pas sur les coûts d'hébergement, mais vous obtenez tous les avantages de performance du frontend. Pour les équipes fortement investies dans le flux de travail d'édition WordPress, c'est souvent le choix pragmatique.

Ai-je besoin de connaître React ou un framework JavaScript pour utiliser Astro ?

Non. Les composants Astro utilisent un format de fichier .astro qui ressemble à du HTML avec un bloc de script frontmatter. Si vous pouvez écrire du HTML et du CSS, vous pouvez construire un site Astro. Les frameworks JavaScript (React, Vue, Svelte) sont optionnels -- vous ne les utiliseriez que si vous avez besoin de composants interactifs côté client comme un widget de recherche, un formulaire avec validation, ou un carrousel d'images. Pour un blog ou un site marketing, vous pouvez construire le tout sans toucher à React.