Hvad headless WordPress betyder i praksis

Headless WordPress betyder, at WordPress bruges til indholdsredigering, medier, brugere og publicering, mens den offentlige hjemmeside 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 specialudviklet applikation indhold fra WordPress og bygger den offentlige brugeroplevelse.

Det kan være nyttigt, hvis WordPress-administrationen fungerer godt, men den offentlige hjemmeside 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 en afvejning.

Den enkle forklaring

På en almindelig WordPress-hjemmeside 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 fornuftige valg afhænger af indholdsmodellen, udviklerens arbejdsgang, behovet for cache og hvor mange specialdata 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 den offentlige hjemmeside blevet for begrænset af temaet eller sidebyggeren. En servicevirksomhed, B2B-virksomhed, rådgiver, webshop 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 en hurtigere frontend. Et statisk eller servergenereret frontendlag kan reducere unødvendigt arbejde i temaet, overflødig kode fra plugins og rod i browseren, hvis det bygges ordentligt.

For det tredje vil redaktørerne stadig gerne bruge WordPress. De kender måske allerede indlæg, sider, medier, specialfelter, 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 en offentlig hjemmeside, 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 ruter, skabeloner, metadata, billeder, interne links, sitemaps, viderestillinger, formularer, cache, forhåndsvisninger og udrulninger. WordPress skal stadig have pluginopdateringer, sikkerhed, sikkerhedskopier, indholdsmodellering, brugerroller og API-adfærd.

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

For en mindre virksomhedshjemmeside kan det stadig være et fornuftigt kompromis, hvis den offentlige hjemmeside er vigtig nok, og implementeringen holdes enkel. For eksempel:

• WordPress til indholdsredigering
• Astro til statisk-first offentlige sider
• Cloudflare til DNS, cache, viderestillinger, HTTP-headere og levering tæt på brugeren
• Et lille integrationslag til kontaktformularer, bookingforespørgsler eller API-data

Det overlapper med arkitekturen i Astro og Cloudflare til AI-klare hjemmesider, 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 leverer sider, som søgemaskiner kan gennemgå, med stabile URL’er, brugbare metadata, rene overskrifter, interne links, canonical-URL’er, alt-tekster på billeder og sitemap.

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

På regionale eller flersprogede hjemmesider skal indholdet stadig have de rigtige målgruppesignaler. En headless ombygning må ikke fjerne nyttig kontekst om sprog, lokation, priser, kontaktveje eller serviceområder fra sider, hvor oplysningerne er relevante.

Hvis den nuværende WordPress-hjemmeside allerede får søgetrafik, er migreringen vigtig. URL’er, viderestillinger, canonical-tags, metadata, overskrifter, interne links, strukturerede data, sprogalternativer og måling bør kortlægges før lanceringen. Den bredere SEO-tjekliste til hjemmesidemigrering 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 sidebyggeren gør vigtige sider langsomme
• Hjemmesiden har struktureret indhold som ydelser, cases, lokationer, produkter, guider eller dokumentation
• Den offentlige hjemmeside kan få reel værdi af statisk generering, cache tæt på brugeren eller et renere komponentsystem
• Projektet har brug for at genbruge indhold i mere end ét frontendlag
• Virksomheden kan vedligeholde både WordPress og udrulningen af frontend

Det kan passe til servicevirksomheder, rådgivere, B2B-hjemmesider, kataloger, bookingforløb og indholdstunge hjemmesider, 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 hjemmesider, der egentlig bare har brug for målrettet forbedring.

Hvis hjemmesiden er langsom på grund af billeder, server, plugins, en overfyldt database, dårlig cache eller et tungt tema, bør arbejdet starte med en gennemgang af WordPress-hastigheden eller performanceforløbet i guiden til hjemmesideoptimering. Et nyt frontendlag kan skjule det oprindelige problem uden at rette de driftsvaner, der skabte det.

Almindelig WordPress kan være bedre når:

• Hjemmesiden er enkel, og det nuværende tema kan vedligeholdes
• Redaktører er afhængige af den visuelle arbejdsgang i en sidebygger
• WooCommerce, medlemskab, formularer, kommentarer eller plugin-renderede features driver forretningen
• Budgettet ikke passer til to systemer
• Ingen kommer til at vedligeholde forhåndsvisninger, API-ændringer, builds og kontrol af udrulningen

Headless bør gøre den offentlige hjemmeside enklere. Det bør ikke skabe en specialudviklet platform, som ingen har lyst til at tage ansvaret for.

Den kontrollerede migrationsvej

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

Først gennemgås den nuværende WordPress-hjemmeside. Find indholdstyper, specialfelter, taksonomier, mediehåndtering, plugins, viderestillinger, 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 hjemmesiden om, før API’et viser, at det stiller de rigtige data til rådighed, og frontendlaget kan vise de rigtige sider.

Derefter skal redigering og forhåndsvisning afklares. Redaktører skal forstå, hvornår en ændring bliver synlig på den offentlige hjemmeside, hvordan kladder forhåndsvises, og hvad der sker, hvis et build fejler.

Til sidst skal driften holdes enkel og forudsigelig: sikkerhedskopier, testmiljø, versionsstyring, logfiler fra udrulning, tilbagerulning, rydning af cache og tydeligt ansvar for WordPress-plugins.

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

Min normale anbefaling

Til de fleste mindre virksomhedshjemmesider 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, en offentlig hjemmeside hvor hastighed og struktur betyder meget, og en tydelig grund til at beholde WordPress som redigeringssystem, men erstatte frontendlaget.

Det kan være en hjemmeside med strukturerede ydelsessider, cases, lokationer, produktkatalog, faglige guider eller en eksisterende WordPress-hjemmeside, hvor administrationen er nyttig, men den offentlige del er blevet for tung at vedligeholde.

Hvis du overvejer headless WordPress, kan du sende mig den nuværende URL og det, du vil forbedre. Jeg kan hjælpe med at vurdere, om arkitekturen er berettiget, eller om en mere fokuseret oprydning i WordPress, Astro, Cloudflare eller hjemmesidens hastighed løser det rigtige problem med mindre risiko.