Hvad headless WordPress betyder i praksis

Headless WordPress betyder, at WordPress bruges til indholdsredigering, medier, brugere og publicering, mens det offentlige website renderes af noget andet.

I stedet for at et traditionelt WordPress-tema producerer de synlige sider, henter et separat frontendlag som Astro, Next.js, Nuxt eller en custom applikation indhold fra WordPress og bygger den offentlige brugeroplevelse.

For en dansk virksomhed kan det være nyttigt, hvis WordPress-administrationen fungerer godt, men det offentlige site har brug for et hurtigere, renere og mere kontrolleret frontendlag til søgning, indholdsstruktur, formularer eller langsigtet vedligeholdelse.

Det er ikke automatisk bedre end almindelig WordPress. Det er et tradeoff.

Den enkle forklaring

På et almindeligt WordPress-site håndterer WordPress begge sider:

• Administrationsdelen hvor indhold redigeres
• Det offentlige tema som besøgende ser

I en headless WordPress-løsning skilles de to ansvar ad:

• WordPress forbliver CMS
• Et API udstiller godkendt indhold
• Et separat frontendlag laver indholdet om til sider

WordPress har allerede et REST API til struktureret adgang til indhold. Nogle projekter bruger GraphQL via et plugin som WPGraphQL i stedet. Det praktiske valg afhænger af indholdsmodellen, udviklerworkflowet, cachingbehov og hvor meget custom data der skal udstilles.

Det vigtige er, at WordPress ikke længere har ansvaret for at rendere det offentlige tema. WordPress bliver indholdsbackend.

Hvorfor virksomheder overvejer det

Headless WordPress dukker typisk op af fire grunde.

For det første er det offentlige site blevet for begrænset af tema eller page builder. En dansk servicevirksomhed, B2B-virksomhed, rådgiver, webshop-light løsning eller bookingorienteret virksomhed kan have brug for hurtige landingssider, struktureret fagligt indhold, tydelige kontaktveje og bedre kontrol end det nuværende tema giver.

For det andet ønsker virksomheden bedre frontend-performance. Et statisk eller server-renderet frontendlag kan reducere unødvendigt temaarbejde, plugin-output og client-side rod, hvis det bygges ordentligt.

For det tredje vil redaktørerne stadig gerne bruge WordPress. De kender måske allerede indlæg, sider, medier, custom fields, kategorier, kladder og publiceringsstatus. At udskifte hele CMS’et kan skabe mere friktion end værdi.

For det fjerde skal indholdet måske bruges flere steder. Det samme WordPress-indhold kan føde et offentligt website, en app, en bookingflade, et nyhedsbrevflow eller et internt værktøj.

Det er reelle grunde. “Headless” i sig selv er ikke en grund.

Hvad ændrer sig teknisk

En headless løsning ændrer projektets form.

Frontendlaget skal nu håndtere routing, templates, metadata, billeder, interne links, sitemaps, redirects, formularer, caching, previews og deployments. WordPress skal stadig have pluginopdateringer, sikkerhed, backups, indholdsmodellering, brugerroller og API-adfærd.

Der er altså to systemer at vedligeholde i stedet for ét.

For et mindre dansk virksomhedswebsite kan det stadig være et fornuftigt tradeoff, hvis det offentlige site er vigtigt nok, og implementeringen holdes enkel. For eksempel:

• WordPress til indholdsredigering
• Astro til statisk-first offentlige sider
• Cloudflare til DNS, caching, redirects, headers og edge-levering
• Et lille integrationslag til kontaktformularer, bookingforespørgsler eller API-data

Det overlapper med arkitekturen i Astro og Cloudflare til AI-klare websites i Danmark, men WordPress bliver den strukturerede indholdskilde i stedet for Markdown- eller MDX-filer.

SEO er ikke automatisk

Headless WordPress kan være stærkt til teknisk SEO, men kun hvis frontendlaget renderer crawlable sider med stabile URL’er, brugbar metadata, rene overskrifter, interne links, canonical URLs, alt-tekster på billeder og sitemap.

Man skal ikke flytte til et JavaScript-frontend og samtidig gemme vigtigt indhold bag client-side rendering. Googles aktuelle JavaScript SEO-vejledning peger stadig tilbage på de praktiske grundregler: gør indhold og links tilgængelige i renderede sider, test hvad søgemaskiner kan se, og undgå skrøbelige antagelser om rendering.

For et dansk website skal indholdet også stadig have det rigtige markedssignal. En headless ombygning må ikke fjerne nyttig lokal kontekst fra sider om danske ydelser, priser i DKK, moms, kontaktveje, serviceområder eller dansk søgeadfærd.

