Migrering til Next.js / Astro i München

Du driver en bedrift i München og nettstedet ligger i WordPress, Joomla, Drupal eller et eldre rammeverk. Denne siden forklarer hvordan jeg flytter det til Astro eller Next.js uten å miste synligheten du har bygget, og hva som gjelder spesielt i det tyske markedet.

#Hva er spesielt med München som marked?

München er hovedstaden i Bayern. Wikipedia oppgir 1 604 384 innbyggere per 30. november 2024 og nevner høyteknologi, bilindustri, tjenestesektor, IT, bioteknologi, ingeniørfag og elektronikk som sentrale næringer. BMW, Siemens, Allianz og Munich Re har hovedkontor i byen.

For nettstedet betyr det tre ting. Kundene og samarbeidspartnerne leser tysk. Mange kjøpere vurderer leverandører etter dokumentasjon og sikkerhet før de vurderer design. Og nettstedet ditt konkurrerer ofte mot tyske aktører som har jobbet med tysk innhold i årevis. Jeg skriver ikke tysk innhold for deg her, men jeg sørger for at strukturen tåler flere språk.

#Når lønner migrering seg?

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. Typiske tegn er TTFB over ett sekund, en admin som er tregere enn fronten, ingen tester før release og redaktører som unngår å publisere i høysesongen.

Jeg måler først. Før jeg foreslår noe, kjører jeg Core Web Vitals på de ti viktigste malene og noterer tallene, slik at du kan sammenligne etterpå. Er løsningen en håndfull plugins som kan fjernes, sier jeg det, og du sparer migreringen.

#Astro eller Next.js?

Astro passer når nettstedet i hovedsak er innhold: tjenestesider, blogg, dokumentasjon, kataloger. Det sender lite JavaScript og bygger statiske sider. Next.js passer når nettstedet har innlogging, personalisering eller mye interaksjon som må rendres på serveren. Jeg velger etter det nettstedet faktisk gjør, ikke etter hva som er på moten. Mer om Astro-arbeidet mitt står på Astro-utvikler, og den generelle migreringsmetoden står på migrering til Astro og Next.js.

#Hvordan flytter jeg et nettsted trinn for trinn?

1. Inventar. Jeg henter alle indekserbare URL-er fra sitemap, crawl og Search Console, og legger til sider som har eksterne lenker. Resultatet er et regneark med gammel adresse, ny adresse og status.
2. Innholdsmodell. Jeg kartlegger innholdstyper, felt og relasjoner. Fra WordPress betyr det innlegg, sider, egendefinerte innleggstyper og ACF-felt. Fra Drupal og Joomla betyr det noder eller artikler med kategorier.
3. URL-kart og 301. Hver gammel adresse får en nøyaktig mål-URL. Jeg bruker 301 der adressen endres, og holder kjeder på ett ledd.
4. Strukturerte data og metadata. Titler, beskrivelser, canonical og JSON-LD flyttes over og sammenlignes mellom gammelt og nytt nettsted.
5. Hreflang. Hver språkversjon peker på sine søsken og på seg selv. Jeg tester at lenkene er gjensidige.
6. Testmiljø. Jeg kjører det nye nettstedet bak innlogging og crawler det, og så sammenligner jeg antall sider, statuskoder og titler mot inventaret.
7. Cutover. På store nettsteder flytter jeg seksjon for seksjon. På små kan en samlet overgang være det enkleste.
8. Etterkontroll. Jeg følger Search Console for dekning, 404-feil og indekseringsfall, og sammenligner Core Web Vitals med målingene fra før.

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

• Glemte adresser. Gamle PDF-er, bildeadresser og parametriserte URL-er mangler i kartet. Jeg henter dem fra serverlogger og lenkeoversikt, ikke bare fra sitemap.
• Redirect-kjeder og løkker. Jeg crawler 301-ene på testmiljøet og feiler bygget hvis en kjede er lengre enn ett ledd.
• Tapt metadata. Jeg sammenligner title, description og canonical side for side mellom gammelt og nytt nettsted.
• Skjemaer som slutter å virke. Kontaktskjemaer og påmeldinger testes ende til ende før cutover, inkludert samtykketekst og kvittering.
• Feil språk til feil leser. Manglende eller ensidig hreflang gjør at søkemotoren velger selv. Jeg sjekker gjensidighet.
• Analyse og samtykke. Skript som setter informasjonskapsler flyttes ikke blindt. Jeg går gjennom hva som lastes og hva som krever samtykke.

#Hva sier tysk regelverk om nettsteder?

Dette er forhold ved markedet, ikke juridisk rådgivning.

Personvern. I Bayern fører Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) tilsyn med private virksomheter. Etaten har egen sjekkliste for soloselvstendige og små og mellomstore handelsbedrifter. Teknisk betyr det at jeg kan sette opp hosting i EU, minimere eksterne skript og dokumentere hvilke tredjepartstjenester nettstedet laster.

Tilgjengelighet. Barrierefreiheitsstärkungsgesetz (BFSG) gjelder etter § 1 blant annet tjenester i elektronisk handel som ytes overfor forbrukere etter 28. juni 2025. Etter § 3 tredje ledd gjelder plikten ikke for mikrobedrifter som yter tjenester. Bygger du en nettbutikk eller bestillingsløsning for tyske forbrukere, bør du avklare med en tysk jurist om du er omfattet. Jeg bygger frontenden slik at kravene lar seg oppfylle: semantiske overskrifter, tastaturnavigasjon, skjemaetiketter og kontrast.

Jeg svarer ikke på rettsspørsmål. Jeg leverer en løsning som lar deg svare ja når en jurist spør.

#Hva får du i hendene etter migreringen?

Repo, miljøvariabler, deploy-pipeline og en kort runbook blir hos deg. Du eier koden og kan flytte hosting. Oppfølgingen etter lansering dekker kritiske rettinger og en ytelsesgjennomgang etter den første trafikktoppen, avtalt skriftlig på forhånd. Jeg jobber alene, så du har én kontaktperson gjennom hele prosessen.

#Neste steg

Send meg dagens adresse, hvilket CMS du bruker og hvor trafikken kommer fra (organisk søk, annonser, direkte, henvisninger). Du får et skriftlig omfang med antall URL-er, risikopunkter, anbefalt rammeverk og hva som er utenfor omfanget. Prisen blir individuell og settes etter omfanget.

#WordPress-miljø og lokale signaler i München

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

Vi bygger sikre og høyytelses WordPress-løsninger for virksomheter i München, tilpasset lokale markedsbehov. I Automotive og bedriftsprogramvare-segmentet handler spørsmålene ofte om WordPress, WooCommerce, Astro, Next.js mot legacy.