Vous créez un backend WordPress pour une application Lovable en gardant WordPress comme source de contenu et en l’exposant à l’application, soit via l’API REST de WordPress, soit en exportant un contenu propre que l’application consomme. L’idée de fond est une séparation : WordPress reste l’endroit où vous écrivez et gérez pages, articles, médias et métadonnées, et l’application n’est que la façade qui les affiche. Vous gardez ainsi l’éditeur que votre équipe connaît, sans renoncer au frontend que vous voulez construire. Le travail consiste à préparer le contenu pour qu’il sorte proprement : du Markdown structuré, une hiérarchie de sections, la carte des routes et la parité des métadonnées. Et si l’application remplace des pages déjà indexées, gardez les URLs ou posez des redirections 301. WPBuildAI analyse le site et livre le contenu prêt pour l’application : Markdown propre, carte des routes et métadonnées.

Deux façons de brancher WordPress derrière l’application

Il y a deux montages, et le choix dépend de la fraîcheur du contenu dont vous avez besoin. Le premier est WordPress en mode headless : l’application lit le contenu en direct via l’API REST, donc une modification dans WordPress apparaît aussitôt côté application. Le second est l’export : vous sortez le contenu une fois, en Markdown propre, et l’application le consomme comme des fichiers. Le headless convient quand le contenu change souvent et que l’éditeur doit publier en continu ; l’export convient quand le contenu est plutôt stable et que vous préférez un frontend sans dépendance à WordPress en production. Les deux gardent WordPress comme source.

Option 1 : WordPress headless via l’API REST

En headless, WordPress n’affiche plus de pages : il sert seulement le contenu en données. L’API REST de WordPress expose pages, articles, médias et champs sous forme de JSON, que l’application va lire pour construire ses écrans. L’éditeur continue d’écrire dans WordPress comme avant, et l’application affiche la version à jour. C’est le montage décrit dans connecter un constructeur IA à l’API WordPress headless et proche de garder le backend WordPress avec un frontend IA. Le point d’attention est la disponibilité : si l’API tombe, l’application n’a plus de contenu, donc elle doit être hébergée et surveillée comme un service.

Option 2 : exporter le contenu propre

Si vous préférez que l’application ne dépende pas de WordPress en production, exportez le contenu une fois. Vous sortez chaque page et article en Markdown propre, avec ses images et ses métadonnées, et l’application les consomme comme des fichiers, sans appel réseau à WordPress. C’est plus simple à héberger et plus robuste, parce qu’il n’y a pas d’API à maintenir en ligne. Le compromis est la fraîcheur : pour mettre à jour le contenu, vous ré-exportez. C’est le bon choix pour un site vitrine ou un blog dont le contenu ne change pas toutes les heures, et il évite de faire tourner WordPress juste pour servir des données.

Ce qu’il faut préparer pour que ça sorte proprement

Quel que soit le montage, le contenu doit sortir structuré, pas en bloc de HTML. Préparez quatre choses :

  • Markdown propre : le texte sans le balisage du thème, avec ses titres et ses listes.
  • Hiérarchie des sections : quel titre contient quoi, pour que l’application recompose la mise en page.
  • Carte des routes : quelle ancienne URL devient quel écran de l’application.
  • Parité des métadonnées : titres, descriptions et balises portés un à un.

Le Web Almanac 2024 (HTTP Archive) rappelle le poids des médias dans une page, donc traitez les images comme du contenu à exporter, pas comme un détail.

Garder les URLs et le référencement

Si l’application remplace un site déjà en ligne, la question du référencement se pose. Gardez les mêmes URLs partout où c’est possible, pour que les pages indexées ne bougent pas. Pour celles qui changent d’adresse dans l’application, posez une redirection 301 de l’ancienne URL vers le nouvel écran, en un seul saut, selon le guide sur le déplacement avec changement d’URL et la documentation sur les redirections. Sans cela, le contenu est peut-être bien servi par l’application, mais aux mauvaises adresses, et le trafic chute. La carte des routes sert justement à ne pas oublier ces redirections.

Les limites à connaître

Ce montage a des limites qu’il vaut mieux connaître d’avance. Les fonctions dynamiques de WordPress (formulaires, commentaires, recherche, espace membre) ne suivent pas toutes seules : en headless, l’application doit les reconstruire ou les remplacer par un service. Les plugins qui injectaient du HTML dans les pages n’agissent plus, donc ce qu’ils ajoutaient doit être repensé côté application. Et l’aperçu en direct de l’éditeur ne reflète plus le rendu réel, puisque c’est l’application qui affiche. Aucune de ces limites n’est bloquante, mais elles demandent une décision consciente, page par fonction, plutôt qu’une découverte après la mise en ligne.

Étapes

  1. Choisissez le montage : headless via l’API REST, ou export propre.
  2. Faites l’inventaire des pages, articles, médias et métadonnées.
  3. Préparez le contenu : Markdown, hiérarchie, carte des routes.
  4. Branchez l’application sur l’API ou importez les fichiers.
  5. Gardez les URLs ou posez des 301 pour celles qui changent.
  6. Vérifiez la parité des métadonnées et renvoyez le sitemap.

Exemple : une vitrine Lovable sur un fond WordPress

Prenons une équipe qui veut une vitrine construite dans Lovable mais qui tient à garder WordPress pour rédiger. Le contenu change peu, donc elle choisit l’export plutôt que le headless. Le site est analysé : 60 pages sortent en Markdown propre, avec leur hiérarchie de sections, leurs images et leurs métadonnées, plus la carte des routes ancienne URL vers nouvel écran. L’application Lovable consomme ces fichiers, et l’équipe continue d’écrire dans WordPress, ré-exportant à chaque mise à jour. Les URLs indexées sont conservées, et les rares qui changent reçoivent une 301. La vitrine est neuve, le backend rédactionnel reste WordPress, et le référencement ne bouge pas.

Les erreurs à éviter

  • Sortir le contenu en bloc de HTML au lieu de Markdown structuré.
  • Choisir le headless pour un contenu stable, et maintenir une API inutilement.
  • Oublier que formulaires et espace membre ne suivent pas en headless.
  • Laisser les URLs indexées changer sans redirection 301.
  • Exporter le texte mais oublier les images et les métadonnées.

Ce qu’il faut retenir

Vous créez un backend WordPress pour une application Lovable en gardant WordPress comme source de contenu, exposée à l’application via l’API REST ou un export propre. WordPress reste le CMS où vous écrivez, l’application n’est que la façade. Choisissez le headless si le contenu change souvent, l’export s’il est stable, et préparez dans les deux cas du Markdown propre, la hiérarchie des sections, la carte des routes et la parité des métadonnées. Gardez les URLs indexées ou posez des 301 pour celles qui changent. WPBuildAI analyse le site et livre le contenu prêt pour l’application : Markdown propre, carte des routes et métadonnées. Envoyez l’adresse de votre site pour une analyse gratuite.

Sans affiliation avec WordPress, Lovable, Webflow, Shopify, Wix ou Squarespace.