Innhold i denne artikkelen
Jeg har mistet tellingen på hvor mange ganger jeg har blitt kontaktet av en ny kunde rett etter en migrering som gikk galt. Ny side, penere design — og trafikken er halvert. Migreringer er sjelden farlige fordi de er teknisk kompliserte. De er farlige fordi så mange gjennomfører dem uten å tenke på hva som kan gå tapt.
Hva er en nettstedmigrering?
En nettstedmigrering er prosessen med å flytte et nettsted fra én plattform til en annen. Fra WordPress til Webflow. Fra en egenutviklet løsning til Wix. Fra Shopify til WooCommerce.
Men det er sjelden bare å kopiere innhold over. En migrering innebærer nesten alltid endringer i URL-struktur, teknisk infrastruktur og designsystem, og hver av disse endringene kan påvirke hvordan Google indekserer og rangerer nettstedet ditt.
Gjort riktig kan du komme ut med et bedre teknisk fundament og styrket synlighet. Gjort feil kan du tape trafikk og rangeringer du har brukt måneder på å bygge opp, og det kan ta like lang tid å gjenopprette dem.
Når er en migrering aktuell?
Det er sjelden én enkelt grunn. Oftest er det en kombinasjon av faktorer som over tid gjør at nåværende plattform ikke lenger er riktig.
- Plattformen begrenser teknisk SEO, du kan ikke kontrollere URL-struktur, canonical-tagger eller robots.txt
- Plattformen er teknisk utdatert og vedlikeholdskostnadene overstiger verdien
- Nettstedet er for tregt for Core Web Vitals, og plattformen setter tak for hva som er mulig
- Forretningsmodellen har endret seg, for eksempel fra informasjonsside til nettbutikk
- Plattformen skalerer ikke med veksten i innhold eller trafikk
Dette ser jeg ofte gå galt, og det er derfor jeg får nye kunder
Mange av de nye kundene mine kommer til meg rett etter en migrering som ikke gikk som planlagt. Ny side, nytt design — og trafikken er borte. Nesten alltid kunne det vært unngått.
1. Noindex er aktivt etter lansering
Under utvikling settes staging som regel til noindex. Riktig. Problemet er når den nye siden lanseres, og ingen husker å slå det av. Resultatet: Google ser nettstedet, men indekserer ingenting. Trafikken forsvinner, og det kan ta dager før noen skjønner hva som har skjedd.
2. Staging er indekserbar
Den andre varianten: staging er ikke satt til noindex. Google crawler og indekserer den uferdige versjonen i ukene før lansering, og skaper duplikatinnhold og forvirring i indeksen som kan følge nettstedet lenge etterpå.
3. Ingen redirect-plan
Ny plattform betyr som regel ny URL-struktur. Og nye URL-er betyr at alle de gamle — som Google har indeksert og rangert — plutselig gir 404-feil.
Uten en redirect-plan fra gammel til ny URL mister du i praksis all opparbeidet SEO-verdi over natten. Lenkeautoritet, rangeringer og innkommende lenker fra andre nettsteder. Alt.
4. For mange endringer på én gang
Mange ser på en migrering som en mulighet til å rydde opp i alt: ny plattform, ny design, ny innholdsstruktur, nye søkeord, nytt domene. Forståelig, men det er en av de vanligste årsakene til at migreringer slår feil.
Migrer «as is». Flytt nettstedet slik det er i dag, med minst mulig endring. Når du gjør alt samtidig og noe går galt, vet du ikke hva som forårsaket det. Og det er mye vanskeligere å rette opp.
5. Mye innhold er fjernet — uten redirect-plan
I forbindelse med en redesign er det fristende å rydde opp: gamle bloggposter, utdaterte sider, produkter som ikke lenger selges. Det kan være riktig, men det krever en plan. Sider med innkommende lenker eller historisk trafikk bør alltid ha en 301-redirect til den mest relevante gjenstående siden.
6. Fokus på design — ikke trafikk eller konvertering
Den nye siden er vakker. Alle er fornøyde med hvordan den ser ut. Men ingen stilte spørsmålene: Hva skjer med konverteringsraten? Hva skjer med den organiske trafikken? Hva skjer med brukerreisene som faktisk fungerte? Design er viktig. Men en pen side som mister halvparten av trafikken er ikke en forbedring.
7. Den nye siden er pen — men teknisk tung
Animasjoner, store videoer, JavaScript-rendret innhold og tredjeparts-scripts. Siden ser imponerende ut, men laster sakte, feiler på Core Web Vitals og er vanskelig for Google å crawle. Teknisk ytelse bør være et krav i designfasen. Ikke en ettertanke.
8. Ingen på teamet tenkte på SEO
Migreringen ble planlagt og gjennomført av designere og utviklere. SEO var ikke en del av samtalen. Ingen sjekket rangeringer eller trafikktall underveis. En migrering uten SEO-perspektiv er som å flytte kontor uten å oppdatere adressen. Du er der — men ingen finner deg.
9. Ingen dokumentasjon før og etter
Ingen noterte Core Web Vitals, organisk trafikk eller rangeringer før migreringen. Etter lansering er det umulig å se om noe er bedre eller verre. Baseline-dokumentasjon er ikke valgfritt — det er det eneste grunnlaget du har for å vurdere om migreringen gikk bra.
10. Det nye systemet gjør uforutsigbare ting
En ny CMS-plattform oppfører seg ikke alltid som forventet. Et vanlig eksempel: systemet importerer innhold fra den gamle siden, men en tom slug-verdi i ett av innleggene fører til at det nye CMS-et genererer hundrevis av URL-er med tilfeldige mønstre. Plutselig har nettstedet hundrevis av nye URL-er som ingen har planlagt for, og som Google begynner å indeksere.
Nedlastbar sjekkliste
Dokumentasjon og planlegging er der migreringer vinnes eller tapes. Hele sjekklisten — før, under og etter lansering — finner du her, og du kan laste den ned som PDF og krysse av etter hvert.
Før migrering
- Dokumenter nåværende tilstand: Core Web Vitals, organisk trafikk, rangeringer og antall indekserte sider
- Lag en komplett URL-mapping: gammel URL → ny URL for alle sider
- Identifiser sider med historisk trafikk eller innkommende lenker. Disse krever prioritert redirect-behandling
- Bestem hvilke sider som eventuelt fjernes, og sett opp redirects til relevante alternativer
- Sørg for at staging er satt til noindex
- Test at staging ikke er tilgjengelig for Google (bruk URL-inspeksjon i GSC)
- Verifiser at alle sider du planlegger å beholde, faktisk finnes i den nye strukturen
- Test sidehastighet og Core Web Vitals på staging
- Verifiser at strukturerte data fungerer korrekt på staging
- Test det nye systemet for uventet URL-generering ved innholdsimport
- Ha en klar plan for hvem som gjør hva på lanseringsdagen
Ved lansering
Lanseringsdagen er ikke slutten — det er begynnelsen på overvåkingsfasen.
- Slå av noindex umiddelbart etter lansering, og verifiser at det er gjort
- Submit oppdatert sitemap.xml i Google Search Console
- Bruk URL-inspeksjon i GSC til å be om indeksering av de viktigste sidene
- Verifiser at alle 301-redirects fungerer korrekt
- Sjekk at robots.txt er korrekt og ikke blokkerer viktige sider
- Sjekk at canonical-tagger peker til riktige URL-er
- Monitor Search Console for nye crawl-feil og 404-varsler
- Sjekk at Google Analytics og GSC fortsatt mottar data
- Logg uventede URL-er som dukker opp i GSC
Etter migrering
De første ukene er kritiske. Rangeringer kan svinge. Det er normalt. Men systematisk overvåking lar deg reagere raskt hvis noe er galt.
- Sammenlign Core Web Vitals, antall indekserte sider og organisk trafikk mot baseline
- Sjekk Search Console ukentlig for nye 404-feil og indekseringsproblemer
- Verifiser at rangeringer for nøkkelsider stabiliserer seg innen 4–8 uker
- Sjekk at interne lenker peker direkte til nye URL-er (ikke gjennom redirects)
- Oppdater Google Business Profile og andre plattformer med nye URL-er
- Sjekk at innkommende lenker fra andre nettsteder fungerer korrekt gjennom redirects
- Vurder å be om re-crawling av viktige sider via URL-inspeksjon
Hva hvis noe går galt?
Selv med god planlegging kan ting skje. Et CMS oppfører seg uventet. En redirect ble ikke fanget opp. En viktig side er ikke indeksert.
Første steg er alltid det samme: åpne Google Search Console og finn ut nøyaktig hva som har skjedd. Se etter 404-feil, crawl-problemer og om noindex fortsatt er aktivt. Sammenlign antall indekserte sider med baseline. Det er forskjell på «Google har ikke rukket å reindeksere ennå» og «vi har et reelt problem», og GSC er der du ser hvilken av de to det er.
Forsinkelser er regelen — hold et kaldt hode
Nesten alle nettstedmigreringer tar lenger tid enn planlagt. Det er ikke et tegn på at noe er galt — det er et tegn på at dere tar det seriøst.
Ny teknologi oppfører seg uventet. Innholdsimport avslører problemer ingen hadde sett. Redirect-planen har hull. En viktig funksjon mangler på den nye plattformen.
Det er alltid bedre å lansere to uker for sent med stabil trafikk, enn å lansere on time med en teknisk katastrofe. Sett forventningene internt fra starten, og bygg inn buffer i tidsplanen.
Mitt siste råd
Involver en SEO-spesialist tidlig — ikke som en siste sjekk før lansering, men i planleggingsfasen. Det er der de viktigste valgene tas. Regn med forsinkelser. Prioriter stabilitet over punktlighet.
Og så dette, som jeg må si: ingenting trenger å bli perfekt. Noe kan ryddes opp i etter lansering. Noen interne lenker kan oppdateres over tid. Noe innhold kan forbedres gradvis.
Et nettsted er noe levende og voksende. Jeg møter mange som aldri migrerer fordi de er perfeksjonister — de venter på det perfekte øyeblikket der alt er på plass. Det øyeblikket kommer ikke. Planlegg godt, test grundig, bevar trafikken dere har, og lanser.
Her kan du lese mer
Vil du grave dypere i temaet? Disse er verdt tiden:
- Google Search Central — Site move with URL changes — Googles offisielle anbefalinger for plattformbytte med URL-endringer
- Google Search Console — der du faktisk ser om migreringen gikk bra eller ikke
- Screaming Frog SEO Spider — crawler for å verifisere redirect-plan og fange 404-feil tidlig
- web.dev — Core Web Vitals — målepunktene du må ha baseline på før og etter migrering
- Ahrefs — Website migration guide — grundig praktisk gjennomgang av prosessen
