WordPress Headless : créer un site moderne avec WordPress et React

Dans une architecture « headless », WordPress ne s’occupe plus que d’une chose : gérer les contenus. L’affichage (la « tête ») est confié à une autre application, souvent écrite avec React. Les équipes conservent l’interface d’administration que leurs rédacteurs connaissent, tout en profitant d’un front moderne, rapide et sur mesure.

Cette approche séduit, mais elle n’est pas toujours la bonne. Voici comment elle fonctionne, comment la mettre en place avec Next.js, et quels points surveiller, notamment pour le référencement. Pour comprendre pourquoi le SEO exige une vigilance particulière dans ce cas, lisez aussi notre article sur le SEO et l’IA.

1. Ce que signifie « headless »

Dans un WordPress classique, le thème récupère les contenus et fabrique les pages HTML. En mode headless, WordPress sert uniquement d’API : les contenus sont lus par une application indépendante, qui les affiche comme elle le souhaite. L’administration reste inchangée, mais la partie publique est une application distincte.

Cette séparation permet de réutiliser les mêmes contenus sur plusieurs supports : un site web, une application mobile, un écran d’affichage, une newsletter. Elle offre aussi une liberté totale de conception et de performance, puisque le front peut utiliser n’importe quelle technologie moderne.

En contrepartie, tout ce qu’un thème gère automatiquement doit être reconstruit : les menus, la recherche, les commentaires, les formulaires, l’aperçu des brouillons, le SEO, le cache. Il faut donc en peser l’intérêt.

2. Quand choisir (ou éviter) cette architecture

Le headless est pertinent pour un site très interactif, un média à fort trafic, une application qui exploite des contenus WordPress, ou une équipe de développeurs à l’aise avec React. Il l’est aussi quand le même contenu alimente plusieurs canaux.

Il est inutile, voire contre-productif, pour un petit site vitrine ou un blog personnel : un thème de blocs léger, bien hébergé et bien mis en cache, offre d’excellentes performances sans la complexité d’un second projet à développer, héberger et maintenir. Vous perdez en outre la compatibilité immédiate avec de nombreuses extensions qui agissent sur l’affichage.

3. REST ou WPGraphQL : choisir l’API

WordPress propose nativement l’API REST, simple et prête à l’emploi. Elle suffit pour la plupart des sites, avec les paramètres _embed et _fields pour limiter le nombre de requêtes et le volume de données. Son inconvénient : on récupère souvent plus de champs que nécessaire, ou l’on doit enchaîner plusieurs appels.

WPGraphQL est une extension gratuite qui expose un point d’accès GraphQL. Le client décrit exactement les données voulues dans une seule requête : un article, son auteur, ses catégories et son image, sans rien d’autre. Cela convient aux écrans complexes et simplifie le code du front. L’extension demande en revanche l’apprentissage d’un nouveau langage de requête et une configuration soignée des accès.

query DerniersArticles {
  posts( first: 5 ) {
    nodes {
      title
      slug
      date
      featuredImage { node { sourceUrl altText } }
    }
  }
}

Quel que soit votre choix, restreignez ce que l’API expose, mettez les réponses en cache et protégez les routes d’écriture. Notre article sur le blogging en 2026 explique pourquoi la qualité du contenu reste, malgré la technique, le premier moteur de croissance.

4. Mettre en place Next.js avec WordPress

Next.js est le framework React le plus utilisé pour ce type de projet, car il gère le rendu côté serveur, la génération statique et le routage. Créez le projet, puis déclarez l’adresse de votre WordPress dans une variable d’environnement.

npx create-next-app@latest mon-site-headless
cd mon-site-headless
# .env.local
WP_API_URL=https://cms.votresite.fr/wp-json/wp/v2

Une page de liste lit ensuite les articles depuis WordPress. Dans l’App Router de Next.js, un composant serveur peut appeler l’API directement et s’exécuter avant l’envoi de la page au navigateur.

// app/blog/page.jsx
export const revalidate = 300; // régénérer au plus toutes les 5 min

export default async function Blog() {
  const res = await fetch(
    `${process.env.WP_API_URL}/posts?per_page=10&_embed`
  );
  const articles = await res.json();

  return (
    <main>
      <h1>Blog</h1>
      {articles.map( ( a ) => (
        <article key={a.id}>
          <h2>{a.title.rendered}</h2>
          <a href={`/blog/${a.slug}`}>Lire</a>
        </article>
      ) )}
    </main>
  );
}

