Beslutningsguide
Spørgsmålet "hvilket CMS?" kommer typisk når marketing vil redigere sider, produkt vil lancere landingssider oftere, og udvikling ikke vil merge copy-ændringer i Git hver uge. Headless løser det ved at adskille redaktion fra frontend — men det introducerer et nyt system I skal drifte, sikre og betale for.
Vi har sat headless CMS op bag Next.js-sites, dokumentationsportaler og marketing-lag oven på SaaS-produkter. Valget handler om hvem der redigerer, hvor ofte indhold ændrer sig, og hvor tæt det skal sidde på produktdata — ikke om hvilken leverandør der vandt en benchmark.
TL;DR
De vigtigste pointer
- Headless giver mening når frontend er Next.js (eller lignende) og indhold skal opdateres uden deploy.
- Markdown eller MDX i repo er ofte rigtigt for små teams med få sider og udviklere tæt på copy.
- Preview og publicerings-flow er vigtigere end feature-listen i salgsbrochuren.
- SEO kræver stadig jeres arbejde: canonicals, sitemap, structured data og hurtige sider kommer ikke af sig selv.
- Migrering fra WordPress er et projekt — ikke en weekend-export.
Hvornår headless slår monolit
Et klassisk WordPress-tema er en hel stack: PHP, plugins, database, sikkerhedsopdateringer og en editor der kender hele sitet. Det er fint til indholdstunge sites hvor teamet allerede kan WordPress. Det skærer dårligt når jeres "site" er en Next.js-app med auth, dashboards og API'er — for så ender I med to verdener der skal styles ens og deles data imellem.
Headless betyder: CMS gemmer struktureret indhold og leverer det via API. Next.js henter ved build (SSG/ISR) eller on-demand, renderer med jeres komponenter, og I beholder kontrol over performance og routing. Redaktøren får et fokuseret interface; udvikleren beholder type-sikkerhed og preview-deploys.
Det giver ikke mening hvis I har fem sider der ændrer sig sjældent, eller hvis det eneste krav er en blog og teamet allerede er glad for WordPress. I de tilfælde er kompleksiteten ofte større end gevinsten.
Headless CMS vs. WordPress vs. filer i repo
Headless CMS
Sanity, Contentful, Payload, Hygraph — redaktion adskilt fra deploy.
- Non-developers kan redigere uden Git-adgang
- Struktureret indhold — ikke bare HTML i en WYSIWYG
- Preview-URL før publicering er muligt
- Ekstra system: brugere, API, backup, evt. licens
- Integration og migrationsplan skal tænkes ind fra start
Alternativer
WordPress, markdown i repo, eller hybrid med statiske sektioner.
- WordPress: stærkt til rent marketing-site med kendt redaktion
- MDX/markdown i Git: enkelt, versioneret, gratis — kræver dev til større ændringer
- Hybrid: marketing på CMS, app og docs i repo
- Page builders i monolit: hurtigt — sværere at matche custom app-UX
- Vælg efter team — ikke efter hvad der ser mest moderne ud
Sådan tænker vi leverandørvalg
Sanity er vores ofte-valgte default til marketing og produkt-indhold: fleksibel schema, god developer experience, hosted eller self-hosted muligheder, og solid preview med Next.js. Contentful er stærkt i enterprise med mange redaktører og godt governance — til en pris i kompleksitet og licens. Payload og Directus giver self-hosted kontrol når data skal blive i jeres VPC. Hygraph og lignende passer når GraphQL og federated content er centralt.
Ingen leverandør løser information architecture. I skal stadig beslutte content types, slugs, locale-struktur og hvem der må publicere. Et dårligt schema i et godt CMS giver et dårligt site — bare med pænere admin UI.
Vi anbefaler at starte med få content types og stramme felter frem for at modellere hele virksomheden dag ét. Det er lettere at udvide schema end at rette op på tusind rodede dokumenter.
Spørgsmål I bør have svar på før I vælger
Brug listen i discovery — den afslører hurtigt om I overhovedet har brug for headless endnu.
- Hvem redigerer — marketing alene, eller også produkt og support?
- Hvor mange sprog skal understøttes, og hvem oversætter?
- Skal indhold previewes på rigtig URL før publicering?
- Hvor tæt skal CMS-indhold sidde på produktdata (priser, features, docs)?
- Hvad er acceptabel downtime og hvem ejer backup af indhold?
- Skal gamle WordPress-URL'er bevare redirects og SEO-værdi ved migrering?
Preview, ISR og publicering
Det flow redaktører mærker er preview og publicering. Vi sætter typisk draft-mode eller preview-secret op så ændringer kan ses på en rigtig URL før de går live. Publicering trigger revalidation (ISR) eller webhook til build — afhængigt af hvor fresh indhold skal være.
Ikke alt skal være dynamisk. Marketing-sider der ændrer sig ugentligt kan ofte bygges statisk og revalidere on-demand. Det er billigere at drive og bedre for performance end at hente alt fra CMS ved hvert request.
Billeder og assets håndteres bedst via CMS'ets asset pipeline eller et dedikeret CDN — ikke store filer i Git. Alt text og cropping-regler bør være felter redaktøren ser, ikke noget udvikleren retter bagefter i kode.
Spørgsmål vi får igen og igen
Kan vi bare beholde WordPress som headless?
Ja — WordPress som API-backend er en valid migreringstrin. I får headless frontend uden at omskrive alt indhold dag ét. Ulempen er at I stadig drifter WordPress, plugins og sikkerhed. For mange teams er det en bro — ikke slutmålet.
Er markdown i repo ikke godt nok?
For docs, changelog og sites med få bidragydere: ofte ja. Det er versioneret, reviewes i PR og kræver ingen ekstra login. Når marketing skal iterate uden dev-kø, bliver CMS attraktivt. Mange produkter kører hybrid: CMS til marketing, markdown til teknisk indhold.
Hvordan håndterer vi flere sprog?
Vælg CMS med first-class locale eller separate felter pr. sprog. Next.js app router med locale-prefix matcher godt. Planlæg hvem der oversætter og om fallback er acceptabelt — teknisk setup er den lette del.
Hvad med e-commerce indhold og Shopify?
Produktdata hører typisk i Shopify (eller jeres PIM); marketing-sider i CMS. Undgå at duplicere produktinfo i to systemer uden sync-strategi. CMS til kampagnesider, Shopify til katalog — med klare links imellem.
Hvor lang tid tager en migrering fra WordPress?
Afhænger af antal sider, custom fields, media og SEO-krav — ikke af CMS-valg alene. Vi kartlægger URL'er, redirects og indholdstyper før migrate. En lille marketing-site er et andet projekt end et site med hundredvis af artikler og custom post types.
Skal I have redaktion uden redeploy?
Lad os finde det CMS-niveau I faktisk har brug for.
Vi hjælper med at afgøre om headless, hybrid eller filer i repo er rigtigt — og sætter preview, schema og SEO op så det holder i drift.