Headless eller traditionelt CMS?
Et traditionelt CMS lagrer indholdet og renderer hjemmesiden i samme system mens et headless CMS kun håndterer indhold og leverer det via API til de kanaler man vælger. Headless passer når indholdet skal ud i flere kanaler og organisationen har egne udviklerressourcer; et traditionelt CMS passer når en hjemmeside er nok og redaktørerne vil have det hele samlet.
Valget mellem headless og traditionelt CMS handler ikke om produktnavne, men om arkitektur: Skal indhold og præsentation hænge sammen i ét system eller være afkoblet fra hinanden? Det valg påvirker hvilke kanaler I kan nå, hvordan redaktørerne arbejder og hvad hver ændring koster i de kommende fem år.
Forskellen ligger i koblingen mellem indhold og præsentation
Et traditionelt CMS gør det hele i ét: Indholdet lagres, skabelonerne bor i systemet, og siderne renderes derfra. Redaktøren ser hjemmesiden mens den redigeres, og én installation er hele løsningen.
Et headless CMS har kappet den kobling. Systemet håndterer kun indhold (struktureret i felter og modeller) og leverer det via API. Præsentationen bygges separat: en hjemmeside, en app, en skærm i butikken. Deraf navnet: Kroppen er der stadig, men hovedet (præsentationslaget) vælger I selv. Eller flere hoveder.
Hvad afkoblingen giver i praksis
Konsekvenserne er konkrete, ikke akademiske:
- Flere kanaler uden dobbeltarbejde. Den samme produkttekst eller nyhed publiceres én gang og hentes af hjemmesiden, appen og infoskærmen. Ingen copy-paste mellem systemer, ingen versioner der glider fra hinanden.
- Redesign uden indholdsmigrering. Vil I skifte udseende eller teknologi på hjemmesiden, bygges en ny frontend op mod det samme API. Indholdet forbliver urørt, og netop det er ellers som regel den dyreste og mest risikable del af en ombygning.
- Teknologifrihed pr. kanal. Hvert præsentationslag kan bygges med den teknologi der passer til netop den kanal, uden at CMS’et sætter rammerne.
En virksomhed med hjemmeside, app og digital skiltning vedligeholder med en traditionel arkitektur ofte tre indholdslag. Med headless: ét.
Hvad redaktørerne mister, og hvordan værktøjerne har indhentet det
Afkoblingen har en pris, og den betales ofte af redaktionen. I et traditionelt CMS ser redaktøren siden som den besøgende ser den, kan bygge sider med træk og slip og se en forhåndsvisning med det samme. I de tidlige headless-løsninger forsvandt alt det: Tilbage var formularfelter og en publiceringsknap der sendte indholdet ud i det blå.
Moderne værktøjer har lukket det meste af hullet: forhåndsvisning op mod den rigtige frontend, visuelle redigeringstilstande og blokbaserede sideskabeloner som redaktørerne selv sætter sammen. Men intet af det kommer gratis. Redaktøroplevelsen er en selvstændig post i et headless-projekt. Afsæt budget til den, ellers betaler redaktionen med sin hverdag.
Traditionelt og headless side om side
| Aspekt | Traditionelt CMS | Headless CMS |
|---|---|---|
| Kanaler | Primært hjemmesiden | Et vilkårligt antal via API |
| Redaktørmiljø | Færdigt, med forhåndsvisning | Bygges og konfigureres pr. projekt |
| Redesign | Ofte migrering af indhold og skabeloner | Ny frontend, indholdet urørt |
| Afhængighed af udviklere | Lavere: Meget løses i platformen | Højere: Frontenden er et projekt for sig |
| Startomkostning | Lavere | Højere |
Beslutningskriterier: kanaler og udviklerressourcer
To spørgsmål afgør det meste:
- Hvor mange kanaler skal indholdet ud i, i dag og om tre år? Én hjemmeside: Det traditionelle CMS er rigeligt. Hjemmeside plus app, flere markeder eller skærme: Headless begynder at betale sig.
- Hvilke udviklerressourcer har I? Headless forudsætter et team eller en bureaupartner der bygger og vedligeholder frontenden. Uden det bliver friheden en byrde.
Læg dertil redaktionens størrelse: En stor indholdsproduktion kræver at forhåndsvisning og arbejdsgange prioriteres uanset arkitektur.
Scenarie: én kanal bliver til tre
En virksomhed driver i dag en hjemmeside i et traditionelt CMS. På roadmappen står en kundeapp næste år og indhold på et par nye markeder året efter. Vælger den at bygge appen med et separat indholdslag, har den snart tre sandheder om de samme produkter.
Flyttes indholdet i stedet til et headless CMS når appen bygges, bliver appen den første der henter fra API’et, og hjemmesiden den anden. Hver ny kanal derefter er endnu et præsentationslag, ikke et nyt indholdssystem. Det er i den situation headless går fra arkitekturdiskussion til ren økonomi.
Står I over for valget? Kontakt os, så ser vi på jeres kanaler, jeres redaktion og hvad der reelt er pengene værd i jeres tilfælde.
Ofte stillede spørgsmål
Er headless altid dyrere end et traditionelt CMS?
I starten oftest ja, fordi frontend og redaktøroplevelse skal bygges i stedet for at følge med platformen. Over tid kan regnestykket vende: Hver ny kanal bliver billigere når indholdet allerede er afkoblet, og et redesign kræver ingen migrering af indhold. Med én enkelt hjemmeside og standardbehov forbliver det traditionelle CMS billigst.
Kan vi skifte til headless gradvist?
Ja. Mange traditionelle CMS’er kan køre i en hybridtilstand hvor indholdet eksponeres via API mens den gamle hjemmeside kører videre. Så kan en ny kanal, f.eks. en app, først bygges op mod det samme indhold, og hjemmesiden kan flyttes når der er grund til det.
Hvad adskiller headless fra et traditionelt CMS med API?
De fleste traditionelle CMS’er har i dag et API, men det er en tilføjelse til en arkitektur der er bygget op omkring sider og temaer. Et headless CMS er bygget API-first: Indholdet modelleres som strukturerede data uden antagelser om hvor det skal vises. Forskellen mærkes når indholdet skal genbruges i flere kanaler.
Skal redaktørerne lære nyt ved et skifte til headless?
Ja, arbejdsgangen ændrer sig: fra at bygge sider til at udfylde struktureret indhold der kan vises flere steder. Mange redaktioner oplever det som en lettelse når skabelonerne først er faldet på plads, men regn med oplæring og med at forhåndsvisning skal fungere fra første dag.
Påvirker headless vores SEO?
Ikke i sig selv. Søgemaskiner går op i det der leveres til den besøgende: indlæsningstid, rendering, struktur og indhold. Det afgøres af den frontend I bygger, ikke af hvor indholdet er lagret. En velbygget headless-løsning klarer sig ofte rigtig godt i Core Web Vitals.