En site migration er det nærmeste SEO kommer på åben hjertekirurgi.

Alt det du har bygget op over måneder eller år — rangeringer, indekserede URL’er, backlinks, crawl-mønstre — er midlertidigt udsat. Og som med kirurgi er det ikke indgrebet i sig selv der er det farligste. Det er de fejl der opstår fordi nogen sprang et trin over.

Jeg har set migrationer der gik galt på den simpleste måde: ingen redirects fra gammel URL-struktur. Fem år med SEO-arbejde slettet over en weekend. Og jeg har set store platformsskift — nyt CMS, nyt domæne, ny URL-struktur på én gang — der gik problemfrit fordi hvert trin var planlagt og hvert trin blev verificeret.

Forskellen er ikke held. Det er protokol.

Denne guide dækker alle SEO-discipliner der berøres af en site migration. Ikke som en tjekliste du printer ud og aldrig bruger, men som en forståelsesramme for hvad der faktisk sker — og hvad der kan gå galt.

Hvad er en site migration?

En site migration er enhver ændring der fundamentalt påvirker, hvordan søgemaskiner crawler og indekserer dit site.

Det inkluderer:

• Domæneflytning: gammelt-domæne.dk → nyt-domæne.dk
• Protokolskift: http → https (stadig en fejlkilde i 2026)
• URL-restrukturering: /produkter/kategori/slug → /kategori/slug
• CMS-skift: WordPress → Astro, Drupal → Shopify
• Subdomæne til roddomæne: blog.eksempel.dk → eksempel.dk/blog/
• Kombinationer af ovenstående (det farligste scenarie)

Alle disse typer har ét til fælles: Google skal lære noget nyt. Den hurtigst mulige migration er én der giver Google præcis de signaler den skal bruge til at opdatere sin forståelse — med minimal tab af autoritet undervejs.

Fase 1: Pre-migration — det arbejde ingen hopper over (men burde)

Migrationer fejler typisk ikke under selve implementeringen. De fejler fordi forberedelsen var ufuldstændig.

Crawl det eksisterende site.

Inden du rører noget som helst, crawl hele det eksisterende site med Screaming Frog eller Ahrefs Site Audit. Gem output’et. Det er din baseline — en komplet inventarliste over alle URL’er du er ansvarlig for.

Hvad du specifikt noterer:

• Alle indexable URL’er (ikke blot dem i sitemap)
• HTTP-statuskoder — inkl. eksisterende 301s og 404s der ikke er adresseret
• Title tags og H1s — de skal mappes til nye URL’er
• Interne links og deres ankertekster
• Canonical tags og eventuelle konflikter

Backlink-audit.

Export alle backlinks fra Ahrefs Site Explorer for det eksisterende domæne. Filtrer for referring domains og sorter efter DR. De top 50–100 links er de vigtigste at bevare — og potentielt kontakte direkte efter migration for at opdatere til nye URL’er.

Dette trin springes over 90% af gange. Og det er præcis det trin der afgør om link equity overføres eller fordamper.

Baseline rank tracking.

Opsæt position tracking for de 50–100 vigtigste søgeord inden migration. Du har brug for en pre-migration baseline at sammenligne mod i ugerne efter. Uden den ved du ikke om trafik-fald skyldes migrationen eller en algoritmeændring der ramte samtidig. Se rank tracking for opsætning.

URL-mapping.

Lav en komplet mapping fra gammel URL til ny URL — én-til-én, i et regneark. Denne mapping driver alt det tekniske arbejde bagefter. Den bør inkludere: gammel URL, ny URL, HTTP-status (hvad der eksisterer nu), og redirect-type (301 til ny).

Sider der ikke har en tilsvarende ny URL mappes til den nærmeste relevante overordnede kategori — aldrig til forsiden. En 301 til forsiden sender et svagt signal til Google om hvad der erstattet hvad.

Fase 2: DNS og hosting — propagation og timing

Hvis migrationen inkluderer domæneflytning eller hostingskift, er DNS-timing kritisk. Se også DNS ved hostingflytning for en mere detaljeret gennemgang.

DNS TTL (Time To Live) bestemmer hvor hurtigt DNS-ændringer propagerer. Standardværdien er typisk 3.600 sekunder (1 time) til 86.400 sekunder (24 timer). Inden migration: sænk TTL til 300 sekunder (5 minutter) — det giver dig mulighed for hurtigt at rulle back hvis noget går galt, og det reducerer ventetiden når du aktivt skifter.

