Drupal como plataforma headless: integración con React y Vue.js

Drupal: uno de los mejores CMS headless del mercado

Drupal es, posiblemente, el CMS open source mejor preparado para funcionar como backend headless. Su sistema de tipos de contenido estructurado, la API JSON incluida en el core, y las capacidades avanzadas de permisos y workflows lo hacen ideal para proyectos donde el frontend se construye con React, Vue.js u otro framework JavaScript.

Nota de actualización (julio de 2026): este artículo se publicó a finales de 2023 y lo hemos revisado por completo. La arquitectura que describe sigue siendo válida, pero el ecosistema ha cambiado: Drupal 11 es hoy la versión de referencia, Drupal 10 tiene fin de soporte previsto para diciembre de 2026, Next.js y Nuxt han dado el salto a nuevas versiones mayores, y han aparecido piezas como Drupal CMS y Drupal Canvas que matizan cuándo compensa desacoplar. Hemos actualizado versiones y herramientas, y añadido secciones de seguridad, SEO, experiencia editorial y errores comunes.

JSON:API en el core

Desde Drupal 9, el módulo JSON:API viene incluido en el core. Expone automáticamente todos los tipos de contenido, taxonomías, usuarios, archivos y campos personalizados como endpoints REST siguiendo la especificación JSON:API. Esto significa que al crear un tipo de contenido en Drupal, automáticamente tienes un endpoint API listo para consumir desde tu frontend.

Esto sigue siendo el gran diferencial de Drupal frente a otros CMS: no hay que instalar ni mantener un plugin de API, ni pagar por asientos de desarrollador. La API es parte del producto, se versiona con el core y hereda el sistema de permisos por rol. Para necesidades más específicas, el módulo contribuido de GraphQL permite definir un esquema a medida, y el core incorpora desde hace tiempo utilidades pensadas para desacoplar, como los menús vía API (decoupled menus). En proyectos donde el frontend necesita datos agregados de varios orígenes, es habitual combinar JSON:API con una capa fina de integraciones hacia CRMs, analítica y sistemas externos que resuelve el backend, no el navegador.

Integración con React

Para proyectos con React, la combinación más popular es Drupal + Next.js usando el módulo next-drupal. Este módulo proporciona funciones helper para consultar la API de Drupal, manejar previsualizaciones de contenido no publicado, y generar rutas estáticas automáticamente. Next.js con ISR (Incremental Static Regeneration) permite tener rendimiento estático con contenido dinámico.

En 2026 esta recomendación no solo se mantiene: se ha consolidado. next-drupal sigue siendo el punto de partida de facto para React, con soporte para el App Router de Next.js, previsualización de borradores mediante Draft Mode y revalidación bajo demanda (el contenido publicado en Drupal invalida la página estática correspondiente sin esperar al siguiente ciclo de regeneración). El patrón que mejor funciona en producción es generar estáticamente las páginas de contenido (SSG/ISR) y reservar el renderizado en servidor (SSR) para las rutas que dependen del usuario, como áreas privadas o buscadores con filtros.

Integración con Vue.js

Para Vue.js, Nuxt.js es el framework recomendado. El módulo drupal-ce (Custom Elements) permite renderizar contenido de Drupal como Web Components que Nuxt consume directamente. Alternativamente, puedes usar la JSON:API directamente con composables de Nuxt 3 para una integración más personalizada.

Aquí sí ha habido un cambio de versión importante: Nuxt 4 es estable desde julio de 2025 y a mediados de 2026 va por la rama 4.5, con mejoras en la captura de datos (composables useFetch y useAsyncData más predecibles), nueva estructura de directorios y mejor rendimiento del servidor de desarrollo. Un dato relevante si tienes un proyecto en marcha: Nuxt 3 termina su mantenimiento a finales de julio de 2026, así que cualquier frontend Vue sobre Drupal que siga en Nuxt 3 debería planificar la migración ya, igual que se planifica una actualización mayor de Drupal.

Qué ha cambiado en Drupal desde finales de 2023

Cuando se publicó este artículo, Drupal 10 era la versión de referencia y Drupal 11 ni siquiera tenía fecha. En julio de 2026 el mapa es otro: Drupal 11 es estable desde 2024 y va por la rama 11.4, Drupal 12 está previsto para diciembre de 2026, y Drupal 10 alcanza su fin de vida el 9 de diciembre de 2026. Si tu backend headless sigue en Drupal 10 (o peor, en 9), conviene leer nuestra guía de migración y actualización de versiones de Drupal y mover ficha este año: un backend sin parches de seguridad es un riesgo mayor en headless, porque su API está expuesta a internet.

La otra novedad es estratégica. La iniciativa Drupal CMS (Starshot) y el editor visual Drupal Canvas (antes Experience Builder) han reforzado la vía «Drupal con frontend propio»: hoy se pueden montar páginas visualmente ricas sin desacoplar, con componentes reutilizables y sin escribir un frontend aparte. Esto no invalida el headless, pero sube el listón de cuándo compensa: si tu motivación era solo «una web más moderna», Canvas probablemente lo resuelve con la mitad de coste. El headless gana cuando hay múltiples canales de consumo (web, app, kioscos, terceros) o requisitos de frontend que un theme no cubre.

