Redesign eller ny nettside? Slik bytter du uten å miste SEO

OVERGANGSGUIDE

KILDEKONTROLLERT 07.10.2026

En ny nettside bør løse et konkret problem og ta vare på verdien som allerede finnes. Kartlegg innhold, URL-er og måling før dere endrer noe. Målet er redusert overgangsrisiko; rangeringer kan svinge når Google behandler endringene, og ingen prosess garanterer uendret trafikk eller SEO-resultater.

Skjerm med teksten Redesign og Ny nettside, håndskrevne SEO-notater og røde piler

( Redesign eller rebuild? )

Velg riktig inngrep før dere velger ny løsning.

Redesign kan være nok når publisering, integrasjoner og teknisk grunnmur fungerer, men uttrykk, innholdsstruktur eller brukerreise trenger forbedring. Beskriv problemet med konkrete sider og handlinger: finner kunden riktig tilbud, fungerer mobilen, og kommer henvendelsen frem? Alder eller et utdatert uttrykk er ikke alene grunn til å bytte hele plattformen.

Rebuild er mer aktuelt når plattformen hindrer nødvendige funksjoner, redaksjonelt arbeid eller stabil drift, eller når dagens struktur gjør endringer uforholdsmessig kostbare. Sammenlign hva som kan beholdes med hva som må bygges på nytt. Et nytt CMS eller en ny kodebase krever ikke automatisk nye offentlige URL-er. Ved rent hostingbytte må også DNS, kapasitet og tilgjengelighet testes.

Før noe endres

Lag ett grunnlag for hele overgangen.

Guiden støtter Tigons webdesign og webutvikling. Avklar også pris og scope for en ny nettside og valget mellom Next.js og WordPress når de spørsmålene inngår i prosjektet.

Eksisterende URL-er og landingssider

Samle URL-er fra crawl, CMS, sitemap, serverlogger og analyse. Ta med bilder og nedlastinger. Marker sider med organisk trafikk, eksterne lenker og viktige kundehandlinger. En side med få besøk kan likevel ha forretningsverdi; sletting krever en konkret vurdering.

Søk og handlinger før byttet

Lagre en datert baseline i Search Console for spørringer, landingssider, visninger, klikk, CTR og gjennomsnittlig posisjon. Sammenlign senere samme side, søk, land og enhet i relevante perioder. GA4 og virksomhetens egne data må vise hva besøket fører til: kontakt, kvalifisert henvendelse eller kjøp. Rangering alene er ikke et salgsresultat.

Tilganger, integrasjoner og eierskap

List domene, DNS, hosting, CMS, repo, GA4, Tag Manager, Search Console, consent-løsning, skjema og CRM. Navngi en ansvarlig for hvert ledd. Bevar eksisterende Search Console-verifisering; ved domenebytte må tilgang til både gammel og ny property avklares. Illustrasjonene på siden er eksisterende Tigon-konsepter, ikke dokumentasjon på en kundemigrering.

Konseptillustrasjon av en interiørdesign-nettside før og etter redesign, vist side om side

BEVAR VERDIEN. TEST ENDRINGENE.

Seks kontroller som reduserer overgangsrisikoen.

Bruk kontrollene som et overleveringsgrunnlag med ansvar, testbevis og åpne avvik. En sjekkliste er først nyttig når noen kan vise at hvert punkt er kontrollert.

