Headless CMS

Et headless CMS er et CMS, hvor systemet til at administrere indhold er adskilt fra den frontend, som besøgende ser. CMS'et fungerer som indholdsbackend, mens en separat applikation henter sider, tekster, billeder og andre data gennem et API og bestemmer, hvordan de bliver vist.

I et traditionelt CMS hænger backend og frontend tættere sammen. I WordPress kan redaktøren eksempelvis oprette en side, og et tema renderer den direkte på websitet. WordPress kan dog også bruges headless. WordPress REST API gør indhold tilgængeligt som JSON, så en separat frontend kan hente og vise det.

Ordet "headless" kommer af, at præsentationslaget – hovedet – ikke er en fast del af CMS'et. Det betyder ikke, at løsningen ingen frontend har. Den har netop en frontend, men den er bygget og deployet uafhængigt af indholdssystemet. Frontenden kan være et website, en app, en informationsskærm eller flere forskellige kanaler på samme tid.

Et headless CMS er heller ikke automatisk det samme som et statisk website. En separat frontend kan generere sider på build-tidspunktet, på serveren eller dynamisk i browseren. Arkitekturen siger først og fremmest noget om adskillelsen mellem indholdslaget og præsentationslaget.

Der findes både CMS'er, der er udviklet specifikt som headless, og traditionelle systemer, der kan bruges decoupled. Drupal dokumenterer eksempelvis en decoupled arkitektur, hvor Drupal fungerer som indholdsbackend og leverer data til en ekstern frontend. WordPress kan på samme måde bruges som backend gennem REST API'et.

Headless bliver ofte fremhævet som moderne og fleksibelt, men det er ikke nødvendigvis den rigtige løsning til en almindelig virksomhedshjemmeside. Adskillelsen giver muligheder, men den betyder også, at funktioner som preview, menuer, formularer, redirects, SEO-data og sidebygning ikke længere automatisk følger med hele vejen til frontenden.

Start med at beskrive problemet, før du vælger arkitekturen. Skal samme indhold bruges på website, mobilapp og kundeportal? Har virksomheden et frontend-team, der arbejder i en bestemt JavaScript-stack? Skal flere websites dele struktureret indhold? Eller er behovet blot en almindelig hjemmeside med nyheder, cases og kontaktformular? Headless giver mest mening, når adskillelsen løser et konkret krav.

Indholdsmodellen er central. I stedet for at tænke hele websider som én stor redigerbar flade bør indhold ofte opdeles i strukturerede felter og komponenter. En medarbejderprofil kan eksempelvis bestå af navn, titel, billede, telefon og biografi. De samme data kan derefter bruges på websites, i en app eller i andre systemer uden at blive kopieret.

API'et bliver kontrakten mellem backend og frontend. Det skal være klart, hvilke felter der findes, hvordan relationer leveres, hvordan billeder håndteres, og hvad der sker, når indholdsmodellen ændres. WordPress REST API eksponerer indhold som JSON, mens Drupal blandt andet kan bruges med JSON:API. Andre platforme har deres egne REST- eller GraphQL-baserede grænseflader.

Preview skal planlægges fra starten. I et traditionelt CMS kan en redaktør ofte trykke "Forhåndsvis" og se den kladde, der arbejdes på. I en headless løsning ligger frontenden et andet sted og skal derfor kunne hente ikke-publiceret indhold sikkert. Hvis preview først tænkes ind til sidst, kan redaktørerne ende med at publicere for at se, hvordan en ændring ser ud.

Det samme gælder SEO. Sidetitler, metabeskrivelser, canonical-tags, robots-indstillinger, strukturerede data og redirects kan godt administreres i et headless CMS, men frontenden skal implementere dem korrekt. Et felt i backend har ingen SEO-værdi, hvis frontend-applikationen aldrig sætter det i HTML'en.

Formularer kræver også en beslutning. En kontaktformular i et traditionelt WordPress-site kan håndteres af et plugin i samme installation. I en headless frontend kan formularen i stedet sende til et API-endpoint, en ekstern formularservice eller en specialbygget backend. Spamkontrol, kvitteringer og fejlbeskeder skal stadig fungere.

Driften er delt mellem flere dele. CMS'et skal hostes og opdateres, frontenden skal deployes, og forbindelsen mellem dem skal overvåges. Hvis et webhook bruges til at starte et nyt build, når indhold publiceres, skal fejlede builds kunne opdages. Et webhook er nyttigt, men bør ikke være et usynligt kritisk punkt uden logning.

Cache og performance skal vurderes på tværs af arkitekturen. Headless kan give meget hurtige websites, fordi frontenden kan optimeres aggressivt og leveres gennem CDN. Men et langsomt API, tunge klient-scripts eller dårlig billedhåndtering kan stadig give en langsom oplevelse. Arkitekturen er en mulighed for performance, ikke en garanti.

Hvis du overvejer headless til en ny hjemmeside, så sammenlign også med et traditionelt setup. Hvis redaktørerne har brug for fri sideopbygning, hurtige kampagnesider og få integrationer, kan et almindeligt CMS være enklere. Hvis indhold skal deles på tværs af produkter og frontends, bliver headless mere interessant.

En medlemsorganisation har et offentligt website, en mobilapp og en lukket medlemsportal. De tre kanaler bruger mange af de samme artikler, arrangementer, medarbejderprofiler og dokumenter. Tidligere bliver indhold kopieret mellem flere systemer, og rettelser skal laves tre steder.

