Jeg flytter frontenden på WordPress-nettsteder til Astro eller Next.js og lar redigeringen bli der den er, i WordPress. Jeg heter Mariusz Szatkowski, har jobbet med WordPress siden 2006 og gjør hver migrering selv, uten team eller underleverandører. Før jeg foreslår et rammeverksbytte, måler jeg hvor problemet ligger. Ofte holder det å rette hurtigbufferen, bildene eller en utvidelse som kjører spørringer ved hvert kall.
Når lønner det seg å migrere?
Et WordPress-nettsted med riktig satt opp hurtigbuffer leverer allerede ferdige sider. Migrering gir mening når frontenden selv er problemet: et tema ingen tør å røre, sidebyggere som laster mye JavaScript, eller et design som krever komponenter WordPress-temaet ikke håndterer godt. Den gir også mening når du vil skille den offentlige siden fra administrasjonen, slik at WordPress ikke lenger svarer direkte på hvert besøk.
Det endrer angrepsflaten, men fjerner den ikke. WordPress, utvidelser, kontoer og API trenger fortsatt oppdateringer, tilgangskontroll og sikkerhetskopier.
Hva du får etter migreringen
- En utgangsmåling. Representative URL-er med LCP, INP, CLS og TTFB målt før noe endres, og laget som skaper problemet navngitt. Viser den at hurtigbuffer eller bilder er nok, sier jeg det i stedet for å selge en migrering.
- En frontend under versjonskontroll. Astro- eller Next.js-maler og komponenter i git, publisering via bygging og forhåndsvisning før noe går live.
- Redigering i WordPress. Samme kontoer, samme roller, samme publiseringsflyt.
- Skjemaer, integrasjoner og videresendinger flyttet over, med listen over URL-er som skal sjekkes etter lansering.
- En før-og-etter-rapport. Samme URL-er, samme testforhold, begge måledatoene og feltdataene dine hvis du har dem. Uten det er en prosent bare et mål.
Astro eller Next.js?
| Astro | Next.js | |
|---|---|---|
| Standard rendering | Hele nettstedet forhåndsrendres; export const prerender = false gir rendering ved forespørsel per rute | I App Router er layouts og sider Server Components; statisk eller dynamisk avhenger av ruten |
| JavaScript i nettleseren | Ingen for Astro-komponenter; interaktive øyer bruker client:load, client:idle eller client:visible | React hydrerer Client Components merket med "use client" |
| Innhold som endres | Ny bygging eller ruter ved forespørsel; server:defer for server islands | ISR med export const revalidate, revalidatePath og revalidateTag |
| Drift | Statisk på hvilken som helst server; for ruter ved forespørsel finnes offisielle adaptere for Cloudflare, Netlify, Node og Vercel | Node.js-server eller Docker; med output: 'export' mister du ISR, Proxy, Server Actions og bildeoptimalisering med standard-loaderen |
Astro passer for blogger, bedriftsnettsteder og dokumentasjon. Next.js gir mening når frontenden er en applikasjon med innlogging, data per forespørsel eller endringer som skjer på serveren. I Next.js 16 ble filkonvensjonen middleware omdøpt til proxy, så eldre veiledninger om middleware handler om samme funksjon.
Vil du ha frontenden driftet i Norge eller på egen server, er Astros Node-adapter det enkleste valget: statiske sider og ruter ved forespørsel kjører da hos den leverandøren du velger, ikke hos en amerikansk plattform.
Har du allerede en frontend i Next.js?
Noen prosjekter kommer med headless WordPress og en Next.js-frontend som ikke lenger trenger å være en applikasjon. Den offisielle guiden for migrering fra Next.js til Astro beskriver veien jeg følger:
- Nytt prosjekt med
npm create astro@latest, og integrasjonen@astrojs/reactfor å gjenbruke eksisterende React-komponenter (filer med.jsxeller.tsx). - Mapper:
public/blir som den er; resten flyttes tilsrc/, og baresrc/pages/styrer ruting. - Layout:
_documentellerapp/layouterstattes av en Astro-layout med<html>,<head>,<body>og<slot />. - Data:
getStaticProps()erstattes avawaiti komponentens frontmatter, medfetch(),getCollection()ellergetEntry(). - Syntaks:
<Link>blir en vanlig<a href="">,{children}blir<slot />, og props leses fraAstro.props. - Bilder:
next/imageerstattes avImagefraastro:assetsi.astro- og.mdx-filer; i React-komponenter brukes en vanlig<img />.
Det som bygger på ISR eller revalidatePath, har ingen direkte motpart. Det løses med ny bygging ved publisering eller med ruter som rendres ved forespørsel.
Hvordan henter Astro innhold fra WordPress?
Astros egen WordPress-guide bruker den innebygde REST API-en under /wp-json/wp/v2/, for eksempel /wp-json/wp/v2/posts. Offentlige lesinger krever ikke autentisering som standard. Med _embed følger relaterte ressurser som fremhevet bilde, og med _fields begrenser du svaret til feltene malen bruker. WPGraphQL er valgfritt.
På et statisk nettsted trenger dynamiske ruter som /blogg/[slug] funksjonen getStaticPaths(). Med rendering ved forespørsel trengs den ikke, men da spør hvert besøk API-et, og hurtigbuffer foran frontenden blir viktig igjen.
Informasjonskapsler og samtykke etter ekomloven
En ny frontend betyr et nytt samtykkebanner, og det er der mange migreringer glipper. Ekomloven § 3-15, i kraft fra 1. januar 2025, forbyr å lagre eller hente opplysninger i brukerens utstyr uten forhåndsinformasjon og samtykke, med unntak for ren overføring og tjenester brukeren selv har bedt om og som krever det.
Under migreringen lager jeg en liste over hvert skript på det gamle nettstedet (analyse, piksler, innebygde videoer, chat), og i den nye frontenden lastes ingen av dem før samtykke. I Astro er det ofte enklere, fordi HTML-en ikke drar med seg JavaScript fra utvidelser ingen har gått gjennom.
Hvordan ser prosessen ut?
- Revisjon. Oversikt over URL-er, maler, skjemaer, integrasjoner og tredjepartsskript, med utgangsmåling.
- WordPress som backend. Jeg slår av det som bare tjente den gamle frontenden, setter opp forhåndsvisning og begrenser tilgangen til API-et der det trengs.
- Ny frontend. Jeg implementerer designet du leverer, som Figma-fil eller som en mal der du markerer hvilket element som står hvor. Grafisk design og wireframes lager jeg ikke.
- Testing i staging. Videresendinger, metadata, strukturerte data, skjemaer, samtykke og analyse. Hver endring beskrives skriftlig.
- Lansering. DNS byttes når du har godkjent i staging, deretter sjekk av URL-listen og dekningen i Search Console.
Typiske scenarier
Innholdsnettsted eller blogg
Det tydeligste tilfellet for Astro. Innlegg endres sjelden og leses ofte, så forhåndsrendret HTML fjerner databasespørringer ved hvert besøk. Det praktiske spørsmålet er publiseringen: automatisk bygging etter hver publisering i WordPress, eller utvalgte ruter som rendres ved forespørsel.
WooCommerce-butikk
Katalogen kan være statisk, men handlekurv, kasse og kundekonto avhenger av økter og data per forespørsel. Før jeg foreslår headless WooCommerce, sjekker jeg hvilke betalings- og fraktutvidelser som er avhengige av WooCommerce-malene, for eksempel Vipps-integrasjonen eller fraktmodulen du bruker i dag. Mer om dette i WooCommerce headless-migrering.
Applikasjon med innloggede brukere
Dashbord, lukkede områder og skjemaer med serverlogikk passer bedre i Next.js, med Server Components for data og Client Components bare der det er interaksjon.
SEO under migreringen
URL-er beholdes eller får en 301. Titler, beskrivelser, kanoniske URL-er, hreflang, Open Graph, strukturerte data, robots.txt og nettstedskartet bygges opp igjen i den nye frontenden og sammenlignes med det gamle nettstedet før lansering. Etterpå følger jeg dekningen i Search Console. En godt gjennomført migrering hindrer tap; den lover ikke økning.
Hvordan starter vi?
Skriv til meg via kontaktskjemaet med nettadressen, hva som bremser deg i dag og hvilke integrasjoner nettstedet har. Du får skriftlig svar med åpne spørsmål og, etter revisjonen, et tilbud med forutsetningene det bygger på. Jeg fakturerer som B2B med EU-mva-nummer PL7393037445.
Hvilke tjenester henger sammen med migreringen?
- Next.js-utvikler, for nye Next.js-prosjekter
- Astro-utvikler, for nye Astro-nettsteder
- Headless CMS-utvikler
