Ti måneder med migrering fra WordPress til Astro på Cloudflare Pages

Plattformbyttet fra WordPress til Astro skulle representere hele prosjektet. Det viste seg imidlertid å være en ren prolog. Å eksportere innholdet, bygge malene på nytt i Astro med Tailwind CSS, få et statisk nettsted til å kompilere og distribuere til Cloudflare Pages tok bare noen uker. Deretter begynte de egentlige månedene: omdirigeringer, hreflang-grafer, streng paritet på tvers av seks språk og et bygg som vokste ut av plattformen det ble distribuert til. Dette er en teknisk feltrapport om hvor ressursene faktisk gikk.

Polemikken retter seg mot den overfladiske oppfatningen av plattformbyttet som en engangsmigrering. “Forlat WordPress til fordel for et statisk nettsted” høres ut som et enkelt prosjekt. For et flerspråklig innholdsnettsted ligger det nærmere det å overta det fulle driftsansvaret for tre fundamentale systemer WordPress pleide å skjule: rutingslaget, byggemotoren og den tverrspråklige innholdsstrukturen. Ingen av dem er uoverkommelige, men alle krever kontinuerlig ingeniørdisiplin.

[!NOTE] Saken kort

• Prosjekt: wppoland.com flyttet fra WordPress til Astro på Cloudflare Pages, en intern ombygging av mitt eget nettsted
• Omfang: seks språk, 15 718 forhåndsgjengitte sider og 8180 adresser i nettstedskartet (bygg fra 20.10.2026), med full hreflang-sammenkobling
• Tidslinje: start i desember 2025 (2. desember kjørte nettstedet fortsatt på WordPress med WPML og WP Rocket, ifølge Wayback Machine; Astro-repositoriet ble opprettet 21. desember), uker til et fungerende bygg, første versjon av denne rapporten etter fem måneder, denne oppdateringen etter ti
• Bygg: oversteg taket på 8 GB for Cloudflare Pages’ runner, løst ved å bygge lokalt med en 16 GB heap og distribuere artefaktet med Wrangler
• Omdirigeringer: 301-regler som traff Cloudflares 100 KB-grense for _redirects; i dag ligger 3619 av dem i et kart i Cloudflare Functions og 249 i _redirects
• Stack: Astro med Tailwind CSS, AVIF-bildepipeline, statisk HTML levert fra globalt kantnettverk
• Resultat: PageSpeed (lab, mobil, 20.10.2026) 94 for den polske forsiden og 98 for tjenestesiden om Astro, ingen PHP og ingen database i produksjon, paritet over seks språk opprettholdt

#Hva koster det å migrere fra WordPress til Astro

1. Flyttingen er den billige delen. Maler og innholdseksport tok uker; etter ti måneder trenger den lange halen av migreringen fortsatt rettelser.
2. Omdirigeringslaget er den første overraskelsen. Tusenvis av tidligere indekserte URL-er trenger hver sin 301-kode, og volumet kolliderte med en filstørrelsesgrense på Cloudflare Pages som stille forkastet regler.
3. Paritet på seks språk er løpende arbeid, ikke en engangsoppgave. Hreflang, kanoniske URL-er og seksjonsstruktur må holde seg samstemte på tvers av hver språkversjon for alltid.
4. Bygget vokste ut av plattformens egen runner. Et byggetak på 8 GB er ikke nok til over 15 000 forhåndsgjengitte sider; svaret var å bygge lokalt med en 16 GB heap og distribuere det ferdige artefaktet via CLI.

#Ordliste: statisk bygg, prerender, hreflang, kant

Rapporten hviler på noen plattformbegreper:

