Migrering til Next.js / Astro i Geneva

Geneva er Sveits’ nest største by, med 203 856 innbyggere i januar 2021, og hovedstad i republikken og kantonen Geneva. Byen huser hovedkontorene til mange FN-organer, Den internasjonale Røde Kors-komiteen (ICRC) og Den internasjonale føderasjonen av Røde Kors- og Røde Halvmåne-foreninger (IFRC). Det offisielle språket i både byen og kantonen er fransk. For et nettsted betyr det ofte en fransk hovedversjon og engelsk for et internasjonalt publikum, og det er nettopp språkstrukturen som oftest går i stykker når et gammelt CMS flyttes til Astro eller Next.js.

Jeg jobber alene, som utvikler, og tar migreringen fra kartlegging til overvåking etter lansering. Den generelle metoden står på siden om migrering til Next.js og Astro. Her er det som gjelder for et prosjekt med publikum i Geneva.

#Bør jeg flytte fra WordPress til Astro eller Next.js?

Ikke alltid. Migrering lønner seg når dagens CMS står i veien for ytelse, sikkerhet eller redaksjon, og ikke når færre plugins og bedre caching hadde holdt. Typiske tegn: TTFB over ett sekund, et adminpanel som er tregere enn fronten, ingen tester før release og redaktører som unngår å publisere når det haster.

Valget mellom de to rammeverkene følger av hva nettstedet gjør:

• Astro passer når nettstedet først og fremst er innhold: artikler, tjenestesider, rapporter og nyheter. Sidene bygges statisk, og JavaScript sendes bare der en komponent faktisk trenger det.
• Next.js passer når deler av nettstedet er en applikasjon: innlogging, medlemsområder, søk med filtre, skjemaer med flere steg eller innhold som må rendres på serveren per forespørsel.

Innholdet kan bli liggende i WordPress som headless CMS, eller flyttes til Markdown-filer eller et annet CMS. Det avgjør jeg sammen med deg etter hvem som redigerer og hvor ofte. Mer om den modellen står på siden om headless CMS-utvikling.

#Hva skjer teknisk under en migrering?

Arbeidet følger en fast rekkefølge, og hvert steg har en sjekk som kan etterprøves.

1. URL-inventar. Jeg henter alle adresser fra sitemap, crawl, Search Console og serverlogger, også de som bare finnes i gamle lenker og PDF-er. Resultatet er en tabell med gammel URL, ny URL og status.
2. Redirect-kart. Hver adresse som endres får en 301 til nærmeste innholdsmessige ekvivalent, ikke til forsiden. Kjeder (A til B til C) slås sammen til ett hopp. Kartet testes automatisk mot testmiljøet før lansering.
3. Innholdsmodell. Felttyper, taksonomier, forfattere, bilder med alt-tekst og interne lenker flyttes som data, ikke som limt HTML. Shortcodes og page builder-markup oversettes til komponenter, så innholdet ikke ser riktig ut bare på forsiden.
4. Metadata og strukturerte data. Titler, beskrivelser, canonical-tagger og JSON-LD sammenlignes side for side mellom gammelt og nytt nettsted. Et skript rapporterer avvik i stedet for at jeg stoler på stikkprøver.
5. Språkversjoner og hreflang. Hver språkversjon peker på de andre og på seg selv, og parene må være gjensidige. Jeg sjekker at en fransk side ikke får engelsk canonical, og at x-default peker dit du faktisk vil sende besøkende uten tydelig språk.
6. Trinnvis overgang. Den nye frontenden tar over én seksjon om gangen bak en reverse proxy eller edge-regler, mens resten kjører videre på det gamle systemet. Big bang bare på små nettsteder.
7. Kontroll etter lansering. I Search Console følger jeg dekningsrapporten, 404-feil, indekserte sider og klikk per seksjon, og retter feil før de blir et trafikkfall.

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

De fleste problemer etter en migrering er stille. Nettstedet ser riktig ut, men søkemotoren ser noe annet.