1. URL-kart med tydelige valg
Gi hver gammel URL en beslutning: behold adressen, flytt innholdet til en konkret ny URL, slå det sammen med relevant innhold eller fjern det etter vurdering. Et praktisk kart har kolonnene gammel URL, handling, ny URL, forventet HTTP-status, begrunnelse, ansvarlig og testresultat. Bevar sterke landingssider når behovet fortsatt finnes.
2. Direkte 301/308 redirects
Ved permanent flytting: bruk serverbasert 301 eller 308 direkte til det relevante sluttmålet. Eksempel: /gammel-tjeneste → 308 → /ny-tjeneste → 200. Test hele kartet for feil mål, løkker og kjeder. Ikke send alle gamle sider til forsiden; innhold uten relevant erstatning kan svare 404 eller 410. Google anbefaler å beholde migreringsredirects i minst ett år; behold dem gjerne lenger for brukere og eksisterende lenker.
3. Canonical og internlenker
Kontroller at hver side som skal indekseres peker på riktig offentlig canonical. Canonical er et signal; Google kan velge en annen URL. Oppdater internlenker til sluttadressene, og samordne canonical, eventuelle hreflang-annotasjoner og sitemap. Finn rester av staging-domene, gamle stier og lenker som går via redirects.
4. Metadata, schema og sitemap
Sammenlign title, H1, beskrivelse og viktig innhold før og etter på de prioriterte landingssidene. Google kan lage sin egen title og snippet, så metadata gir ingen visningsgaranti. Valider relevant strukturert data mot synlig innhold og nye adresser. Det nye sitemappet skal peke på de foretrukne offentlige URL-ene; innsending hjelper oppdagelse, men garanterer ikke indeksering.
5. GA4, consent og skjema
Bevar riktig GA4-property og måle-ID når målehistorikken skal videreføres. Kartlegg hendelser, key events, Tag Manager og samtykkesignaler før byttet. Test med og uten analysesamtykke. Kontroller hendelser i DebugView når samtykke tillater det; fravær ved avvist consent er ikke alene en feil. form_submit er ikke bevis på en levert henvendelse: test validering, innsending, mottak i CRM/e-post og korrekt generate_lead uten dobbel telling.
6. QA med klare lanseringskriterier
Crawl den nye løsningen og test URL-kart, statuskoder, canonical, metadata, schema, sitemap og kritiske internlenker. Test også mobil, tastatur, ytelse, skjema, integrasjoner og tracking. Kontroller at staging-beskyttelse ikke følger med til produksjon: viktige offentlige sider skal ikke ha utilsiktet noindex eller crawlblokkering. Be om testbevis og en navngitt eier for feilretting før dere godkjenner lansering.

QA / lansering / oppfølging

Gjør overgangen kontrollert og etterprøvbar.

Avtal hvem som godkjenner, hvem som lanserer og hvem som følger opp. Sett av tid til feilretting etter at den nye nettsiden er tilgjengelig.

01
Lukk kritiske avvik før launch
Avtal stoppkriterier: feil redirectmål, feil canonical, utilgjengelige viktige sider eller et skjema som ikke leverer skal avklares før lansering. Ta backup, dokumenter gjeldende konfigurasjon og lag en praktisk plan for tilbakeføring. Tigons anbefaling er å teste planen og definere hvem som beslutter tilbakeføring; en plan på papir er ikke testbevis.
02
Lanser i et avtalt vindu
Velg gjerne en periode med lavere trafikk og tilgjengelig teknisk ansvarlig. Unngå å endre domene, plattform og hovedinnhold samtidig når endringene kan deles. Aktiver det ferdige URL-kartet og kontroller offentlig respons, redirects og måling straks etterpå. Send det nye sitemappet til Search Console. Change of Address er aktuelt ved støttet domene-/subdomeneflytting, ikke ved vanlig redesign på samme domene.
03
Følg feil, indeksering og faktiske handlinger
Se etter 404-, redirect- og serverfeil i crawl/logger. Følg Page indexing, sitemap og Crawl stats i Search Console. URL Inspection viser lagret indexstatus og Google-valgt canonical; en grønn Live Test beviser ikke indeksering. Bekreft fortsatt property-eierskap. Sammenlign søk, landingssider og posisjoner med baseline, og følg GA4-hendelser, leverte skjema, kvalifisering og salg separat. Skill feil fra sesong og endret samtykke. Avtal kontrollpunkter etter launch. Tigon anbefaler ukentlige kontrollpunkter videre til viktige URL-er og handlinger er stabile.

Alle ressurser

Vurder overgangsrisikoen før nettsiden byttes.

Ta med adressen til dagens nettside, målet med endringen og det dere vet om trafikk, innhold, skjema og integrasjoner. Tigon kan vurdere hva som bør beholdes, hva som må endres og hvilket migreringsarbeid som bør inngå i scope. Strategi, design, utvikling og måling må henge sammen for at den nye løsningen skal fungere for både kunder og virksomheten.

Velg riktig inngrep før dere velger ny løsning.

Vurder overgangsrisikoen før nettsiden byttes.

Redesign eller ny nettside? Slik bytter du uten å miste SEO