Hvad er et headless CMS? Fordele, ulemper og hvornår det giver mening

Hvad er et headless CMS? (det korte svar)

Et headless CMS er et content management system, der kun håndterer indholdet i backend og leverer det via et API til én eller flere separate frontends. Der følger altså ikke et indbygget “website-tema” eller sidetemplater med.

Den klassiske metafor er krop og hoved:

• Krop: databasen og redaktørfladen, hvor du opretter og strukturerer indhold
• Hoved: hjemmesiden, appen, skærmen i butikken osv., hvor indholdet bliver vist

I et traditionelt CMS hænger krop og hoved tæt sammen. I et headless CMS skærer du “hovedet” af og lader udviklere bygge frontenden frit, typisk med moderne JavaScript-frameworks eller andre teknologier. Det gør det nemmere at genbruge det samme indhold flere steder, men kræver også mere kode og flere udviklerressourcer.

Sådan fungerer et headless CMS i praksis

I praksis kan du tænke et headless CMS som en specialiseret indholds-backend med tre lag:

• Content repository: Her definerer du content-typer (artikler, produkter, events osv.) og felter (titel, tekst, billeder, priser).
• API-lag: Systemet udstiller indholdet via API’er, typisk REST eller GraphQL. Frontenden henter og sender data gennem de endpoints.
• Separat frontend: Ét eller flere websites, mobilapps, infoskærme, smart TV apps osv., der bruger API’et til at hente indhold og vise det for brugerne.

Det afgørende er, at dit CMS ikke bestemmer, hvordan indholdet ser ud. Det leverer kun data. Frontendlaget kan være:

• Et moderne website bygget i fx Next.js, Nuxt, SvelteKit eller lignende
• En native mobilapp, der viser de samme artikler som dit website
• En butiksskærm, der viser kampagner hentet direkte fra CMS’et

Det er heller ikke selve framework-navnet, der gør en løsning headless. Det handler om arkitekturen: at indhold renderer i et frontendlag, som er koblet løst til CMS’et via API’er, i stedet for at CMS’et selv står for både data og rendering.

Hvis du er usikker på, hvad det betyder at “kalde et API”, er den her guide til REST API’er en god blød landing.

Headless CMS vs. traditionelt CMS (og decoupled)

Inden man taler fordele og ulemper, er det vigtigt at have begreberne på plads. Groft forenklet har du tre modeller:

Traditionelt / monolitisk CMS

• Backend og frontend er tæt koblet.
• Samme system styrer både indhold, templates og rendering.
• Eksempler: Klassisk brug af WordPress, Drupal, Umbraco.

Her installerer du typisk temaer, plugins og bygger sider direkte inde i CMS’ets egen page builder.

Headless CMS

• Kun backend og API. Ingen templates, ingen indbygget hjemmeside.
• Indholdet hentes altid via API til en separat frontend.
• Eksempler: Contentful, Sanity, Strapi (men også WordPress/Drupal i ren headless-mode).

Her er CMS’et en ren data- og redaktørmotor. Frontenden er en separat applikation, der kunne leve et helt andet sted (fx hos Vercel eller Netlify).

Decoupled / hybrid

• CMS’et har stadig en indbygget frontend, men kan også levere indhold via API.
• Du kan blande klassiske CMS-sider med headless-lignende integrationer.
• Eksempler: Mange nyere versioner af WordPress, Drupal og Umbraco understøtter det i større eller mindre grad.

Den praktiske forskel mærkes især på:

• Genbrug af content: Headless og decoupled gør det nemmere at bruge samme indhold på tværs af sites og kanaler.
• Frontend-frihed: Headless giver maximal frihed til at vælge frameworks, hosting og arkitektur.
• Redaktøroplevelse: Traditionelle systemer har ofte stærkere WYSIWYG-oplevelse, mens headless kræver mere modelleret content.
• Teknisk kompleksitet: Headless betyder typisk flere komponenter at designe, bygge og drifte.

Fordele ved et headless CMS

Headless bliver ofte solgt som løsningen på alt. Det er det ikke, men der er nogle reelle styrker, især når du har mere end “et simpelt website”.

1. Genbrug af indhold på tværs af kanaler

I et headless CMS modellerer du indhold mere struktureret: ikke bare som “en side med tekst”, men som felter og typer. Det gør det langt lettere at genbruge det samme content flere steder:

