Hvorfor jeg har droppet WordPress som frontend – og hvorfor React (Next.js) er fremtiden

Langt de fleste websites bliver stadig bygget i WordPress. Og det forstår jeg godt. Det er nemt, hurtigt, og der findes plugins til det meste. Alle kan altså komme i gang med det samme, helt uden nogen forstand på kodning.

Jeg har selv brugt WordPress i mange år. Men det har altid begrænset mit websites hastighed, og jeg har længe haft lyst til at rykke over i noget hurtigere og bedre. Noget hvor jeg har mere kontrol. Jeg har bare haft travlt. Jeg kører mange projekter og tjener reelt ikke noget på at holde min blog kørende, så – ligesom for mange andre – er det blevet udskudt igen og igen. Men nu har jeg altså gjort det.

Indholdsfortegnelse

• 1 React? Næsten. Det handler om Next.js.
• 2 Mit setup: Det bedste fra to verdener
• 3 Hvorfor jeg ikke gider klassisk WordPress længere
• 4 Og når du smider det op på Vercel…
• 5 “Men kan Google læse det?”
• 6 Hvorfor alle ikke gør det
• 7 Er React/Next.js altid bedre?
• 8 SEO-tjekliste til React/Next.js
  • 8.1 Kilder og referencer

React? Næsten. Det handler om Next.js.

Lad os få begreberne på plads. Jeg siger “React”, men det jeg bruger er faktisk Next.js, et framework ovenpå React. Hvorfor? Fordi Next løser Reacts største svaghed: SEO og rendering. Og det er præcis dér, React-websites tidligere er faldet igennem.

Når folk siger “React er ikke godt til SEO”, tager de fejl. Problemet er ikke React, det er client-side rendering, hvor HTML’en først bliver genereret i browseren der er udfordringen.

Forestil dig, at Googles bot henter din side, men kun ser et tomt <div id=”root”></div> og en masse JavaScript, der skal køres, før indholdet dukker op. Hvis Googlebot ikke venter længe nok eller ikke kan køre alt JavaScript korrekt, så får den intet at indeksere. Resultatet? Dårligere placeringer eller slet ingen indeksering.

Next.js løser det med server-side rendering (SSR) og static site generation (SSG). SSR betyder, at serveren sender færdig HTML til Google fra start, så indholdet er klar, når botten lander. SSG går skridtet videre og bygger siderne statisk på forhånd, så de leveres ekstremt hurtigt og uden render-forsinkelse.

Med begge metoder får Google præcis dét, den vil have: HTML med alt indhold, metadata og structured data klar til at blive læst – uden at skulle vente på JavaScript.

Mit setup: Det bedste fra to verdener

Jeg bruger stadig WordPress. Men kun som backend. Artikler og indhold opretter jeg der. Statiske sider bygger jeg direkte i React.

Men selve sitet – header, footer, design, performance, kører i Next.js. Det betyder at du får:

• Lynhurtig frontend
• Minimal kode
• Maksimal kontrol
• Backend, du kender fra WP

Det kaldes Headless WordPress. I praksis betyder det, at jeg har en frontend, der er let og responsiv, uden at backend trækker tempoet ned.

Her kan du se en sammenligning:

Det er dog vigtigt at pointere, at målingen her faktisk ikke er helt valid, da jeg måler WordPress-versionen “ren” uden tracking scripts, mens React-versionen inkluderer alle tredjepartscripts som en rigtig bruger oplever.

Lad os gå mere i detaljer og se nærmere på de konkrete forskelle. Til venstre ser du mit gamle WordPress-setup, igen, ren WordPress vs. React der loades på mit hovedomæne! Netop derfor, vinder WordPress-installen lige i dette scenarie. Det havde ikke været tilfældet, hvis målingen havde været lavet på live WP-sitet.

Hvorfor jeg ikke gider klassisk WordPress længere

Fordi almindelig WordPress er et rodet system, der kun bliver mere rodet, nu mere du arbejder i det. Temaer og plugins sløver, konflikter opstår. Du opdaterer én ting, og noget andet går i stykker. Du kender det sandsynligvis godt. Jeg har personligt selv, spildt uanede mængder af tid på tema-konflikter mv. når jeg har arbejdet i WordPress.

Sammenligningen er simpel:

Klassisk WordPress Next.js + Headless WordPress Hastighed Ofte tungt og langsomt Hurtigt med statisk rendering Fleksibilitet Låst til temaer og plugins Frihed i design og funktion SEO Risiko for renderblokering SSR/SSG giver korrekt HTML til Google Sikkerhed Hyppige angreb og huller Kun backend eksponeret Skalerbarhed Tungt og ressourcekrævende Let med Vercel og CDN-integration

Og når du smider det op på Vercel…

Får du lynhurtig server og distribution, der gør loadtiderne ekstremt korte, helt uden ekstra opsætning. Vercel er altså ikke bare et webhotel. Det er en hostingplatform bygget til moderne JavaScript-frameworks som Next.js. Den håndterer alt fra server-side rendering til caching på edge-servere, så dit indhold leveres fra en server tæt på brugeren, uanset om de sidder i København eller New York.

Hvis du kender Cloudflare, så tænk samme idé med global distribution, men direkte integreret i din deployment, så du ikke skal nørkle med opsætningen selv. Hvor Cloudflare typisk fungerer som et ekstra lag ovenpå din eksisterende hosting, så er Vercel hele pakken: hosting, CDN, build-pipeline og automatisk skalering i én samlet løsning!

Det fungerer i praksis som et CDN, men med en afgørende forskel: Et traditionelt CDN (som Cloudflare, Akamai eller Fastly) gemmer og distribuerer statiske filer som billeder, CSS og JavaScript. Med Vercel bliver ikke kun dine statiske filer, men også hele din server-renderede HTML distribueret ud på edge-servere. Det betyder, at både dynamiske sider og statiske ressourcer leveres fra nærmeste lokation, direkte til brugeren.

Sammenlignet med klassisk hosting, hvor du typisk har én server i ét datacenter, gør Vercel det modsatte: det skubber hele sitet ud til et globalt netværk. Resultatet er markant kortere loadtider, lavere latency og en oplevelse, der kan mærkes af både brugere og søgemaskiner.

“Men kan Google læse det?”

Ja. Hvis du gør det rigtigt. Her fejler mange, især hvis de bygger alt client-side. Google kan sagtens læse og indeksere Next.js-sites, hvis HTML’en er prægenereret, metadata er placeret korrekt, og struktureret data er på plads. Jeg har set Next.js + WordPress ranke hurtigere og højere end klassiske WP-sider masser af gange af netop den grund.

Hvorfor alle ikke gør det

Det kræver mere. Du kan ikke bare installere et tema. Du skal have styr på routing, rendering, data-fetching og SEO på komponentniveau. Men det er også derfor, løsningen er så stærk. Du skærer alt det overflødige fedt fra og står tilbage med et site, der leverer, hver eneste gang.

Er React/Next.js altid bedre?

Nej. Hvis du bare skal have en lille blog, er WP fint.

Men hvis du vil:

• Have 100 % kontrol over frontend
• Bygge komponentbaseret og skalerbart
• Få en side, der performer og konverterer
• Sikre at SEO spiller fra dag ét

… så er Next.js + Headless WordPress vejen frem, hvis du spørger mig.

SEO-tjekliste til React/Next.js

Hvis du sætter det korrekt op, kan du udkonkurrere selv de stærkeste websites.

• SSR eller statisk generation
• Dynamiske meta-tags og Open Graph i <head>
• Structured data (JSON-LD) direkte i komponenter
• Canonicals ved headless CMS
• HTML klar til crawling – ikke gemt bag JS
• LCP under 2,5 sekunder
• Intern linking, Google kan følge
• Opdateret sitemap og robots.txt
• Korrekte 404-sider, redirects og hreflang hvis relevant

Next.js + Headless WordPress giver dig hastighed, fleksibilitet og SEO-ydelse, som klassisk WP ikke kan matche. Det kræver mere arbejde, men er også markant bedre, mere stabilt og langt hurtigere.

Kilder og referencer

1. Next.js Documentation
   Officiel dokumentation for Next.js framework med guides til SSR, SSG og SEO-optimering.
   nextjs.org/docs

1. Vercel Documentation
   Vercels officielle dokumentation om deployment, edge functions og global distribution.
   vercel.com/docs

1. Google Search Central – JavaScript SEO Basics
   Googles officielle guide til SEO for JavaScript-renderede websites.
   developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

1. WordPress REST API Handbook
   Officiel dokumentation for WordPress REST API, der muliggør headless setups.
   developer.wordpress.org/rest-api/

1. Smashing Magazine – Headless CMS
   Artikler og guides om headless CMS-arkitektur og implementering.
   www.smashingmagazine.com/category/headless