Slik relanserer du nettsteder uten å tape SEO

Når du lanserer en ny nettside er det stor risiko for å miste hardt opparbeidet SEO. Nye plattformer, ny URL-struktur og nye domener eller underdomener gir mange steder noe kan gå galt — særlig rundt videresendinger, 404-er og Google Search Console.

Denne artikkelen er en praktisk gjennomgang av hva som typisk svikter ved relansering, og hva du bør gjøre før, under og etter for å holde organisk synlighet stabil.

I 2026 kan mye av det manuelle arbeidet også gjøres agentisk: AI-assistenter med tilgang til CMS via MCP (for eksempel Sanity MCP eller WordPress.com MCP) kan bygge videresendingskart, hente alle slugs og flagge døde lenker — mens du fortsatt godkjenner det som skal i produksjon. Mer om det lenger ned.

Hva som typisk skjer i ukene etter lansering

Googles crawler oppdaterer ikke indeksen sin øyeblikkelig. Etter en lansering vil Google gradvis lete gjennom nettstedet på nytt (“crawle”), oppdage endringer og rekalibrere rangeringer. Det er normalt å se et midlertidig dip i organisk synlighet de første ukene,det kalles gjerne en «Google dance».

Problemet oppstår når det midlertidige dipet ikke normaliserer seg. Da er det som regel tekniske årsaker: vidersendinger som ikke er på plass, 404-feil (lenker som ikke lenger fungerer), eller at Google Search Console ikke er konfigurert til å gi deg innsikten du trenger for å oppdage problemene i tide.

Tre årsaker til at organisk trafikk kollapser

1. Feil eller manglende videresendinger

301-videresendinger er det viktigste enkeltgrepet du gjør for å bevare SEO ved en URL-endring. En 301 signaliserer til Google at en side er permanent flyttet, og at rangeringssignalene (lenkeautoritet, relevans, historikk), bør overføres til den nye URL-en.

Uten 301-videresendinger starter den nye siden i praksis på null. Og det er sjelden én side det gjelder, ofte er det titalls eller hundrevis av URL-er som endres når man bytter plattform.

Vanlige feil:

• Videresendingskartet er ufullstendig: Man fokuserer på de 20 viktigste sidene og glemmer 200 andre som faktisk hadde trafikk
• Videresendinger er implementert som 302 i stedet for 301 (mer om dette under)
• Videresendingslenker (“Videresendingskjeder”): A => B => C i stedet for A => C direkte — hvert hopp svekker overføringen og bremser innlastingen
• Videresendinger er kun manuelt testet, ikke systematisk crawlet

2. 404-feil som ikke oppdages

En lenke fra et eksternt nettsted treffer en URL som ikke lenger finnes. En intern lenke i en bloggpost peker til en gammel slug. Et bilde er hardkodet med gammel URL. Alt dette genererer 404-feil.

Det er ikke nødvendigvis noe krise med en enkelt 404. Det er at uten aktiv logging eller crawler-overvåking akkumuleres 404-ene over uker uten at noen ser dem. Innen noen oppdager det, er noe av rangeringspotensialet allerede tapt.

3. Google Search Console konfigureres for sent

Google Search Console er det nærmeste du kommer direkte kommunikasjon med Googles crawler. Uten det har du ingen innsikt i hva som faktisk skjer etter lansering.

Et typisk scenario: Nettstedet lanserer 1. juni. Google Search Console settes opp tre uker ETTER. Da mister du de verdifulle første tre ukene der de fleste tekniske problemene oppstår og kunne vært fanget. Eventuelle feil som ble logget i den perioden er fortsatt synlige i Google Search Console, men du hadde ingen mulighet til å reagere i tide.

Videresendingsstrategi

301 vs. 302

En 301-videresending betyr at denne siden er permanent flyttet hit. Google tolker det som en instruksjon om å overføre rangeringssignaler til den nye URL-en.

En 302-videresending betyr at denne siden er midlertidig utilgjengelig her. Google beholder rangeringen på den opprinnelige URL-en og overfører ikke signalene.