• Statisk bygg - hele nettstedet gjengis til rene HTML-filer på forhånd, under et byggesteg, i stedet for å genereres dynamisk per forespørsel fra en webserver.
• Prerender - å generere hele DOM-treet til hver underside til fysiske HTML-filer ved byggetid. Et nettsted med seks språk multipliserer sideantallet med antall språk, noe som krever deterministisk minnekontroll i V8.
• Cloudflare Pages - vertsplattformen som serverer forhåndsbygde filer fra det globale kantnettverket (CDN) og kjører serverløs logikk via Pages Functions på forespørselsgrensen.
• Wrangler - Cloudflares kommandolinjeverktøy, brukt her til å distribuere den lokalt kompilerte dist/-mappen direkte og omgå plattformens byggesteg og minnebegrensninger.
• Hreflang - HTML-header-attributter som forteller søkemotorer hvilken URL som er den lokale ekvivalenten på et annet språk, avgjørende for å unngå regional nøkkelordkannibalisering.
• 301-omdirigering - en permanent HTTP-videresending som overfører rangeringssignalet og indekshistorikken til en flyttet URL til sin nye adresse.

#Hvor lang tid tar flytting fra WordPress til Astro

Den synlige migreringen er delen som blir estimert, og estimatet er innledningsvis nokså treffsikkert. Innhold eksporteres fra WordPress MySQL-databaser til Markdown-filer med YAML-frontmatter. PHP-maler og undertemaer skrives om til Astro-komponenter med Tailwind CSS. Bygget kompilerer feilfritt og distribusjonen lander på Cloudflare Pages. Et innholdsnettsted av moderat størrelse når et fungerende statisk bygg i løpet av noen uker. Dette er fasen som demonstrerer godt internt og overbeviser ledelsen om at prosjektet er nesten fullført.

I virkeligheten står prosjektet bare ved inngangen til sine reelle ingeniørmessige utfordringer. Et fungerende bygg beviser kun at Astro-komponenter kan sette sammen HTML uten syntaksfeil. Det beviser ingenting om hvorvidt tusenvis av historiske URL-er fortsatt overfører trafikk korrekt, om hreflang-relasjoner er intakte i Google-indeksen, eller om Node.js-prosessen vil tåle videre innholdsvekst.

#301-omdirigeringer etter flytting til Astro

Da bygget kjørte, var omdirigeringsinfrastrukturen neste oppgave. Hver URL WordPress noensinne hadde opprettet siden 2006 (inkludert datoarkiver, kategorier, forfattere, taksonomier og eldre slugger), krevde en presis 301-omdirigering til sin nye Astro-adresse. Uten et komplett kart over omdirigeringer skjøt 404-feilene i været i Google Search Console og opparbeidet søkeautoritet forsvant.

På et enspråklig nettsted er dette en lineær regnearkoppgave. På et nettsted med seks språk og oversatte slugger (norske, tyske, polske, spanske og portugisiske URL-er) gikk listen raskt opp i tusenvis av regler. I oktober 2026 har kartet i Cloudflare Functions 3619 regler og filen _redirects 249.

Her traff jeg en udokumentert begrensning på Cloudflare Pages: _redirects-filen har en hard grense på 100 KB. Over denne størrelsen forkaster plattformens parser overskytende linjer uten noen feilmelding under distribusjonen. Resultatet var at tidlige regler fungerte, mens senere regler falt igjennom som 404-feil. Løsningen var å flytte all omdirigeringslogikk til en TypeScript-basert Edge-mellomvare (functions/redirect-map.ts), som utfører O(1)-oppslag i minnet på kantnivå for hver innkommende forespørsel.

#Hvordan holde hreflang synkronisert på seks språk

I tradisjonelle WordPress-installasjoner skjuler flerspråklige plugins som WPML eller Polylang relasjonene bak databasetabeller. En statisk SSG-arkitektur blottlegger alle koblinger direkte i filer og markup.

Seks språkversjoner av hver artikkel må holde seg strengt parallelle over tid:

• Identisk H2- og H3-overskriftsstruktur i logisk rekkefølge.
• Komplette, gjensidige hreflang-lenker i dokumenthodet til alle fem søsterspråk.
• Nøyaktige kanoniske URL-er som gjenspeiler det regionale rutingoppsettet.
• Konsekvent kategorisering og taksonomikoblinger på tvers av alle markeder.

