Migrering til Next.js / Astro i Frankfurt am Main

En bedrift i Frankfurt som vurderer å forlate WordPress, Joomla, Drupal eller et eldre rammeverk, har som regel ett av tre problemer: sidene er trege, oppdateringene av utvidelser tar mer tid enn innholdet, eller sikkerhetsavdelingen liker ikke angrepsflaten. Astro og Next.js løser alle tre, men bare hvis flyttingen ikke koster deg søketrafikken du har bygget opp. Jeg tar jobben alene, fra første URL-liste til siste kontroll i Search Console.

#Når lønner det seg å bytte fra WordPress til Astro eller Next.js?

Ikke alltid. Er problemet ti utvidelser for mye og manglende caching, er det billigere å rydde i det gamle systemet. Et bytte lønner seg når redaksjonen kjemper mot sidebyggeren, når hver oppdatering må testes manuelt fordi ingen tør å trykke på knappen, eller når du trenger en frontend som selskapets egne utviklere kan vedlikeholde i et vanlig Git-repo.

Astro passer for innhold: tjenestesider, blogg, rapporter, dokumentasjon. Sidene leveres som ferdig HTML, og JavaScript lastes bare der en komponent trenger det. Next.js passer når nettstedet har innlogging, kundeportal, personlige data eller priser som endres hele tiden. Mange nettsteder har begge deler, og da skiller jeg dem: innholdet i Astro, portalen i Next.js eller i det systemet den allerede kjører i.

#Hvordan lager jeg et URL-kart som holder?

Jeg henter gamle adresser fra fire kilder og slår dem sammen: XML-sitemap, Search Console, serverlogger og en crawl av hele nettstedet. Logger er viktigst, fordi de viser adresser som bare lenkes fra andre nettsteder eller fra gamle PDF-er og nyhetsbrev. Bilder og nedlastbare filer er med på listen, ikke bare HTML-sider.

Hver adresse får én beslutning: uendret, 301 til en bestemt ny adresse, eller 410 når innholdet bevisst fjernes. Google advarer mot å sende mange ulike gamle sider til forsiden, fordi det kan bli behandlet som en myk 404. Kjeder er også ute: hver gammel adresse peker direkte til sluttmålet. Tabellen får du til godkjenning før noe går live.

Omdirigeringene skal ligge lenge. Googles egen veiledning for flytting med nye URL-er sier at de bør beholdes så lenge som mulig, som regel minst ett år. Derfor legger jeg dem i hostens konfigurasjon, ikke i applikasjonskoden der de lett forsvinner ved neste refaktorering.

En felle i Astro: uten en adapter skriver astro build omdirigeringer som HTML-filer med meta refresh. Serveren sender da aldri statuskoden 301. Med en adapter eller hostens egen redirect-fil blir de ekte serveromdirigeringer, og det sjekker jeg med en HTTP-forespørsel per regel, ikke ved å se på konfigurasjonen.

#Hva skjer med innholdet, feltene og de strukturerte dataene?

Fra WordPress henter jeg innlegg, sider, taksonomier, forfattere og egendefinerte felt via REST API eller WP-CLI og gjør dem om til Markdown eller MDX med frontmatter, eller til et headless CMS når redaksjonen publiserer daglig. Fra Drupal og Joomla leser jeg databasen direkte. Shortcodes og sidebyggerblokker er den største risikoen: de blir enten til komponenter eller til ren HTML, og du får en liste over berørte sider før jeg begynner.

Title, meta description, canonical og JSON-LD følger hver side. Jeg sammenligner gammel og ny versjon maskinelt: samme title, samme canonical-logikk, samme schema-typer, samme antall interne lenker. Avvik kommer som en liste du kan gå gjennom, ikke som en påstand om at alt ser bra ut.

#Hvordan håndterer jeg tysk og engelsk på samme domene?

Mange nettsteder i Frankfurt har en tysk og en engelsk versjon. Hreflang fungerer bare når annotasjonene er gjensidige: Google skriver at taggene ignoreres hvis to sider ikke peker på hverandre, og hver språkversjon må også peke på seg selv. Ved en migrering flyttes disse parene ofte feil, fordi den gamle utvidelsen genererte dem og den nye frontenden ikke vet om dem. Jeg bygger parene fra innholdsmodellen, ikke fra en liste skrevet for hånd, og kontrollerer dem i den ferdige HTML-en. En x-default legger jeg bare inn når det finnes en reell språkvelger eller standardside.

