Headless eller tradisjonelt CMS?
Et tradisjonelt CMS lagrer innholdet og leverer ferdige sider fra samme system, mens et headless CMS bare håndterer innhold og leverer det via API til hvilke kanaler som helst. Headless passer når innholdet skal ut i flere kanaler og organisasjonen har egen utviklerkapasitet. Et tradisjonelt CMS passer når én nettside er nok og redaktørene vil ha alt samlet.
Valget mellom headless og tradisjonelt CMS handler ikke om produktnavn, men om arkitektur: Skal innhold og presentasjon henge sammen i ett system, eller være frikoblet fra hverandre? Det valget påvirker hvilke kanaler dere kan nå, hvordan redaktørene jobber, og hva hver endring koster de neste fem årene.
Forskjellen ligger i koblingen mellom innhold og presentasjon
Et tradisjonelt CMS gjør alt i ett: Innholdet lagres, malene ligger i systemet, og sidene genereres derfra. Redaktøren ser nettsiden mens den redigeres, og én installasjon utgjør hele løsningen.
Et headless CMS har kuttet den koblingen. Systemet håndterer bare innhold, strukturert i felter og modeller, og leverer det via API. Presentasjonen bygges separat: en nettside, en app, en skjerm i en butikk. Derav navnet: Kroppen er der fortsatt, men hodet, altså presentasjonslaget, velger dere selv. Eller flere hoder.
Hva frikoblingen gir i praksis
Konsekvensene er konkrete, ikke akademiske:
- Flere kanaler uten dobbeltarbeid. Den samme produktteksten eller nyheten publiseres én gang og hentes av nettsiden, appen og infoskjermen. Ingen klipp og lim mellom systemer, ingen versjoner som glir fra hverandre.
- Redesign uten innholdsmigrering. Vil dere bytte utseende eller teknologi på nettsiden, bygges en ny frontend mot det samme API-et. Innholdet står urørt, og det er ellers ofte den dyreste og mest risikable delen av en omlegging.
- Teknologifrihet per kanal. Hvert presentasjonslag kan bygges med den teknologien som passer for akkurat den kanalen, uten at CMS-et setter rammene.
Med tradisjonell arkitektur vedlikeholder en virksomhet med nettside, app og digital skilting ofte tre innholdslag. Med headless: ett.
Hva redaktørene mister, og hvordan verktøyene har tatt igjen det meste
Frikoblingen har en pris, og den betales ofte av redaksjonen. I et tradisjonelt CMS ser redaktøren siden slik den besøkende ser den, kan bygge sider med dra-og-slipp og forhåndsvise med en gang. I tidlige headless-løsninger forsvant alt dette: Det som ble igjen, var skjemafelter og en publiseringsknapp som sendte innholdet rett ut i det blå.
Moderne verktøy har tettet det meste av gapet: forhåndsvisning mot den faktiske frontenden, visuelle redigeringsmoduser og blokkbaserte sidemaler som redaktørene setter sammen selv. Men ingenting av dette følger med gratis: Redaktøropplevelsen er en egen arbeidspakke i et headless-prosjekt. Budsjetter for den, ellers er det redaksjonen som betaler prisen i hverdagen.
Tradisjonelt og headless side om side
| Aspekt | Tradisjonelt CMS | Headless CMS |
|---|---|---|
| Kanaler | Først og fremst nettsiden | Valgfritt antall via API |
| Redigeringsmiljø | Ferdig, med forhåndsvisning | Bygges og konfigureres per prosjekt |
| Redesign | Ofte migrering av innhold og maler | Ny frontend, innholdet urørt |
| Avhengighet av utviklere | Lavere, mye løses i plattformen | Høyere, frontenden bygges for seg |
| Startkostnad | Lavere | Høyere |
Beslutningskriterier: kanaler og utviklerkapasitet
To spørsmål avgjør det meste:
- Hvor mange kanaler skal innholdet ut i, i dag og om tre år? Med én nettside strekker et tradisjonelt CMS godt til. Med nettside og app, flere markeder eller skjermer begynner headless å lønne seg.
- Hvilken utviklerkapasitet har dere? Headless forutsetter et team eller en byråpartner som bygger og forvalter frontenden. Uten det blir friheten en belastning.
I tillegg kommer størrelsen på redaksjonen: Store innholdsmengder krever at forhåndsvisning og arbeidsflyt prioriteres uansett arkitektur.
Scenario: Én kanal blir tre
En virksomhet har i dag en nettside i et tradisjonelt CMS. På veikartet står en kundeapp neste år og innhold på et par nye markeder året etter. Velger de å bygge appen med et eget innholdslag, har de snart tre sannheter om de samme produktene.
Flyttes innholdet i stedet til et headless CMS når appen bygges, blir appen den første som henter innhold fra API-et, og nettsiden den andre. Hver ny kanal etter det er et presentasjonslag til, ikke et nytt innholdssystem. Det er i den situasjonen headless går fra arkitekturdiskusjon til ren økonomi.
Står dere foran valget? Ta kontakt, så ser vi på kanalene og redaksjonen deres og på hva som faktisk er verdt kostnaden for dere.
Ofte stilte spørsmål
Er headless alltid dyrere enn et tradisjonelt CMS?
I starten som oftest ja. Frontend og redaktøropplevelse må bygges i stedet for å følge med plattformen. Over tid kan regnestykket snu: Hver ny kanal blir billigere når innholdet allerede er frikoblet, og et redesign krever ingen innholdsmigrering. Med én enkelt nettside og standardbehov forblir et tradisjonelt CMS billigst.
Kan vi gå over til headless gradvis?
Ja. Mange tradisjonelle CMS kan kjøres i hybridmodus, der innholdet eksponeres via API mens den gamle nettsiden går som før. Da kan en ny kanal, for eksempel en app, bygges mot det samme innholdet først, og nettsiden flyttes når det er grunn til det.
Hva skiller headless fra et tradisjonelt CMS med API?
De fleste tradisjonelle CMS har et API i dag, men det er et tillegg til en arkitektur bygget rundt sider og temaer. Et headless CMS er bygget API-først: Innholdet modelleres som strukturerte data uten antakelser om hvor det skal vises. Forskjellen merkes når innholdet skal gjenbrukes i flere kanaler.
Må redaktørene omstille seg når dere går over til headless?
Ja, arbeidsmåten endres: fra å bygge sider til å fylle inn strukturert innhold som kan vises flere steder. Mange redaksjoner opplever det som en lettelse når malene først er satt opp, men regn med opplæring og med at forhåndsvisning må være på plass fra første dag.
Påvirker headless SEO-en vår?
Ikke i seg selv. Søkemotorene bryr seg om det som leveres til den besøkende: lastetid, rendering, struktur og innhold. Det avgjøres av frontenden dere bygger, ikke av hvor innholdet lagres. En godt bygget headless-løsning gjør det ofte svært godt i Core Web Vitals.