• Samme produktdata på website, app og butiksskærm
• Nyheder, der både vises på hovedsite, intranet og i en app
• Tekster til e-mails hentet direkte fra CMS’et i stedet for at blive kopieret manuelt

Pointen er, at indhold og præsentation er skilt ad. Det samme stykke indhold kan få flere “dragter” uden at blive duplikeret.

2. Fleksibel frontend-arkitektur

Udviklere får lov til at vælge den frontend-teknologi, der giver bedst mening nu og om tre år. Du er ikke låst til CMS’ets templatemotor.

• Du kan bygge én frontend som klassisk server-renderet site, og en anden som SPA.
• Du kan skifte frontend-framework uden at røre content-backenden.
• Du kan kombinere flere værktøjer på tværs af dine løsninger.

Hvis du står foran et valg mellem fx SPA og klassisk MPA, kan det være værd at læse om erfaringerne i denne artikel om SPA vs. MPA, for det valg hænger meget tæt sammen med en headless-frontend.

3. Skalerbarhed og løs kobling

Når du skiller backend og frontend ad, kan du skalere dem uafhængigt af hinanden:

• Har du mange API-kald fra apps, kan du skalere API-laget uden at ændre på hjemmesidens drift.
• Har du tunge sidevisninger på websitet, kan du optimere og cache frontenden uden at belaste CMS’et unødigt.

Arkitekturen bliver mere modulær. Det gør det typisk nemmere at tilføje nye kanaler senere, hvis du fra starten har tænkt content-modellen ordentligt igennem.

4. Performance og sikkerhed – med nuancer

Mange skriver, at “headless er hurtigere og mere sikkert”. Det er kun delvist sandt.

• Performance: Du kan bygge meget hurtige frontends (fx statisk genererede sider), men det afhænger af, hvordan du implementerer frontenden. Headless i sig selv gør ingenting, hvis koden og arkitekturen er tung.
• Sikkerhed: Et headless CMS kan ligge bag lås og slå, og frontenden kan være statiske filer uden admin-login. Det giver et godt udgangspunkt, men det kræver stadig, at API’er, hosting og auth er konfigureret ordentligt.

Hvis du nørder webperformance, hænger mange af overvejelserne det samme sted som i guiden til Core Web Vitals: arkitektur og detaljer i frontenden betyder mere end ordet “headless”.

Ulemper og udfordringer ved headless CMS

Der er en grund til, at ikke alle små websites er bygget headless. Du får meget fleksibilitet, men du betaler med kompleksitet.

1. Højere startomkostninger

Et traditionelt CMS med et standardtema kan være i luften relativt hurtigt. Med et headless setup skal du næsten altid:

• Designe og bygge en custom frontend
• Lægge et API-design oven på CMS’et (eller i hvert fald integrere det ordentligt)
• Opsætte hosting/infrastruktur til både frontend, CMS og eventuelle mellemservices

Det betyder flere udviklertimer og typisk højere projektpris i opstarten.

2. Mere kode og arkitektonisk kompleksitet

Du får flere bevægelige dele:

• CMS-backend
• Ét eller flere frontendprojekter
• API-lag og integrationer til andre systemer
• Deployment-pipelines og monitorering for alle dele

For et lille team uden stærke udviklerkompetencer kan det hurtigt blive sårbart. Alt skal spille sammen, og fejl kan gemme sig i flere lag. Det øger også kravene til logning og observability, som gennemgået i fx denne artikel om logs og observability.

3. Redaktøroplevelse kan blive dårlig

Hvis man ikke tænker redaktørerne ind fra start, kan et headless CMS føles som at redigere i et regneark:

• Ingen eller dårlig visuel preview
• Komplekse content-typer uden forklaring
• Felter, der ikke afspejler den måde, indholdet bruges på i praksis

Mange moderne headless CMS’er har fået bedre editorværktøjer, men oplevelsen afhænger meget af, hvordan du designer content-modellen og bygger preview/workflows rundt om den.

4. Vedligeholdelse og driftsomkostninger

Headless kan over tid være effektivt, men der er flere ting at holde styr på:

• Frontendprojekter skal opdateres (frameworks, dependencies, sikkerhedsopdateringer).
• CMS’et og eventuelle plugins skal vedligeholdes.
• Integrationer (webhooks, custom API’er, middleware) kan gå i stykker, når andre systemer ændrer sig.