Ventajas de Drupal como headless CMS

Frente a alternativas como Contentful, Strapi o Sanity, Drupal ofrece: sin costes de licencia, sin límites de contenido o usuarios, sistema de permisos granular, workflows de publicación avanzados (módulo Content Moderation), revisiones de contenido nativas, y una comunidad enorme con décadas de experiencia en gestión de contenido.

Consideraciones y limitaciones

El principal inconveniente es la complejidad de mantenimiento del backend Drupal comparado con un CMS headless SaaS. Necesitas servidor, actualizaciones, backups y un equipo que conozca PHP/Drupal para el backend. Si tu equipo es puramente frontend, un CMS headless SaaS como Contentful puede ser más práctico aunque más caro a escala.

A esa complejidad se suma la del propio desacople: en headless mantienes dos stacks (PHP/Drupal y Node/JavaScript), dos pipelines de despliegue y dos superficies de error. Es un coste estructural que hay que presupuestar desde el día uno, tanto en horas de desarrollo como en el mantenimiento continuo de la plataforma.

Autenticación y seguridad de la API

Al desacoplar, la API de Drupal pasa a estar expuesta públicamente, y eso convierte su seguridad en un tema de primer orden. Las reglas básicas: para contenido público, limita JSON:API a solo lectura (hay una opción de configuración para deshabilitar las operaciones de escritura) y expón únicamente los recursos que el frontend consume. Para operaciones autenticadas, usa OAuth 2 con el módulo Simple OAuth y aplica mínimo privilegio: el usuario de la API del frontend no necesita permisos de administración, solo los de lectura (y escritura puntual) que exija la funcionalidad.

Configura CORS de forma restrictiva (solo los orígenes de tus frontends, no un asterisco), añade rate limiting en el proxy o CDN para frenar scraping y fuerza HTTPS extremo a extremo. Los errores clásicos de APIs — como las referencias directas a objetos sin control de autorización (BOLA, el número uno del OWASP API Security Top 10) — aplican igual a un Drupal desacoplado; los repasamos en nuestra guía de seguridad en APIs REST: autenticación, rate limiting y buenas prácticas. Y si tu organización quiere formalizar estos controles dentro de un marco reconocido, la certificación ISO 27001 es el camino natural: el inventario de APIs, el control de accesos y las pruebas periódicas — idealmente con un pentesting anual — forman parte de sus controles.

SEO y rendimiento: lo que headless no te regala

Un mito frecuente es que desacoplar mejora automáticamente el SEO y la velocidad. No es así: lo que hace es trasladarte la responsabilidad. Las metaetiquetas, los datos estructurados, el sitemap y las redirecciones 301 que el theme de Drupal resolvía ahora deben renderizarse en el servidor del frontend (SSR o SSG); si el contenido crítico solo aparece tras ejecutar JavaScript en el cliente, el posicionamiento sufrirá. El módulo Metatag sigue siendo la fuente de datos, pero el frontend tiene que consumirlo y pintarlo.

En rendimiento, un frontend Next.js o Nuxt bien hecho puede volar — HTML estático servido desde CDN — pero también puede hundirse con hidratación excesiva y JavaScript innecesario, penalizando métricas como INP. Las técnicas de caché del propio Drupal siguen importando para la API (Varnish o el propio page cache cachean respuestas JSON igual que HTML); lo explicamos en detalle en la guía de optimización de rendimiento en Drupal: caché, BigPipe y Varnish. La regla práctica: mide Core Web Vitals antes y después de desacoplar; si empeoran, el problema no es Drupal.

Experiencia editorial y previsualización

El coste oculto del headless clásico es el editor de contenidos: pierde la previsualización nativa («guardar y ver») porque la página ya no la pinta Drupal. Resolverlo exige trabajo explícito: con next-drupal, el Draft Mode de Next.js permite previsualizar borradores y revisiones de Content Moderation en el frontend real; en Nuxt se consigue con rutas de previsualización equivalentes. Presupuesta esta pieza siempre — un equipo editorial que no puede previsualizar acaba publicando «a ciegas» o pidiendo capturas al equipo de desarrollo.

También conviene decidir qué páginas edita quién: una arquitectura híbrida (Drupal renderiza las páginas corporativas, el frontend JavaScript las vistas de producto o la app) suele dar mejor equilibrio entre autonomía editorial y flexibilidad técnica que un desacople total. Para organizaciones con varias webs sobre un mismo Drupal, esta decisión se cruza además con la de multisite: se puede desacoplar solo uno de los sitios sin tocar el resto.

Errores comunes al desacoplar Drupal

Los que más vemos en auditorías de proyectos headless:

1. Desacoplar sin necesidad. El frontend JavaScript se eligió por moda y el proyecto solo necesitaba un theme moderno. Resultado: el doble de coste para el mismo resultado visible.

2. Olvidar las redirecciones y los errores 404. El módulo Redirect gestiona las 301 en Drupal, pero si el frontend no las consulta (o no las prerenderiza), las URLs antiguas se pierden y el SEO se resiente.