Organisationen vælger et headless setup, hvor CMS'et bliver fælles kilde til indhold. Hver indholdstype får strukturerede felter. Et arrangement har eksempelvis titel, dato, sted, beskrivelse, billede og tilmeldingslink. Frontends kan vælge de felter, de har brug for.

Websitet bygges som en separat frontend, mens appen henter de samme data gennem API'et. Medlemsportalen bruger kun indhold, som den pågældende bruger har adgang til. Det betyder, at CMS'et ikke længere ejer den visuelle præsentation; det ejer indholdet og reglerne omkring det.

Redaktionen får et preview-link, som åbner en sikker forhåndsvisning af den aktuelle kladde i website-frontenden. Når en artikel publiceres, sender CMS'et et webhook, der opdaterer de relevante sider. Hvis buildet fejler, bliver det registreret, så redaktionen ikke tror, at en publicering er gået igennem.

SEO-felter ligger stadig i CMS'et. Frontenden bruger dem til title, meta description, canonical og sociale delingsdata. Redirects har ligeledes en central model, så en ændret URL ikke ender som et dødt link, bare fordi routing ligger uden for CMS'et.

Organisationen får værdi af headless, fordi de faktisk har flere kanaler og et behov for at genbruge struktureret indhold. Hvis projektet kun havde været ét almindeligt informationswebsite, ville den ekstra frontend, API-håndtering og deploymentproces være sværere at forsvare.

Det samme princip gælder et bureauprojekt. En webbureau-løsning bør ikke blive headless for at se teknisk avanceret ud. Arkitekturen skal vælges, fordi den løser en konkret opgave bedre end den simplere løsning.

Den største faldgrube er at vælge headless som modeord. En separat frontend betyder flere kodebaser, flere deployments og flere steder at fejlsøge. Hvis virksomheden ikke får en tydelig gevinst, betaler den blot for ekstra kompleksitet.

Redaktøroplevelsen bliver ofte undervurderet. Udviklere kan være tilfredse med rene API'er, mens marketingafdelingen savner at kunne se siden, flytte sektioner og lave en kampagne uden en udvikler. Preview og komponentmodel skal derfor vurderes lige så seriøst som teknologien.

En anden fejl er at tro, at headless automatisk løser performance og SEO. Frontenden skal stadig generere korrekt HTML, håndtere billeder, metadata, interne links, redirects og indeksering. En teknisk moderne frontend kan sagtens være dårlig for både brugere og Google.

Pas også på med at duplikere forretningslogik. Hvis både CMS og frontend hver især forsøger at bestemme navigation, rettigheder eller URL-struktur uden en klar master, opstår uoverensstemmelser. Definér hvilket system der ejer hvilke regler.

Afhængigheder kan flytte sig i stedet for at forsvinde. Et traditionelt CMS kan være afhængigt af plugins. En headless løsning kan være afhængig af frontend-framework, hostingplatform, buildpipeline, API-klienter og cloudtjenester. Dokumentér alle kritiske dele.

Endelig kan en dårlig indholdsmodel gøre hele idéen om genbrug værdiløs. Hvis redaktøren gemmer hele sider som færdig HTML i ét felt, er indholdet svært at bruge på andre kanaler. Headless fungerer bedst, når indholdet modelleres efter betydning og ikke kun efter én sides layout.

Headless og decoupled bruges ofte næsten synonymt. "Decoupled" fremhæver selve adskillelsen mellem backend og frontend. "Headless" bruges typisk om et CMS, hvor præsentationslaget ikke er den faste outputkanal. Der findes også hybride og progressivt decoupled løsninger, hvor kun dele af frontenden er adskilt.

WordPress behøver ikke være headless for at bruge REST API'et. Den officielle dokumentation siger direkte, at man ikke skal føle sig presset til at bruge REST API'et, hvis et almindeligt WordPress-site allerede løser opgaven. API'et er et værktøj, ikke et mål.

Drupal har tilsvarende officielle guides til decoupled Drupal og beskriver både backend, API'er og separate frontends. Det viser, at headless ikke er knyttet til én bestemt leverandør eller ét bestemt CMS.

Et headless CMS kan være både open source og kommercielt SaaS. Arkitekturformen siger ikke noget om licens eller ejerskab. Et cloudbaseret headless CMS kan være mere leverandørbundet end et traditionelt open source-CMS, selv om frontenden er helt separat.

REST og GraphQL er to almindelige måder at levere indhold på, men et headless projekt behøver ikke vælge den mest avancerede API-teknologi. Det bedste interface er det, som frontend-teamet kan bruge stabilt, dokumentere og vedligeholde.

Det er også muligt at bygge en webshop headless, men checkout, lager, kurv, login og betaling gør arkitekturen mere kompleks end et almindeligt content-site. Hvis en virksomhed primært skal have en webshop, bør gevinsten ved en separat commerce-frontend derfor vurderes meget konkret.

For de fleste projekter er det nyttigt at starte med det simpleste setup, der opfylder kravene. Headless bør vælges, når flere kanaler, særlige frontendkrav eller integrationsbehov gør adskillelsen værdifuld. Ellers kan et traditionelt CMS give mere funktion for færre udviklingstimer.