Flere kilder i researchen peger på, at den samlede vedligeholdelse ofte er højere end i et enkelt traditionelt CMS-setup, især hvis du har mange specialbyggede led imellem.

Hvornår giver et headless CMS mening – og hvornår gør det ikke?

Det vigtigste spørgsmål er ikke “er headless moderne?”, men “passer det til vores behov og kompetencer?”. Her er nogle tommelfingerregler.

Typiske situationer hvor headless giver god mening

• Flere kanaler: Du vil bruge samme indhold på website, app, skærme, måske også i nyhedsbreve eller interne systemer.
• Flere websites/brands: Fx koncerner eller kæder, hvor mange sites skal dele noget indhold, men stadig have egen identitet.
• Komplekse digitale produkter: Apps, portaler eller digitale services, hvor CMS’et mest er datakilde, ikke selve “hjemmesiden”.
• International tilstedeværelse: Mange sprog og markeder med krav om genbrug af content, men forskelle i lovgivning, produkter osv.
• Stærke udviklerressourcer: Du har et team eller en fast partner, der kan eje arkitekturen og løbende udvikle videre.

Situationer hvor headless sjældent er det bedste valg

• Små brochure-sites og kampagnesider uden særlige integrationer eller apps.
• Organisationer uden faste udviklerressourcer, hvor man er afhængig af “installér et tema og kør”.
• Projekter med stramt budget og kort levetid, hvor et simpelt tema i et traditionelt CMS løser opgaven fint.

Er du i tvivl, er det ofte bedre at starte simpelt og kun gå headless, hvis der er en tydelig grund. Den samme logik går igen i diskussionen om performance og ny teknologi, som du kan se i artiklen om at lade være med at jage bund-hastighed for enhver pris.

Konkrete eksempler og scenarier

Det bliver ofte mere håndgribeligt med konkrete scenarier. Her er nogle typiske mønstre, jeg selv har set og læst om.

Webshop med flere touchpoints

En webshop vil gerne:

• Bruge de samme produkttekster og billeder på website og i en mobilapp
• Styres kampagnebannere centralt og vise dem på webshop, skærme i butikker og måske i mails

Her kan et headless CMS styre alt “redaktionelt” indhold, mens selve e-handelsdelen (kurv, betaling) styres af fx Shopify eller andre systemer. Shopify bliver ofte nævnt i den sammenhæng, fordi nogle bruger det ren headless: Shopify til ordre og lager, et andet CMS til content og en custom frontend ovenpå.

B2B-site med komplekst produktkatalog

En B2B-virksomhed har et stort katalog med mange tekniske specifikationer. Produkterne skal vises på:

• Hovedsite
• Partnersites og lokale distributørers sites
• Internt salgsværktøj

Her kan et headless CMS fungere som fælles indholdslag, hvorfra data distribueres til flere frontends. Det kræver en god content-model, men kan spare rigtig meget dobbeltarbejde.

Content site + app

Et medie, en blog eller en vidensbank vil gerne have:

• Website med artikler, guides og måske interaktive elementer
• En mobilapp, der viser de samme artikler og push-notifikationer

Her giver det ofte mening at tænke headless fra start, så artikler, kategorier, tags og forfattere lever i CMS’et, og både website og app “bare” er klienter, der trækker på samme datalag.

Internationale løsninger

Et brand er til stede i flere lande og vil:

• Udgive globalt indhold, der kan oversættes og varieres per marked
• Give lokale teams mulighed for selv at tilføje indhold inden for nogle rammer

Et headless CMS med stærk støtte til sprog og lokalisation kan her være en fordel, især hvis flere websites og apps skal deles om det samme fundament.

Omkostninger og tekniske krav

Der findes ikke én “pris på headless”, men nogle generelle omkostningsdrivere går igen.

Hvad koster det typisk ekstra?

• Udvikling: Du skal bygge en frontend fra bunden og integrere den med CMS’et. Det koster flere timer end at tage et hyldetema.
• Integrationer: Webhooks, custom API’er og middleware er ofte nødvendige for at få systemer til at spille sammen.
• Vedligeholdelse: Flere kodebaser og komponenter skal patch’es og opdateres løbende.
• Hosting og drift: Du har typisk både CMS-hosting og frontend-hosting (fx Vercel, Netlify, egen server osv.).