Når én språkversjon driver av (for eksempel ved at en seksjon legges til eller en slug endres), begynner søkemotorer å ignorere asymmetriske hreflang-signaler. Dette fører til nøkkelordkannibalisering mellom land. For å hindre dette innførte jeg automatiserte skript for paritetsvalidering som kjøres før hver commit.

#Hvordan fikse JavaScript heap out of memory i Astro-bygget

Astro kompilerer statiske sider i én enkelt arbeidsprosess. Da arkivet passerte 14 000 undersider (i oktober 2026 er de 15 718) (gjennom en kombinasjon av tekniske veiledninger, tjenestesider, case-studier og byprofiler på 6 språk), ble standardgrensen på 4 GB heap i V8-motoren raskt oppbrukt.

Cloudflare Pages’ standard bygge-runner stiller 8 GB RAM til rådighet. Under intensiv TypeScript-skjemavalidering, MDX-AST-transformasjon og Tailwind CSS-optimalisering krasjet prosessen jevnlig med JavaScript heap out of memory.

Jeg løste dette ved å omstrukturere hele distribusjonsflyten:

1. Lokal bygging på Apple Silicon: Bygget kjøres lokalt på M-serie-prosessorer med en eksplisitt satt heap (--max-old-space-size, 16 GB i produksjonsprofilen). 20. oktober 2026 laget steget astro build 15 718 sider på 5 minutter og 30 sekunder, og opplastingen med Wrangler tok ytterligere 338 sekunder.
2. Opprydding av prerender-artefakter: Astro genererer mappen dist/.prerender for servermoduler. Enkeltfiler nådde 43,9 MiB, noe som brøt Cloudflare Pages’ filgrense på 25 MiB. Distribusjonsskriptet fjerner disse interne modulene automatisk før opplasting for å forhindre avbrutte utrullinger.
3. Direkte opplasting via Wrangler: Den verifiserte dist/-mappen lastes direkte opp til Cloudflares kantnettverk, og eliminerer byggesteg i skyen helt med full deterministisk artefaktkontroll.

#Dele opp sitemap i Astro i flere filer

En annen vesentlig utfordring lå i sitemap-arkitekturen. Standardintegrasjonen @astrojs/sitemap kjenner ikke reglene for indeksering som jeg har per samling (noindex, lengdegrenser, bysider).

Jeg bygde min egen generator. I oktober 2026 lager den denne strukturen:

• En sentral sitemap-index.xml lister 24 nettstedskart, fire for hvert av de seks språkene.
• Hvert språk har egne filer for tjenestesider (sitemap-pages.xml), bloggen, porteføljen og bysider (sitemap-locations.xml), til sammen 8180 adresser.
• Et strengt filter som ekskluderer alle sider med noindex-attributt (overvåket av skriptet check:noindex-sitemaps).

Denne oppdelingen gjør det mulig for søkemotorer og KI-crawlere å hente nettkart trinnvis uten tidsavbrudd.

#Automatiske kontroller før publisering av et Astro-nettsted

En ofte oversett kostnad ved å forlate et CMS er oppbyggingen av kvalitetssikringen som WordPress og dets plugins utførte usynlig i bakgrunnen. WordPress forhindret dupliserte slugger, ivaretok relasjonell integritet i MySQL og varslet om brutte lenker. I et statisk system havner enhver skrivefeil i frontmatter direkte i produksjon hvis den ikke fanges opp av automatiserte tester.

Innen mai 2026 hadde jeg 34 automatiserte kvalitetsporter (run-gates.mjs); i oktober 2026 lister npm run gates over 120. Eksempler:

• Intern lenkeintegritet (check:incoming-internal-links og check:service-navigation-parity): Kontrollerer at hver tjeneste har innkommende lenker og at navigasjonen stemmer på alle språk.
• Tegnsett- og diakritikakontroll (check:diacritic-wordlist): Fanger opp tegnsettfeil og feilformaterte spesialtegn på alle seks språk.
• Prisbeskyttelsesvakt (check:no-own-prices): Sikrer at uautoriserte timepriser eller fastpriser ikke lekker inn i veiledningstekster utenfor godkjente prissider.
• Content Security Policy-validering (check:csp-inline): Beregner SHA-256-hasher for alle integrerte skript i generert HTML og håndhever strenge CSP-headere uten unsafe-inline.
• KI-retorikk-revisjon (check:slop-rhetoric): Filtrerer ut tomme markedsføringsfraser og opprettholder en faktabasert, teknisk tone.

Hver av disse portene ble skrevet etter en konkret feil som allerede hadde nådd produksjon.

#Astro Content Collections med Zod-skjemaer

I motsetning til WordPress, der tilpassede felter (Advanced Custom Fields / ACF) lagres som ustrukturerte metadata i wp_postmeta, håndhever Astro streng typesikkerhet gjennom Content Collections med Zod-skjemaer:

• Obligatorisk felttyping: Hvert Markdown- og MDX-dokument valideres mot et Zod-skjema under byggingen. Manglende felter som title, description, canonicalUrl eller feilformaterte datoer stanser byggeprosessen umiddelbart med nøyaktig linjeangivelse.
• Schema.org JSON-LD-automatisering: Strukturerte data for søkemotorer (Article, FAQPage, HowTo, Organization) genereres typesikkert direkte fra frontmatter, noe som eliminerer strukturelle feil i Googles indeksering.
• Relasjonsintegritet ved kompilering: Koblinger mellom forfattere, kategorier og tverrspråklige ekvivalenter løses opp ved kompilering uten behov for tunge database-joins i sanntid.

#Hvordan sette opp Content Security Policy uten unsafe-inline

Et velkjent problem med modne WordPress-nettsteder er risikoen for Cross-Site Scripting (XSS) via tredjepartsutvidelser som injiserer ukontrollerte skript. I en statisk Astro-arkitektur etableres sikkerheten deterministisk under bygging:

1. Fullstendig eliminering av unsafe-inline: I stedet for ettergivende sikkerhetsregler beregner et automatisert byggesteg (check:csp-inline) kryptografiske SHA-256-hasher for alle nødvendige integrerte skript.
2. Strenge sikkerhetshoder på CDN-kanten: Sikkerhetspolicyen håndheves direkte i HTTP-hodene fra Cloudflare Pages, inkludert Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, X-Content-Type-Options: nosniff og Referrer-Policy: strict-origin-when-cross-origin.
3. Isolerte tredjepartsintegrasjoner: Analyseverktøy isoleres strengt via Permissions-Policy uten tilgang til sensitive nettleser-API-er.

#Bildeoptimalisering og lokale fonter i Astro

I dynamiske WordPress-miljøer håndteres bildebehandling ved opplasting via GD eller ImageMagick. I Astro blir bildeoptimalisering en integrert del av selve byggeprosessen.

Uforsiktig behandling av tusenvis av høyoppløselige bilder førte innledningsvis til minneoverbelastning i Sharp-biblioteket. Jeg etablerte en klar ressursdeling:

1. Forhåndskomprimerte statiske ressurser: Dekorative bakgrunner konverteres til AVIF og WebP på forhånd og plasseres i public/, slik at de leveres direkte fra CDN uten kompilatorbelastning.
2. Faste bildedimensjoner: Alle innholdsbilder tildeles eksplisitte width- og height-attributter, noe som hindrer layout-forskyvninger (Cumulative Layout Shift).
3. Lokalt hostede fonter: Jeg fjernet alle eksterne kall til Google Fonts. Skrifttypen Geist leveres fra mitt eget domene som WOFF2-filer med latinsk delsett (pakken @fontsource/geist), noe som hindrer gjengivelsesblokkering og oppfyller europeiske personvernkrav (GDPR).

#Hvordan legge til JavaScript i skjemaer på et statisk Astro-nettsted

