Migrering til Next.js / Astro i Hamburg

Bedrifter i Hamburg flytter fra WordPress, Joomla, Drupal eller eldre rammeverk til Astro eller Next.js når hastighet, vedlikehold eller angrepsflate ikke lenger står i forhold til det nettstedet gir. Jeg gjør jobben alene, fra første URL-liste til siste kontroll i Search Console. Under står hva som faktisk skjer, og hva som er spesielt med markedet i Hamburg.

#Hva innebærer en migrering til Astro eller Next.js?

Du bytter ut systemet som genererer sidene, men beholder det søkemotorer og kunder kjenner: adresser, tekster, bilder, metadata og strukturerte data. Fem arbeidsdeler går igjen:

1. Inventar over alle URL-er som får trafikk eller lenker, fra sitemap, Search Console, serverlogger og en crawl.
2. Innholdsmodell: hvilke felter eksisterende innhold har, og hvordan de blir til filer eller et headless API.
3. Redirectkart og meta-paritet på et testmiljø.
4. Cutover, enten samlet eller seksjon for seksjon.
5. Kontroll etter lansering i Search Console og i serverlogger.

#Hvordan kartlegger jeg URL-er og 301-redirects?

Jeg starter med å hente alle adresser fra tre kilder og slå dem sammen: sitemap, Search Console (sider med visninger) og en crawl av det gamle nettstedet. Hver adresse får én av tre avgjørelser: beholdes uendret, flyttes med 301 til en ny adresse, eller fjernes med 410 når siden ikke har noen erstatning. Avgjørelsen skrives ned i en tabell som du kan lese og godkjenne før noe går live.

Reglene jeg holder meg til: ingen redirect-kjeder, ingen redirect til forsiden som erstatning for en konkret side, og trailing slash behandles likt i hele nettstedet. På Cloudflare Pages ligger redirects i en _redirects-fil, som har en øvre grense på antall regler. Har det gamle nettstedet tusenvis av adresser, flytter jeg mønstre over i edge-regler i stedet for én linje per URL.

#Hvordan flytter jeg innholdet uten å miste struktur?

Fra WordPress eksporterer jeg innlegg, sider, kategorier, forfattere og egendefinerte felt via REST API eller WP-CLI og gjør dem om til Markdown eller MDX med frontmatter. Fra Drupal og Joomla gjør jeg det samme fra databasen. Bilder flyttes med alt-tekst og får nye, stabile filnavn. Shortcodes og sidebyggere er det vanskeligste: de blir enten til komponenter eller til vanlig HTML, og jeg viser hvilke sider som er berørt før jeg begynner.

Valget mellom filbasert innhold og et headless CMS tar jeg ut fra hvem som skal redigere. Redaktører som publiserer daglig trenger et grensesnitt. Et nettsted som endres noen ganger i kvartalet klarer seg med filer i et repo.

#Astro eller Next.js, hva passer?

Astro passer når nettstedet i hovedsak er innhold: bedriftsside, blogg, dokumentasjon, tjenestesider. Sidene leveres som ferdig HTML uten JavaScript til alt som ikke trenger det. Next.js passer når det finnes innlogging, personlige sider, handlekurv eller data som endres hele tiden. En nettbutikk på WooCommerce kan flyttes gradvis, og det beskriver jeg på siden om headless-migrasjon av WooCommerce. Den generelle fremgangsmåten står på siden om migrering til Astro og Next.js.

#Hvordan beholder jeg strukturerte data, canonical og hreflang?

Canonical, title, meta description og JSON-LD følger innholdet side for side. Jeg sammenligner gammel og ny side maskinelt: samme title, samme canonical-logikk, samme schema-typer, samme antall interne lenker. Avvik får jeg som liste, ikke som magefølelse.

For nettsteder med flere språk må hreflang være gjensidig: hvis den tyske siden peker på den norske, må den norske peke tilbake, og hver side peker også på seg selv. Språkkoden settes på riktig nivå, for eksempel de-DE for tysk innhold rettet mot Tyskland og nb for norsk. Mangler ett ledd, ignorerer Google hele paret.

#Hva er spesielt for bedrifter i Hamburg?

Hamburg er ifølge Wikipedia Tysklands nest største by med 1 973 896 innbyggere per 31. desember 2024, og en av tre tyske bystater sammen med Berlin og Bremen. Havnen i Hamburg er Tysklands største og Europas tredje største, bak Rotterdam og Antwerpen. Wikipedia nevner også media (NDR, Gruner + Jahr, Der Spiegel, Die Zeit) og industribedrifter som Airbus og Lufthansa Technik blant de store aktørene i byen.

For et nettsted betyr det tre ting. Kundene leser standard tysk. Lavtysk (Hamborger Platt) er det opprinnelige språket i Hamburg, men jeg bygger ikke egne sider på det, så hreflang og innhold planlegges for tysk og eventuelt engelsk og norsk. Bedrifter innen media og handel kan ha mange eldre undersider, arkiver og vedlegg, og da blir URL-inventaret den største enkeltposten i en migrering.

Personvernforordningen (GDPR) er EU-rett og gjelder i Norge gjennom EØS-avtalen, så de samme grunnreglene følger med uansett om besøkende kommer fra Hamburg eller Oslo. Praktisk betyr det at analyse, skrifttyper og innebygde tjenester må sjekkes ved flyttingen: hva som lastes fra tredjeparter, hva som settes før samtykke, og hvor hostingen ligger. Jeg lister det som lastes på hver sidemal og lar deg avgjøre hva som beholdes. Tilsynsmyndighet for personvern i Hamburg er Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit (HmbBfDI), som har egne temaer for internett og handel. Jeg gir ingen juridisk vurdering, det hører hjemme hos en jurist.

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

• Glemte URL-er. Sider som bare lenkes fra eksterne nettsteder står ikke i sitemap. Jeg sammenligner crawl, Search Console og serverlogger før cutover.
• Redirect-kjeder og løkker. Jeg crawler hele redirectkartet og krever én hop til en side som svarer 200.
• Noindex fra testmiljøet. Det vanligste lanseringsfeilen. Jeg leser den ferdige HTML-en på produksjon, ikke bare konfigurasjonen.
• Tapt intern lenking. Menyer og relaterte lenker teller antall innkommende lenker per side før og etter.
• Ytelse som blir dårligere. Jeg måler Core Web Vitals på en reell sidemal før og etter, med samme verktøy.
• Skjemaer og sporing. Kontaktskjema, e-postvarsler og målinger testes manuelt på produksjon rett etter bytte.

Etter lansering følger jeg Search Console på sidenivå i de første ukene: dekning, sider som faller ut, og 404-er som Google fortsatt prøver å hente. Ukjente 404-er får en ny redirect eller en bevisst 410.

#Hvordan kommer vi i gang?

Send meg adressen til dagens nettsted, hvilket CMS det kjører på og hvor trafikken kommer fra. 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.

#Å arve en installasjon i Hamburg

Hamburg Digital Hub & MediaCity gir partnerkontekst; tema- og plugin-endringer lander i kundens Git.

Vi bygger sikre og høyytelses WordPress-løsninger for virksomheter i Hamburg, tilpasset lokale markedsbehov. Profil: Medier og maritim logistikk. Ramme: DSGVO og BSI-praksis for driftsansvarlige.