Pular para o conteúdo 
Hai uns meses, un cliente pediunos “unha web headless con WordPress e Next.js”. Cando preguntamos por que headless, a resposta foi: “porque é máis moderno e escala mellor”. Explicámoslle que o seu proxecto —un sitio corporativo informativo con 50 páxinas e un blog— non necesitaba headless, e que a “escalabilidade” que gañaba era insignificante. A complexidade que engadía, enorme. Ao final fixemos WordPress tradicional con Elementor. O proxecto entregouse en 6 semanas. Non 14. Custou a metade. O cliente edita o seu contido só. Non nos chama para cambiar unha coma. Headless WordPress é unha ferramenta poderosa para casos específicos. Pero converteuse nun buzzword que vende proxectos innecesariamente complexos. Saber cando si e cando non aforra diñeiro. E dores de cabeza.
Que é “headless”
WordPress tradicional é “monolítico”: o backend (onde xestionas contido) e o frontend (o que ven os usuarios) están acoplados. Usas temas PHP que xeran HTML directamente.
Headless separa:
-
WordPress é só CMS. Xestiona contido.
-
O frontend é outra aplicación (React, Vue, Next.js). Pide o contido por API.
-
O frontend xera o HTML. WordPress non o ve.
A vantaxe teórica: flexibilidade total no frontend. Rendemento optimizado. Mesmo contido para web, app móbil, pantallas dixitais. O custo real: Dous sistemas que manter. Despregamento máis complexo. Editores de contido sofren. Dependencia técnica enorme.
Cando headless vale a pena?
Despois de anos vendo proxectos headless exitosos e fallidos, estes son os casos onde realmente brilla:
Experiencia multicanle complexa
Necesitas o mesmo contido en web, app móbil nativa, aplicación de escritorio, e quen sabe que máis. WordPress como fonte única de verdade, distribuído por API a todos os frontends. Exemplo: Unha editorial que publica en web, app iOS, app Android, newsletter, e syndication a partners. Headless xustifica o custo. O contido reutilízase de verdade.
Frontend altamente interactivo
Aplicacións onde a experiencia de usuario é máis similar a unha app que a unha web tradicional: transicións complexas, estado de aplicación persistente, interaccións en tempo real. Exemplo: Un configurador de produto 3D con state complexo, onde o usuario pasa 10 minutos interactuando sen recargas de páxina.
Rendemento extremo
Cando cada milisegundo conta e necesitas optimizacións agresivas: xeración estática, edge caching, precarga de rutas. Un frontend moderno (Next.js, Astro) pode facer isto mellor que WordPress PHP tradicional. Exemplo: Un e-commerce de alto volume onde a velocidade de carga impacta directamente en conversión e cada décima de segundo conta.
Equipo técnico especializado
Tes desenvolvedores frontend experimentados en React/Vue e queren aproveitar ese expertise. O custo de que aprendan PHP e temas WordPress é maior que o de manter un frontend separado.
Cando headless é overengineering
Pola contra, estes son casos onde vemos headless vendido inapropiadamente:
“Quero que a web sexa máis rápida”
WordPress ben optimizado (caché, bo hosting, imaxes lixeiras) carga en menos de 1 segundo. O problema case nunca é PHP. É contido pesado ou mala configuración. Antes de headless, audita a túa web lenta. Probablemente non é a arquitectura.
“Quero usar tecnoloxía moderna”
React non é mellor que PHP. É diferente. Para un sitio informativo, PHP con HTML estático funciona. É probado, simple, e calquera desenvolvedor WordPress o mantén.
“Quero que o meu equipo de marketing poida editar”
Ironía: headless adoita facer máis difícil a edición de contido. Os page builders visuais de WordPress (Elementor, WPBakery) non funcionan en headless. O contido edítase en campos estruturados, e o frontend o renderiza. Se o teu equipo de marketing quere “arrastrar e soltar” elementos en páxinas, headless impídello.
Sitios pequenos a medianos
Se tes menos de 500 páxinas, menos de 10.000 visitas diarias, e contido principalmente estático, headless é gastar un canón para matar unha mosca.
Os custos ocultos de headless (que ninguén che conta)
Os vendedores de headless enfatizan beneficios pero minimizan custos. Sé honesto sobre eles: Custo de desenvolvemento. Headless custa 2 ou 3 veces máis que WordPress tradicional. Dous sistemas que integrar. Máis complexidade. Máis puntos de fallo. Custo de mantemento. Actualizacións de seguridade: dous sistemas. Cambios no frontend: necesitas desenvolvedor. Marketing non pode tocar o deseño desde WordPress. Custo de hosting. Necesitas infraestrutura para o frontend (Node.js) + o backend WordPress. Máis complexo. Máis caro. Custo de dependencia técnica. Calquera cambio, por pequeno, necesita un desenvolvedor que entenda todo o stack. Non podes contratar a calquera freelancer de WordPress. Custo de tempo. Headless tarda máis. En desenvolverse, en debuguearse, en lanzarse.
Alternativas híbridas
Non todo é branco ou negro. Hai arquitecturas intermedias: WordPress con frontend estático. Usas WordPress como CMS. Xeras un sitio estático (plugins como Simply Static ou Strattic). Tes a facilidade de edición de WordPress coa velocidade dun sitio estático. Non é headless puro. Captura moitos beneficios sen a complexidade. Next.js con WordPress parcial. Usas Next.js só onde o necesitas (ex: unha app interactiva). O resto, WordPress tradicional. O mellor de ambos mundos. Headless con page builder visual. Algunhas solucións como Frontity ou Gatsby con plugins específicos intentan recuperar a experiencia visual. Funcionan, pero engaden complexidade adicional.
Preguntas frecuentes
¿Headless é máis seguro? Parcialmente. Separar backend e frontend reduce superficie de ataque. Pero engade complexidade e novas vulnerabilidades. Non é máis seguro por si só. Depende de como o implementes. ¿Podo migrar de WordPress tradicional a headless facilmente? Non. Estás reconstruíndo o frontend desde cero. O contido migra. O tema, os page builders e a personalización visual, non. ¿Headless mellora o SEO? Se se fai mal, empeora. Google executa JavaScript, pero un frontend mal feito pode ser invisible. Next.js axuda con SSR, pero engade complexidade. ¿Debería usar GraphQL ou REST API? GraphQL é máis flexible. Para datos complexos. REST é máis simple. Suficiente para casos sinxelos. Depende da complexidade das túas consultas.
Conclusión
Headless WordPress é unha ferramenta lexítima e poderosa para casos específicos. Pero vendérono como solución universal. A maioría das webs corporativas funcionan mellor con WordPress tradicional. A pregunta correcta non é “¿debería usar headless?” senón “¿que problema estou resolvendo, e é headless a forma máis eficiente de resolvelo?”
A pregunta correcta non é “¿debería usar headless?” É: “¿que problema resolvo? ¿é headless a mellor forma?”
Se estás pensando en headless, podemos avalialo xuntos. Ás veces si. Ás veces non. Ás veces unha solución híbrida é mellor. O importante é decidir con información. Non con buzzwords.
— Headless WordPress separa el backend (WordPress como CMS) del frontend (React, Vue, etc.) comunicados por API.
— Tiene sentido para experiencias multicanal complejas, pero es overkill para la mayoría de sitios web corporativos.
— El coste de desarrollo y mantenimiento de headless es significativamente mayor que WordPress tradicional.
Hace unos meses, un cliente nos pidió “una web headless con WordPress y Next.js”. Cuando preguntamos por qué headless, la respuesta fue: “porque es más moderno y escala mejor”. Le explicamos que su proyecto —un sitio corporativo informativo con 50 páginas y un blog— no necesitaba headless, y que la “escalabilidad” que ganaba era insignificante. La complejidad que añadía, enorme.
Al final hicimos WordPress tradicional con Elementor. El proyecto se entregó en 6 semanas. No 14.
Costó la mitad. El cliente edita su contenido solo. No nos llama para cambiar una coma.
Headless WordPress es una herramienta poderosa para casos específicos. Pero se ha convertido en buzzword que vende proyectos innecesariamente complejos. Saber cuándo sí y cuándo no te ahorra dinero. Y dolores de cabeza.
Qué es “headless”
WordPress tradicional es “monolítico”: el backend (donde gestionas contenido) y el frontend (lo que ven los usuarios) están acoplados. Usas temas PHP que generan HTML directamente.
Headless separa:
-
WordPress es solo CMS. Gestiona contenido.
-
El frontend es otra aplicación (React, Vue, Next.js). Pide el contenido por API.
-
El frontend genera el HTML. WordPress no lo ve.
La ventaja teórica: flexibilidad total en el frontend. Rendimiento optimizado. Mismo contenido para web, app móvil, pantallas digitales.
El coste real: Dos sistemas que mantener. Despliegue más complejo. Editores de contenido sufren. Dependencia técnica enorme.
¿Cuándo headless vale la pena?
Después de años viendo proyectos headless exitosos y fallidos, estos son los casos donde realmente brilla:
Experiencia multicanal compleja
Necesitas el mismo contenido en web, app móvil nativa, aplicación de escritorio, y quien sabe qué más. WordPress como fuente única de verdad, distribuido por API a todos los frontends.
Ejemplo: Una editorial que publica en web, app iOS, app Android, newsletter, y syndication a partners. Headless justifica el coste. El contenido se reutiliza de verdad.
Frontend altamente interactivo
Aplicaciones donde la experiencia de usuario es más similar a una app que a una web tradicional: transiciones complejas, estado de aplicación persistente, interacciones en tiempo real.
Ejemplo: Un configurador de producto 3D con state complejo, donde el usuario pasa 10 minutos interactuando sin recargas de página.
Rendimiento extremo
Cuando cada milisegundo cuenta y necesitas optimizaciones agresivas: generación estática, edge caching, precarga de rutas. Un frontend moderno (Next.js, Astro) puede hacer esto mejor que WordPress PHP tradicional.
Ejemplo: Un e-commerce de alto volumen donde la velocidad de carga impacta directamente en conversión y cada décima de segundo cuenta.
Equipo técnico especializado
Tienes desarrolladores frontend experimentados en React/Vue y quieren aprovechar ese expertise. El coste de que aprendan PHP y temas WordPress es mayor que el de mantener un frontend separado.
Cuándo headless es overengineering
Por el contrario, estos son casos donde vemos headless vendido inapropiadamente:
“Quiero que la web sea más rápida”
WordPress bien optimizado (caché, buen hosting, imágenes ligeras) carga en menos de 1 segundo. El problema casi nunca es PHP. Es contenido pesado o mala configuración.
Antes de headless, audita tu web lenta. Probablemente no es la arquitectura.
“Quiero usar tecnología moderna”
React no es mejor que PHP. Es diferente. Para un sitio informativo, PHP con HTML estático funciona. Es probado, simple, y cualquier desarrollador WordPress lo mantiene.
“Quiero que mi equipo de marketing pueda editar”
Ironía: headless suele hacer más difícil la edición de contenido. Los page builders visuales de WordPress (Elementor, WPBakery) no funcionan en headless. El contenido se edita en campos estructurados, y el frontend lo renderiza.
Si tu equipo de marketing quiere “arrastrar y soltar” elementos en páginas, headless se lo impide.
Sitios pequeños a medianos
Si tienes menos de 500 páginas, menos de 10.000 visitas diarias, y contenido principalmente estático, headless es gastar un cañón para matar una mosca.
Los costes ocultos de headless (que nadie te cuenta)
Los vendedores de headless enfatizan beneficios pero minimizan costes. Sé honesto sobre ellos:
Coste de desarrollo. Headless cuesta 2 o 3 veces más que WordPress tradicional. Dos sistemas que integrar. Más complejidad. Más puntos de fallo.
Coste de mantenimiento. Actualizaciones de seguridad: dos sistemas. Cambios en el frontend: necesitas desarrollador. Marketing no puede tocar el diseño desde WordPress.
Coste de hosting. Necesitas infraestructura para el frontend (Node.js) + el backend WordPress. Más complejo. Más caro.
Coste de dependencia técnica. Cualquier cambio, por pequeño, necesita un desarrollador que entienda todo el stack. No puedes contratar a cualquier freelancer de WordPress.
Coste de tiempo. Headless tarda más. En desarrollarse, en debuguearse, en lanzarse.
Alternativas híbridas
No todo es blanco o negro. Hay arquitecturas intermedias:
WordPress con frontend estático. Usas WordPress como CMS. Generas un sitio estático (plugins como Simply Static o Strattic). Tienes la facilidad de edición de WordPress con la velocidad de un sitio estático. No es headless puro. Captura muchos beneficios sin la complejidad.
Next.js con WordPress parcial. Usas Next.js solo donde lo necesitas (ej: una app interactiva). El resto, WordPress tradicional. Lo mejor de ambos mundos.
Headless con page builder visual. Algunas soluciones como Frontity o Gatsby con plugins específicos intentan recuperar la experiencia visual. Funcionan, pero añaden complejidad adicional.
Preguntas frecuentes
¿Headless es más seguro?
Parcialmente. Separar backend y frontend reduce superficie de ataque. Pero añade complejidad y nuevas vulnerabilidades. No es más seguro por sí solo. Depende de cómo lo implementes.
¿Puedo migrar de WordPress tradicional a headless fácilmente?
No. Estás reconstruyendo el frontend desde cero. El contenido migra. El tema, los page builders y la personalización visual, no.
¿Headless mejora el SEO?
Si se hace mal, empeora. Google ejecuta JavaScript, pero un frontend mal hecho puede ser invisible. Next.js ayuda con SSR, pero añade complejidad.
¿Debería usar GraphQL o REST API?
GraphQL es más flexible. Para datos complejos. REST es más simple. Suficiente para casos sencillos. Depende de la complejidad de tus consultas.
Conclusión
Headless WordPress es una herramienta legítima y poderosa para casos específicos. Pero lo han sobrevendido como solución universal. La mayoría de las webs corporativas funcionan mejor con WordPress tradicional.
La pregunta correcta no es “¿debería usar headless?” sino “¿qué problema estoy resolviendo, y es headless la forma más eficiente de resolverlo?”
La pregunta correcta no es “¿debería usar headless?”
Es: “¿qué problema resuelvo? ¿es headless la mejor forma?”
Si estás pensando en headless, podemos evaluarlo juntos. A veces sí. A veces no. A veces una solución híbrida es mejor. Lo importante es decidir con información. No con buzzwords.
A few months ago, a client asked us for “a headless website with WordPress and Next.js.” When we asked why headless, the answer was: “because it’s more modern and scales better.” We explained that their project —an informational corporate site with 50 pages and a blog— didn’t need headless, and the “scalability” gained was insignificant. The complexity added, enormous. In the end, we did traditional WordPress with Elementor. The project was delivered in 6 weeks. Not 14. It cost half. The client edits their content alone. They don’t call us to change a comma. Headless WordPress is a powerful tool for specific cases. But it has become a buzzword that sells unnecessarily complex projects. Knowing when yes and when no saves you money. And headaches.
What is “headless”
Traditional WordPress is “monolithic”: the backend (where you manage content) and the frontend (what users see) are coupled. You use PHP themes that generate HTML directly.
Headless separates:
-
WordPress is just CMS. It manages content.
-
The frontend is another application (React, Vue, Next.js). It requests content via API.
-
The frontend generates the HTML. WordPress doesn’t see it.
The theoretical advantage: total flexibility in the frontend. Optimized performance. Same content for web, mobile app, digital screens. The real cost: Two systems to maintain. More complex deployment. Content editors suffer. Huge technical dependency.
When is headless worth it?
After years of seeing successful and failed headless projects, these are the cases where it truly shines:
Complex multichannel experience
You need the same content on web, native mobile app, desktop application, and who knows what else. WordPress as a single source of truth, distributed via API to all frontends. Example: A publisher that publishes on web, iOS app, Android app, newsletter, and syndication to partners. Headless justifies the cost. Content is truly reused.
Highly interactive frontend
Applications where the user experience is more like an app than a traditional website: complex transitions, persistent application state, real-time interactions. Example: A 3D product configurator with complex state, where the user spends 10 minutes interacting without page reloads.
Extreme performance
When every millisecond counts and you need aggressive optimizations: static generation, edge caching, route preloading. A modern frontend (Next.js, Astro) can do this better than traditional WordPress PHP. Example: A high-volume e-commerce where load speed directly impacts conversion and every tenth of a second counts.
Specialized technical team
You have experienced frontend developers in React/Vue and want to leverage that expertise. The cost of them learning PHP and WordPress themes is greater than maintaining a separate frontend.
When is headless overengineering
Conversely, these are cases where we see headless sold inappropriately:
“I want the website to be faster”
Well-optimized WordPress (cache, good hosting, lightweight images) loads in less than 1 second. The problem is almost never PHP. It’s heavy content or poor configuration. Before headless, audit your slow website. It’s probably not the architecture.
“I want to use modern technology”
React is not better than PHP. It’s different. For an informational site, PHP with static HTML works. It’s proven, simple, and any WordPress developer can maintain it.
“I want my marketing team to edit”
Irony: headless often makes content editing harder. WordPress visual page builders (Elementor, WPBakery) don’t work in headless. Content is edited in structured fields, and the frontend renders it. If your marketing team wants to “drag and drop” elements on pages, headless prevents it.
Small to medium sites
If you have fewer than 500 pages, less than 10,000 daily visits, and primarily static content, headless is using a cannon to kill a fly.
The hidden costs of headless (that no one tells you)
Headless vendors emphasize benefits but minimize costs. Be honest about them: Development cost. Headless costs 2 or 3 times more than traditional WordPress. Two systems to integrate. More complexity. More points of failure. Maintenance cost. Security updates: two systems. Frontend changes: you need a developer. Marketing can’t touch the design from WordPress. Hosting cost. You need infrastructure for the frontend (Node.js) + the WordPress backend. More complex. More expensive. Technical dependency cost. Any change, however small, needs a developer who understands the entire stack. You can’t hire just any WordPress freelancer. Time cost. Headless takes longer. To develop, to debug, to launch.
Hybrid alternatives
Not everything is black or white. There are intermediate architectures: WordPress with static frontend. Use WordPress as CMS. Generate a static site (plugins like Simply Static or Strattic). You have the ease of WordPress editing with the speed of a static site. It’s not pure headless. It captures many benefits without the complexity. Next.js with partial WordPress. Use Next.js only where you need it (e.g., an interactive app). The rest, traditional WordPress. The best of both worlds. Headless with visual page builder. Some solutions like Frontity or Gatsby with specific plugins try to recover the visual experience. They work, but add additional complexity.
Frequently Asked Questions
Is headless more secure? Partially. Separating backend and frontend reduces attack surface. But it adds complexity and new vulnerabilities. It’s not more secure by itself. It depends on how you implement it. Can I migrate from traditional WordPress to headless easily? No. You’re rebuilding the frontend from scratch. The content migrates. The theme, page builders, and visual customization do not. Does headless improve SEO? If done poorly, it worsens. Google executes JavaScript, but a poorly made frontend can be invisible. Next.js helps with SSR, but adds complexity. Should I use GraphQL or REST API? GraphQL is more flexible. For complex data. REST is simpler. Sufficient for simple cases. It depends on the complexity of your queries.
Conclusion
Headless WordPress is a legitimate and powerful tool for specific cases. But it has been oversold as a universal solution. Most corporate websites work better with traditional WordPress. The right question is not “should I use headless?” but “what problem am I solving, and is headless the most efficient way to solve it?”
The right question is not “should I use headless?” It’s: “what problem am I solving? Is headless the best way?”
If you’re considering headless, we can evaluate it together. Sometimes yes. Sometimes no. Sometimes a hybrid solution is better. The important thing is to decide with information. Not with buzzwords.