Servicio

Headless CMS: contenido vía API, velocidad en estático

Next.js + Payload, Sanity o Strapi. Un enfoque JAMstack: el editor edita el contenido y el sitio sirve páginas estáticas desde nodos edge. Cuándo compensa y cuándo le diremos con franqueza que es excesivo.

Con franqueza

Headless CMS es la opción correcta para unos casos y excesiva para otros

Cuándo headless CMS es la opción correcta

  • Un mismo contenido y muchos «escaparates»: un sitio web, una aplicación móvil, una pantalla en sala, una plantilla de email. Un CMS API-first sirve el mismo contenido a todos los canales a la vez.
  • Necesita velocidad máxima: páginas estáticas en una CDN, LCP < 1.0s, Lighthouse 95+. En sitios con mucho tráfico donde el SEO es crítico, la diferencia se nota.
  • El equipo es técnico y quiere control total del stack: TypeScript de extremo a extremo, CI/CD y estructuras de datos que ustedes diseñan a su medida.
  • Contenido complejo con relaciones: productos → categorías → autores → etiquetas, un modelo relacional diseñado en torno a su contenido.
  • Seguridad: el panel de administración en un dominio aparte o tras autenticación, el frontend solo estático y la superficie de ataque al mínimo.

Cuándo headless es excesivo

  • Un sitio corporativo pequeño donde una sola persona actualiza el contenido una vez por semana: WordPress o Tilda se lanzan antes y son más baratos de mantener.
  • Presupuesto ajustado y plazos cortos: headless exige más tiempo de arquitectura y más competencia técnica.
  • No hay equipo técnico para el mantenimiento: Payload y Next.js no son de «instalar y olvidarse»; hace falta un desarrollador para actualizaciones y ampliaciones.
  • Una landing sencilla o un sitio de presentación: un stack más simple da el mismo resultado por menos. Si su proyecto está en el límite, se lo diremos en la llamada; no vendemos un stack más pesado donde no hace falta.

Qué incluye un proyecto headless

  • Arquitectura de colecciones de Payload en torno al modelo de contenido del cliente. Tipos de TypeScript desde el primer día.
  • Frontend en Next.js: SSG / ISR / SSR según el tipo de página. Despliegue en edge: Vercel o Cloudflare.
  • Localización uk + ru a nivel de Payload (campos localized: true donde haga falta).
  • Capa SEO: meta, canonical, hreflang, og:image, schema.org, generados automáticamente a partir de las colecciones. El sitemap y el robots.txt se generan al publicar.
  • Core Web Vitals: LCP < 1.5s, CLS < 0.05, INP < 150ms, medidos antes del lanzamiento.
  • Migración de contenido desde un sitio antiguo o WordPress (si hace falta).
  • Panel de Payload: pestañas, vista previa en vivo, borradores, generación automática de slugs: un editor no técnico puede trabajar sin un desarrollador.
  • Documentación de mantenimiento: colecciones de Payload, hooks, procedimiento de despliegue.
Nuestro stack headless
  • Next.js 15
  • Payload CMS 3
  • Sanity
  • Strapi
  • TypeScript
  • Tailwind CSS
  • GSAP
  • PostgreSQL
  • Vercel
  • Cloudflare

Casos de éxito

Este sitio funciona con Next.js + Payload. Aquí tiene más proyectos sobre el stack headless

Todos los casos

Cómo trabajamos

