Migrering til Next.js / Astro i Zürich

Zürich er Sveits’ største by, med 440 935 innbyggere ved utgangen av 2025, og hovedstad i kantonen Zürich. Byen er et av de ledende finans- og forsikringssentrene i Europa, og ETH Zürich gjør den til et viktig sted for teknologiutvikling. Nettstedene her har derfor ofte tre trekk som gjør en migrering krevende: mange år med innhold, flere språk og strenge krav fra juridisk avdeling om hvor data havner.

Jeg er Mariusz Szatkowski og flytter nettsteder fra WordPress, Joomla, Drupal eller eldre rammeverk til Astro eller Next.js. Her er hva jobben består av, hvordan du kan kontrollere den, og hva som er spesielt for en virksomhet i Zürich.

#Bør vi bytte til Astro eller Next.js, eller bare rydde i WordPress?

Et nytt frontend løser strukturelle problemer: et tema som ikke lar seg oppdatere uten å knekke, en plugin-stabel ingen tør røre, eller et nettsted som må bygges om for hver kampanje. Det løser ikke én treg plugin eller manglende caching. Da sier jeg det i omfanget, fordi en opprydding er billigere og har mindre risiko.

Valget mellom rammeverkene følger av innholdet. Astro passer når nettstedet er mest tekst, artikler og landingssider, fordi sidene bygges til statisk HTML og bare de interaktive delene får JavaScript. Next.js passer når du trenger innlogging, kundeportal, personalisering eller server-rendering per forespørsel. Mer om vurderingen finner du på migrering til Astro og Next.js.

#Hvordan beholder vi rangeringene i Google når adressene endres?

Med et URL-kart der hver gammel adresse har en eksplisitt skjebne. Jeg bygger inventaret fra tre kilder: sitemapen, en full crawl og sidene i Search Console som har visninger eller eksterne lenker. Sider som ikke finnes i menyen, men som fortsatt henter trafikk fra gamle lenker, dukker opp i den tredje kilden og ellers ingen andre steder.

Hver rad i kartet får ett av tre utfall: samme adresse (200), en 301 til den nye adressen, eller en skriftlig begrunnelse for at siden fjernes. Ingen adresse endres fordi en generator foretrekker et annet mønster. Jeg sjekker også eksisterende omdirigeringer, fordi gamle regler fra tidligere relanseringer ofte gir kjeder på to eller tre hopp. Etter migreringen skal hver kilde nå målet i ett hopp.

Titler, metabeskrivelser, canonical og strukturerte data (schema.org) hentes ut fra begge versjonene og sammenlignes side for side før lansering. Avvik er en liste med konkrete adresser, ikke et inntrykk.

#Hvordan håndterer vi tysk og engelsk på samme nettsted?

Tysk er hovedspråket for over 60 prosent av befolkningen i Sveits, og i Zürich er tysk det offisielle språket. Engelsk er det mest brukte språket blant utenlandske innbyggere som ikke er et av de fire nasjonalspråkene, og brukes i økende grad i forretningslivet. Mange nettsteder i byen har derfor en tysk og en engelsk versjon, noen også fransk for kunder i Romandie.

Det skrevne språket er standardtysk, mens sveitsertysk dominerer i tale. For en migrering betyr det at språkkoden må være bevisst valgt. Bruker dagens nettsted de-CH i hreflang, eller bare de? Retter du deg også mot Tyskland og Østerrike med samme tekst? Det avgjør om du trenger én tysk versjon eller flere, og det må være bestemt før URL-strukturen låses.

Kontrollen av hreflang er mekanisk: hver side peker til alle språksøsknene sine og til seg selv, og hvert mål svarer med 200, ikke 301. Sider som bare finnes på ett språk, får ingen falske par. Flerspråklige WordPress-plugins lagrer oversettelser på ulike måter, med prefiks, underdomener eller parametere, så første steg er å finne mønsteret dagens nettsted faktisk bruker.

#Hva betyr den sveitsiske personvernloven for et nytt frontend?