Praktisk sekvens:

1. Sæt TTL ned til 300s — mindst 48 timer inden migration
2. Opsæt ny hosting, verificer at sitet fungerer på ny IP inden DNS-skift
3. Skift DNS A/CNAME records
4. Verificer fra eksterne lokationer (ikke blot din egen browser med cache)
5. Hold gammel server kørende i minimum 72 timer efter DNS-skift

DNS-propagation er ikke binær. Forskellige DNS-resolvere verden over opdaterer på forskellige tidspunkter. Det er normalt at noget trafik stadig rammer gammel server 12–24 timer efter skift. Sørg for at gammel server redirecter korrekt i overgangsperioden.

Fase 3: Redirects — fundamentet der ikke må vakle

301-redirects er mekanismen der overfører link equity fra gammel til ny URL. En 301 signalerer til Google: denne side er permanent flyttet, overfør al autoritet til den nye adresse.

Vigtige redirect-regler:

Ét hop, ikke kæder. Redirect-kæder (A → B → C) er ineffektive. Google følger dem, men hvert hop medfører tab af PageRank og øger crawl-tid. Verificer at ingen gammel redirect peger på en URL der selv redirecter.

Ingen loops. A → B → A. Det sker oftere end man tror ved CMS-migrationer. Screaming Frog opdager dem.

Dæk alle varianter. http og https, www og non-www. En 301 der dækker https://www.gammelt-domæne.dk men ikke http://gammelt-domæne.dk er en halvfærdig implementation.

Redirect sitemap og robots.txt. Det lyder mærkeligt, men Googlebot forsøger at fetche disse fra gammelt domæne. En 301 fra /sitemap.xml til den nye sikrer at botten finder vej.

Hvad der sker uden redirects: Google behandler nye URL’er som nye sider uden autoritet. Al link equity fra backlinks til gamle URL’er fordamper. Rangeringer forsvinder. Det kan tage måneder at genopbygge — og det er fuldstændig undgåeligt.

Fase 4: Teknisk SEO — det CMS’et ikke klarer automatisk

Canonical tags.

Efter migration skal canonical tags pege korrekt. Sider der er tilgængelige via multiple URL’er (f.eks. med og uden trailing slash, med og uden www) skal have canonical der peger på den ene foretrukne version. Verificer at ingen canonical tags stadig peger på gamle URL’er.

Robots.txt.

Det klassiske migrationsfejlscenarie: ny staging-server har Disallow: / i robots.txt, og det følger med til produktion. Verificer robots.txt på ny server inden DNS-skift — og igen umiddelbart efter.

XML sitemap.

Generer ny sitemap med udelukkende nye URL’er. Ingen gamle URL’er, ingen non-canonical URL’er, ingen 301-redirects i sitemap. Sitemap er Googles vejviser — fyld den med det du faktisk vil indekseret.

Hreflang (ved internationale migrationer).

Hreflang-tags skal opdateres til nye URL’er. Forkerte hreflang-implementeringer er en af de mest tilbagevendende fejlkilder ved internationale migrationer og kan føre til rangering på forkerte markeder.

Struktureret data.

Structured data der inkluderer absolutte URL’er skal opdateres til nye URLs. Det gælder BreadcrumbList, WebPage, Article og Organisation-markup specielt.

Fase 5: On-page — bevar det der virker

En typisk fejl ved migrationer: at bruge den som lejlighed til at forbedre alt på én gang. Skift ikke URL-struktur, title tags, H1s og indhold simultant med CMS-skift. Du kan ikke separere årsagerne til rangerings-bevægelser efterfølgende.

Det du bør bevare præcis som det er:

• Title tags og meta descriptions
• H1s og overskriftsstruktur
• Primært indhold (body copy)
• Intern linking og ankertekster

Det du bør migrere omhyggeligt:

• URL-slugs: bevar originale slugs hvor muligt. Ændring af /ordbog/seo-grundlaeggende/ til /seo-ordbog/ er en meningsfuld URL-ændring der kræver redirect — og den er undgåelig.

Hvis URL-restrukturering er formålet med migrationen, gør det isoleret — ikke kombineret med domæne- eller CMS-skift.

Fase 6: Search Console — signaler til Google

Search Console er den direkte kanal til Google. Under en migration er det kritisk.

Tilføj og verificer ny property.