#Hva må en nettside i Frankfurt oppfylle etter flyttingen?

Frankfurt ligger i delstaten Hessen og er hjemsted for Den europeiske sentralbanken og Deutsche Bundesbank. Kundene og myndighetene du forholder deg til er tyske, så noen krav gjelder uansett hvilket system sidene kjører på.

• Impressum. Den tyske loven om digitale tjenester (DDG § 5) pålegger tilbydere av forretningsmessige digitale tjenester å holde bestemte opplysninger lett gjenkjennelige, direkte nåbare og alltid tilgjengelige. Ved migreringen sjekker jeg at Impressum finnes, er lenket fra hver sidemal og svarer 200 på produksjon.
• Tilgjengelighet for netthandel. Barrierefreiheitsstärkungsgesetz (BFSG) gjelder ifølge § 1 for tjenester i elektronisk handel som leveres til forbrukere etter 28. juni 2025. Selger du til forbrukere, er en ny frontend en anledning til å få overskrifter, skjemaer, kontrast og tastaturnavigasjon riktig fra start i stedet for å lappe senere.
• Personvern. Tilsynsmyndighet i Hessen er Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI), som blant annet har egne temaer for handel og kredittbransjen. For deg som leser på norsk: personvernforordningen gjelder også som norsk lov gjennom personopplysningsloven, så grunnreglene er de samme på begge sider. Praktisk betyr det at jeg lister hva hver sidemal laster fra tredjeparter, som analyse, skrifttyper, kart og video, og hva som settes før samtykke. Du bestemmer hva som blir med.

Jeg gir ingen juridisk vurdering. Jeg sørger for at de tekniske forutsetningene er på plass og at ingenting forsvinner i overgangen.

#Hva kan gå galt, og hvordan oppdager jeg det?

• Noindex fra testmiljøet blir med til produksjon. Jeg leser robots-tagger og X-Robots-Tag i svarene fra produksjon rett etter bytte.
• Glemte adresser. Sider som bare har eksterne lenker mangler i sitemapet. Serverloggene etter lansering viser hvilke 404-er Googlebot fortsatt prøver, og hver av dem får en omdirigering eller en bevisst 410.
• Tapt intern lenking. Menyer, brødsmuler og relaterte lenker telles per side før og etter. En side som mister halvparten av sine innkommende lenker, faller ofte i søk.
• Skjemaer og sporing. Kontaktskjema, e-postvarsler og konverteringsmåling testes med ekte innsending på produksjon.
• Ytelse som blir dårligere. Jeg måler Core Web Vitals på de samme sidemalene før og etter, med samme verktøy.

I Search Console følger jeg den gamle og den nye sitemapen side om side: den gamle skal krympe, den nye vokse. Visningene for nye URL-er skal komme mens de gamle faller. Går domenet også over til et nytt, sender jeg adresseendring for hver verifiserte variant av det gamle domenet. Ved bytte innenfor samme domene trengs ikke det verktøyet.

Overgangen kan gjøres seksjon for seksjon bak samme domene, med en reverse proxy eller edge-regler som sender hver sti til riktig system. Da kan en seksjon rulles tilbake uten at resten av nettstedet merker det.

#Hvordan kommer du i gang?

Send meg adressen til dagens nettsted, hvilket CMS og hvilken hosting det kjører på, og hvor trafikken kommer fra: organisk søk, annonser, nyhetsbrev eller partnere. Si også om du har tysk og engelsk, og om du selger til forbrukere. Du får et skriftlig omfang med URL-inventar, anbefalt løsning og risikopunkter. Pris og tidsplan følger av omfanget og avtales skriftlig før arbeidet starter.

Den generelle fremgangsmåten står på siden om migrering til Astro og Next.js. Skal redaksjonen fortsette i et redigeringsgrensesnitt, beskriver jeg mulighetene på siden om headless CMS-utvikling.

#Stack-valg i Frankfurt am Main

Meetup: WordPress Frankfurt (https://www.meetup.com/wordpress-frankfurt/).