Fra WordPress til Claude Code — vores erfaringer

Siden du læser det her, ser du på resultatet. I april 2026 besluttede vi at bygge allegroit.dk om fra bunden. Den gamle side var en WordPress-installation med Elementor, Polylang og otte aktive plugins på en delt host. Den nye side — den, du er på nu — er skrevet helt i hånden af Claude Code som plain PHP, kører i en enkelt Docker-container på en VPS i Helsinki, og har ingen database, intet admin-panel og ingen plugins overhovedet.

Det er ikke en teknisk øvelse for øvelsens skyld. Vi sælger AI-assisteret udvikling som ydelse, og det bedste argument vi kunne finde var at gøre det på vores egen hjemmeside først. Her er regnskabet — hastighed, filantal, database, sikkerhed — og også det vi måtte give op for at komme hertil.

Hvordan arbejdet fordelte sig

Før tallene er det vigtigt at være ærlig omkring, hvem der gjorde hvad. Ellers bliver historien "AI byggede en hjemmeside" — og det er ikke helt sandt.

Det praktiske forløb: vi skrev det oprindelige tekstmateriale selv — alt det, vi ved om vores egne ydelser, kunder og referencer — og Claude finpudsede sprog, struktur og tone. Koden skrev Claude fra bunden efter vores tekniske retning, og vi reviewede hvert commit før det blev pushet. Designet udviklede sig i samtale: vi beskrev, hvad vi ville have; Claude foreslog layouts og implementerede dem; vi fik resultatet i browseren og bad om justeringer. Det blev til omkring 125 filer og en fuldt fungerende tosproget marketing-side.

Den nye stak, kort

• Én Alpine-container med PHP 8.3-FPM + nginx + supervisord
• Parsedown til Markdown-rendering — intet CMS
• Indhold i git: hver side og hvert indlæg er en .md-fil med frontmatter
• Tosproget via filnavn: post.da.md + post.en.md, ingen Polylang
• Ingen database: backup er git push, rollback er git reset --hard
• Deploy via GitHub Actions til Hetzner → docker compose up -d

Et frisk git clone + docker compose up giver en fuldt fungerende side på under 30 sekunder. Den gamle WordPress-side kunne ikke deployes uden også at importere en SQL-dump og gen-aktivere plugins i den rigtige rækkefølge.

Hvad kostede det i tid?

Cirka 15 timers arbejde i alt — fra første commit til live site i produktion. Det er falsificerbart; git log er offentligt. Og det er alt, ikke en delmængde:

• Design og implementering af layout: header, footer, forside, service-sider, indlægs-arkiv, enkelt-indlæg med to forskellige visningsstile
• Migrering af alt indhold fra WordPress til Markdown — sider, indlæg, referencer, billeder
• Tosproget routing med DA↔EN slug-par og sprogskifter
• Kontaktformular med server-side validering og SMTP via Microsoft 365
• GDPR-compliant log-håndtering, privatlivspolitik og cookie-notice banner
• Deploy-pipeline: GitHub Actions → Docker build → Hetzner
• SEO-metadata, JSON-LD, sitemap, robots.txt og llms.txt for AI-crawlere
• HTTP-sikkerhedsheaders (som tog os fra karakter D til A)
• Favicon-generering, logo-kropning, Open Graph billeder

Fra tomt git-repo til komplet, tosproget, sikker, produktionsklar marketing-side — alt sammen i 15 timer. Det er den faktiske omkostning ved det vi sælger, og et tal enhver potentiel kunde kan bruge til at regne baglæns på, hvad en lignende løsning ville koste dem.

Hvad blev det til i tal?

Vi målte begge sider i produktion samme dag — allegroit.dk på WordPress og den nye stak — og tog tallene fra Chromes Performance API, ikke gættede. Her er det korte overblik:

Den vigtigste tal at forstå er TTFB (Time To First Byte) — altså hvor længe serveren tænker, før den begynder at sende svar tilbage. 325 ms vs. 123 ms handler ikke om hosting; det handler om, at WordPress skal starte hele sin kerne, indlæse otte plugins og køre 30+ SQL-forespørgsler, før den overhovedet kan skrive det første tegn. Den nye stak læser én Markdown-fil, renderer den, og er færdig.

Sikkerhed: fra ingen headers til A

Det var en sidegevinst, vi ikke havde forventet. Da vi målte begge sider, havde ingen af dem de moderne HTTP-sikkerhedsheaders slået til. WordPress-siden havde kun X-Content-Type-Options (den får den automatisk af Simply.com). På securityheaders.com gav det karakteren D.

På den nye stak tog det én commit og ti linjer nginx-config at tilføje hele settet: HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy. Vi gik fra ingenting til karakteren A.

Forskellen handler ikke om, at vi er særligt dygtige — det er en tier-change på hvor let det er at ændre noget. På et WordPress-site på en delt host skal du have værtens samarbejde for at ændre nginx-headers. Hos os er det to filer i git og en docker compose up -d.

