Headless WordPress i 2026: Hvornår giver det mening?
"Headless WordPress" er et af de mest hypede buzzwords i WordPress-verdenen. Idéen lyder fantastisk: Behold WordPress som dit CMS, men brug et moderne frontend-framework som Next.js eller Astro til at bygge selve hjemmesiden.
Resultatet? Lynhurtige sider, total designfrihed og en moderne tech stack.
Men virkeligheden er mere nuanceret. Headless WordPress løser reelle problemer — men det skaber også nye. Og for mange virksomheder er det simpelthen overkill.
Her er min ærlige vurdering efter at have bygget både klassiske og headless WordPress-løsninger.
Hvad er headless WordPress?
I et headless setup bruger du WordPress kun som backend — til at skrive indhold, administrere sider og håndtere data. Selve den hjemmeside brugerne ser, bygges med et separat frontend-framework (Next.js, Astro, Nuxt, etc.) der henter data fra WordPress via REST API eller WPGraphQL.
Hvordan headless WordPress fungerer
I et klassisk WordPress-setup ser flowet sådan ud:
- Bruger besøger side → WordPress genererer HTML → Browser viser siden
I et headless setup:
- Bruger besøger side → Frontend-framework henter data fra WordPress API → Framework genererer HTML → Browser viser siden
WordPress er stadig "hjernen" — men den taler ikke direkte til brugeren. Den taler til et mellemled.
De to mest populære tilgange
| Tilgang | Frontend | Datahentning | Hosting |
|---|---|---|---|
| Next.js + WPGraphQL | React/Next.js | GraphQL | Vercel, Netlify, Docker |
| Astro + REST API | Astro (multi-framework) | REST API | Cloudflare Pages, Netlify |
Next.js er det mest modne valg med størst community. Astro er nyere men genererer endnu mindre JavaScript — perfekt til indholdstunge sider.
De reelle fordele
1. Performance
Det her er den primære grund til at gå headless. Tallene taler for sig selv:
| Metrik | Klassisk WordPress | Headless (Next.js) | Headless (Astro) |
|---|---|---|---|
| TTFB | 400-1200ms | 50-200ms | 30-150ms |
| LCP (mobil) | 2.5-5.0s | 1.0-2.0s | 0.8-1.5s |
| JavaScript | 200-800 KB | 80-200 KB | 10-50 KB |
| PageSpeed (mobil) | 40-75 | 85-100 | 90-100 |
Forskellen skyldes primært at klassisk WordPress genererer HTML on-the-fly med PHP, mens headless-løsninger typisk pre-renderer sider som statiske filer.
2. Designfrihed
Med headless er du ikke begrænset af WordPress-temaer eller page builders. Du har fuld kontrol over:
- Animationer og overgange
- Komplekse layouts der ikke passer i WordPress' blok-system
- Interaktive elementer (konfiguratorer, dashboards, realtids-data)
- Konsistent designsystem på tværs af alle sider
3. Sikkerhed
Når WordPress ikke er eksponeret direkte mod internettet, reduceres angrebsfladen markant:
- Ingen brute force mod
wp-login.php - Ingen direkte adgang til plugins med sikkerhedshuller
- WordPress kan køre bag en firewall eller VPN
- Frontend er statiske filer — intet at hacke
4. Skalerbarhed
Statiske filer + CDN skalerer uendeligt. Et spike på 100.000 besøgende crasher ikke din side — det er bare flere filhentninger fra et CDN.
De reelle ulemper
1. Kompleksitet og omkostninger
Det her er den elefant i rummet som headless-entusiaster sjældent nævner:
| Faktor | Klassisk WordPress | Headless WordPress |
|---|---|---|
| Udviklingstid | 40-80 timer | 80-200 timer |
| Krævet kompetence | PHP, WordPress | PHP, WordPress + React/JS + API + hosting |
| Løbende vedligeholdelse | 1 system | 2 systemer |
| Hosting-kompleksitet | 1 server | 2+ services |
| Plugin-kompatibilitet | Fuld | Begrænset |
Du betaler dobbelt — for WordPress-backend OG for frontend-udvikling. Og du har brug for en udvikler der mestrer begge verdener.
2. Plugin-problemer
De fleste WordPress-plugins forventer at kontrollere frontend. I et headless setup virker de ikke:
Virker ikke:
- Page builders (Elementor, Bricks, Divi)
- Kontaktform-plugins (Contact Form 7, WPForms)
- SEO-plugins frontend-features (Yoast sitemap, meta tags)
- Cookie consent-plugins
- Kommentar-systemer
Virker stadig:
- ACF / Meta Box (custom fields via API)
- Yoast SEO (meta-data via API med plugin)
- WooCommerce (via WooGraphQL — men komplekst)
- WPML/Polylang (sprogdata via API)
Det betyder at du skal genimplementere mange features manuelt i frontend.
3. Preview og live-redigering
WordPress' "Preview"-knap og live customizer virker ikke i et headless setup. Du kan opsætte draft preview via API, men det kræver ekstra udvikling og er aldrig helt lige så smooth.
Klienter der er vant til at se ændringer live i WordPress vil mærke forskellen.
4. Caching og invalidering
Når du opdaterer en artikel i WordPress, skal frontend-cachen invalideres. Det kræver webhooks, ISR (Incremental Static Regeneration) eller on-demand revalidation. Det er løseligt — men det er endnu et system at vedligeholde.
Hvornår headless giver mening
Din side er performance-kritisk
E-commerce med høj konvertering, mediasites med millioner af sidevisninger, eller lead generation hvor hvert millisekund tæller. Headless giver dokumenterbart bedre Core Web Vitals.
Du har et udviklerteam
Headless kræver løbende vedligeholdelse af to systemer. Hvis du ikke har in-house udviklere eller en fast freelancer, bliver det dyrt og skrøbeligt.
Du har brug for avanceret frontend
Interaktive dashboards, realtids-data, komplekse animationer, eller en app-lignende oplevelse der ikke kan bygges med WordPress-blokke.
Du vil have WordPress som centralt CMS for flere platforme
Samme WordPress-backend leverer indhold til website, app og digital signage? Perfekt headless use case.
Hvornår headless er overkill
- Typisk virksomhedsside (5-15 sider) — et block theme er hurtigere at bygge og billigere at vedligeholde
- Blog eller nyhedsside — WordPress' native blogging er allerede fremragende
- Klienten redigerer selv — headless preview er aldrig lige så godt som klassisk WordPress
- Budgettet er under 50.000 kr. — headless-overhead spiser budgettet
- Du har ikke en fast udvikler — ingen bør driftes af "det bureau der byggede det for 2 år siden"
Den dyre fejl
Det mest almindelige scenarie jeg ser: En virksomhed betaler 80.000-150.000 kr. for en headless WordPress-løsning, og 2 år senere kan ingen vedligeholde den, fordi det originale bureau/freelancer ikke er tilgængelig. De ender med at genbygge fra bunden.
Headless er kun en god investering hvis du har en langsigtet plan for vedligeholdelse.
Alternativerne i 2026
Før du vælger headless, overvej disse alternativer der giver mange af de samme fordele:
| Alternativ | Performance | Kompleksitet | Pris |
|---|---|---|---|
| Block theme + god hosting | God (LCP 1.5-2.5s) | Lav | Lav |
| Block theme + Cloudflare | Meget god (LCP 1.0-2.0s) | Lav-medium | Lav |
| Bricks Builder + caching | God (LCP 1.5-3.0s) | Medium | Medium |
| Headless + Next.js | Fremragende (LCP 0.8-1.5s) | Høj | Høj |
| Headless + Astro | Bedst (LCP 0.5-1.2s) | Høj | Høj |
For 80% af danske virksomheder er "Block theme + Cloudflare" det sweet spot der giver 90% af headless-performance til 30% af prisen.
Konklusion
Headless WordPress er et fantastisk værktøj — når det bruges til de rigtige projekter. Men det er ikke en universel opgradering. Det er et arkitekturvalg med reelle trade-offs.
Min tommelfingerregel:
- Under 50.000 kr. budget: Klassisk WordPress med block theme
- 50.000-150.000 kr.: Klassisk WordPress med premium hosting + CDN
- Over 150.000 kr. og kompleks frontend: Overvej headless
Det vigtigste spørgsmål er ikke "er headless bedre?" — det er "har vi ressourcerne til at vedligeholde det?"
Usikker på valget?
Jeg hjælper med begge dele — klassisk WordPress og headless med Next.js. Lad os tage en snak om dit projekt og finde den rigtige arkitektur. Book en gratis afklaring.