Tilføj nyt domæne som property inden migration. Verificer ejerskab via DNS-record (den mest stabile metode) eller HTML-fil. Du behøver begge properties aktive — gammel og ny — i overgangsperioden.

Brug “Change of Address”-værktøjet.

Hvis du skifter domæne, send “Change of Address”-anmodning fra gammel property til ny i Search Console. Det er Googles officielle mekanisme til at accelerere overførslen af signaler fra gammelt til nyt domæne. Kræver at 301-redirects allerede er på plads.

Indsend ny sitemap.

Indsend sitemap.xml til ny property umiddelbart efter migration. Monitor Coverage-rapporten dagligt i de første to uger.

Verificer crawl-fejl omgående.

GSC rapporterer 404-fejl typisk inden for 24–48 timer efter Google begynder at crawle ny server. En spike i 404s er normalt i de første dage — det er gamle URL’er Google ikke er kommet til at opdatere endnu. Men vedvarende 404s for vigtige sider indikerer manglende redirects der skal adresseres.

Fase 7: Post-migration monitoring

De første fire uger efter en migration er den kritiske observation-periode. Du skal kunne skelne normale overgangssignaler fra reelle problemer.

Hvad der er normalt:

• 10–15% trafik-fald i de første 1–2 uger (Google reindekserer)
• Udsving i rankings for prioriterede søgeord
• Spike i GSC crawl-fejl de første dage
• Forsinkelse i indeksering af nye URL’er (Google er metodisk, ikke hurtig)

Hvad der er et problem:

• Vedvarende 20%+ trafik-fald efter 4 uger uden tegn på bedring
• Vigtige sider forsvinder fra indeks og vender ikke tilbage
• 404-fejl for sider der burde redirecte (manglende eller forkerte redirects)
• Canonical-konflikter i GSC

Den daglige monitoring-rutine (uge 1–4):

• GSC → Coverage → fejl: nye 404s, server-fejl, crawl-anomalier
• GSC → Performance: trafik-trend, CTR, impressions
• Rank tracker: bevægelse på de 50 baseline-søgeord
• Ahrefs: indeks-status for top 20 URL’er

Fra uge 5 kan du reducere til ugentlig check — medmindre der er aktive problemer.

De hyppigste migrationsfejl

Ingen redirects er den mest alvorlige fejl. Alle URL’er der eksisterer i backlinks, bookmarks og eksisterende indeksering skal redirecte.

Redirects fra staging er en variant jeg ser for ofte: staging-URL’er der er indekseret (fordi robots.txt var åben på staging) og ikke redirecter korrekt. Crawl staging-miljøet inden launch og blokér det med robots.txt.

Manglende baseline. Uden pre-migration rank tracking og trafik-baseline kan du ikke validere om migrationen lykkedes. Du kan ikke styre det du ikke måler.

“Vi tager det efterfølgende” om redirects. Redirects laves inden launch — ikke som oprydningsopgave ugen efter.

Ændre for meget på én gang. Nyt domæne + ny URL-struktur + nyt CMS + ny indholdsarkitektur i ét projekt. Isolér ændringer. Gør domæneflytning alene, CMS-skift alene, URL-restrukturering alene — hvis muligt.

Glemme mobilversionen. Sites med separat mobil-URL (m.domæne.dk) kræver mobil-specifikke redirects og hreflang-opdateringer.

Migration som investering, ikke risiko

Det paradoksale ved site migrationer er at de fleste af de risici der beskrives her er fuldt forebyggelige. En migration er ikke et lotteri — det er et ingeniørprojekt. Hver enkelt risikofaktor har en løsning, og løsningerne er velkendte.

Det der adskiller en vellykket migration fra en katastrofe er ikke teknisk snilde. Det er disciplin. Planlæg hvert trin. Verificer hvert trin. Monitor bagefter.

Det meste af det SEO-arbejde der ødelægges i fejlslagne migrationer tog måneder at bygge. Det tager typisk 3–6 måneder at genopbygge det — og det er i bedste fald. I den tid mister du trafik, kunder og den organiske vækst der ellers var på vej.

En ordentlig migration er ikke gratis — men den er markant billigere end konsekvenserne af en dårlig én.

---

Har du en migration på vej? De vigtigste trin at starte med er: komplet crawl af eksisterende site, backlink-export fra Ahrefs, og URL-mapping inden du rører noget som helst andet.