En ny frontend, en app eller en række integrationer får ofte spørgsmålet til at opstå: Headless CMS versus WordPress – hvad er det rigtige valg? Det korte svar er, at det afhænger af, hvor indholdet skal bruges, hvem der skal redigere det, og hvilket ansvar organisationen vil påtage sig for drift, sikkerhed og videreudvikling. Det lange svar er mere interessant, fordi platformvalget påvirker både budget, compliance og jeres handlefrihed i mange år.
Et headless CMS bliver ofte præsenteret som det moderne alternativ til WordPress. Men det er en forenkling. WordPress kan både fungere som et klassisk CMS, hvor indhold og præsentation ligger tæt sammen, og som et headless CMS, hvor indhold stilles til rådighed via API’er for eksempelvis en app, en webshop eller flere websites. Derfor handler valget sjældent om gammel versus ny teknologi. Det handler om at vælge en arkitektur, der løser et konkret behov uden at skabe unødig kompleksitet.
Hvad adskiller et headless CMS fra WordPress?
I en klassisk WordPress-løsning redigeres indholdet i administrationen og vises gennem et tema på samme platform. Redaktion, design og publicering hænger sammen. Det gør det hurtigt at bygge, nemt at forstå for redaktører og effektivt at vedligeholde, når website er den primære kanal.
Et headless CMS adskiller indholdet fra den kanal, der viser det. CMS’et gemmer tekst, billeder, strukturerede data og metadata, mens en selvstændig frontend henter indholdet via et API. Den frontend kan være bygget i eksempelvis React, Vue eller en mobilteknologi. Samme indhold kan dermed bruges på et website, i en app, på infoskærme eller i interne systemer.
Adskillelsen kan være en fordel, men den er ikke gratis. Når frontend og CMS er to selvstændige dele, skal begge dele udvikles, testes, overvåges og opdateres. Redaktionelle ændringer, preview, søgning, redirects og formularer kræver også mere bevidst design end i en samlet WordPress-løsning.
WordPress er ikke kun en monolit
Det er en udbredt misforståelse, at WordPress altid er bundet til et traditionelt tema. WordPress har et modent REST API og kan udvides med andre API-mønstre. Det betyder, at en organisation kan begynde med et klassisk WordPress-site og senere stille udvalgt indhold til rådighed for andre kanaler.
Denne mulighed er relevant, når behovet udvikler sig gradvist. I behøver ikke vælge en fuldt afkoblet arkitektur fra første dag, hvis den eneste konkrete opgave er at publicere indhold på ét website. Omvendt skal man heller ikke presse flere digitale produkter ind i samme frontend, hvis de reelt har forskellige brugerrejser og tekniske krav.
Headless CMS versus WordPress i redaktørernes hverdag
For marketing- og kommunikationsteams er redigeringsoplevelsen afgørende. En klassisk WordPress-løsning giver typisk en direkte kobling mellem indhold, skabeloner og visuel præsentation. Redaktøren kan oprette en landingsside, placere indholdsblokke og se en forhåndsvisning, der ligger tæt på det offentliggjorte resultat. Det reducerer behovet for udviklerhjælp ved almindelige ændringer.
I et headless setup skal redaktørens arbejdsflow designes mere eksplicit. Hvordan ser preview ud? Hvilke indholdsmodeller findes der? Kan en kampagneside bygges frit, eller skal den følge faste komponenter? Hvordan håndteres billeder i flere formater og kanaler? Et godt headless CMS kan give en fremragende redaktionel oplevelse, men det opstår ikke automatisk ved at vælge en API-baseret platform.
For organisationer med mange redaktører, hyppige kampagner og begrænsede interne udviklingsressourcer vil WordPress ofte være den mest omkostningseffektive løsning. Især når en gennemtænkt komponentstruktur og redaktørrettigheder gør det muligt at arbejde hurtigt uden at svække design, tilgængelighed eller kvalitet.
Integrationer kan tale for begge løsninger
Integrationer bliver ofte brugt som argument for headless. Det giver mening, hvis data skal flyde mellem mange selvstændige systemer: PIM, ERP, CRM, produktkataloger, medlemsplatforme, booking, sagsbehandling eller apps. En API-først arkitektur kan gøre det lettere at dele data på tværs og lade hvert system løse sin egen opgave.
Men WordPress er også velegnet til integrationsbaserede løsninger. Det afgørende er ikke, om der står WordPress eller headless på tegningen. Det afgørende er, om integrationerne har klare ejere, veldokumenterede grænseflader, fejlhåndtering og en plan for ændringer. En dårlig integration bliver ikke bedre af, at CMS’et er headless.
I e-handel er dette særligt tydeligt. En WooCommerce-løsning med et klassisk frontend kan være et stærkt valg, når sortiment, kunderejse og redaktionelt indhold skal administreres samlet. En afkoblet frontend kan være relevant, når webshoppen skal levere data til flere salgskanaler, eller når en særlig købsoplevelse kræver mere specialiseret frontend-udvikling. Her bør beslutningen tages ud fra dokumenterede krav til performance, redaktion og drift – ikke ud fra teknologiens signalværdi.
Performance handler om arkitektur og drift
Et headless CMS kan levere høj performance, særligt når en statisk eller cachet frontend distribueres effektivt. Men performance afhænger fortsat af billedoptimering, caching, kodekvalitet, tredjepartsscripts, databaseforespørgsler og hosting. En langsom frontend bliver ikke hurtig, bare fordi den henter indhold fra et API.
Det samme gælder WordPress. En veldesignet WordPress-løsning med god cache-strategi, kontrollerede plugins, optimerede billeder og professionel drift kan være meget hurtig. I praksis er det ofte manglende vedligeholdelse, ukritisk brug af plugins og tunge marketingtags, der skaber problemer – ikke selve CMS’et.
Det er derfor relevant at spørge, hvem der overvåger løsningen, håndterer opdateringer og reagerer på fejl. En moderne arkitektur fritager ikke organisationen for driftsansvar. Tværtimod kan flere tekniske lag øge behovet for tydelig overvågning, logning og release-procedurer.
GDPR, data og digital suverænitet skal vurderes tidligt
CMS-valget har også en datamæssig side. Mange headless CMS-produkter leveres som cloudtjenester, hvor leverandøren bestemmer drift, datalagring og ofte dele af den tekniske roadmap. Det kan være praktisk, men det kræver en grundig vurdering af databehandlerkæden, behandlingssteder, adgangsforhold og mulighederne for at flytte data ud igen.
For danske virksomheder og offentlige organisationer er det ikke nok at se på, om en leverandør markedsfører sig med GDPR. Der skal være klarhed over, hvor data behandles, hvilke underdatabehandlere der indgår, og hvordan personoplysninger holdes ude af unødige systemer. Det gælder også analyseværktøjer, formularer, nyhedsbreve, søgning og supportfunktioner omkring CMS’et.
WordPress som open source giver et stærkt udgangspunkt for ejerskab. I kan vælge en EU-baseret hostingmodel, kontrollere jeres data og flytte løsningen, hvis behovet ændrer sig. Det samme kan lade sig gøre med open source-baserede headless løsninger, men det kræver, at man aktivt vælger drift og arkitektur frem for en lukket softwaretjeneste. Hos Netkant er dette et centralt princip: Teknologien skal understøtte kundens handlefrihed, ikke begrænse den.
Hvornår er headless den rigtige investering?
Headless er ofte relevant, når én fælles indholdsplatform skal forsyne flere selvstændige digitale kanaler. Det kan være en organisation med både hovedsite, kundeportal, app og interne løsninger, hvor indhold skal genbruges kontrolleret. Det kan også være relevant, når frontend-oplevelsen har krav, som et traditionelt CMS-tema ikke løser hensigtsmæssigt.
Det kræver dog et team eller en partner, som kan håndtere den samlede løsning over tid. Budgettet skal omfatte udvikling af frontend, API’er, preview, deployment, sikkerhedsopdateringer og løbende kvalitetssikring. Hvis disse discipliner ikke er finansieret, risikerer headless at blive en teknisk gæld forklædt som innovation.
WordPress er ofte det rigtige valg, når website eller webshop er den centrale kanal, redaktører skal kunne arbejde selvstændigt, og time-to-market betyder noget. Det er også et stærkt valg, når løsningen skal integreres med andre systemer, men ikke nødvendigvis levere indhold til mange forskellige frontends fra starten.
Vælg efter behov, ikke efter mode
Det bedste platformvalg starter med konkrete spørgsmål: Hvilke kanaler skal bruge indholdet de næste tre til fem år? Hvilke integrationer er forretningskritiske? Hvem skal kunne publicere hvad? Hvor behandles data? Hvad koster det at drifte og ændre løsningen, når den er lanceret?
Svarene kan pege på et klassisk WordPress-site, en afkoblet WordPress-arkitektur eller et dedikeret headless CMS. Den rigtige løsning er den, der giver redaktører handlekraft, IT-afdelingen kontrol og organisationen frihed til at udvikle sig uden unødig leverandørafhængighed. Det er et bedre udgangspunkt end at vælge den mest omtalte teknologi.
