Separar el backend de WordPress del frontend para tener lo mejor de ambos mundos
En un WordPress tradicional, el CMS sirve tanto el contenido como la presentación (HTML, CSS, temas). En un enfoque headless, WordPress actúa solo como backend: gestiona el contenido y lo expone mediante una API (REST o GraphQL). El frontend se construye por separado con tecnologías como Astro o Next.js.
// Flujo headless WordPress (CMS) ──API (REST/GraphQL)──► Astro / Next.js (Frontend) ↑ │ │ Editores conocidos │ HTML + CSS + JS │ Gestión de contenido │ Rendimiento moderno └────────────────────────────────────┘
WordPress mantiene su interfaz: editores, medios, páginas y entradas. Los equipos de contenido siguen trabajando como siempre, sin curva de aprendizaje.
Astro y Next.js generan sitios rápidos, optimizados y con buena experiencia de usuario. Carga inicial ligera, navegación fluida y mejor SEO.
El contenido vive en WordPress; la presentación en el frontend. Cambios de diseño no afectan el CMS y viceversa.
output: "export" genera solo HTML, CSS y JavaScript estáticos en build time. Sin servidor Node en producción; se puede hospedar en cualquier hosting estático.fetch y generan HTML estático en build time.Hemos preparado demos con Astro y Next.js: ambos conectan a WordPress vía WPGraphQL, generan HTML/CSS/JS estático y mantienen el CMS conocido por los clientes.
WordPress ├── WPGraphQL (o REST API) ├── Contenido: páginas, posts, media └── Plugin headless (opcional) │ │ HTTPS / JSON ▼ Astro / Next.js ├── Fetch en build (SSG) ├── Componentes UI └── Salida: HTML + CSS + JS estático
Es la opción más usada para headless: una API GraphQL sobre WordPress. Permite pedir solo los campos necesarios en una sola petición, lo que reduce payload y complejidad.