Primero la arquitectura, después el código — así construimos un sitio headless

  1. Llamada de arquitectura

    30 minutos: analizamos la tarea y decidimos si headless es la opción correcta aquí. Si no lo es, se lo decimos de entrada y proponemos un stack más simple. Resultado: una decisión de stack + una horquilla aproximada.

  2. Arquitectura de contenido

    Esquema de colecciones de Payload, relaciones entre entidades, campos de localización. Tipos de TypeScript desde el primer día. Resultado: un diagrama entidad-relación + un borrador de esquema de Payload + una estructura de panel acordada.

  3. Diseño y frontend

    Maquetas en Figma → componentes de Next.js → Storybook (opcional). Despliegue en staging tras cada sprint. Resultado: maquetas finales + un sistema de diseño + un precio cerrado.

  4. Integraciones y contenido

    Conectamos las API (pago, CRM, analítica) y migramos o cargamos el contenido a través del panel de Payload. Resultado: un sitio completamente cargado en staging + todas las integraciones.

  5. Rendimiento y lanzamiento

    Lighthouse CI, comprobación de Core Web Vitals, configuración edge. Redirecciones desde el sitio antiguo, GSC, analítica. Resultado: un sitio en vivo + Lighthouse ≥ 90 Mobile + documentación + 30 días de soporte.

Preguntas frecuentes

Headless — preguntas sobre arquitectura y presupuesto

Hablemos

En 30 minutos con un desarrollador sabrá si headless merece la pena

  • 30 minutosReunión individual
  • Formato flexibleVídeo o llamada
  • Enfoque en solucionesRespuestas prácticas
¿Dónde le contactamos?

Sus datos están protegidos y no se comparten con terceros.

En detalle

Headless CMS y JAMstack en Next.js, Payload, Sanity o Strapi — cuándo es la opción correcta

Un CMS headless es un enfoque en el que el backend (el almacén de contenido y la API) está separado del frontend (lo que ve el usuario). El contenido se edita en el panel, se sirve vía API y el frontend en Next.js construye páginas estáticas o dinámicas. De ahí dos ventajas: la velocidad del estático y que el mismo contenido se sirve a un sitio web, una aplicación móvil y una pantalla de showroom.

Pasamos a un stack headless para nuestro propio desarrollo no porque «esté de moda», sino porque el trabajo lo exigía. Este sitio, apri-code.com, es Next.js 15 + Payload CMS 3 + PostgreSQL. Mantenemos la velocidad dentro de un presupuesto de rendimiento estricto y la medimos antes de cada lanzamiento. El contenido se edita en el panel de Payload sin nada de HTML. La localización uk + ru va integrada a nivel de campo. Es nuestro propio stack de producción.

Payload CMS es nuestra opción principal para proyectos headless a medida. Código abierto, Node.js + TypeScript, integrado en Next.js. Frente a Sanity, no hay dependencia de un servicio alojado ni cuotas SaaS mensuales por elemento de contenido. Frente a Strapi, el tipado va de extremo a extremo, del esquema al frontend. Para proyectos donde importa un editor colaborativo en tiempo real alojado, Sanity también es la opción correcta. Para proyectos con roles complejos y varios equipos, Strapi. Usamos los tres, según la tarea del cliente.

JAMstack en 2026 significa aplicaciones web con lógica compleja, no solo sitios estáticos de presentación: las páginas públicas se sirven como estático y las zonas autenticadas como SSR o RSC. Un CMS headless encaja de forma natural en esta arquitectura: una tienda online con páginas de producto estáticas y un carrito dinámico, una plataforma educativa con materiales de curso estáticos y un área personal dinámica. Desarrollo de aplicaciones web →

Un apunte sobre SEO. Las páginas estáticas en una CDN mantienen de forma estable el LCP < 1.5s, y la velocidad es una de las señales que Google tiene en cuenta en el posicionamiento. Para páginas comerciales es una ventaja, no un detalle. Nuestra capa SEO va integrada en el stack: meta, canonical, hreflang, og:image y schema.org se generan a partir de las colecciones de Payload automáticamente al publicar.

Headless no siempre compensa. Un sitio corporativo pequeño de menos de 20 páginas: WordPress o un stack más simple da el mismo resultado más barato y más rápido de lanzar. Presupuesto y plazos ajustados: headless necesita más tiempo de arquitectura. Un equipo sin un desarrollador técnico para el mantenimiento: Payload y Next.js no son de «instalar y olvidarse». Donde headless no hace falta, se lo diremos con franqueza y propondremos otro stack. Hablemos de su tarea: en 30 minutos quedará claro si headless es la opción correcta aquí.WordPress — cuando es más simple →