Headless CMS forklaret: hvornår skal du vælge Sanity, Statamic eller Payload?

Et headless CMS er et redigeringssystem der kun styrer indholdet, mens selve hjemmesiden er kodet for sig og henter teksterne via et API. Det er det rigtige valg når din side er bygget i fx Next.js eller Laravel, og redaktørerne skal kunne udgive trygt uden at røre koden. Min korte anbefaling: Sanity når frontend er Next.js og flere redaktører arbejder samtidig, Statamic når projektet i forvejen er Laravel, og Payload når du vil eje hele backend og databasen selv.

Jeg bygger selv hjemmesider og platforme i Laravel og Next.js, så jeg har en interesse i at du vælger en kodet løsning. Derfor får du også et afsnit om hvornår headless er det forkerte valg.

Den korte version

Tommelfingerreglen er enkel: vælg det CMS der passer til den stack du alligevel bygger i, og tjek derefter om det passer til redaktørerne. Valget er én del af en større beslutning om hvor meget du vil bygge selv, og den afvejning gennemgår jeg i guiden til at lave din egen platform.

Hvad betyder headless, og hvornår er det besværet værd?

I et traditionelt CMS som WordPress hænger redigering og visning sammen. Samme system gemmer teksterne, styrer temaet og bygger siderne. Et headless CMS har intet "hoved", altså ingen visning. Det leverer indholdet som data, og en udvikler bygger frontend (den del de besøgende ser) i det værktøj der passer bedst.

Fordelene er konkrete:

• Du er ikke bundet til et tema, så design og hastighed kan styres helt.
• Samme indhold kan bruges på hjemmesiden, i en app, i nyhedsbreve eller på en skærm i butikken.
• Redaktørerne får felter der passer til jeres indhold i stedet for ét stort tekstfelt hvor alt kan ske.
• Frontend kan bygges om uden at indholdet skal flyttes.

Prisen er at du altid skal bruge en udvikler for at ændre layout eller tilføje nye typer indhold. Der er ingen temabutik og ingen plugins der klikker en ny sektion ind. Derfor anbefaler jeg kun headless når nogen alligevel skal udvikle på siden løbende.

Statamic er i øvrigt ikke rent headless. Det kan både vise siderne selv med skabeloner og levere indholdet via API. Den blanding kaldes ofte hybrid, og i praksis er den en fordel: du kan starte traditionelt og åbne API'et senere. Er du i tvivl om du overhovedet skal forlade WordPress, så læs min ærlige sammenligning af WordPress og en kodet hjemmeside først.

Sanity, Statamic og Payload set fra redaktørens stol

Teknisk kan alle tre det meste. Forskellen mærkes i hverdagen: hvordan redaktøren ser en ændring før udgivelse, hvor mange der kan arbejde samtidig, og hvem der rydder op når noget går galt.

Sanity: bedst når mange redigerer samtidig

Redigeringsfladen hedder Sanity Studio, og den sættes op i kode. Det lyder teknisk, men for redaktøren betyder det at felterne kan formes præcis efter jeres indhold: en produktside har de felter en produktside skal have, og intet andet. Flere kan arbejde i samme dokument på én gang og se hinandens ændringer med det samme.

Indholdet ligger i Sanitys cloud, så der er ingen server eller database du skal passe. Sanity oplyser at deres backend kører i ét EU-område i Belgien, men også at uploadet indhold kan ligge i EU, i USA eller i andre regioner hvor de har drift (Sanitys sikkerhedsside). Har du strenge krav til hvor data ligger, så læs databehandleraftalen før du vælger.

Gratisplanen dækker op til 20 brugere og 10.000 dokumenter, men kun med to roller: administrator og læser. Skal redaktørerne have begrænsede rettigheder, skal du på Growth-planen til 15 dollar pr. bruger om måneden (Sanitys prisside). For en lille marketingafdeling er det beskedent. For en organisation med 40 skribenter bliver det en fast post på budgettet.

Statamic: det naturlige valg i et Laravel-projekt