Astros fremste arkitektoniske fortrinn er prinsippet om null JavaScript som standard (Zero-JS by default). Lesere som navigerer i teknisk innhold laster ned ren HTML og CSS uten unødvendige rammeverk.

Der interaktivitet er teknisk påkrevd (kontaktskjemaet, søket, kalkulatorer), legger jeg til et lite skript bare på den siden:

• Kontaktskjemaet er vanlig HTML med et kort skript i komponenten, uten rammeverk i nettleseren.
• Spambeskyttelse håndteres av Cloudflare Turnstile, uten bildeoppgaver.
• Innsendingene går til et endepunkt i Cloudflare Pages Functions (functions/api/enquiry.ts), som sender meldingen gjennom Resend og, hvis Resend svikter, gjennom Web3Forms. Det finnes ingen applikasjonsserver å vedlikeholde.

#Søk på et statisk nettsted med Astro

WordPress baserte tradisjonelt sin søkefunksjon på SQL-spørringer mot wp_posts. I en ren statisk arkitektur må fulltekstsøk fungere uten en database i bunn.

I stedet for databasespørringer bruker søket en indeks som lages under bygget:

• Hvert språk får sin egen JSON-fil (/api/search/<språk>.json). Oppdelingen per språk var nødvendig fordi én felles fil oversteg grensen på 25 MiB per fil i Cloudflare Pages.
• Søkesiden laster ned indeksen for sitt språk og søker i den i nettleseren med biblioteket Fuse.js. Hver fil er i dag 7,7 til 9,4 MB, så bare de som åpner søkesiden laster den ned, ikke alle lesere.
• Serveren gjør ingen jobb ved søk, uansett hvor mange som søker. Prisen er indeksens størrelse, som vokser med bloggen.

#Hvordan måle Core Web Vitals etter migrering fra WordPress til Astro

I WordPress-installasjoner forringes ofte ytelsesmålinger etter plugin-oppdateringer. I Astro følger jeg med på ytelsen slik:

• Lighthouse i GitHub Actions: Arbeidsflyten lighthouse.yml kjører jeg manuelt eller med en etikett på en pull request når maler eller oppsett endres. Den kjører ikke ved hver commit, fordi kvoten med Actions-minutter er begrenset.
• Måling med PageSpeed Insights: 20. oktober 2026 var labresultatet på mobil 94 for /pl/ (LCP 2,7 s) og 98 for /en/astro-developer/ (LCP 2,3 s). Google viser ennå ingen feltdata fra CrUX for disse adressene, så dette er en labmåling, ikke en vurdering av Core Web Vitals.
• Umiddelbar tømming av kantcache: Ved utrulling kaller distribusjonsskriptet Cloudflares Zone API (purge_cache: {"purge_everything": true}), slik at globale kantnoder leverer oppdatert innhold umiddelbart uten å vente på s-maxage-utløp.
• Deterministisk hurtigbufring for hashede ressurser: Statiske CSS-, JS- og AVIF-filer leveres med Cache-Control: public, max-age=31536000, immutable, mens HTML-dokumenter styres via max-age=0, must-revalidate med kantoppmerking. Dette muliggjør umiddelbare tilbakerullinger (instant rollbacks) uten foreldede mellomlagrede ressurser på globale noder.

#Sjekkliste for migrering fra WordPress til Astro

Basert på denne migreringen oppsummerer denne sjekklisten de kritiske stegene før DNS-omlegging:

1. Fullstendig ruteinventar: Eksporter alle historiske URL-er fra WordPress MySQL (innlegg, sider, arkiver, kategorier, feeder og vedlegg).
2. Design av omdirigeringsarkitektur: Etabler et komplett 301-omdirigeringskart som tar høyde for flerspråklige slugger.
3. Distribusjon av Edge Functions: Implementer omdirigeringsmotoren i en Edge Function (Cloudflare Functions / Worker) for å unngå statiske filgrenser.
4. Validering av hreflang-nettverk: Kontroller at alle språkversjoner har fullstendige, gjensidige koblinger over hele nettstedet.
5. Revisjon av JSON-LD-skjemaer: Valider Article-, FAQPage-, HowTo- og Organization-skjemaer mot schema.org.
6. Modulær nettkartutrulling: Etabler segmenterte XML-nettkart med streng ekskludering av noindex-sider.
7. Byggeprofilering og minnejustering: Test kompilering under minnebegrensninger og optimaliser V8-heapen.
8. Konfigurering av sikkerhetshoder: Håndhev CSP, HSTS, X-Frame-Options og Permissions-Policy på CDN-nivå.
9. Indekserbarhetskontroll: Sikre at testmiljøer og duplikater er pålitelig ekskludert fra indeksering.
10. Testkjøring etter omlegging: Sett opp automatiserte HTTP-røyktester og overvåk Search Console umiddelbart etter DNS-propagering.

#Bør jeg flytte fra WordPress til et statisk nettsted etter PHP2Shell?

21. oktober 2026 slapp PHP-prosjektet rettelser for PHP2Shell, to kritiske sårbarheter i selve PHP (CVE-2026-109618 og CVE-2026-109619). Ifølge php.net er alle PHP-installasjoner som betjener nettforespørsler utsatt, og for oppsettet med høyest risiko finnes det en demonstrert utnyttelse som slår til før noen applikasjonskode kjører (php.net). Wiz Research legger til at selv en enkel “Hello World”-applikasjon på en berørt PHP-versjon kan være sårbar (Wiz). Et nettsted som bygges til HTML-filer og serveres uten PHP, faller utenfor dette varselet. Dette nettstedet er et av dem: den uken fantes det ikke noe PHP her å oppdatere. Hva du gjør på et nettsted som fortsatt kjører PHP, står i veiledningen min om PHP2Shell.

Samme uke beskrev forfatteren av en teknisk publikasjon som flyttet fra WordPress til Hugo på Cloudflare Pages, sikkerhetsgevinsten slik på r/webdev:

Å slippe å ha en velkjent /wp-admin/-portal eksponert og stadig sondert, og deretter måtte bekymre seg for sårbarheter i stakken under, er for meg den største gevinsten.

(egen oversettelse, u/Select_From, r/webdev)

I en annen tråd skrev en utvikler at han etter PHP2Shell hadde konvertert 45 WordPress-nettsteder for kunder til Astro på 36 timer med en KI-agent. Et av de første svarene spurte om den delen et statisk bygg ikke løser:

Du nevner hele tiden statiske filer i GitHub-README-en din, men hva med nye innlegg? Hva bruker du som lar kundene legge til nye data eller redigere eksisterende?

(egen oversettelse, u/Lower_Rabbit_5412, r/webdev)

Forfatteren svarte at han hadde laget et Git-basert CMS for de 2 eller 3 kundene som ville redigere selv. Angrepsflaten fra PHP forsvinner, og hver dynamiske oppgave WordPress gjorde på ett sted, flytter et annet sted og trenger en egen ansvarlig:

Et svar i Hugo-tråden satte opp rekkefølgen på problemene slik jeg selv møtte dem:

Det største hinderet er som regel permalenker, hver gamle URL trenger en 301, ellers blør du rangeringer. Så de dynamiske delene: kommentarer, søk, skjemaer.

(egen oversettelse, u/ResidentPomegranate6, r/webdev)

Porteringen av malene tok uker for meg, og månedene etterpå gikk til omdirigeringer, hreflang og kontrollene beskrevet over. En migrering betyr å bygge nettstedet på nytt.

