SEO & migration
Hvis I søger efter ny hjemmeside SEO eller relancering SEO, er I typisk tæt på en redesign-, CMS- eller platformskift. Det er det rigtige tidspunkt at beskytte det, I allerede har tjent i søgning — og det forkerte tidspunkt at behandle redirects som en eftertanke.
Vi har set flot designede relaunches miste måneder af synlighed, fordi URL-struktur skiftede uden mapping, fordi canonicals pegede forkert i en uge, eller fordi staging blev crawlet. Denne guide er den checkliste vi bruger, når målet er en ny site — uden at smide placeringer væk.
TL;DR
De vigtigste pointer
- SEO-tab ved relancering skyldes næsten altid URL-brud, tynd indholdsparitet eller crawl-fejl — ikke "Google kan ikke lide det nye design".
- Byg en 1:1 redirect-map før cutover, og bevar vigtige stier hvor det er muligt.
- Hver side der ranker skal have en tydelig efterfølger med samme intent — ikke en generisk forsides-redirect.
- Noindex staging, lås preprod, og verificér canonicals før DNS-skift.
- Planlæg en overvågningsperiode efter launch: Search Console, sitemap, 404-log og ranking-stikprøver.
- Stack-skift (WordPress til Next.js m.m.) er muligt uden tab — hvis migrationen behandles som et SEO-projekt.
Hvorfor relaunches mister placeringer
Google følger links og redirects. Den følger ikke jeres intention. Når en URL forsvinder uden 301 til en ækvivalent side, mister den side sin akkumulering af signaler. Når 50 sider redirectes til forsiden, fortæller I Google, at indholdet er væk — ikke flyttet.
Designteams optimerer for visuelle sektioner. SEO kræver URL-stabilitet, intern linking og indholdsparitet. De to mål er ikke i konflikt, men de konkurrerer om tid i projektet. Hvis SEO først kommer ind i UAT, er skaden ofte allerede bygget ind i informationsarkitekturen.
Et andet klassisk fejlmønster er "vi rydder op i URL'erne samtidig". At skifte CMS, design og URL-struktur på samme dag er tre migrationer. I kan gøre det — men så skal mapping, QA og rollback være tilsvarende disciplineret.
Det positive: de fleste tab er undgåelige. De kræver kedeligt arbejde før launch, ikke magiske SEO-tricks bagefter.
URL-strategi før I rører designet
Start med et udtræk af de URL'er der faktisk betyder noget: Search Console (sider med impressions), analytics (organiske landingssider), og en crawl af det nuværende site. Sortér efter værdi — ikke efter hvad der ser pænt ud i en sitemap.
For hver vigtig URL beslutter I: behold stien, redirect 1:1 til en ny sti, eller konsolidér bevidst ind i en stærkere side. Konsolidering er legitimt, når I merger tyndt indhold. Det er ødelæggende, når I merger urelaterede intents.
Bevar stier hvor det er muligt. Et nyt design behøver ikke nye slugs. Hvis `/ydelser/webudvikling` stadig beskriver samme service, så lad den leve. Ændr kun URL'er, når informationsarkitekturen reelt ændrer sig.
Sprog og locale-prefixes kræver ekstra disciplin. Hvis I skifter fra `/da/insights/...` til `/da/indsigter/...`, er det en masseredirect — planlæg den eksplicit, og hold den permanent.
Cutover-planen der beskytter SEO
En praktisk rækkefølge I kan følge, uanset om I skifter tema, CMS eller hele stacken.
- 01
Byg redirect-mappen tidligt
Excel eller et script er fint. Kolonner: gammel URL, ny URL, statuskode, ejer, notat. Ingen cutover uden at de vigtigste rækker er grønne.
- 02
Match indholdsparitet
For hver vigtig side: er H1-intent den samme? Er de afgørende afsnit med? Er FAQ og interne links bevaret eller forbedret? Tyndere sider efter relaunch er en stille ranking-dræber.
- 03
Lås staging for crawl
Noindex, auth eller IP-allowlist. Sørg for at canonicals på staging ikke pege på produktion med forkert indhold — og omvendt.
- 04
Test redirects i preprod
Crawl det gamle URL-sæt mod det nye miljø. Tæl 404, redirect-kæder og utilsigtede 302'er. Ret kæder til direkte 301'er.
- 05
Cutover med sitemap og Search Console
Skift DNS/deploy, indsend opdateret sitemap, verificér at nye URL'er svarer 200, og overvåg dækning og 404 de første uger.
Tekniske signaler der skal være korrekte på dag ét
Canonicals skal pege på den foretrukne live URL — ikke på staging, ikke på en gammel sti, ikke på en parameter-variant. Hreflang (hvis I er flersprogede) skal spejle de faktiske locale-par efter relaunch.
Structured data skal stadig være gyldig. Hvis I havde FAQPage eller Article-markup, så verificér at den nye stack emitter den korrekt. En redesign der "glemmer" JSON-LD er usynlig for mennesker og synlig for rich results.
Performance hjælper, men den redder ikke brudte URL'er. Et hurtigere site med 404 på jeres bedste landingsider er stadig et SEO-tab. Få redirects og paritet på plads først; optimér Core Web Vitals i samme sprint, ikke som erstatning.
robots.txt og sitemap.xml skal opdateres i samme release. En sitemap der lister gamle stier, eller en robots der utilsigtet disallow'er vigtige sektioner, er klassiske cutover-fejl.
Intern linking er det signal mange glemmer i redesignet. Hvis den nye navigation skjuler sider, der tidligere var to klik fra forsiden, falder crawl-dybden — også når URL'erne er bevaret. Gennemgå de vigtigste landingsider og sørg for, at de stadig har tydelige indgange fra hub-sider og relateret indhold.
Kontrolleret relaunch vs. håbefuld go-live
Kontrolleret
SEO er en workstream med ejer og acceptkriterier.
- Redirect-map færdig før design-freeze
- Vigtige URL'er bevaret eller 1:1-mappet
- Staging ikke indeksérbar
- Crawl-test af gamle URL'er i preprod
- Post-launch overvågning i Search Console
Håbefuld
SEO "tager vi efter launch".
- Nye slugs fordi det ser pænere ud
- Mange 301'er til forsiden
- Staging åben for crawl i uger
- Redirects skrevet i panik på launch-dagen
- Ingen ved, hvilke sider der bar trafikken
“En relaunch uden redirect-map er ikke et redesign. Det er en planlagt 404-kampagne med bedre typografi.”
Særligt ved WordPress til Next.js (og lignende skift)
Stack-skift skræmmer ofte SEO-ansvarlige mere end et tema-skift — men mekanikken er den samme. Google crawler HTTP-svar, ikke jeres framework. Hvis URL'er, indhold og interne links bevares, kan I skifte fra WordPress til Next.js uden at starte forfra.
Det der ændrer sig, er ansvaret: redirects ligger i applikationen eller edge-laget, metadata bygges i kode, og preview-miljøer skal holdes ude af indekset. Det er en fordel, når det er disciplineret — og en risiko, når redirects er hardcodet i panik.
Planlæg indholdsparitet eksplicit: blocks i et headless CMS skal spejle de gamle siders intent, ikke kun deres look. En case-side der mister sine afsnit og FAQ, er en ny side i Googles øjne — også hvis slug'en er den samme.
Hvis I alligevel ændrer informationsarkitektur, så splittes projektet: først URL-stabil relaunch, derefter bevidste konsolideringer. To klare trin slår én kaotisk big bang.
Behold URL — eller skift bevidst?
Brug rækkerne til at undgå "vi retter URL'er mens vi er i gang".
Behold eller 1:1-redirect når…
Siden ranker eller får impressions i dag
Skift URL-struktur når…
I har en dokumenteret mapping og accept af midlertidig uro
Behold eller 1:1-redirect når…
Intent og indhold er det samme efter relaunch
Skift URL-struktur når…
Informationsarkitekturen reelt ændrer sig (nye sektioner, nye products)
Behold eller 1:1-redirect når…
I kan bevare stien uden teknisk smerte
Skift URL-struktur når…
Gamle stier er inkonsistente og blokerer en klar model fremad
Behold eller 1:1-redirect når…
I er midt i et design-/CMS-skift i forvejen
Skift URL-struktur når…
I har kapacitet til en separat SEO-migration med egen QA
Launch-tjekliste for SEO
Hvis punkterne ikke er grønne, er I ikke klar — uanset hvor færdigt designet ser ud.
- Top-URL'er fra Search Console er mapped 1:1 eller bevidst konsolideret
- Ingen kritiske sider 301'er til forsiden
- Staging/preprod er noindex eller afskærmet
- Canonicals, hreflang og sitemap peger på de nye live URL'er
- Crawl af gamle URL'er viser 200 eller korrekte 301'er — ikke kæder og 404
- Der er en ejer på 404-log og Search Console de første uger efter launch
Spørgsmål vi får igen og igen
Hvor lang tid tager det, før placeringer stabiliserer sig efter en relaunch?
Det varierer med crawl-frekvens og hvor store URL-ændringerne er. Med rene 301'er og indholdsparitet ser vi typisk, at det meste genfindes over uger — ikke timer. Hvis I har brudt mappingen, kan "stabilisering" i praksis være et nyt baseline-tab.
Er 302 midlertidige redirects okay under cutover?
Nej som sluttilstand. Brug 301 (eller 308) til permanente flytninger. 302'er kan være midlertidige i en teknisk nødplan, men de skal ikke blive hængende — Google er mere forsigtig med at overføre signaler via midlertidige redirects.
Kan vi skifte design uden at røre URL'er?
Ja — og det er ofte det sikreste. Et nyt UI på samme stier er den laveste SEO-risiko. Gem slug-oprydning til et separat, planlagt trin.
Hvad med backlinks til gamle URL'er?
De er præcis derfor, redirects skal være permanente og korrekte. En god 301 bevarer værdien fra eksterne links. En 404 eller en forsides-redirect spilder dem.
Skal vi fjerne gammelt indhold, vi ikke vil genudgive?
Gerne — men gør det bevidst. 404/410 på irrelevant indhold er fint. Hvis indholdet havde trafik eller backlinks, så konsolidér til den nærmeste relevante side med 301, eller behold en opdateret version.
Hvis I planlægger en relaunch
Lad os sikre, at SEO overlever cutover.
En kort gennemgang af jeres URL-kort og cutover-plan er ofte nok til at spotte de fejl, der koster placeringer.