Séparer WordPress de son interface publique peut servir un projet éditorial ou applicatif, mais ne garantit pas un site rapide. Les guides actuels d’Astro et de Next.js permettent surtout de définir un prototype mesurable avant une migration.
1. Choisir selon le parcours à reconstruire
WordPress conserve contenus, comptes éditoriaux et médias. Un frontend indépendant interroge son API puis produit les pages ; le thème PHP ne les compose plus.
| Besoin principal | Candidat à tester | Travail à prévoir |
|---|---|---|
| Documentation et pages surtout statiques | Astro | Reconstruction après modification |
| Interface React avec parcours dynamiques | Next.js | Exécution serveur et gestion du cache |
| Boutique dépendante de nombreuses extensions | Prototype limité d’abord | Panier, paiement et fonctions du thème |
Astro convient à un essai centré sur le contenu avec peu de JavaScript. Next.js est un candidat naturel si l’équipe maîtrise React et doit gérer des parcours applicatifs. Ce sont des critères de choix, pas un classement de vitesse.
REST est fourni par WordPress ; WPGraphQL ajoute un schéma GraphQL via une extension. REST suffit souvent à une première page. GraphQL permet de demander des champs liés dans une requête, mais ajoute une dépendance et ne supprime ni les coûts SQL ni les contrôles d’accès.
2. Construire une page et son cycle de mise à jour
Commencez par un article public. Cette commande de diagnostic n’utilise aucune clé ; remplacez le domaine :
BASE="https://cms.example.com"curl --fail --get "$BASE/wp-json/wp/v2/posts" \ --data-urlencode "slug=guide-test" \ --data-urlencode "_fields=id,slug,title,content"Vérifiez le titre, les liens, les images et les blocs réellement présents. Le HTML provenant du CMS doit rester soumis à votre politique de confiance et de nettoyage.
Pour Astro statique, reliez une modification éditoriale à un rebuild authentifié. Pour Next.js, définissez explicitement quels contenus sont mis en cache et comment ils sont revalidés ; ne supposez pas que tous les appels sont automatiquement cachés. Testez une correction, une suppression et un échec de reconstruction.
Gardez les prévisualisations privées, authentifiées et hors cache partagé. Un frontend statique nécessite un chemin de prévisualisation distinct ou un rendu à la demande ; Next.js propose Draft Mode, à connecter à l’authentification du CMS.
3. Valider SEO et hébergement avant bascule
Reproduisez titres, descriptions, URL canoniques, redirections, sitemap et données structurées. Une extension SEO côté WordPress ne garantit pas que le frontend restitue ses données. Inspectez le HTML reçu sans JavaScript.
Un export statique peut être servi comme des fichiers. Un rendu serveur exige un runtime compatible, un processus surveillé et les ressources nécessaires ; la présence de cPanel ne garantit pas ces capacités. Sur VPS, placez le serveur applicatif derrière un proxy HTTPS. Plusieurs instances Next.js demandent une stratégie de cache et d’invalidation commune.
Erreurs fréquentes
Migrer toutes les pages avant de tester les blocs, exposer un secret de prévisualisation ou oublier les URL supprimées crée une dette évitable.
FAQ et vérification finale
Headless est-il automatiquement plus rapide ? Non : comparez JavaScript, réponse serveur et interactions sur le même contenu.
Peut-on conserver toutes les extensions ? Les fonctions purement serveur et celles liées au thème doivent être évaluées séparément.
Validez une publication, une prévisualisation, une suppression, un lien ancien et le retour à l’ancien frontend avant de changer le trafic.