somejuan

AI

Sådan flyttede jeg min side fra WordPress til Astro

Indhold

Jeg har lige flyttet min personlige side fra WordPress til Astro. Den kører nu som et statisk site på Cloudflare Pages, og resultatet er en side der er hurtigere, pænere og næsten gratis at drive. Det her er hele opskriften: hvorfor jeg gjorde det, hvordan jeg gjorde det, og hvornår du selv bør overveje det samme.

Det er ikke et “WordPress er dødt”-indlæg. WordPress er stadig fint til mange ting. Men hvis du har en simpel personlig side eller en lille firmaside, og du er træt af at betale for hosting, opdatere plugins og se på PHP du ikke gider røre, så findes der et alternativ der passer langt bedre til en AI-first hverdag.

Forsiden på den nye somejuan.dk bygget i Astro med chat-interface

Hvad jeg skiftede til og hvorfor

Den korte version: væk fra et WordPress-abonnement med dele der skal vedligeholdes, over til filer og gratis hosting.

Stakken før og efter: WordPress med Simply hosting, PHP, MySQL, plugins og Elementor mod Astro med Cloudflare Pages, Zoho Mail og markdown-filer

Resultatet: hele siden koster nu kun domænet. Resten er 0 kr. Den er hurtigere, fordi der ikke er en server der bygger siden ved hvert besøg, og jeg skal aldrig opdatere et plugin igen.

Men den største gevinst er ikke prisen. Det er at jeg nu kan arbejde med hele siden direkte fra min AI-agent, eller bare fra en terminal. Indholdet er Markdown-filer i et repo, så et nyt blogindlæg, en rettelse eller et lille designtweak er noget jeg beder min agent om, præcis som alt mit andet arbejde. Siden passer nu ind i mine AI-processer i stedet for at ligge som en ø for sig selv i et wp-admin.

Forstå det her først: Astro er ikke et CMS

Det her er den vigtigste ting at have styr på, før du går i gang. Folk vælger forkert lige præcis her.

Astro er et webframework, ikke et CMS. Der er ingen wp-admin du logger ind i. Dine blogposts er Markdown-filer i et git-repo. Du skriver i en editor (eller får din AI-agent til at gøre det), committer, og siden bygges og deployes automatisk.

For mig er det en fordel, ikke en mangel:

  • Markdown er en fornøjelse at skrive og rette i
  • Alt ligger i git, så jeg har fuld historik over hvad der er ændret
  • Det er lynhurtigt, fordi der ikke er en database eller en server der render’er ved hvert besøg
  • Det er SEO-venligt ud af boksen

Hvorfor en statisk side er hurtigere: WordPress bygger siden via server og database ved hvert besøg, Astro serverer færdig HTML fra CDN

Forskellen er ikke teoretisk. Da jeg målte den nye somejuan.dk, lå førsteindtrykket (First Contentful Paint) omkring 0,35 sekunder, og siden var fuldt indlæst på under et halvt sekund. Det er den slags tal man nærmest får forærende med en statisk side serveret fra et CDN, hvor min gamle WordPress-side brugte mærkbart længere tid på at bygge hver side på serveren først.

Offentlige benchmarks af den samme side før og efter en WordPress-til-Astro migration peger samme vej: markant hurtigere indlæsning og bedre Lighthouse-scores, blandt andet fordi Astro som udgangspunkt sender nul JavaScript til browseren. En typisk WordPress-blog sender til sammenligning 200 til 500 KB JavaScript afsted, før du overhovedet er begyndt at optimere.

Men hvis du har brug for at en ikke-teknisk kollega skal kunne redigere indhold uden at røre kode, så skal du have et CMS ovenpå. Kig i retning af Sanity eller et andet headless CMS sammen med Astro. For en personlig side er det overkill. For en kundeside med flere redaktører er det relevant. Hold den skelnen klar, inden du vælger.

Sådan migrerede jeg, trin for trin

1. Scaffold en Astro-side

Start med Astros blog-template. Med en AI-agent (jeg brugte Claude Code, men det kan sagtens ske i ChatGPT eller Codex) er det her ti minutters arbejde:

npm create astro@latest

Vælg blog-templaten. Den kommer med en posts-struktur, RSS og en grundstruktur du kan bygge videre på. Den officielle Astro-guide til at migrere fra WordPress er et godt opslagsværk undervejs.

Vil du have AI til at hjælpe dig hele vejen, så er det her en prompt du kan give din agent (Claude, Claude Code, ChatGPT eller lignende):

Hjælp mig med at sætte et nyt Astro-projekt op med blog-templaten.
Forklar mappestrukturen kort, og vis mig hvor blogindlæg, billeder
og layout ligger, så jeg ved hvor jeg selv kan rette bagefter.

2. Træk dit WordPress-indhold ud som Markdown

Det her er det trin folk frygter mest, og det er faktisk det nemmeste at automatisere.

Eksportér dit WordPress-indhold (Værktøjer → Eksportér → en WXR-fil). Få så din AI-agent til at skrive et lille konverteringsscript der laver WXR og HTML om til Markdown-filer med frontmatter. Jeg brugte turndown til selve HTML-til-Markdown-delen.

Hver post ender som en .md-fil med titel, dato, slug og kategori i toppen. 30 poster, ét script, færdig.

Her er en prompt du kan give din agent til selve konverteringen:

Jeg har eksporteret mit WordPress-indhold til en WXR-fil (XML).
Skriv et Node-script der læser filen og konverterer hver post til en
Markdown-fil med frontmatter (title, date, slug, category). Brug
turndown til at lave selve indholdet om fra HTML til Markdown, og
behold den oprindelige slug som filnavn. Læg filerne i
src/content/blog/.