Bruk alltid 301 ved permanente URL-endringer. Bruk 302 kun når du faktisk planlegger å gjenopprette den opprinnelige URL-en, for eksempel under kortvarig vedlikehold.

Slik bygger du videresendingskartet

Et videresendingskart er en enkel mapping: gammel URL => ny URL. Det kan lages i et regneark, men det er viktig å bygge det systematisk, ikke intuitivt.

1. Eksporter alle eksisterende URL-er fra dagens plattform. Google Search Console (Performance → Sider) gir deg URL-er med faktisk trafikk. En crawler som Sitebulb gir deg alle URL-er uavhengig av trafikk.
2. Prioriter etter Google Search Console-data: hvilke URL-er har faktisk fått klikk eller visninger siste 12 måneder? Disse har høyest SEO-verdi og bør komme først.
3. Map gammel => ny for alle URL-er som endres. Hvis en side ikke lenger eksisterer på nytt nettsted, vurder om innholdet kan slås sammen med en annen side og videresendes dit, eller om en 410 (Gone) er mer korrekt enn en 404.
4. Sjekk for videresendingskjeder og videresendingsløkker med et crawler-verktøy etter implementering.

Vanlige feil i implementeringen

• Videresendinger som virker på utviklingsserveren, men ikke i produksjon — regler i .htaccess, Nginx-konfig eller CDN som ikke er overført
• Case-sensitivity: /Om-Oss og /om-oss behandles ulikt av noen webservere
• Avsluttende skråstrek: /kontakt og /kontakt/ er to forskjellige URL-er — pass på konsistens
• Videresendinger som kun er satt for HTML-sider, ikke for bilder og andre filer som eksisterende backlinker kan peke mot

Google Search Console: sett det opp FØR lansering

Google Search Console-oppsett bør gjøres minst to uker før lansering.

Hva du bør ha på plass i god tid

• Domeneverifisering (via DNS) for nytt domene
• Sitemap.xml generert for ny struktur, klar til å sende inn til Google Search Console rett etter lansering.
• Hvis du bytter domene eller underdomene: bruk Google Search Console sin «Endre adresse»-funksjon (Change of Address). Den gjelder ikke for URL-endringer på samme domene (ny sti-struktur), da er 301-videresendinger og sitemap det som gjelder.

Hva du skal følge med på i ukene etterpå

I ukene etter lansering bør du sjekke Google Search Console minst annenhver dag. Se spesielt etter:

• Dekningsrapporten: nye 404-er, serverfeil, og sider ekskludert fra indeksen
• Indekseringsstatus: er de viktigste sidene faktisk indeksert?
• Klikk og visninger: sammenlign mot baseline — forvent et midlertidig fall, men sjekk at det stabiliserer seg
• URL-inspeksjon: bruk dette til å manuelt be om indeksering av kritiske sider, og til å verifisere at Google ser korrekt innhold

404-håndtering: det folk glemmer

Slik overvåker du 404-er i praksis

• Dekningsrapporten i Google Search Console viser 404-er Google har oppdaget. Sjekk minst ukentlig og ha en prosess for å håndtere dem fortløpende.
• CMS-logging: Mange CMS’er har oversikter over hvilke 404-sider som har blitt truffet. Dette er vanligvis den raskeste måten å finne videresendinger du har oversett, for eksempel til en artikkel som har mye trafikk fra søkemotorer eller eksterne sider.
• Crawler-kjøring: kjør Sitebulb eller tilsvarende på live nettsted etter lansering for å finne interne broken links som ikke nødvendigvis fanges i Google Search Console med det første.
• Backlink-audit: sjekk hvilke backlinker som peker til 404-er via Google Search Console (Lenker → Eksterne lenker) eller et eksternt verktøy. Backlinker som treffer 404-sider bidrar ikke til rangeringer.

Gjør det agentisk: MCP og AI-assistenter

