Headless CMS
Hva er et headless CMS, og hva betyr det for SEO? Google ser ikke CMS-et, den ser frontenden. Se hva dere skal kreve av oppsettet før dere migrerer.
Valget av publiseringsverktøy blir ofte tatt som et redaksjonelt spørsmål og får konsekvenser som er tekniske. Det er derfor headless CMS hører hjemme i en SEO-sammenheng: ikke fordi Google har en mening om hvilket system dere skriver i, men fordi arkitekturen bak avgjør hva søkemotorene og AI-crawlerne faktisk får se.
Hva er et headless CMS?
Et headless CMS er et publiseringssystem der innholdet er skilt fra visningen. Backenden lagrer og strukturerer innholdet og leverer det ut gjennom et API. Frontenden, altså nettstedet, er et eget lag som henter innholdet inn og bestemmer hvordan det ser ut.
"Headless" viser til nettopp det: systemet har ikke noe hode, ingen innebygd visning. Innholdet kan gå til nettstedet, til appen, til nyhetsbrevet og til en skjerm i butikken fra samme kilde, uten å bli skrevet på nytt for hver flate.
Et tradisjonelt CMS som WordPress gjør begge jobbene i samme system. Innhold, mal og visning ligger sammen, og det er både styrken og begrensningen: det er raskt å komme i gang, og tungt å endre uttrykket eller ytelsen uten å røre alt.
Vanlige headless-systemer er Storyblok, Sanity, Contentful, Strapi og Prismic. Frontenden bygges typisk i Next.js, Nuxt, SvelteKit eller Astro.
Google ser ikke CMS-et. Den ser frontenden
Dette er den ene setningen som betyr noe i denne guiden. Google kan ikke se hvilket headless CMS dere bruker, og det påvirker ikke rangeringen. Det som påvirker rangeringen, er hvordan frontenden leverer innholdet.
Grovt sagt: CMS-et tar seg av innholdet, og frontenden tar seg av teknikken. Derfor er valget av rammeverk og renderingsstrategi den beslutningen som får følger for synligheten, ikke valget av CMS.
Og her er skillet skarpere enn det var for noen år siden. En frontend som først sender et tomt skall og deretter bygger innholdet i nettleseren med JavaScript, kan fortsatt bli lest av Googlebot, som gjengir sider. Men crawlerne bak ChatGPT, Perplexity og Claude gjør i praksis ikke det samme. De henter HTML-en og leser det som står der. Ligger teksten deres bare i JavaScript, er dere usynlige på de flatene, selv om Google klarer å finne dere.
Kravet er derfor enkelt å formulere: innholdet skal ligge i HTML-en som serveren sender. Server-side rendering eller statisk generering løser det. Ren klientsidegjengivelse gjør det ikke. Vi går grundigere gjennom mekanikken i JS SEO og rendering.
Hva norske nettbutikker faktisk bruker
Da vi kartla de 50 største norske nettbutikkene, var CMS-bildet påfallende spredt. Microsoft ASP.NET og Magento lå på toppen, og resten fordelte seg over et bredt felt av både skreddersydde og hyllevare-løsninger.
Det interessante var ikke rekkefølgen, men konsekvensen: valget av system la rammene for hvor lett eller vanskelig det var å optimalisere teknisk. Noen av butikkene kunne rette en malfeil på tvers av tusenvis av produktsider på en ettermiddag. Andre måtte gjennom et utviklingsløp for å endre en sidetittel. Den forskjellen dukker opp igjen hver eneste måned i et løpende SEO-arbeid, og den er verdt å prise inn allerede før dere velger plattform.
Tre reelle fordeler
Hastigheten. En statisk generert frontend leverer ferdige sider fra et CDN. Det gir et bedre utgangspunkt for Core Web Vitals enn et tradisjonelt oppsett som bygger hver side på nytt ved hvert besøk, og hastighet merkes både av brukeren og i målingene.
Kontrollen over markup. Dere bestemmer selv hva som ligger i HTML-en: overskriftshierarki, strukturerte data, canonical, hreflang. I et tradisjonelt CMS er dette ofte noe et tema eller et plugin bestemmer for dere.
Skalerbarheten. Backenden er driftet som en tjeneste, og frontenden kan optimaliseres per flate. Store kataloger og høy trafikk håndteres uten at redaksjonen merker det.
Sjekklisten før dere sier ja
Skal dere over på headless, er det fem ting dere bør ha skriftlig fra leverandøren:
- Renderingsstrategi. SSR eller SSG for alt innhold som skal rangere. Få det bekreftet, og få det testet ved å se på kildekoden til en ferdig side.
- Kontroll over metadata. Redaksjonen skal kunne sette sidetittel, meta description, canonical og noindex uten en utvikler.
- Sitemap og robots.txt. Genereres dynamisk, oppdateres ved publisering.
- Strukturerte data. Schema-markup som del av malene, ikke som et etterarbeid.
- URL-kontroll. Redaksjonen skal kunne styre slugs, og systemet skal håndtere redirects når de endres.
Mangler noen av punktene, er de dyrere å legge til etterpå enn å kreve nå.
Migreringen er der risikoen ligger
De største trafikkfallene vi rykker ut på, kommer ikke av dårlige plattformvalg. De kommer av migreringer der URL-strukturen endret seg uten at redirects fulgte med, der metadata forsvant i overføringen, eller der den nye frontenden viste seg å bygge innholdet i nettleseren.
Alle tre kan dere planlegge dere ut av. Kartlegg URL-ene og trafikken før flyttingen, legg 301-kartet før lansering, og kontroller de viktigste sidene i indeksen dagene etter. Står dere foran et bytte, er site-migrering leveransen vår for nettopp den prosessen, og webutvikling er stedet å se hvis frontenden skal bygges riktig fra starten.
Resten av det tekniske fundamentet finner dere i oversikten over teknisk SEO. Hvordan det nåværende oppsettet deres oppfører seg mot søkemotorene og AI-crawlerne, får dere svart på i en gratis SEO-analyse.