Hvis det nuværende WordPress-site allerede får søgetrafik, er migreringen vigtig. URL’er, redirects, canonical tags, metadata, overskrifter, interne links, schema, sprogalternativer og tracking bør kortlægges før launch. Den bredere SEO-tjekliste til website-migrering gælder også her.

Hvornår headless WordPress giver mening

Headless WordPress er værd at overveje, når der er en tydelig grund til den ekstra arkitektur:

• Redaktører vil beholde WordPress, men det offentlige frontendlag kræver mere kontrol
• Det eksisterende tema eller page builder gør vigtige sider langsomme
• Sitet har struktureret indhold som ydelser, cases, lokationer, produkter, guides eller dokumentation
• Det offentlige website kan få reel værdi af statisk generering, edge caching eller et renere komponentsystem
• Projektet har brug for at genbruge indhold i mere end ét frontendlag
• Virksomheden kan vedligeholde både WordPress og frontend-deployment

Det kan passe til danske servicevirksomheder, rådgivere, B2B-sites, kataloger, bookingflows og indholdstunge websites, hvor offentlige sider skaber henvendelser.

Det kan også være en gradvis modernisering. Den eksisterende WordPress-administration kan forblive genkendelig, mens det offentlige frontendlag bliver hurtigere og lettere at forstå.

Hvornår almindelig WordPress er bedre

Headless WordPress er ofte det forkerte svar til mindre websites, der egentlig bare har brug for praktisk forbedring.

Hvis sitet er langsomt på grund af billeder, hosting, plugins, databasefylde, dårlig cache eller et tungt tema, bør arbejdet starte med en WordPress performance-audit eller en fokuseret gennemgang af en langsom hjemmeside. Et nyt frontendlag kan skjule det oprindelige problem uden at rette de driftsvaner, der skabte det.

Almindelig WordPress kan være bedre når:

• Sitet er enkelt, og det nuværende tema kan vedligeholdes
• Redaktører er afhængige af visuelle page-builder workflows
• WooCommerce, medlemskab, formularer, kommentarer eller plugin-renderede features driver forretningen
• Budgettet ikke passer til to systemer
• Ingen kommer til at vedligeholde previews, API-ændringer, builds og deployment-tjek

Headless bør gøre det offentlige website enklere. Det bør ikke skabe en custom platform, som ingen har lyst til at eje.

Den praktiske migrationsvej

Hvis headless WordPress kan være relevant, så start småt.

Først gennemgås det nuværende WordPress-site. Find indholdstyper, custom fields, taxonomier, mediehåndtering, plugins, redirects, SEO-metadata, søgetrafik, formularer og forretningskritiske sider.

Derefter vælges én eller to indholdstyper til en prototype. Lad være med at bygge hele sitet om, før API’et beviser, at det udstiller de rigtige data, og frontendlaget kan rendere de rigtige sider.

Derefter skal redigering og preview afklares. Redaktører skal forstå, hvornår en ændring bliver synlig på det offentlige site, hvordan kladder previewes, og hvad der sker, hvis et build fejler.

Til sidst skal driften holdes kedelig: backups, staging, versionsstyring, deploy-logs, rollback, cache-invalidering og tydeligt ejerskab af WordPress-plugins.

Her bliver stagingmiljø til WordPress og PHP, rettelser i custom WordPress-plugins og driftssikre API-integrationer relevante. Headless WordPress er ikke kun en frontendbeslutning.

Min normale anbefaling

Til de fleste mindre virksomhedswebsites ville jeg ikke starte med at anbefale headless WordPress. Jeg ville først undersøge, om almindelig WordPress kan gøres hurtigere, renere, sikrere og lettere at redigere.

Jeg ville overveje headless WordPress, hvis virksomheden har en reel indholdsmodel, et offentligt site hvor hastighed og struktur betyder meget, og en tydelig grund til at beholde WordPress som redigeringssystem, men erstatte frontendlaget.

For danske virksomheder kan det være et website med strukturerede ydelsessider, cases, lokationer, produktkatalog, faglige guides eller et eksisterende WordPress-site, hvor administrationen er nyttig, men den offentlige del er blevet for tung at vedligeholde.

Hvis du overvejer headless WordPress til et dansk website, kan du sende mig den nuværende URL og hvad du vil forbedre. Jeg kan hjælpe med at vurdere, om headless WordPress er berettiget, eller om en mere fokuseret WordPress-, Astro-, Cloudflare- eller performanceoprydning løser det rigtige problem med mindre risiko.