Hvad kunne vi ikke måle?

For at være ærlig: alt ovenstående er tal der kan aflæses af en browser. Det er de nemme ting. Der er tre ting, som vi bevidst ikke har prøvet at tage med i regnskabet:

1. SEO — den nye side har tekniske fordele (hurtigere, mindre, korrekt struktureret JSON-LD, hreflang, llms.txt for AI-crawlere), men det afgørende er, hvordan Google rangerer den om tre måneder. Det kan vi ikke måle endnu.
2. Usability — om besøgende finder det, de leder efter, og om de ringer til os bagefter. Det skal vi ind og spørge kunderne om.
3. UX og design-kvalitet — er det pænt? Det er subjektivt, og dem vi gerne ville spørge er dig, der læser det her.

Hvis I har kigget den nye side igennem og har feedback på noget af det ovenstående, så sig til — det er den slags input vi ikke kan måle os til.

Hvad med WordPress' klassiske fordele?

Den traditionelle liste over WordPress-fordele består typisk af tre ting: en WYSIWYG-editor som alle kan bruge, et kæmpe plugin-økosystem, og 20 års kendt terræn. Vi har tænkt over hver af dem — og i 2026 er de ikke nær så tunge, som de plejede at være.

1. "Alle kan redigere i WP admin". Det er en sandhed med modifikationer — og der er en grund til, at det oftest er web-bureauer der bygger og vedligeholder WordPress-sites. I praksis kræver WP admin stadig en teknisk person: Elementor og andre page-buildere har deres egen læringskurve, plugin-opdateringer knækker ting med jævne mellemrum, konflikter skal løses, backups skal køre, og SEO- og sikkerheds-plugins skal konfigureres. Løftet om "alle kan redigere" er for det meste marketing — langt de fleste WP-kunder ringer alligevel til deres bureau, når der skal ændres noget ikke-trivielt.

   Og når man alligevel har en udvikler (eller et bureau) i loopet, ændrer argumentet sig markant. Git er faktisk bedre end WordPress til flere samtidige redaktører — to personer der åbner den samme side i WP admin skaber konflikter og mistede ændringer, mens git merger det rent og efterlader en revisionshistorik helt ned til linjen. Markdown er let at lære for enhver der er bare en smule teknisk. Og allervigtigst: ingen behøver selv at skrive ændringerne. Beskriv hvad der skal laves i almindelig dansk — "ret prisen i tabellen, tilføj en ny reference, byt billedet ud" — så klarer Claude Code resten, opretter et commit og pusher. WYSIWYG-editoren løser et problem, der ikke længere er et problem.

2. "Der er altid et plugin til det". WordPress har et plugin til næsten alt — og det er også det, der skaber otte eksterne kodebaser i din installation, hver med sit eget angrebsflade, opdateringscyklus og CVE-hale. Når du i stedet beder Claude om at bygge en funktion lavet specifikt til dit site — booking, nyhedsbrev-signup, filtre, hvad det end måtte være — bliver det mindre, hurtigere og mere præcist end et generelt plugin, der skal dække alles brugsmønstre. Spørgsmålet er ikke længere "findes der et plugin?", men "kan det bygges hurtigt?" — og svaret er typisk ja.

   Et konkret eksempel fra et WordPress-site vi arbejdede på for en kunde: siden fyrede duplikerede API-requests af — samme kald flere gange per sideload. Vi forsøgte at fejlfinde det med AI-hjælp og måtte opgive. Ikke fordi AI'en ikke var god nok, men fordi koden ikke var vores — det var en håndfuld plugins der hver især hægtede sig på WordPress' hooks uden at vide om hinanden. Du kan ikke fikse noget, du ikke ejer. På en stak som den her har Claude Code fuld adgang til en kodebase, vi selv skrev hver linje af; den slags debugging er trivielt.

3. "Når WordPress knækker, kan man Google sig til svaret". Det er sandt — WordPress er 20 år gammelt, og der er masser af hjælp derude. Men når jeres site knækker, vil I ikke Google; I vil have det fikset. Det er præcis den slags vedligehold vi laver for kunder. Hvis I kører en plain-PHP-løsning bygget med Claude Code, og den ene dag bliver mærkelig, så ring til os. Svartid inden for 24 timer.

Kunne I bruge noget lignende?

Hvis I har et gammelt WordPress-site der er blevet langsomt og svært at vedligeholde — eller hvis I overvejer at bygge en ny marketing-side fra bunden og er nysgerrige på, hvor hurtigt det kan gå med Claude Code i førersædet — så fortæl os om jeres projekt. Vi vender tilbage inden for 24 timer med et uforpligtende forslag.

Og hvis I vil dykke længere ned i tallene — de fulde målinger, metode og sammenligning side om side — så kan I hente den komplette effektivitetsrapport som PDF.