En una arquitectura headless, WordPress gestiona el contenido pero la web que ve el usuario se construye con otra tecnología que consume su API. Ofrece flexibilidad y rendimiento, a cambio de más complejidad. No es la respuesta para todos los proyectos.
Qué cambia respecto a un WordPress tradicional
| Aspecto | Tradicional | Headless |
|---|---|---|
| Quién muestra la web | El tema de WordPress | Una aplicación aparte |
| Edición del contenido | En WordPress | En WordPress |
| Plugins visuales | Funcionan | Muchos no aplican |
| Equipo necesario | WordPress | WordPress y desarrollo web moderno |
| Mantenimiento | Un sistema | Dos sistemas |
Casos en que puede tener sentido
- Sitios con requisitos de rendimiento muy exigentes.
- Contenido que se publica en varios canales (web, app, pantallas).
- Equipos con desarrolladores front-end consolidados.
- Proyectos con interfaz muy a medida.
Casos en que probablemente no
- Sitios de servicios o pequeñas empresas.
- Clientes que quieren editar el diseño sin desarrolladores.
- Presupuestos y plazos ajustados.
- Equipos sin experiencia en la arquitectura.
Riesgos para el SEO
Al renderizar contenido en el cliente, debes asegurar que Google pueda ver el contenido, que las URLs, títulos y datos estructurados se generen correctamente y que las vistas previas funcionen. Planifica pruebas de rastreo. Mira JavaScript y SEO: qué revisar y SEO en sitios estáticos, Astro y Jamstack.
En resumen
- Casos en que puede tener sentido: Sitios con requisitos de rendimiento muy exigentes.; Contenido que se publica en varios canales (web, app, pantallas).
- Casos en que probablemente no: Sitios de servicios o pequeñas empresas.; Clientes que quieren editar el diseño sin desarrolladores.
- Riesgos para el SEO: Al renderizar contenido en el cliente, debes asegurar que Google pueda ver el contenido, que las URLs, títulos y datos estructurados se generen correctamente y que las vistas previas funcionen.
Preguntas frecuentes
¿Headless es más rápido siempre?
Puede serlo, pero depende de la implementación; no es automático.
¿El cliente puede seguir usando el editor?
Sí, aunque la vista previa y algunos plugins pueden requerir adaptación.
¿Cuánto mantenimiento añade?
El de dos sistemas; planifícalo en la propuesta.
¿Es más seguro que un WordPress tradicional?
Reduce la superficie expuesta al público, pero el panel y la API siguen necesitando protección.