Une seconde page dynamique (app/blog/[slug]/page.jsx) charge un article par son slug. Utilisez generateStaticParams pour préparer les pages à l’avance, et notFound() quand l’article n’existe pas. Pour afficher le contenu HTML renvoyé par WordPress, nettoyez-le d’abord avec une bibliothèque de filtrage avant de l’injecter dans la page.

5. Choisir le mode de rendu : statique, serveur ou hybride

Le rendu statique (SSG) génère les pages au moment de la construction du site : elles sont servies instantanément depuis un CDN, c’est la solution la plus rapide. Elle convient aux contenus qui changent peu. Le rendu côté serveur (SSR) génère la page à chaque requête : utile pour des données personnalisées ou très fréquentes, au prix d’un temps de réponse plus long.

La régénération incrémentale (ISR) combine les deux : la page est statique, mais elle est reconstruite en arrière-plan à intervalle régulier ou à la demande. Quand un rédacteur publie un article dans WordPress, un webhook peut déclencher la régénération de la page concernée et, éventuellement, des pages de liste.

Dans tous les cas, évitez le rendu uniquement côté navigateur pour les pages que Google doit indexer : le contenu doit se trouver dans le HTML initial. C’est le point le plus important pour le référencement, et il se vérifie avec l’outil d’inspection d’URL de Search Console.

6. Aperçu des brouillons, médias et formulaires

Les rédacteurs veulent voir leurs brouillons avant publication. Dans une architecture headless, il faut donc reconstruire l’aperçu : le bouton « Aperçu » de WordPress pointe vers une route du front qui reçoit un jeton temporaire et charge la version non publiée. Cette partie demande de l’authentification et un peu de travail, mais elle est essentielle pour l’adoption par l’équipe.

Les images doivent rester performantes : le composant Image de Next.js redimensionne et convertit automatiquement les fichiers, à condition d’autoriser le domaine de votre WordPress dans la configuration. Conservez les tailles générées par WordPress comme source et utilisez des textes alternatifs.

Pour les formulaires, envoyez les données vers une route de l’API (une route personnalisée ou une extension de formulaire qui expose l’API), avec contrôle des champs, protection anti-spam et gestion des erreurs. Les commentaires et la recherche demandent un traitement équivalent.

7. SEO en mode headless : ne rien perdre

Le référencement est le point de vigilance numéro un. Les titres, descriptions, balises canonical, données structurées et paramètres Open Graph gérés par votre extension SEO doivent être repris dans le front. Certaines extensions (Yoast, Rank Math) exposent ces données par l’API ou avec WPGraphQL : utilisez-les pour alimenter les métadonnées de chaque page.

Générez aussi un sitemap XML depuis le front, un fichier robots.txt propre, des adresses cohérentes avec celles d’origine et des redirections 301 pour tout changement d’URL. Évitez que le site WordPress d’administration reste indexable sous un autre domaine : sinon, vous créez des doublons. Placez-le en noindex ou protégez-le par authentification.

Pour une boutique en ligne headless, les sujets d’indexation de fiches produits et de catégories sont encore plus sensibles : notre guide sur le SEO technique WooCommerce détaille les points à surveiller.

8. Hébergement, sécurité et coûts

Vous gérez désormais deux applications. WordPress peut rester sur un hébergement WordPress classique, de préférence protégé et accessible uniquement par l’API. Le front React se déploie sur une plateforme dédiée aux applications Next.js, ou sur votre propre serveur avec Node.js.

Sécurisez l’API : limitez l’accès en écriture, activez le HTTPS partout, gardez WordPress et les extensions à jour et ne laissez pas l’administration ouverte à tous. Placez les secrets (mots de passe d’application, jetons) dans des variables d’environnement côté serveur, jamais dans le code du navigateur.

Budgétez enfin la maintenance : deux dépôts de code, deux séries de mises à jour, des tests et un suivi des erreurs. Pour un projet qui le justifie, l’investissement est rentable ; pour les autres, un bon thème de blocs reste la voie raisonnable.

Checklist : projet WordPress headless

Conclusion

Le headless apporte de la liberté, de la performance et la possibilité de réutiliser vos contenus partout, mais il demande plus de développement et de maintenance qu’un WordPress classique. Réservez-le aux projets qui en tirent un vrai bénéfice, et surveillez de près le SEO, l’aperçu et la sécurité. Pour un site plus classique, un thème de blocs bien configuré reste souvent le meilleur choix. Pensez à vérifier que votre site reste visible, avec notre guide des 15 erreurs SEO à éviter.