# Headless WordPress: cando ten sentido e cando é sobreenxeñaría Source: https://baqueiro.es/gl/ingenieria-sin-atajos/headless-wordpress-cando-si-cando-non/ Published: 2026-05-18T12:25:55+00:00 Updated: 2026-05-18T12:25:55+00:00 Author: Baqueiro Desarrollo Web Language: gl-ES Usage: Atribución requirida: permítese a cita cunha ligazón visible de volta --- **TL;DR** - Headless WordPress separa o backend (WordPress como CMS) do frontend (React, Vue, etc.), que se comunican mediante unha API. - Ten sentido para experiencias multicanle complexas, pero é excesivo para a maioría de sitios web corporativos. - O custo de desenvolvemento e mantemento dun proxecto headless é bastante maior ca o dun WordPress tradicional. Hai uns meses, un cliente pediunos “unha web headless con WordPress e Next.js”. Cando lle 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, en cambio, era enorme. Ao final fixemos un WordPress tradicional con Elementor. O proxecto entregouse en 6 semanas, non en 14. Custou a metade. O cliente edita o seu contido el só. Non nos chama para cambiar unha coma. Headless WordPress é unha ferramenta potente para casos concretos. Pero converteuse nunha palabra de moda que vende proxectos innecesariamente complexos. Saber cando si e cando non afórrache diñeiro. E dores de cabeza. ## Que é “headless” O WordPress tradicional é “monolítico”: o backend (onde xestionas o contido) e o frontend (o que ven as persoas usuarias) están acoplados. Usas temas PHP que xeran o HTML directamente. Headless sepáraos: - WordPress é só o CMS. Xestiona o 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. O mesmo contido para a web, a app móbil e as pantallas dixitais. O custo real: 2 sistemas que manter. Despregamentos máis complexos. As persoas que editan contido sofren. Unha dependencia técnica enorme. ## Cando paga a pena headless? Despois de anos vendo proxectos headless que saíron ben e outros que fracasaron, estes son os casos nos que realmente brilla: ### Experiencia multicanle complexa Necesitas o mesmo contido na web, nunha app móbil nativa, nunha aplicación de escritorio e quen sabe onde máis. WordPress fai de fonte única de verdade e distribúe o contido por API a todos os frontends. Exemplo: unha editorial que publica na web, nunha app de iOS, nunha app de Android, nun boletín e en sindicación a socios. Aquí headless xustifica o custo. O contido reutilízase de verdade. ### Frontend moi interactivo Aplicacións nas que a experiencia de usuario se parece máis á dunha app ca á dunha web tradicional: transicións complexas, estado de aplicación persistente, interaccións en tempo real. Exemplo: un configurador de produto en 3D con estado complexo, onde a persoa usuaria pasa 10 minutos interactuando sen recargar a páxina. ### Rendemento extremo Cando cada milisegundo conta e necesitas optimizacións agresivas: xeración estática, caché no edge, precarga de rutas. Un frontend moderno (Next.js, Astro) pode facelo mellor ca un WordPress PHP tradicional. Exemplo: un comercio electrónico de gran volume onde a velocidade de carga inflúe directamente na conversión e cada décima de segundo conta. ### Equipo técnico especializado Tes desenvolvedores frontend con experiencia en React ou Vue que queren aproveitar ese coñecemento. Que aprendan PHP e temas de WordPress custaría máis ca manter un frontend separado. ## Cando headless é sobreenxeñaría Pola contra, estes son os casos nos que vemos headless vendido de forma inadecuada: ### “Quero que a web sexa máis rápida” Un WordPress ben optimizado (caché, bo aloxamento, imaxes lixeiras) carga en menos de 1 segundo. O problema case nunca é PHP. É o contido pesado ou unha mala configuración. Antes de pensar en headless, audita a túa web lenta. Probablemente a culpa non é da arquitectura. ### “Quero usar tecnoloxía moderna” React non é mellor ca PHP. É distinto. Para un sitio informativo, PHP xerando HTML estático funciona. Está probado, é simple e calquera desenvolvedor de WordPress pode mantelo. ### “Quero que o meu equipo de márketing poida editar” A ironía: headless adoita facer máis difícil a edición de contido. Os construtores visuais de páxinas de WordPress (Elementor, WPBakery) non funcionan en headless. O contido edítase en campos estruturados e o frontend é quen o representa. Se o teu equipo de márketing quere “arrastrar e soltar” elementos nas páxinas, headless impídello. ### Sitios pequenos e medianos Se tes menos de 500 páxinas, menos de 10.000 visitas diarias e contido principalmente estático, headless é matar moscas a canonazos. ## Os custos ocultos de headless (que ninguén che conta) Quen vende headless salienta os beneficios e minimiza os custos. Sexamos honestos sobre eles: **Custo de desenvolvemento.** Na nosa experiencia, headless custa 2 ou 3 veces máis ca un WordPress tradicional. 2 sistemas que integrar. Máis complexidade. Máis puntos de fallo. **Custo de mantemento.** Actualizacións de seguridade: 2 sistemas. Cambios no frontend: necesitas un desenvolvedor. Márketing non pode tocar o deseño desde WordPress. **Custo de aloxamento.** Necesitas infraestrutura para o frontend (Node.js) e tamén para o backend de WordPress. Máis complexo. Máis caro. **Custo de dependencia técnica.** Calquera cambio, por pequeno que sexa, precisa dun desenvolvedor que entenda todo o stack. Non podes contratar a calquera freelance de WordPress. **Custo de tempo.** Headless leva máis tempo. Para desenvolvelo, para depuralo, para lanzalo. ## Alternativas híbridas Non todo é branco ou negro. Hai arquitecturas intermedias: **WordPress con frontend estático.** Usas WordPress como CMS e xeras un sitio estático (con plugins como Simply Static). Tes a facilidade de edición de WordPress coa velocidade dun sitio estático. Non é headless puro, pero recolle moitos dos beneficios sen a complexidade. **Next.js con WordPress parcial.** Usas Next.js só onde o necesitas (por exemplo, nunha aplicación interactiva). O resto, WordPress tradicional. O mellor dos dous mundos. **Headless con construtor visual de páxinas.** Algúns frameworks pensados para WordPress headless, como Faust.js, tentan recuperar parte da experiencia visual (representación de bloques, vistas previas). Funcionan, pero engaden aínda máis complexidade. ## Preguntas frecuentes **É headless máis seguro?** En parte. Separar backend e frontend reduce a superficie de ataque. Pero engade complexidade e novas vulnerabilidades. Non é máis seguro por si só. Depende de como o implantes. **Podo migrar doadamente dun WordPress tradicional a headless?** Non. Estás reconstruíndo o frontend desde cero. O contido migra. O tema, os construtores de páxinas e a personalización visual, non. **Mellora headless o SEO?** Se se fai mal, empeórao. Google executa JavaScript, pero un frontend mal feito pode ser invisible. Next.js axuda co SSR, pero engade complexidade. **Debería usar GraphQL ou a API REST?** GraphQL é máis flexible, ideal para datos complexos. REST é máis simple e abonda para casos sinxelos. Depende da complexidade das túas consultas. ## Conclusión Headless WordPress é unha ferramenta lexítima e potente para casos concretos. Pero vendeuse en exceso como solución universal. A maioría das webs corporativas funcionan mellor cun WordPress tradicional. A pregunta correcta non é “debería usar headless?”, senón “que problema estou a resolver, e é headless a forma máis eficiente de resolvelo?” Se estás a pensar en headless, [podemos avalialo xuntos](https://baqueiro.es/gl/contacto/). Ás veces é a opción correcta. Ás veces non. Ás veces unha solución híbrida é mellor. O importante é decidir con información, non con palabras de moda.