Oppdateringer og løpende vedlikehold er ofte det bedre svaret. PHP2Shell ble lukket med en PHP-oppdatering, og en migrering som tar uker, hjelper ikke en server som er upatchet i dag. Bli på WordPress, WooCommerce, Magento eller en annen PHP-stakk og hold den oppdatert hvis redaksjonen jobber i adminpanelet hver dag, hvis virksomheten hviler på utvidelser med ekte logikk (nettbutikk, booking, medlemskap, kurs), eller hvis ingen i teamet vil eie en Git-arbeidsflyt. Et statisk bygg passer når innholdet endres sjelden, få personer redigerer det, og den dynamiske delen er et skjema og en søkeboks. Et PHP-nettsted trenger jevnlig WordPress-vedlikehold med PHP-oppdateringer; ombygging til statisk nettsted er jobben til en Astro-utvikler.

Oppdatert 24. oktober 2026, en mellomvei: Å bli på WordPress eller bygge om i Astro er ikke de eneste to valgene. Matt Cromwell beskrev 14. oktober 2026 hvordan han bygde om nettstedet til firmaet sitt uten en offentlig WordPress-installasjon. WordPress kjører bare på hans egen maskin, i WordPress Studio. En kompilator gjør designsystemet hans om til theme.json og gjenbrukbare blokkmønstre, utvidelsen Simply Static eksporterer nettstedet til statiske filer, og Cloudflare Pages leverer dem. Blokkredigereren blir med, og det offentlige nettstedet har ingen PHP å oppdatere. Skjemaene er der det koster arbeid: en skjemautvidelse som sender inn via PHP, virker ikke på eksporterte sider, så han skrev et eget API-endepunkt som sender nyhetsbrevpåmeldinger til MailerLite. Han skriver også at et statisk nettsted har sine grenser, uansett utvidelse. Oppsettet passer et firmanettsted som redigeres på én maskin. En nettbutikk, et medlemsområde eller en redaksjon som publiserer daglig, trenger fortsatt en server. Må redigeringen være på nett mens forsiden skal gå uten PHP, er det et headless CMS-oppsett.

#Hva gir migrering fra WordPress til Astro etter ti måneder?

Etter ti måneder er balansen for migreringen til Astro på Cloudflare Pages positiv for min innholds- og tjenesteplattform:

1. Serverresponstid (TTFB): En side fra Cloudflares kantcache svarer fra Gdynia på omtrent 0,21 til 0,26 s, inkludert TLS-oppkobling (curl, 20.10.2026). Jeg har ingen sammenlignbar måling fra WordPress-tiden, så jeg oppgir ingen prosentvis forbedring.
2. Mindre angrepsflate: Uten PHP, SQL-database og wp-admin forsvinner hele klasser av typiske WordPress-angrep: SQL-injeksjon, kodekjøring gjennom en sårbar utvidelse, brute-force mot innloggingen. En mindre flate gjenstår å passe på: endepunktene i Cloudflare Functions (skjema, API) og sikkerhetshodene.
3. Tilgjengelighet for søkemotorer og KI-crawlere: Ren, semantisk HTML uten blokkerende JavaScript gjør det mulig for søkemotorer og LLM-crawlere (OpenAI, Anthropic, Perplexity) å indeksere teknisk innhold umiddelbart (GEO/AEO).
4. Forutsigbare driftskostnader: Servering av statiske filer fra kanten koster en brøkdel sammenlignet med å drifte skalerbare databaseklynger under trafikktopper.
5. Null vedlikeholdsnedetid: Utrullinger skjer atomisk på kanten uten at besøkende opplever feilmeldinger eller databaseavbrudd under oppdateringer.

Den ærlige ingeniørkonklusjonen: Migrering fra WordPress til Astro er ikke en overfladisk maloverhaling. Det er et helhetlig programvareprosjekt der malbygging er det enkleste steget, og hovedinvesteringen ligger i rutingarkitektur, automatiserte kvalitetsporter og flerspråklig disiplin. For innholdsnettsteder som er opptatt av fart og rekkevidde på flere språk, lønner arbeidet seg. Ønsker du denne arkitekturen implementert for din bedrift, se hvordan jeg jobber som Astro-utvikler, eller les mer om min WordPress-til-Astro-migrering. Flere tekniske analyser finner du på WPPoland-bloggen.