Headless CMS: quan té sentit i quan complica més del necessari
Un headless CMS no és millor per defecte. Depèn del projecte, l'equip i les necessitats editorials. T'expliquem quan suma i quan afegeix complexitat innecessària.
Per Laia Torrents

En els últims anys, l'arquitectura headless s'ha popularitzat molt entre equips de desenvolupament. La idea és seductora: separes el backend de contingut (el CMS) del frontend (la web), i cada part pot evolucionar independentment. Pots servir el mateix contingut a la web, l'app mòbil, un quiosc digital o qualsevol canal. Però la realitat és que per a molts projectes —especialment pimes i startups en fase primerenca— un headless CMS afegeix complexitat operativa i cost de manteniment que no es justifica amb els beneficis.
Quan un headless CMS realment aporta valor
Un headless CMS té sentit quan el projecte té necessitats que un CMS tradicional (WordPress, Drupal) no pot satisfer eficientment. El cas més clar és el multicanal: si el teu contingut ha d'aparèixer a la web, a una app mòbil iOS/Android, a un smartTV i a una API pública, gestionar-ho tot des d'un WordPress és un malson. Amb un headless CMS (Contentful, Sanity, Strapi) el contingut es defineix una vegada i es distribueix via API a tots els canals.
El segon cas és l'escala editorial: si el teu equip de contingut publica 50+ articles al dia, necessita fluxos de treball complexos (aprovació multinivell, programació, localització), o treballa en múltiples idiomes, les eines editorials d'un headless CMS professional superen clarament les d'un WordPress estàndard.
El tercer cas és el rendiment extrem: combinat amb un framework de frontend modern (Nuxt.js, Next.js, Astro) i una estratègia de generació estàtica, un headless CMS permet aconseguir webs amb puntuacions de 99/100 a Lighthouse que serien impossible amb un WordPress amb plugins.
- Headless TÉ SENTIT quan: el contingut s'ha de servir a múltiples canals (web + app + API pública).
- Headless TÉ SENTIT quan: l'equip editorial és gran i necessita fluxos de treball complexos.
- Headless TÉ SENTIT quan: el rendiment és un avantatge competitiu directe (e-commerce d'alt volum, media).
- Headless TÉ SENTIT quan: el frontend necessita tecnologia molt específica incompatible amb WordPress.
- Headless NO TÉ SENTIT quan: el projecte és una web corporativa estàndard amb menys de 10 actualitzacions de contingut al mes.
- Headless NO TÉ SENTIT quan: l'equip de contingut no és tècnic i necessita una experiència d'edició simple.
- Headless NO TÉ SENTIT quan: el pressupost és limitat —la infraestructura d'un headless setup és més cara i complexa de mantenir.
- Headless NO TÉ SENTIT quan: no hi ha un equip de frontend dedicat. Sense aquest equip, els canvis de disseny es converteixen en projectes llargs i costosos.
Opcions headless i el seu cost real de propietat
El cost d'un headless CMS no és només la llicència. Has de sumar el cost del CMS (Contentful Basic: gratu ï t fins a un límit, Pro: 300€/mes; Sanity: gratu ï t amb límits, Business: des de 100€/mes; Strapi: open source però necessita servidor), el cost del hosting del frontend (Vercel, Netlify, o el teu propi servidor), i el cost de manteniment i actualització.
Per comparar: un WordPress ben optimitzat en hosting de qualitat (15-30€/mes) amb Elementor Pro o un tema personalitzat cobreix el 90% dels casos de webs corporatives catalanes. La diferència de velocitat i flexibilitat rara vegada justifica el cost addicional per a projectes de menys de 50.000€ de pressupost total.
Si el projecte requereix escala editorial o multicanal real, headless suma molt. Si no, sol ser una capa tècnica innecessària que consumeix pressupost que podria anar a SEO o contingut.