Statamic er bygget oven på Laravel og kan installeres i et eksisterende Laravel-projekt. Som standard ligger indholdet i Markdown- og YAML-filer i kodearkivet (repository), så teksterne versioneres sammen med koden. Vokser indholdet, kan det flyttes til en database uden at skabelonerne skal skrives om.

For redaktøren er Control Panel overskueligt, og live preview (forhåndsvisning af siden mens du redigerer) er med allerede i den gratis udgave. Core har dog kun én administratorbruger og én formular. Flere brugere, revisioner, flersprogede sites og REST- eller GraphQL-API kræver Pro, som koster 349 dollar pr. site inklusive et års opdateringer og derefter 99 dollar om året for fortsatte opdateringer (Statamics prisside).

Har du allerede en Laravel-app, eller skal hjemmesiden hænge tæt sammen med en (fx med login, bookinger eller kundedata), er Statamic efter min vurdering det enkleste valg. Det hele ligger i én kodebase, og den samme udvikler kan passe begge dele. Ulempen er et mindre økosystem end WordPress og færre udviklere der kender det.

Payload: mest kontrol, mest ansvar

Payload er et open source-CMS skrevet i TypeScript og installeres direkte i en Next.js-app. Du beskriver dine indholdstyper i konfigurationen, og Payload bygger admin-panel og API ud fra den. Data ligger i din egen database, og officielt understøttes MongoDB, Postgres og SQLite (Payloads dokumentation).

Det gør Payload stærkt når indhold og forretningsdata hænger sammen. En kursusside kan pege direkte på kursets tilmeldinger i samme database uden at to systemer skal synkroniseres. Admin-panelet minder lidt mere om et dataværktøj end om et skriveprogram, så redaktører der skriver lange tekster hver dag skal have tid til at vænne sig til det. Til gengæld står du selv for hosting, backup, sikkerhedsopdateringer og skalering. Der er ingen leverandør at ringe til.

Payload-teamet blev en del af Figma i juni 2025, og Figma skriver at Payload forbliver open source (Figmas blogindlæg om opkøbet). Jeg ser det ikke som en risiko i dag, men jeg holder øje med hvor produktet bevæger sig hen.

Sådan vælger du CMS i 6 trin

1. Start med redaktørerne, ikke teknologien. Skriv ned hvem der redigerer, hvor ofte og hvad. Fem marketingfolk der udgiver dagligt har andre behov end én direktør der retter åbningstider to gange om året.
2. Tag udgangspunkt i den stack du har. Er backend Laravel, så start med Statamic. Er frontend Next.js, står valget typisk mellem Sanity og Payload. Har du ikke valgt endnu, så start med min sammenligning af Laravel og Next.js.
3. Lav indholdsmodellen før du vælger. Skriv sidetyper, blokke og relationer ned: "en medarbejder hører til en afdeling", "en case viser tre ydelser". Jo flere relationer, jo vigtigere er det at CMS'et håndterer dem godt.
4. Test preview med rigtigt indhold. Bed udvikleren vise hvordan en redaktør ser en side før den udgives. Preview kræver opsætning i alle tre systemer, og det er her redaktørerne oftest bliver frustrerede hvis det er sprunget over.
5. Regn på tre år, ikke på licensen. Læg brugerbetaling, licens, hosting og udviklertimer sammen for tre år. Softwaren er sjældent den store post. Opsætning, indholdsmodel og løbende ændringer er.
6. Tjek ejerskab og udgang. Hvor ligger data, kan alt eksporteres, og hvem har adgang? Med Statamic og Payload ligger data hos dig. Med Sanity ligger det hos dem, men det kan eksporteres.

Hvad koster et headless CMS i praksis?

Licenspriserne er de nemme tal. Sanity er gratis indtil du har brug for flere roller, flere dokumenter eller private datasæt, og så betaler du for hver bruger. Statamic Core er gratis med én administrator, mens Pro koster et engangsbeløb pr. site plus et årligt beløb for opdateringer. Payload koster intet som software, men du betaler for at hoste Next.js-appen og databasen.

De store poster ligger andre steder:

• Indholdsmodellen. Hvilke sidetyper, felter og blokke skal der være, og hvordan hænger de sammen?
• Redigeringsfladen. Felter, hjælpetekster, rettigheder og preview, så redaktørerne kan arbejde uden at ringe til udvikleren.
• Koblingen til frontend. Hver sidetype og blok skal vises korrekt, også på mobil.
• Flytning af eksisterende indhold. På et site med hundredvis af sider kan migreringen være et projekt i sig selv.
• Drift og opdateringer. Mest mærkbart ved Statamic og Payload, hvor du selv hoster.

Derfor er "hvilket CMS er billigst?" sjældent det rigtige spørgsmål. Et gratis CMS med en uklar indholdsmodel bliver dyrere end et betalt med en god.

Hvornår headless er det forkerte valg

Headless er ikke en opgradering af alt. Her er situationerne hvor jeg fraråder det:

• Du har én redaktør, en håndfuld sider og sjældne ændringer. Et headless CMS og en separat frontend er to ting at vedligeholde for et behov som en simpel hjemmesidebygger eller statiske filer kan løse.
• Du har ingen udvikler tilknyttet efter lanceringen. Med headless kræver hver ny sektion eller layoutændring kode. Vil du selv kunne bygge nye sider fra bunden, er Webflow eller WordPress et mere ærligt valg, og her hjælper min sammenligning af Wix, Squarespace, Webflow og en udvikler.
• Du er afhængig af færdige plugins. WordPress har et stort økosystem til formularer, flersprog og SEO. I en headless opsætning skal mange af de ting bygges eller integreres.
• Budgettet er stramt. Så er pengene bedre brugt på gode tekster og billeder end på arkitektur. Overvej om du selv kan lave hjemmesiden eller bør få den lavet.

Og har du brug for én partner der også leverer design, tekster og annoncer, er en freelanceudvikler som mig ikke hele svaret alene. Så er et bureau eller et samarbejde med en designer bedre.

Næste skridt

Kan du krydse de fleste punkter af, er du klar til en snak med en udvikler. Jeg bygger hjemmesider i Laravel og Next.js med et CMS der passer til jeres redaktører, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Er WordPress et headless CMS?+

Ikke som udgangspunkt, men det kan bruges headless. WordPress har et indbygget REST API, så en Next.js-frontend kan hente indholdet derfra. Det kan være en fornuftig vej hvis redaktørerne kender WordPress godt. Ulempen er at du stadig skal drive og opdatere WordPress, og at mange plugins forudsætter at WordPress selv viser siderne.

Er et headless CMS bedre for SEO?+

Ikke i sig selv. Google ser den færdige side, ikke hvilket CMS der ligger bag. Headless kan give hurtigere sider og fuld kontrol over den tekniske SEO, men det kræver at udvikleren bygger titler, metadata, sitemap og omdirigeringer ind fra start. I WordPress klarer et plugin meget af det for dig.

Kan jeg skifte CMS senere?+

Ja, men det er et projekt i sig selv. Indholdet skal eksporteres, tilpasses den nye indholdsmodel og importeres, og frontend skal kobles om. Skiftet er typisk lettere med headless end med et traditionelt CMS fordi indhold og visning allerede er adskilt. Planlæg også omdirigeringer, så gamle adresser ikke giver fejl og koster trafik.

Hvad med GDPR i et headless CMS?+

Det afhænger af hvor data ligger, og hvem der behandler det. Indeholder CMS'et persondata, fx formularsvar eller medarbejderprofiler, skal du have en databehandleraftale med leverandøren. Sanity tilbyder en, og med Statamic eller Payload på europæisk hosting styrer du selv placeringen. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du er i tvivl.

Hvad med Strapi, Contentful og Storyblok?+

De er alle reelle alternativer. Contentful og Storyblok er hostede ligesom Sanity, og Strapi er open source og selvhostet ligesom Payload. Jeg har fokuseret på Sanity, Statamic og Payload fordi de passer bedst til Laravel og Next.js, som er det jeg bygger i. Brug de samme seks trin når du vurderer andre systemer.