Headless WordPress: cando ten sentido e cando é sobreenxeñaría

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. Á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.