Migrering til Next.js / Astro i Bern

Bedrifter i Bern flytter fra WordPress, Joomla, Drupal eller et eldre rammeverk til Astro eller Next.js når det gamle systemet koster mer i vedlikehold, sikkerhetsoppdateringer og treg lasting enn det gir tilbake. Jeg gjør slike migreringer alene, fra URL-kart til overvåking etter lansering, og her står hvordan jeg jobber, hva som er spesielt for et nettsted i Bern, og hva som kan gå galt.

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

Migrering lønner seg når dagens CMS står i veien for ytelse, sikkerhet eller redaksjon, og ikke når det hadde holdt med færre plugins og bedre caching. Derfor starter jeg alltid med å se på det eksisterende nettstedet før jeg anbefaler et bytte. Typiske tegn på at et bytte gir mening: administrasjonen er tregere enn selve nettstedet, hver plugin-oppdatering må testes manuelt fordi noe brekker, og redaktørene unngår å publisere når det er travelt.

Valget mellom de to rammeverkene følger innholdet. Astro passer når nettstedet er mest tekst, bilder og sider som sjelden endrer seg: det bygger statisk HTML og sender bare JavaScript til de delene som trenger det. Next.js passer når det finnes innlogging, kundeområder, personaliserte data eller mye interaksjon som må rendres på serveren. Mange nettsteder trenger ikke å bytte backend i det hele tatt: WordPress kan bli værende som redigeringsverktøy og levere innhold over REST eller GraphQL. Mer om det står på siden om headless CMS-utvikling.

#Hvordan beholder jeg rangeringene i Google når URL-ene endres?

Hver URL-endring er en skriftlig beslutning, ikke noe generatoren gjør av seg selv. Arbeidet starter med et inventar som slår sammen fire kilder: en crawl av dagens nettsted, XML-sitemapen, eksport av sider med visninger fra Search Console og, der hostingen gir tilgang, serverloggene. Loggene viser adresser som fortsatt får trafikk fra gamle lenker, men som verken crawleren eller sitemapen finner.

Ut av dette kommer et URL-kart med én rad per gammel adresse: ny adresse, statuskode (301 eller bevisst 410) og hvem som har godkjent raden. Jeg unngår kjeder, slik at en gammel adresse går rett til den endelige siden og ikke via en mellomstasjon fra en tidligere relansering. Før overgangen kjører jeg kartet som et skript mot testmiljøet og sjekker at hver rad gir riktig statuskode og riktig mål. Rader som feiler, blir rettet før noe går live.

Det samme gjelder metadata. Tittel, metabeskrivelse, canonical og strukturerte data (for eksempel Organization, BreadcrumbList og Article) sammenlignes side for side mellom gammel og ny versjon. Strukturerte data bygges fra innholdsmodellen i stedet for å limes inn manuelt, slik at de ikke forsvinner når en redaktør endrer en side senere.

#Hvordan håndterer et nettsted i Bern tysk, fransk og engelsk?

Bern er hovedstad i kantonen Bern, som er offisielt tospråklig på tysk og fransk, og byens eget nettsted tilbyr tysk, engelsk, fransk og italiensk. Mange bedrifter i Bern har derfor minst to språkversjoner, og det er der en migrering oftest går galt i stillhet.

For flerspråklige nettsteder gjør jeg tre ting. Hver språkversjon får sine egne rader i URL-kartet, også når slugen er oversatt. Hreflang settes med språk og region der det er relevant (for eksempel de-CH og fr-CH) og med en x-default, og jeg sjekker at hver side peker tilbake til søstrene sine. En seksjon flyttes på alle språk samtidig, ellers peker hreflang i en periode fra ny side til en gammel adresse som snart blir en redirect. Etter lansering kontrollerer jeg språkversjonene i Search Console hver for seg.

#Hva krever den sveitsiske personvernloven av det nye nettstedet?