3. API abierta de par en par. JSON:API con escritura habilitada, CORS con asterisco y sin rate limiting. Funciona… hasta que alguien lo encuentra.

4. Ignorar la caché de la API. Cada visita dispara decenas de peticiones JSON sin cachear y el backend se satura con la mitad de tráfico que aguantaba el theme clásico.

5. No presupuestar la previsualización editorial. Se entrega el frontend «bonito» y a la semana el equipo de contenidos descubre que no puede ver un borrador antes de publicarlo.

¿Cuándo elegir Drupal headless?

Drupal headless es ideal cuando necesitas un backend de contenido potente y personalizable sin costes de licencia recurrentes, cuando tienes un equipo backend PHP/Drupal, cuando necesitas workflows de publicación complejos, o cuando el volumen de contenido haría que un CMS SaaS fuera prohibitivamente caro.

Si estás valorando el paso, tenemos una guía específica con un checklist de decisión en cinco preguntas: Drupal headless: cuándo desacoplar el frontend y cómo hacerlo bien. Y como referencia de lo que Drupal aporta como plataforma corporativa (desacoplada o no), puedes ver el caso de Alfil Logistics (Grupo Damm), donde el peso recayó precisamente en los puntos fuertes del backend: contenido estructurado, permisos y fiabilidad.

Hosting y despliegue: dónde vive cada pieza

En un Drupal clásico todo vive en el mismo servidor; en headless hay que decidir dónde se aloja cada mitad. El backend Drupal sigue necesitando un hosting PHP con base de datos — un VPS bien dimensionado, un proveedor especializado o infraestructura propia — con sus backups, su firewall y su ciclo de parches. El frontend, en cambio, encaja de forma natural en plataformas de despliegue de aplicaciones JavaScript (Vercel, Netlify, Cloudflare) o en un Node gestionado por tu equipo, con la CDN delante sirviendo el HTML estático.

Dos consejos de operación que evitan sustos. Primero, trata los despliegues como independientes pero coordinados: un cambio de esquema en Drupal (un campo renombrado, un tipo de contenido nuevo) puede romper el frontend si este se despliega después; conviene versionar los cambios de API y desplegar el consumidor antes que el productor cuando algo deja de ser compatible. Segundo, monitoriza las dos piezas por separado — tiempos de respuesta de la JSON:API por un lado y métricas de usuario real del frontend por otro — porque un incidente puede vivir solo en una de las mitades y los síntomas aparecer en la contraria. Este doble plano de operación es precisamente lo que se presupuesta mal cuando se compara headless con un Drupal tradicional: no es solo desarrollar dos stacks, es operarlos, actualizarlos y vigilarlos durante toda la vida del proyecto.

Preguntas frecuentes

¿Sigue siendo buena idea Drupal headless en 2026?

Sí, cuando hay una razón de arquitectura: varios canales consumiendo el mismo contenido, un frontend con requisitos que un theme no cubre, o equipos frontend y backend separados. Si la motivación es solo estética, opciones como Drupal Canvas dentro del propio Drupal resuelven más barato.

¿Next.js o Nuxt?

Técnicamente ambos están a la altura. Decide por tu equipo: si ya hay React en la empresa, next-drupal es el camino más trillado y mejor documentado; si el equipo viene de Vue, Nuxt 4 ofrece una curva más suave. Cambiar de framework a mitad de proyecto es mucho más caro que elegir «el segundo mejor» desde el principio.

¿Qué versión de Drupal necesito para headless?

Cualquier Drupal soportado sirve (JSON:API está en el core desde Drupal 8.7), pero en 2026 lo razonable es estar en Drupal 11: Drupal 10 deja de recibir parches en diciembre de 2026, y una API pública sin soporte de seguridad no es aceptable.

¿El headless mejora el SEO?

Por sí mismo, no. Con SSR/SSG bien hecho, metas y sitemap servidos en servidor y redirecciones respetadas, iguala o mejora al theme clásico. Con renderizado solo en cliente, lo empeora. El SEO no depende de desacoplar, sino de cómo se desacopla.

¿Puedo desacoplar solo una parte de la web?

Sí, y suele ser la mejor opción: el patrón «progressively decoupled» mantiene Drupal renderizando la mayor parte del sitio e incrusta componentes JavaScript donde aportan valor (configuradores, buscadores, dashboards). Reduce coste y riesgo frente al desacople total.

Conclusión

Drupal llega a 2026 como uno de los backends headless más sólidos del mercado: JSON:API en el core, permisos y workflows de nivel empresarial, y cero licencias. Lo que ha cambiado es el contexto — Drupal 11 como versión de referencia, Nuxt 4 y un Next.js maduro en el frontend, y alternativas como Canvas que hacen innecesario desacoplar en proyectos puramente web. La decisión correcta pasa por una pregunta de arquitectura (¿cuántos canales consumen tu contenido?) y por presupuestar honestamente los dos stacks, la seguridad de la API y la experiencia editorial. Si eso cuadra, la combinación Drupal + React/Vue es una base excelente para años.