Nogle kilder i researchen peger på, at hosting og skalerbarhed i visse setups kan blive billigere på sigt (fx ved meget trafik og statisk genererede frontends), men der er ikke solide tal nok til at sige det generelt. Det er bedre at se på din konkrete arkitektur og trafik.

Hvis du står overfor at vælge hosting til din frontend, er det værd at kigge på sammenligningen af Vercel, Netlify og Cloudflare Pages eller den lidt mere generelle guide til at vælge hostingløsning.

Kompetencekrav

Et headless setup kræver typisk:

• Frontend-udviklere, der er trygge ved moderne frameworks og API-integrationer
• Backend- eller full stack-udviklere til at designe og vedligeholde API’er og integrationer
• Arkitektkompetencer til at tænke systemlandskab, sikkerhed og dataflow igennem

Hvis du selv bygger API’er og mellemservices, er guides som “byg et lille Express API” og “undgå API-kaos” gode steder at starte.

Typiske faldgruber og hvad du skal være opmærksom på

De fleste problemer, jeg ser med headless, handler ikke om værktøjet, men om beslutningerne rundt om.

1. Overengineering

Det er fristende at bygge et avanceret, microservice-baseret setup til et meget lille projekt. Risikoen er, at du får:

• Unødigt mange systemer at drifte
• Kompleksitet som ingen i organisationen rigtig ejer
• En løsning, der er svær at ændre, fordi ingen helt forstår hele kæden

Hvis problemerne, du vil løse, handler om simple ting som et par specialfelter på sider eller et enkelt sprog mere, er det sjældent headless, der er svaret.

2. Ingen ordentlig content-model

Headless tvinger dig til at tænke struktur, men det gør ondt, hvis du springer det over:

• Content-typer bliver for generiske eller for specifikke.
• Redaktører ved ikke, hvor de skal putte indholdet hen.
• Frontenden får svært ved at bygge logik oven på et dårligt skema.

Brug tid på at modellere de vigtigste typer: sider, artikler, produkter, kategorier, facetter. Test med rigtige redaktører, før du bygger alt ovenpå.

3. Dårlig SEO- og URL-arkitektur

SEO bliver ikke automatisk bedre eller værre af headless, men det bliver lettere at lave fejl:

• Ingen gennemtænkt URL-struktur
• Manglende server-side rendering eller fallback, så søgemaskiner kun ser tomme skaller
• Ingen håndtering af redirects, canonical-tags eller sitemaps

Her spiller frontend-arkitekturen ind. Hvis du er i tvivl om fx routing og deploy af et moderne frontend-framework, kan artiklen om SPA vs. serverrouting være en god reality check.

4. Manglende preview og redaktørværktøjer

Hvis du ikke planlægger preview, lander du med:

• Redaktører, der udgiver “blindt” og må tjekke ting live
• Flere fejl i produktion, fordi ingen så siderne før go-live

Mange headless CMS’er har hooks og webhooks til at lave preview. Det kræver lidt ekstra arbejde, men det er sjældent der, du vil spare, hvis mange mennesker skal bruge systemet dagligt.

5. At bruge headless som plaster på et forkert CMS-valg

Nogle vælger headless for at “fikse” et eksisterende system, der i virkeligheden bare er forkert til opgaven. Hvis du i forvejen kæmper med et CMS, der ikke passer til jeres behov, hjælper det sjældent at smide et ekstra lag ovenpå. Så er det ofte bedre at kigge grundigere på selve systemvalget og organisationens kompetencer.

Hvordan kommer du videre, hvis du overvejer headless?

Hvis du står og skal vælge arkitektur, ville jeg personligt tage de her skridt:

1. Skriv ned, hvilke kanaler og devices der realistisk skal have dit indhold de næste 2-3 år.
2. Kortlæg interne kompetencer: Hvem kan eje frontend, backend, drift og governance?
3. Beslut, om du kunne skifte frontend uafhængigt af CMS’et inden for projektets levetid.
4. Lav et simpelt diagram over systemlandskabet: CMS, e-handel, app, integrationer, hosting.
5. Vurder, om kompleksiteten står mål med gevinsten. Hvis ikke – start enklere.

Har du allerede besluttet dig for at gå headless, er det næste oplagte skridt at dykke mere ned i frontend-værktøjerne. Artiklen om Vite vs. Next.js giver et godt indblik i forskellene på nogle af de værktøjer, der ofte ender foran et headless CMS.