Tolv 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 det egentlige året: 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 vårt eget nettsted
• Omfang: seks språk, over 14 000 forhåndsgjengitte sider med beskrivende slugger og full hreflang-sammenkobling
• Tidslinje: uker til et fungerende statisk bygg, omtrent tolv måneder til stabil, feilfri søkeytelse i globale søkemotorer
• 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: tusenvis av 301-regler som traff Cloudflares 100 KB-grense for _redirects og ble flyttet til et Cloudflare Functions-lag
• Stack: Astro med Tailwind CSS, AVIF-bildepipeline, statisk HTML levert fra globalt kantnettverk
• Resultat: global TTFB under 40 ms, null dynamisk angrepsflate, forutsigbar KI-crawler-tilgang, paritet over seks språk opprettholdt

#WordPress-til-Astro-migrering, den virkelige kostnaden: TL;DR i 4 punkter

1. Flyttingen er den billige delen. Maler og innholdseksport tok uker; migreringen brukte rundt tolv måneder på å nå stabil søkeytelse uten tilbakefall.
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 14 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.

#Uker: flyttingen alle budsjetterer for

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.

#Måneder: omdirigeringslaget ingen planla

Det første kvartalet etter lansering gikk med til omdirigeringsinfrastrukturen. 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) vokste listen til over 18 000 distinkte regler.

Her traff vi 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.

#Måneder: seks språk som må være enige for alltid

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 vi automatiserte skript for paritetsvalidering som kjøres før hver commit.

#Minnetopologi i Node.js ved 14 000 forhåndsgjengitte sider

Astro kompilerer statiske sider i én enkelt arbeidsprosess. Da arkivet passerte 14 000 undersider (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.

Vi løste dette ved å omstrukturere hele distribusjonsflyten:

1. Lokal bygging på Apple Silicon: Bygget kjøres lokalt på M-serie-prosessorer med eksplisitt minnetildeling via NODE_OPTIONS='--max-old-space-size=12288'. Maskinen kompilerer 14 477 HTML-sider på under 3,5 minutter gjennom effektiv flertrådet prosessering.
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.

#Modulær nettkartgenerering og kanonisk graf

En annen vesentlig utfordring lå i sitemap-arkitekturen. Standardintegrasjonen @astrojs/sitemap produserte én gigantisk XML-fil for 14 000 URL-er, noe som overbelastet crawler-grenser og overså spesifikke noindex-regler.

Vi utviklet en modulær sitemap-generator som produserer en struktur bestående av 32 sammenkoblede XML-filer:

• En sentral sitemap-index.xml som peker til 6 regionale språkindekser (sitemap-nb.xml, sitemap-en.xml osv.).
• Hver språkindeks deles inn i dedikerte bladfiler: bloggartikler, tjenestesider, case-studier og byprofiler.
• 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.

#Verktøyene du bygger på nytt som WordPress ga gratis

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.

I løpet av tolv måneder utviklet vi en testpakke med 34 automatiserte kvalitetsporter (run-gates.mjs), som kjøres før hver utrulling:

• Intern lenkeintegritet (check:links og check:service-navigation-parity): Skanner alle ruter for 404-lenker og sikrer at hver kjernetjeneste har minst to innkommende lenker.
• 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.

Dette testsettet gir en pålitelighet ingen WordPress-backend kan matche, men krevde hundrevis av dedikerte ingeniørtimer å etablere.

#Typesikre Content Collections med Zod-validering

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.

#Bedriftssikkerhet og automatisert Content Security Policy (CSP)

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=63072000; 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.

#Medie-pipelines og lokal GDPR-kompatibel typografi

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. Vi 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 eliminerer uønskede layout-forskyvninger (Cumulative Layout Shift, CLS = 0.00).
3. Lokalt hostede fonter: Vi fjernet alle eksterne kall til Google Fonts. Fontfamilier lagres lokalt i WOFF2-format med latinsk delsett (subsetting), noe som hindrer gjengivelsesblokkering og oppfyller europeiske personvernkrav (GDPR).

#Astro Islands for interaktivitet uten JavaScript-overhead

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 (som kontaktskjemaer, filtervelgere eller kalkulatorer), benytter vi Astro Islands:

• Kontaktskjemaet lastes som en isolert øy med client:visible, som utsetter skriptnedlasting til brukeren ruller skjemaet inn i synsfeltet.
• Filtermenyer og kategorivelgere benytter client:idle for å kjøre skript i ledige nettlesersykluser, slik at hovedtråden holdes responsiv under sideinnlasting.
• Responsive navigasjonselementer benytter client:media="(max-width: 768px)", slik at desktop-brukere slipper å laste ned menyskript.
• Spambeskyttelse håndteres via usynlig Cloudflare Turnstile uten forstyrrende bildeoppgaver eller personvernutfordringer.
• Skjemainnsendinger rutes tilstandsløst gjennom et Edge API-endepunkt til Resend-webhooks, helt uten behov for en persistent server.

#Klientside WASM-søk uten databasekall

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.

Vi implementerte en WebAssembly-basert (WASM) søkemotor direkte i nettleseren:

• Under bygget kompileres en kompakt, segmentert leksikalsk indeks fra artikkeltekstene, renset for menyer, kodeblokker og standardkode.
• Nettleseren laster kun ned små indekssegmenter (15-30 KB) som matcher aktive søketegn, og viser søkeresultater med uklar matching (fuzzy search) og termutheving på under 15 ms.
• Flerspråklige stoppordbøker og ordstamming sikrer høy treffsikkerhet ved minimal datamengde på tvers av alle seks språk.
• Serverbelastningen forblir null uansett hvor mange samtidige søk som utføres.

#Kontinuerlig Core Web Vitals-automatisering i CI/CD

I WordPress-installasjoner forringes ofte ytelsesmålinger etter plugin-oppdateringer. I Astro håndheves ytelsesbudsjetter programmatisk i distribusjonsflyten:

• Lighthouse CI: Hvert bygg gjennomgår automatiske revisjoner for Largest Contentful Paint (LCP < 1,0s), Interaction to Next Paint (INP < 50ms) og Cumulative Layout Shift (CLS = 0,00).
• Visuelle regresjonstester: Automatiserte Playwright-tester verifiserer kritiske visningsformater på mobil og desktop før sammenslåing.
• 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.

#Teknisk migreringssjekkliste: 10 trinn før WordPress kobles fra

Basert på tolv måneders produksjonserfaring 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.

#Hva migreringen faktisk kjøpte: 12-måneders ingeniørresultater

Etter tolv måneder med kontinuerlige telemetridata er balansen for migreringen til Astro på Cloudflare Pages entydig positiv for vår innholds- og tjenesteplattform:

1. Serverresponstid (TTFB): Falt fra et gjennomsnitt på 650-1200 ms (under PHP/MySQL-belastning) til stabile 25-45 ms fra ethvert Cloudflare-kantpunkt i verden.
2. Eliminering av sårbarheter: Fjerningen av PHP-kjøremiljøet, SQL-databasen og wp-admin fjernet 100 % av typiske CMS-angrepsvektorer (SQL-injeksjoner, plugin-sårbarheter, brute-force-angrep).
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 organisasjoner som krever global toppytelse, skalerbarhet og null vedlikeholdsbyrde, er dette et teknologisk skritt som gir solid avkastning i alle ledd. Ønsker du denne arkitekturen implementert for din bedrift, se hvordan vår Astro-utvikler jobber, eller les mer om vår WordPress-til-Astro-migrering. Flere tekniske analyser finner du på WPPoland-bloggen.