Når valget står mellem WordPress eller headless CMS, handler det sjældent kun om teknologi. Det handler om, hvor let jeres organisation kan arbejde med indhold, hvor mange kanaler løsningen skal understøtte, og hvem der har ansvaret, når integrationen fejler en mandag morgen.
For mange danske virksomheder er WordPress det mest fornuftige valg, fordi platformen samler redaktørarbejde, funktionalitet og administration i en løsning, der er kendt, moden og flytbar. Headless kan være det rigtige arkitekturvalg, men kun når der er et konkret behov for det. Ellers risikerer man at betale for mere kompleksitet, end forretningen får værdi af.
WordPress eller headless CMS er ikke et enten-eller
Sammenligningen bliver ofte forsimplet. WordPress beskrives som den traditionelle løsning, mens headless fremstilles som den moderne og fleksible tilgang. Virkeligheden er mere nuanceret.
Et klassisk WordPress-site har et samlet system: WordPress administrerer indholdet og leverer det til hjemmesidens frontend. Redaktøren opretter en side, vælger moduler, tilføjer billeder og publicerer. Det er en overskuelig arbejdsgang, og ændringer kan oftest gennemføres uden hjælp fra udviklere.
I en headless-arkitektur adskilles indholdsadministrationen fra den frontend, brugeren ser. CMS’et leverer indhold via et API, mens en separat frontend – eksempelvis en webapp eller flere forskellige klienter – henter og viser indholdet. Det gør det muligt at bruge samme indhold på tværs af website, app, selvbetjening, digitale skærme eller andre kanaler.
WordPress kan også bruges headless. Det er derfor ikke nødvendigvis et spørgsmål om WordPress mod headless. Det kan lige så godt være et valg mellem et samlet WordPress-setup og WordPress som indholdsmotor bag en selvstændig frontend.
Hvornår et samlet WordPress-setup er det stærkeste valg
Et traditionelt WordPress-setup passer godt til organisationer, der primært skal drive en hjemmeside, et intranet eller en webshop med en overskuelig digital kunderejse. Her er redaktøroplevelsen, time-to-market og den løbende driftsomkostning ofte vigtigere end maksimal arkitektonisk frihed.
Når frontend og CMS følges ad, er der færre dele at overvåge, opdatere og fejlfinde. Det betyder noget i hverdagen. En kampagneside skal ikke vente på en udviklingsrelease, og et ændret kontaktmodul skal ikke nødvendigvis testes på tværs af et separat API-lag og en frontend-applikation.
For en WooCommerce-webshop er det samlede setup også ofte en fordel. Produktdata, lagerintegrationer, checkout, betalingsløsning, kundekommunikation og redaktionelt indhold skal fungere sammen. En headless frontend kan godt give mening ved meget høje performancekrav eller særlige købsflows, men den gør som regel både udvikling og videre drift mere omfattende.
Det betyder ikke, at et klassisk WordPress-site skal være langsomt eller usikkert. Performance afhænger af arkitektur, hosting, caching, billedhåndtering, kodekvalitet og integrationer. Sikkerheden afhænger af opdateringsdisciplin, adgangsstyring, backup, overvågning og et begrænset, velvurderet plugin-landskab. Platformnavnet alene afgør ingen af delene.
Headless CMS giver værdi, når indholdet skal leve flere steder
Headless er særligt relevant, når indhold ikke kun skal publiceres på ét website. Det kan være en virksomhed med både kundevendt site, medarbejderapp og forhandlerportal. Det kan også være en offentlig organisation, der skal genbruge indhold i flere selvbetjeningsløsninger med forskellige brugergrænseflader.
Her kan et centralt indholdslag være en reel gevinst. Redaktionelle data oprettes ét sted og distribueres til flere kanaler gennem veldefinerede API’er. Frontends kan udvikles uafhængigt, og teams kan arbejde mere specialiseret med henholdsvis indhold, design og applikationsudvikling.
Men friheden har en pris. I får typisk to løsninger at drifte i stedet for én: CMS’et og frontenden. Der kommer flere deployments, flere overvågningspunkter og flere tekniske afhængigheder. Preview af indhold, søgning, formularer, personalisering og redaktørens mulighed for at se resultatet før publicering kræver ofte særskilt udvikling.
Det er ikke et argument imod headless. Det er et argument for at vælge headless på baggrund af dokumenterede behov frem for en antagelse om, at nyere arkitektur altid er bedre.
Vurdér fire forhold før I vælger
Valget bliver mere præcist, når det tager udgangspunkt i den konkrete forretning frem for en teknologisk præference. Især fire forhold bør være afklaret:
- Kanaler og genbrug: Skal det samme indhold reelt bruges i flere selvstændige digitale kanaler, eller er hjemmesiden den primære destination?
- Redaktionel hverdag: Har redaktørerne behov for visuel sideopbygning, hurtige kampagneændringer og simple publiceringsflows, eller arbejder de struktureret med indhold, der skal distribueres via API?
- Integrationer: Skal løsningen kobles tæt til PIM, ERP, CRM, medlemsdata, sagsbehandling eller andre kerneplatforme? Integrationernes modenhed er ofte vigtigere end selve CMS-valget.
- Drift og ejerskab: Hvem skal vedligeholde frontend, CMS, API’er og sikkerhedsopdateringer om to, fem og syv år? Og kan løsningen flyttes, hvis leverandør eller hostingstrategi ændrer sig?
Det sidste spørgsmål bliver ofte undervurderet. En moderne løsning er ikke nødvendigvis fri, bare fordi den består af mange komponenter. Tværtimod kan afhængigheden vokse, hvis frontend, hosting, analyseværktøjer og tredjepartsservices er bundet tæt sammen uden dokumenterede grænseflader og en klar exit-plan.
Sikkerhed, GDPR og data er arkitekturspørgsmål
Headless bliver nogle gange solgt som et mere sikkert valg, fordi CMS’et ikke er direkte eksponeret mod offentligheden. Det kan reducere bestemte angrebsflader, men gør ikke løsningen automatisk sikker. API’er, adgangstokens, webhooks, frontend-afhængigheder og administrationsmiljøer skal stadig sikres, overvåges og opdateres.
På samme måde er WordPress ikke i sig selv en compliance-risiko. Risikoen opstår, hvis opdateringer udebliver, adgangsrettigheder er for brede, data sendes til unødvendige tredjeparter, eller løsningen består af ukendte plugins uden et tydeligt ansvar.
For virksomheder og offentlige organisationer bør GDPR-vurderingen omfatte hele databehandlerkæden. Hvor ligger data? Hvilke underleverandører modtager personoplysninger? Hvilke logs, analyseværktøjer og mailflows indgår? Og er der styr på databehandleraftaler, opbevaring og sletning?
En EU-forankret hosting- og driftsmodel kan gøre denne opgave langt mere overskuelig. Når platformen bygges med open source, dokumenterede integrationer og en databehandlerkæde i EU, reduceres afhængigheden af amerikanske cloudgiganter og uklare dataoverførsler. Det er digital suverænitet i praksis – ikke et ekstra lag kommunikation oven på en uigennemsigtig teknisk løsning.
Performance skal måles på brugeroplevelsen
En headless frontend kan levere meget hurtige websites, blandt andet fordi den kan optimeres specifikt til moderne frontend-teknologier og statisk levering af indhold. Det er relevant ved høj trafik, internationale markeder eller komplekse applikationsoplevelser.
Men et velbygget WordPress-site kan også være hurtigt. Ofte er de største flaskehalse tunge billeder, ukontrollerede scripts, dårlige tredjepartsintegrationer, for mange plugins eller utilstrækkelig caching. Hvis problemet er en udisciplineret teknisk implementering, løser headless ikke årsagen.
Det rigtige krav er derfor ikke, at løsningen skal være headless. Kravet er, at den skal levere en dokumenterbar god brugeroplevelse under realistisk belastning, også når redaktører publicerer nyt indhold, og integrationer arbejder i baggrunden.
Vælg den løsning, I kan tage ansvar for
Et CMS-valg bør holde længere end det næste redesign. Derfor skal redaktører, IT, sikkerhedsansvarlige og forretningen kunne forstå, hvad løsningen består af, og hvilke konsekvenser den har for drift og budget.
For mange er et samlet WordPress-setup den mest omkostningseffektive og redaktørvenlige vej til en sikker, hurtig og integrationsklar platform. For organisationer med flere selvstændige digitale kanaler eller avancerede applikationsbehov kan en headless-arkitektur være det rigtige fundament. Netkant arbejder med begge tilgange, men tager altid udgangspunkt i den løsning, der giver jer kontrol over data, drift og fremtidige ændringer.
Det bedste næste skridt er ikke at vælge den mest fashionable arkitektur. Det er at få kortlagt jeres kanaler, data, integrationer og driftsansvar, før teknologien bliver besluttet. Så bliver platformen et aktiv, I ejer og kan udvikle videre på – frem for endnu en afhængighed, der skal forklares og forsvares ved næste leverandørskifte.