• Tapte URL-er. Gamle adresser uten redirect gir 404. Jeg crawler hele den gamle URL-listen mot det nye nettstedet før og etter lansering og krever 200 eller én 301.
• Brutt hreflang. En språkversjon som mangler, eller som peker til en redirect, gjør at feil språk vises i søk. Jeg validerer gjensidigheten i bygget HTML, ikke i malen.
• Noindex som ble med. Et testmiljø med noindex eller en blokkerende robots.txt som kopieres til produksjon er en klassiker. Det er det første jeg sjekker på lanseringsdagen.
• Skjemaer og sporing. Kontaktskjemaer, nyhetsbrev og analyse må testes med ekte innsendinger, ikke bare visuelt.
• Bilder og filer. PDF-er og bilder som andre nettsteder lenker til får egne redirects, ellers forsvinner eksterne lenker.

#Hvilke personvernregler gjelder for et nettsted i Geneva?

Sveits er ikke medlem av EU eller EØS og har sin egen personvernlov. Tilsynsmyndigheten er den føderale personvern- og informasjonskommissæren (FDPIC, på fransk PFPDT), en uavhengig myndighet som fører tilsyn med personvern og megler i saker om innsyn i offentlige dokumenter. FDPIC skriver at privat sektor og føderale myndigheter må tilpasse behandlingen av personopplysninger til den nye føderale personvernloven, og at loven gjelder direkte også for AI-støttet databehandling. Overføring av data til utlandet er et eget tema hos FDPIC.

For en migrering betyr det konkrete spørsmål: hvor hostes den nye frontenden og CMS-et, hvilke tredjepartstjenester (analyse, skjemaer, fonter, video) sender data ut av landet, og stemmer personvernerklæringen med det nettstedet faktisk gjør etter flyttingen. Jeg lager en liste over alle eksterne kall det nye nettstedet gjør, slik at du eller juristen din kan vurdere dem. Juridisk rådgivning gir jeg ikke.

#Hvordan håndteres fransk og engelsk i det nye nettstedet?

Siden fransk er offisielt språk i byen og kantonen, og kantonens egen nettside er på fransk, er fransk som regel hovedversjonen. Engelsk kommer ofte i tillegg. Før migreringen avklarer jeg:

• om språkene ligger i undermapper (/fr/, /en/) eller på egne domener, og om det skal endres (helst ikke samtidig med plattformbyttet),
• om slugs er oversatt, og om de gamle oversatte slugsene skal beholdes,
• hvordan redaktørene kobler en side til oversettelsene sine i det nye CMS-et, så hreflang ikke er avhengig av at noen husker det.

Å bytte plattform og URL-struktur samtidig gir to endringer som ikke kan skilles fra hverandre i Search Console. Jeg anbefaler én om gangen.

#Kan WordPress bli liggende som CMS?

Ja. WordPress kan levere innhold via REST API eller GraphQL mens Astro eller Next.js rendrer fronten. Redaktørene beholder grensesnittet de kjenner, og det offentlige nettstedet slipper PHP og plugins på hver forespørsel.

#Mister jeg rangeringer når jeg bytter plattform?

En viss uro i Search Console de første ukene er vanlig ved store URL-endringer. Risikoen ligger i manglende redirects, endret innhold og brutt hreflang, og det er nettopp det sjekkene over fanger opp før og etter lansering.

#Fungerer dette for Joomla og Drupal også?

Ja. Fremgangsmåten er den samme: URL-inventar, innholdsmodell, redirect-kart, metadata og trinnvis overgang. Forskjellen ligger i eksporten, fordi Joomla og Drupal lagrer felt, menyer og språkkoblinger på hver sin måte.

#Kan nettstedet hostes i Sveits?

Astro bygger statiske filer, og Next.js kan kjøre på egen Node-server, så begge kan hostes hos en leverandør du velger. Hvor dataene skal ligge er en beslutning for deg og juristen din. Jeg setter opp løsningen etter det.

#Neste steg

Send meg adressen til dagens nettsted, hvilket CMS det kjører på og hvor trafikken kommer fra (organisk søk, kampanjer, henvisninger). Da får du et skriftlig omfang med URL-antall, språkversjoner, valgt rammeverk og hva som må sjekkes ekstra i ditt tilfelle.

#Regelverk som styrer prosjektet i Geneva

I et migration-oppdrag dokumenterer vi hostingsted, hvem som administrerer WordPress, og hva som ligger utenfor scope.