Vigtigt: behold dine URL-slugs 1:1. Lå din gamle post på /blog/min-post/, skal den ligge på /blog/min-post/ på den nye side. Ellers smider du din SEO og dine backlinks i skraldespanden. Lav 301-redirects for alt der alligevel ændrer sig, og send et nyt sitemap til Google Search Console.

3. Byg designet (her er AI-first det vildeste)

Det her var hvor det blev sjovt. Jeg byggede hele designet i Claude Code, fra bunden. Et samlet lys- og mørk-system, en forside-idé jeg faktisk synes om, det hele. Hvis du vil se hvordan jeg arbejder med design direkte i en AI-agent, har jeg skrevet mere om det i min guide til Claude Design og hvordan jeg bruger Claude Cowork.

Pointen med AI-first er ikke “AI skrev min kode”. Det er at hele miljøet er bygget til at arbejde sammen med en agent: alt er kode i et repo, alt kan beskrives i tekst, og du itererer i sekunder i stedet for at klikke rundt i en Elementor. Du behøver ikke være designer. Du beskriver hvad du vil have, kigger på resultatet og justerer.

4. Søgning, contact-form og alt det “dynamiske” man tror man mister

“Men en statisk side kan jo ikke X.” Jo, som regel kan den godt.

  • Søgning: Pagefind bygger et søgeindeks ud af dine statiske sider. Ingen server nødvendig.
  • Contact-form: En lille Cloudflare Pages Function tager imod formularen og sender mailen videre (jeg sender via Zoho SMTP). Det er omkring 30 linjers kode, og det er gratis inden for Cloudflares free tier.

Du mister stort set ingenting ved at gå statisk. Du mister vedligeholdelsen.

Contact-formen lyder som det mest tekniske, men det er også et oplagt sted at lade din agent gøre arbejdet. En prompt du kan give den:

Lav en contact-form til min Astro-side på Cloudflare Pages. Byg en
Pages Function der tager imod formularen (navn, email, besked) og
sender den til min mail via SMTP. Hold SMTP-brugernavn og kodeord i
miljøvariabler, ikke i koden. Tilføj simpel validering og en
tak-besked når den er sendt.

5. Hosting på Cloudflare Pages (gratis)

Forbind dit repo til Cloudflare Pages. Hver gang du pusher til main, bygger og deployer den automatisk. Build-kommandoen er astro build (jeg kører pagefind ovenpå for søgning). Gratis, hurtigt, globalt CDN, ingen server at passe.

6. DNS og email (her er der en .dk-fælde)

Det her trin gør folk nervøse, men det er til at overskue.

  • DNS: Flyt dine nameservers til Cloudflare. Apex peger på din Pages-side, og www laver en 301-redirect til apex.
  • Fælde for .dk-domæner: Cloudflare Registrar understøtter ikke .dk. Så du beholder selve domæneregistreringen hos Simply (eller din nuværende registrar) og downgrader bare til deres billigste DNS-tier. Nameserverne peger på Cloudflare. Det virker fint, du flytter bare hvor DNS’en styres fra.
  • Email: Jeg flyttede mailen til Zoho Mail (gratis tier, EU-region). Sæt MX, SPF og DKIM op. Bruger du et nyhedsbrevsværktøj, så husk at beholde dets include i din SPF-record, ellers begynder dine mails at bounce.

SPF-fælden: en SPF-record må kun have ÉN v=spf1-linje. Skal du have både Zoho og dit nyhedsbrevsværktøj med, samler du dem i samme record, fx v=spf1 include:zoho.eu include:_spf.dit-newsletter.com -all.

Tracking og samtykke fulgte uændret med over: Google Tag Manager og Cookiebot blev sat ind i Astro-layoutet på samme måde som før. Skal du have styr på den del, har jeg en guide til Google Tag Manager og en til cookieless tracking.

7. Luk WordPress ned

Når den nye side kører og DNS er flyttet:

  1. Tag en fuld backup af din gamle WordPress (database + uploads). Bare for en sikkerheds skyld.
  2. Tjek at alle dine gamle URLs stadig svarer 1:1 på den nye side.
  3. Downgrade dit gamle hosting-abonnement.

Og så er du fri.

Hvad det kostede mig

  • Penge: Domænet. Det er det.
  • Tid: Agenten arbejdede i baggrunden om aftenen. Det meste af min egen tid gik med design-valg og med at dobbelttjekke, at jeg ikke knækkede en eneste URL.

Bør du selv skifte fra WordPress til Astro?

Ja, hvis:

  • Du har en simpel personlig side eller en lille firmaside
  • Du er træt af plugins, opdateringer og hosting-regninger
  • Du vil arbejde AI-first og have alt som kode

Nej, hvis:

  • Flere ikke-tekniske personer skal redigere indhold dagligt (så: et CMS som Sanity ovenpå Astro)
  • Du har tung dynamisk funktionalitet (webshop med lager, login, medlemsområder)

For alt det midt imellem er Astro + Cloudflare + Zoho svært at slå. Du får en hurtigere side, en bedre SEO-baseline og en regning der stort set forsvinder. Den eneste pris er, at indhold nu lever i Markdown og git i stedet for i et wp-admin, og for mig var det en opgradering, ikke en omkostning.

Skal du i gang, så start med Astros officielle migrationsguide, eksportér dit indhold til Markdown, og byg resten sammen med din AI-agent.