Den reviderte personvernloven (revDSG, SR 235.1) har gjeldt fra 1. september 2023. Den gjelder for virksomheten din i Zürich, med GDPR i tillegg hvis du retter deg mot kunder i EU og EØS. Fire bestemmelser treffer en migrering direkte:

• Artikkel 7 krever personvern fra planleggingsfasen og standardinnstillinger som begrenser behandlingen til det formålet krever. Et nytt frontend er planleggingsfasen.
• Artikkel 9 sier at en databehandler bare kan brukes når du selv lovlig kunne behandlet dataene, og at underleverandører krever forhåndsgodkjenning.
• Artikkel 16 og 19 krever at du sier hvilke land data sendes til, og at mottakerlandet har et tilstrekkelig vernenivå eller andre garantier.
• Artikkel 24 krever melding til den føderale personvernkommissæren (EDÖB) så raskt som mulig ved et brudd som sannsynligvis gir høy risiko.

En migrering endrer ofte hvor data flyter. Kontaktskjemaet som gikk via en WordPress-plugin, går kanskje nå via en ekstern skjematjeneste. Hosting, CDN og analyse kan flytte til nye leverandører i andre land. Jeg leverer derfor en liste over hver tjeneste i den nye løsningen som behandler personopplysninger, med hvor den lagrer data. Med den kan du oppdatere personvernerklæringen, databehandleravtalene og registeret over behandlingsaktiviteter før lansering.

#Hvordan foregår selve overgangen?

1. Innholdsmodell. Innleggstyper, egendefinerte felt, taksonomier og skjemaer blir til en eksplisitt modell, i Markdown-filer, i et headless CMS eller via WordPress-API-et hvis redaksjonen vil beholde panelet de kjenner.
2. Testmiljø. Den nye versjonen kjører på en egen adresse med noindex og passord. URL-kartet kjøres mot den, og hver rad må gi riktig statuskode og riktig mål.
3. Trinnvis cutover. Store nettsteder flyttes seksjon for seksjon, for eksempel aktuelt-seksjonen først og tjenestesidene etterpå. Alt på én gang bruker jeg bare der hele kartet kan testes på én ettermiddag.
4. Kontroll etter lansering. URL-kartet kjøres mot produksjon. I Search Console følger jeg dekningsrapporten, 404-feil og indekserte sider per språk, sammen med Core Web Vitals.

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

• Tapte adresser. Hele kartet kjøres mot produksjon, og hvert avvik fra forventet statuskode listes.
• Testmiljøet blir indeksert. Jeg sjekker noindex og tilgangsbeskyttelse før første crawl og søker etter testdomenet i Google etter lansering.
• Feil språkpar. Hreflang valideres per side, med retur-lenker og statuskoder.
• Skjemaer som slutter å levere. Hvert skjema testes med ekte innsending til riktig mottaker før omdirigeringene aktiveres.
• Indekseringsfall. Dekningsrapporten følges per språk de første ukene, og 404-er rettes før de rekker å koste trafikk.

Du får repoet, miljøvariablene og deploy-pipelinen i dine egne kontoer, sammen med en kort veiledning for å publisere. Vil du beholde et kjent redaksjonspanel, se headless CMS-utvikling.

#Hva trenger du å sende for et skriftlig omfang?

Send meg adressen til dagens nettsted, hvilket CMS og hvilke språk det kjører på, og hvor trafikken kommer fra i dag (organisk søk, annonser, direkte eller henvisninger). Da får du et skriftlig omfang med URL-inventar, anbefalt rammeverk og plan for overgangen før noe arbeid starter.

#WordPress-miljø og lokale signaler i Zürich

Community-referansen er WordPress Zürich (https://www.meetup.com/wordpress-zurich/). Den erstatter ikke kontrakt, men setter det tekniske språket team bruker i Zürich.

Zürich er et viktig forretnings- og teknologisenter. Vi leverer WordPress-løsninger med fokus på ytelse, sikkerhet og målbare forretningsresultater. I Bank og farmasi-segmentet handler spørsmålene ofte om WordPress, WooCommerce, Astro, Next.js mot legacy.