Den totalreviderte sveitsiske personvernloven, Federal Act on Data Protection (FADP), trådte i kraft 1. september 2023. Tilsynsmyndigheten er Federal Data Protection and Information Commissioner (FDPIC), som fører tilsyn med om private virksomheter behandler personopplysninger lovlig. Loven krever blant annet at den som samler inn personopplysninger informerer den registrerte om det, og overføring av personopplysninger til utlandet har egne regler.

For en migrering betyr det noe helt praktisk. En ny frontend tar ofte inn nye tjenester: et annet skjemaverktøy, en ny analyseløsning, et CDN eller hosting hos en leverandør med servere i et annet land. Jeg leverer en liste over hver tjeneste den nye løsningen sender data til, og hvor den er plassert, slik at du eller rådgiveren din kan oppdatere personvernerklæringen før lansering. Jeg gir ikke juridiske råd, men jeg sørger for at den tekniske oversikten finnes og stemmer.

#Hvordan foregår overgangen i praksis?

1. Inventar av URL-er, redirects, strukturerte data, skjemaer, integrasjoner og kritisk innhold.
2. Innholdsmodell: hvilke innholdstyper, felter og relasjoner som finnes i dag, og hvilke som faktisk brukes. Felter ingen har fylt ut på flere år, flyttes ikke.
3. Valg mellom Astro og Next.js, og om backenden blir værende som headless kilde.
4. Testmiljø med fullt URL-kart, metadata-paritet og en automatisk sammenligning av gammel og ny side.
5. Overgang seksjon for seksjon bak en reverse proxy eller edge-regler, big bang bare på små nettsteder.
6. Innsending av ny sitemap i Search Console og overvåking av indeksering, 404-feil og Core Web Vitals de første ukene.

Repo, miljøvariabler, deploy-pipeline og en kort driftsbeskrivelse blir hos deg. Oppfølgingen etter lansering dekker kritiske rettinger og en ytelsesgjennomgang etter den første trafikktoppen.

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

De vanligste feilene ser jeg etter med vilje, fordi de sjelden gir en synlig feilmelding:

• Glemte adresser. PDF-er, bildeadresser og gamle kampanjesider mangler i kartet. Serverloggene og 404-rapporten i Search Console avslører dem; jeg går gjennom begge daglig i den første perioden.
• Noindex fra testmiljøet. En robots-regel eller meta noindex fra staging følger med til produksjon. Jeg kontrollerer den rendrede HTML-en på et utvalg sider rett etter lansering, ikke bare innstillingene.
• Tapt innhold i overføringen. Kortkoder, innebygde skjemaer eller tabeller fra en sidebygger forsvinner i eksporten. En automatisk sammenligning av ordtelling og overskrifter per side fanger de fleste tilfellene.
• Skjemaer som ikke leverer. Et kontaktskjema som ser riktig ut, men aldri sender e-post. Hvert skjema testes med en ekte innsending før og etter overgangen.
• Hreflang som peker feil. Språkversjoner som peker til redirects eller til hverandre feil vei. Jeg kjører en kontroll av gjensidighet over hele sitemapen.

Et midlertidig fall i visninger etter en relansering er vanlig mens Google crawler de nye adressene. Det som betyr noe, er at fallet går tilbake, og det følger jeg med på i Search Console til det gjør det.

#Hva trenger jeg fra deg for et skriftlig omfang?

Send meg adressen til det nåværende nettstedet, hvilket CMS og hvilken hosting det kjører på, hvilke språkversjoner som finnes, og hvor trafikken kommer fra i dag (organisk søk, annonser, nyhetsbrev, henvisninger). Tilgang til Search Console i lesemodus gjør inventaret raskere, men er ikke nødvendig for den første vurderingen. Ut fra dette skriver jeg et omfang med hva som flyttes, hva som blir igjen og hvilke risikoer jeg ser. Den generelle fremgangsmåten står også på siden om migrering til Next.js og Astro.