Innhold i denne artikkelen
En dårlig redirect ser du ikke. Du merker den bare når rangeringene har forsvunnet og trafikken har lekket. Det gode er at redirects er blant de tekniske SEO-grepene du har mest kontroll over, hvis du gjør dem riktig fra start.
Hva er en redirect?
En redirect er serverens måte å si «denne siden bor et annet sted nå». Når nettleseren eller Googlebot ber om en URL, svarer serveren med en 3xx-statuskode og en Location-header som peker til den nye adressen.
For brukeren skjer det stille — nettleseren følger med til den nye URL-en uten at du merker det. For Google er det en beskjed om hva som skal skje med indekseringen: skal den gamle URL-en byttes ut med den nye, eller er dette bare midlertidig?
Svaret på det spørsmålet ligger i selve statuskoden. Og det er der de fleste gjør feil.
301, 302, 307, 308 — hva er egentlig forskjellen?
Fire redirect-koder, to viktige distinksjoner. Første distinksjon: permanent eller midlertidig. Andre distinksjon: bevarer den HTTP-metoden (GET, POST) eller ikke.
Her er det viktige oppsummert:
| Kode | Type | Bevarer HTTP-metode | Bruk når |
|---|---|---|---|
| 301 | Permanent | Nei (i praksis ja for GET) | Siden har flyttet for godt — standardvalget for SEO |
| 302 | Midlertidig | Nei | Innhold er midlertidig et annet sted, du kommer tilbake til gammel URL |
| 307 | Midlertidig | Ja | Sjelden brukt — tekniske tilfeller der POST må bevares |
| 308 | Permanent | Ja | Moderne alternativ til 301, spesielt for API-er |
For 99 % av tilfellene er valget enkelt: bruk 301 for permanente flyttinger, 302 for midlertidige. Bruker du feil kode, gir du Google feil beskjed, og du risikerer at rangeringene ikke følger med.
Hvorfor redirect-kjeder er et problem
En redirect-kjede oppstår når URL A redirecter til B, som redirecter til C, som redirecter til D. Hvert hopp er teknisk sett en ny 301, men resultatet er alt annet enn nøytralt.
For hver ekstra 301 skjer tre ting: brukeren venter litt lenger, Google mister litt lenkekraft underveis, og risikoen øker for at Google gir opp å følge kjeden. Ifølge Googles egen dokumentasjon støtter de opptil fem redirect-hopp per crawl, men i praksis begynner de å nedprioritere kjeder lenge før det.
De vanligste årsakene til redirect-kjeder er:
- Migreringer stablet oppå tidligere migreringer uten opprydning
- HTTP → HTTPS-redirect kombinert med www → non-www-redirect kombinert med trailing slash-redirect
- Redirects fra gamle kategori-strukturer som aldri er blitt konsolidert
Løsningen er alltid den samme: kollaps kjeden. Hvis A → B → C → D, endre redirectene slik at A, B og C peker direkte til D. Ett hopp for alle, ferdig.
Hva er en redirect-plan?
En redirect-plan er dokumentet du lager før du bytter URL-struktur, migrerer plattform eller lanserer på nytt. Det er en én-til-én-mapping fra hver gamle URL med verdi til en ny URL, pluss statuskoden som skal brukes.
En god redirect-plan har fire kolonner: gammel URL, ny URL, statuskode og notat om hvorfor. Den lages i regneark, verifiseres mot en crawl av det nåværende nettstedet, og leveres til utvikleren før relaunch, ikke etter.
Det er også i migreringsfasen mange nettsteder mister trafikk, fordi noen URL-er glipper i mappingen og ender som 404-feil på relaunch-dagen.
Det finnes to måter å angripe en migrering på. Enten flytter du alt én-til-én for å ikke miste noe, eller så bruker du anledningen til å rydde i innholdet samtidig. Her er fremgangsmåten for begge.
As-is-migrering: flytt alt én-til-én
Denne tilnærmingen passer når du skal over på ny plattform eller ny struktur, men vil beholde alt innholdet som det er. Målet er at ingen URL gir 404. Jeg anbefaler denne fremgangsmåten som standard, fordi det gjør det lettere å tolke en eventuell trafikknedgang etter relaunch. Gjør du for mange endringer samtidig, blir det vanskelig å vite hva som faktisk gikk galt.
| Steg | Hva du gjør |
|---|---|
| 1 | Crawl det gamle nettstedet med Screaming Frog. Eksporter alle 200-URL-er. |
| 2 | Suppler med URL-er fra Google Search Console (Ytelse → Sider) og eventuelle URL-er fra XML-sitemaps, slik at ingenting glipper. |
| 3 | Slå sammen listene i regneark, fjern duplikater, og sorter alfabetisk eller etter mappestruktur. |
| 4 | Map hver gamle URL til én ny URL. Noter statuskode (nesten alltid 301). |
| 5 | QA: crawl et staging-miljø etter migrering og verifiser at hver gamle URL redirecter riktig, med kun ett hopp. |
| 6 | Etter relaunch: overvåk GSC daglig i fire uker for uventede 404-feil. |
Migrering med opprydding: analyser, prioriter og konsolider
Denne tilnærmingen passer når du vil bruke migreringen til å rydde opp. Da må du vite hva som har verdi, hva som kan slås sammen, og hva som kan fjernes.
| Steg | Hva du gjør |
|---|---|
| 1 | Crawl det gamle nettstedet og eksporter alle 200-URL-er. |
| 2 | Hent topp 500 URL-er fra GSC (Ytelse → Sider), de med visninger eller klikk. |
| 3 | Hent innkommende lenker via GSC (Lenker → Toppsider). Disse er ekstra viktige. |
| 4 | Slå sammen listene i regneark, fjern duplikater, og sorter etter trafikk/verdi. |
| 5 | Gjennomgå URL-ene: behold, konsolider eller fjern. Sider uten trafikk og uten backlinks kan gis 410 i stedet for 301. |
| 6 | Map gjenværende gamle URL-er til nye. Noter statuskode (301 eller 410). |
| 7 | QA etter migrering og overvåk GSC i fire uker. |
Dette ser jeg ofte gå galt med redirects
Etter mange redirect-planer og migreringer, gjentar de samme feilene seg:
- 302 der det skulle vært 301. Standard i mange CMS-er, koster deg rangeringer uten at du merker det med det samme.
- Redirect-kjeder som ingen har ryddet opp i. Særlig etter to eller flere migreringer stablet oppå hverandre.
- Alt redirectet til forsiden. Fungerer teknisk, men Google konsoliderer ikke lenkekraft. Bedre å la unødvendige URL-er gi 410 enn å redirecte dem til noe irrelevant.
- Ingen mapping av gamle URL-er med backlinks. Innkommende lenker er gull. Hvis den siden lenkene peker til gir 404, mister du hele verdien.
- Redirects fjernet for tidlig. Utviklere «rydder opp» og fjerner 301-er ett år etter migrering. Ikke gjør det. La dem stå.
- Client-side JavaScript-redirects i stedet for server-side 301. Google følger dem, men tregere og med tap. Bruk .htaccess, nginx-config eller CMS-ets redirect-modul.
Oppsummert: Min mening om redirects
Redirects er kanskje det enkleste kraftige verktøyet i teknisk SEO. Én linje i en konfigurasjonsfil kan bevare ti år med opparbeidet rangering, eller ødelegge den.
Min erfaring er at bedrifter som behandler redirects som et strategisk grep før relaunch, sjelden mister trafikk over migrering. De som legger det på til slutt, mister ofte 30–50 %, og noen kommer aldri tilbake til nivået fra før.
Det handler ikke om avansert teknikk. Det handler om å bruke en time på et regneark før du bruker seks måneder på å ta igjen tapt trafikk.
Her kan du lese mer om redirects
- Google Search Central — Redirects and Google Search — offisiell dokumentasjon om hvordan Google håndterer alle 3xx-koder
- MDN — HTTP redirections — teknisk gjennomgang av 301, 302, 307, 308 og forskjellene
- Ahrefs — Redirects for SEO — praktisk gjennomgang med eksempler
- Screaming Frog — Learn SEO: Redirects — praktisk gjennomgang av redirects og hvordan du finner kjeder i en crawl
- Moz — Redirection — grunnleggende om redirects i SEO-sammenheng