Mye av arbeidet over er repetitivt: eksportere URL-er, matche gammel slug mot ny, sjekke at videresendinger svarer 301, og fange døde interne lenker. Det er arbeid AI-agenter kan gjøre godt — forutsatt at de har trygg tilgang til CMS-et og at et menneske fortsatt godkjenner endringer i produksjon.

Model Context Protocol (MCP) lar en assistent snakke direkte med verktøyene du allerede bruker, i stedet for at du kopierer CSV-er frem og tilbake.

Eksempler i praksis

Sanity MCP: Be agenten liste alle publiserte dokumenter med slug (sider, bloggposter, cases). Sammenlign mot det gamle URL-kartet, foreslå videresendinger der slugs har endret seg, og flagg dokumenter som mangler. Agenten kan også opprette utkast — men publisering og produksjonsendringer bør kreve eksplisitt godkjenning.

WordPress.com MCP: På WordPress.com-nettsteder kan agenten hente innlegg og sider, sjekke permalenkestruktur, og hjelpe med å oppdatere interne lenker etter en relansering. Samme prinsipp: les gjerne bredt, skriv kun når du har sagt ja.

Crawl og verifikasjon: Kombiner CMS-eksporten med Sitebulb (eller tilsvarende) og en agent som systematisk sjekker statuskoder for gamle URL-er (curl -I / HTTP 301 mot forventet mål). Da oppdager du videresendingskjeder og 404-er før Google gjør det.

Hva agenten ikke skal gjøre alene

Agenter er sterke på kartlegging og utkast. De er svake — eller farlige — når de får frie tøyler i produksjon. Hold disse reglene:

• Ingen publisering eller masseoppdatering i live CMS uten at du har godkjent endringen.
• Ingen «Endre adresse» eller andre irreversible Google Search Console-steg uten menneskelig vurdering.
• Bruk gjerne utviklingsdataset eller utviklingsserver når agenten skal eksperimentere med innhold.

Brukt riktig blir agenten en kraftig medarbeider på videresendingskart og QA — ikke en erstatning for SEO-ansvaret rundt lanseringen.

Sjekkliste: lansering uten organisk kollaps

Minst to uker før lansering

• Eksporter alle eksisterende URL-er (crawler + Google Search Console Performance)
• Bygg videresendingskart for alle URL-er som endres
• Verifiser ny Google Search Console-eiendom og begge domenevarianter
• Generer og validér ny sitemap.xml
• Konfigurer 404-logging og varsling
• Eksporter Google Search Console-baseline (klikk, visninger, posisjoner per side)

Dagen før lansering

• Test videresendingskart på utviklingsserveren, bruk crawler, ikke bare manuell sjekk
• Kontroller at det ikke finnes videresendingskjeder (maks ett hopp)
• Bekreft at robots.txt er riktig konfigurert og ikke blokkerer crawling
• Sjekk at sitemap.xml peker til korrekte, ikke-videresendte URL-er

Uke 1 etter lansering

• Send inn ny sitemap.xml i Google Search Console
• Bruk URL-inspeksjon til å be om indeksering av de viktigste sidene
• Sjekk Dekningsrapport daglig
• Kjør crawler på live nettsted og kryss mot videresendingskartet

Uke 2–4 etter lansering

• Monitorer klikk og visninger i Google Search Console mot baseline
• Kjør backlink-audit — sjekk at viktige backlinker ikke treffer 404
• Håndter nye 404-er fortløpende etter hvert som de dukker opp

Det er sjelden én stor feil — det er mange små

Det vi typisk ser etter en lansering uten god SEO-forberedelse er ikke ett dramatisk fall. Det er gradvis erosjon over seks til åtte uker: noen URL-er mister rangeringer de aldri gjenvinner, noen backlinker slutter å bidra, noen sider indekseres aldri riktig fordi crawl-budsjettet brukes feil.

Det gode er at det aller meste er forebyggbart. Et solid videresendingskart, Google Search Console konfigurert tidlig, og aktiv overvåking i den kritiske perioden er som regel nok til å holde organisk synlighet stabil gjennom en lansering.