WordPress headless: cuándo conviene y cómo cotizo el proyecto

Conoces WordPress, pero el front superó al tema

Lo habitual no es curiosidad técnica. Marketing u operaciones ya usan WordPress, a veces desde hace años o porque acaban de pasarse a él, y nadie quiere aprender otro CMS. WordPress es el CMS más usado de la web, así que es una situación muy común. Al mismo tiempo, el producto pide herramientas a medida, flujos para clientes o varias mini aplicaciones en el navegador, no un sitio corporativo clásico envuelto en un tema.

En WordPress headless, WordPress sigue siendo el back end de contenido en PHP. Un front aparte, normalmente Next.js o React en JavaScript, carga entradas, páginas, tipos personalizados y campos por la API REST en `/wp-json/wp/v2/` y renderiza la experiencia que realmente necesitas. WordPress ya no define el HTML público; define el contenido y gran parte del flujo editorial que tu equipo ya conoce.

Para quién conviene WordPress headless y cuándo es mejor un sitio clásico

Headless compensa su complejidad cuando WordPress debe seguir siendo el sistema editorial pero la experiencia pública es deliberadamente a medida. Si buscas publicar con edición visual y poca lógica de aplicación, un WordPress tradicional es más simple. Revisa diseño web con WordPress para ese camino.

Una aplicación web disfrazada de sitio

Cuando digo una aplicación web disfrazada de sitio, me refiero a flujos con lógica de software: áreas con login, tareas de varios pasos, tableros, configuradores o varias apps pequeñas que comparten contenido y reglas. Por fuera puede parecer marca corporativa, pero el trabajo duro está en la interfaz y las integraciones, no en elegir un demo de tema.

• WordPress para contenido

  Tu equipo sigue con entradas, páginas, tipos y campos en el panel que ya domina. El costo de capacitación suele ser menor que mover la edición a otro CMS.

• Evitar un admin a medida para todo

  WordPress ya trae roles, revisiones y medios. Sumado a la API REST, muchas veces evitas construir otro panel solo para lanzar la parte aplicación.

• Libertad en el front

  No estiras un tema hasta romperlo. Construyes interfaz pensada en las tareas del usuario, con WordPress entregando contenido estructurado.

Esa mezcla puede acercar el lanzamiento más rápido que un CMS nuevo más admin propio, y a veces resulta más barato porque la capa editorial reutiliza WordPress. A veces más barato es el límite honesto: integración, vistas previas y migración pueden dominar el presupuesto.

El stack que uso

La mayoría de las veces elijo Next.js para el front público, o React si el proyecto ya lo estandarizó. La experiencia en navegador es JavaScript; WordPress sigue en PHP como sistema de contenido. Los datos circulan por la API REST de WordPress por defecto. GraphQL existe con plugins como WPGraphQL si un equipo ya lo adoptó; yo sigo con REST salvo una razón concreta para añadir esa capa.

Define el modelo de contenido al inicio: tipos personalizados, taxonomías, campos obligatorios y qué objetos debe listar, filtrar y detallar el front. Cambiar el modelo a mitad de obra afecta plantillas, caché y SEO. Para producto fuera de WordPress compara desarrollo de aplicaciones web e integración de APIs.

Plugins: decídelos antes de construir

Mantener WordPress como back trae ventaja: muchos plugins siguen sirviendo en servidor (SEO, formularios, seguridad, caché en origen, tipos de contenido). El truco es compatibilidad: cierra la lista en el alcance y conecta solo lo que el front necesita, en lugar de replicar cada función del panel.

SEO en un proyecto headless

Los buscadores siguen necesitando HTML limpio, URLs estables y metadatos correctos en el dominio que ve el visitante. Headless no elimina SEO; lo reparte en el código del front. No prometo posiciones; sí me aseguro de que contenido y metadatos aparezcan en el HTML renderizado.

Si usamos Yoast SEO, integro en Next.js o React lo que Yoast ya calcula. En entradas y páginas, Yoast añade `yoast_head` (HTML de head prefabricado) y `yoast_head_json` (datos estructurados) a las respuestas REST. Para URLs arbitrarias está `/wp-json/yoast/v1/get_head?url=`. Título, meta description, canonical, Open Graph y schema pueden ir a páginas renderizadas en servidor o estáticas para que rastreadores los vean sin depender solo del cliente.

Vistas previas y edición

Sin rodeos: headless no da al editor una vista previa en vivo del front a medida desde el block editor. El botón Vista previa en WordPress asume que el tema renderiza el sitio. Al desacoplar, la preview es integración explícita, no un extra gratis.

1. Paso 1

   Los borradores exigen API autenticada

   El contenido no publicado no sale en REST anónimo. Usa contraseñas de aplicación u otro mecanismo acordado para pedir borradores con seguridad.

2. Paso 2

   Draft Mode en Next.js (o equivalente)

   Una ruta protegida con secreto en el front activa draft mode cuando WordPress abre el enlace de preview. Mientras dura, el fetch usa REST autenticado.

3. Paso 3

   Expectativas claras para editores

   Define qué tipos tienen preview, cuánto dura el modo borrador y si el layout coincide con producción. En plantillas tipo app, la preview parcial es común.

Cómo cotizo un proyecto WordPress headless

El precio depende de la complejidad del front y de la aplicación que quieres que usen visitantes o tu equipo, porque ahí está la variable. No cotizamos un tema a medida; cotizamos JavaScript a medida más la profundidad con la que la app lee y escribe WordPress por REST. Cada proyecto lleva cotización fija por escrito antes de empezar.

1. Paso 1

   Envía qué debe hacer la aplicación

   Roles, pantallas, integraciones y pruebas de éxito en lenguaje claro. Wireframes o sitio actual ayudan.

2. Paso 2

   Lista plugins y tipos de contenido

   SEO, formularios, membresía, idiomas y campos. Indica qué debe sobrevivir al salir del tema.

3. Paso 3

   Yo dimensiono front e integración

   Mapeo plantillas, flujos de datos, auth, previews, migración y hosting. Lo desconocido queda como supuesto escrito.

4. Paso 4

   Recibes cotización fija por escrito

   Incluye entregables, exclusiones y qué pide orden de cambio. El trabajo arranca cuando acordamos alcance y cotización.

Agencias pueden entregar bajo su marca con desarrollo web en marca blanca. Para asesoría antes del desarrollo, mira consultor WordPress o externalización WordPress.

Qué enviarme

El camino más rápido a una cotización útil es un brief conciso y restricciones honestas. URLs públicas bastan al inicio; credenciales después de acordar alcance.

Organización y sitio público: {{nombre y URL}}
Por qué headless ahora: {{qué falló o qué debe hacer la app}}
Usuarios y roles: {{visitante, cliente, tareas internas}}
Qué debe quedar en WordPress: {{tipos de contenido, plugins, flujo editorial}}
Expectativas del front: {{Next.js o React, auth, idiomas, referencia de diseño}}
Integraciones: {{CRM, pagos, búsqueda, APIs internas}}
SEO y URLs: {{Yoast u otro, plan de dominio, redirecciones}}
Vistas previas: {{quién revisa borradores y con qué frecuencia}}
Hosting actual: {{host WordPress; preferencia de host front}}
Plazos y límites: {{ventana de lanzamiento, cumplimiento, cadena de aprobación}}