Et redesign eller et CMS-skifte kan føles som en frisk start. For SEO er det ofte det stik modsatte: en øvelse i kontinuitet, hvor Google helst skal opleve, at alt det vigtige stadig findes, stadig giver mening og stadig hænger sammen.
SEO-migrering handler ikke om at “gøre noget ekstra for Google”. Det handler om at undgå at miste det, du allerede har betalt for i tid, indhold, links, data og brand-søgninger.
Hvad SEO-migrering dækker (og hvad den ikke dækker)
En SEO-migrering er den disciplin, der sikrer, at synlighed, crawlbarhed og rankings overlever et stort websiteskift. Det kan være:
- nyt design på samme CMS
- flyt til nyt CMS
- ændring i URL-struktur
- flyt til nyt domæne
- sammenlægning af sites, sprog eller sektioner
Det er fristende at tænke, at “Google finder nok ud af det”. Google finder ud af meget, ja, men de finder ikke automatisk ud af, hvad der erstatter en side, du har flyttet, slettet eller delt op i fem.
Planen starter med et før-billede, ikke en to-do-liste
Du kan ikke styre et migrationsprojekt på mavefornemmelse. Første skridt er at gøre din nuværende performance målbar og konkret, så du kan se, om noget går galt, og hvor.
En stærk baseline består typisk af crawl-data, Search Console-data, analytics-data og en prioritering af de sider, der betyder mest for omsætning, leads eller efterspørgsel.
[markdown] | Fase | Formål | Typiske leverancer | Det, der oftest går galt | | --- | --- | --- | --- | | Baseline & inventar | Dokumentere “før” og finde dine vigtigste SEO-aktiver | Crawl-export, top-URL-liste, top-queries, backlink-oversigt | Man måler kun trafik og overser indexering, skabeloner og interne links | | Mapping | Sikre én klar destination pr. gammel URL | Redirect-map, beslutning om sletning/merge, ny IA | “Næsten rigtigt” redirects og for mange sider, der ender på forsiden | | Staging QA | Fange fejl før launch | Crawl af staging, skabelon-check, robots/noindex-check, CWV-scan | Staging er blokeret på den forkerte måde, og samme opsætning ryger i produktion | | Launch | Skifte kontrolleret og verificere alt kritisk | Redirects live, sitemap, tracking, GSC-setup | Redirect-kæder, 404-storme, manglende tracking eller canonical-kaos | | Post-launch stabilisering | Hurtige rettelser og ro i signalerne | Fejlretning, intern link-oprydning, monitorering, 30/60/90-dages review | Man lukker projektet for tidligt og opdager problemer, når trafikken allerede er faldet | [/markdown]SEO.DK ser man ofte, at teams overvurderer værdien af et flot launch og undervurderer værdien af et præcist før-billede. Baseline er din forsikring, fordi den gør tab synligt, før det bliver dyrt.
URL’er: Bevar, flyt eller fjern (men beslut det bevidst)
URL’er er ikke bare adresser. De er identiteter i Googles indeks, de har historik, links og relevans knyttet til sig. Derfor er URL-strategien et af de steder, hvor migreringer vindes eller tabes.
Det første spørgsmål er banalt, men afgørende: Kan de vigtigste URL’er bevares 1:1? Hvis svaret er ja, har du elimineret en stor del af risikoen. Hvis svaret er nej, skal du være kompromisløst præcis.
Efter en kort prioritering af dine vigtigste landingssider giver det mening at opstille redirect-regler, der kan testes maskinelt.
- Én gammel URL, én ny URL: 301 til den mest relevante, indholdsmæssigt tætte destination
- Slettet indhold: 410 eller 404 med vilje, ikke tilfældigt
- Undgå kæder: gammel URL skal lande på en 200-side i ét hop
- Ingen “alt til forsiden”: det udvander relevans og ødelægger brugerens forventning
Når du mapper, så tænk i intention. Hvis en gammel side ranker på et købssignal, så er “nærmeste kategori” ofte et ringe match. Det rigtige match er den side, der løser samme behov i den nye struktur.
Redirect-map som styringsværktøj (ikke bare en teknisk liste)
Et godt redirect-map er også et beslutningsdokument: Hvad bevarer vi? Hvad konsoliderer vi? Hvad udfaser vi?
Hvis du bruger anledningen til at rydde op i tyndt eller overlappende indhold, kan det være sundt. Men oprydning under migrering kræver disciplin, fordi du ellers mister long-tail trafik uden at opdage det.
Staging-miljø: her fanger du de fejl, du ikke kan “kommunikere” bagefter
Det nye site skal kunne crawles og forstås, før det får lov at gå live. Staging QA er et teknisk kvalitetscheck, men det er også et indholdscheck: Er de samme signaler til stede, eller har skabelonerne ændret semantik?
Det er især her, klassikeren opstår: En skabelon sætter noindex eller en robots-regel, som var tænkt til staging, og den ender i produktion. Et andet typisk problem er, at metadata-felter fra det gamle CMS ikke findes i det nye, så titles bliver generiske eller ens på tværs af sider.
Efter du har crawlet staging og sammenlignet med baseline, giver det mening at køre et fast “kritisk tjek” på dine vigtigste skabeloner og URL’er.
- Statuskoder (200, 301, 404)
- Canonical-tags
- H1 og overskriftshierarki
- Titles og meta descriptions
- Schema/structured data
- Intern linkbarhed (orphan pages)
- Core Web Vitals på nøglesider
En enkelt manglende canonical kan skabe dubletter. En enkelt ændring i heading-struktur kan flytte, hvad siden opfattes som relevant for. Visuelt kan alt se rigtigt ud, mens SEO-signalerne er blevet svagere.
JavaScript og rendering: et stille risikopunkt ved nye frontends
Mange redesigns ender med mere JavaScript, flere komponenter og flere afhængigheder. Det er ikke farligt i sig selv, men det øger risikoen for, at indhold eller interne links ikke er tilgængelige som HTML ved crawl.
Hvis du skifter til headless eller et nyt framework, så planlæg en konkret rendering-test: Kan en crawler og Google se det, du kan se?
Launch-dagen: lav et kontrolleret skifte med klare stopklodser
En stabil launch handler om to ting: at de tekniske signaler er rigtige fra minut ét, og at du kan måle, hvad der sker.
Gå live på et tidspunkt med lav belastning, og fastfrys ændringer i dagene op til. Mange problemer opstår, når der stadig merges features og indhold samtidig med redirect-regler og tracking.
Det vigtige er ikke, at alt er perfekt. Det vigtige er, at de uoprettelige fejl ikke sker: at vigtige sider bliver utilgængelige, at redirects mangler, eller at indexeringen blokeres.
De første uger efter launch: monitorering, der giver handlekraft
De første 14 til 30 dage er en periode, hvor Google genbesøger, om alt hænger sammen. Små udsving er normale. Store udsving uden en tydelig forklaring skal behandles som et signalproblem, ikke som “markedet”.
Search Console bør være dit cockpit. Kig især efter:
- stigning i 404/soft 404
- “Duplicate, Google chose different canonical”
- fald i impressions på dine vigtigste queries
- sider, der pludselig ekskluderes fra indekset
Supplér med crawl af både gamle URL’er (for at validere redirects) og nye URL’er (for at finde interne fejl). Hvis du har adgang til serverlogs, får du et ekstra lag: Ser du Googlebot ramme 301 og hurtigt finde 200, eller spilder den tid på kæder og fejl?
Efter en kort første stabilisering giver det også mening at arbejde målrettet med intern linkkraft. Mange sites mister rankings efter migrering, fordi navigation og interne links blev “forenklet” i designprocessen. Det føles bedre, men det kan gøre vigtige sider mindre centrale.
CMS-skifte: kravspecen er din bedste ven
Et CMS-skifte er ofte grunden til, at migreringen overhovedet sker. Det er også her, mange mister kontrol, fordi platformen låser ting, man før tog for givet.
Når du vurderer et CMS, bør du tænke i SEO-funktioner som en del af produktkravene, ikke som plugins man “kan finde senere”. Det handler om kontrol over URL’er, metadata, indekseringssignaler og performance.
Efter du har beskrevet dit nuværende behov, kan du teste platformen imod en enkel tjekliste.
- URL-kontrol: kan du styre slugs, trailing slash, små bogstaver og hierarki?
- Metadata i skala: titles, descriptions, open graph og redigerbare felter pr. sidetype
- Indexering: robots.txt, noindex pr. skabelon, canonical og håndtering af parametre
- Sitemaps: automatisk generering, segmentering og opdatering ved nyt indhold
- Performance: caching, billedhåndtering, kodeopsætning og mulighed for at holde CWV i ro
- Structured data: mulighed for JSON-LD i templates uden at det bliver et specialprojekt hver gang
Et CMS kan være stærkt på redaktør-oplevelse og stadig være svagt på SEO-kontrol. Det er ikke et problem, hvis du ved det på forhånd og planlægger løsningerne.
Samarbejdet: SEO-migrering lykkes, når ansvar er tydeligt
Migreringer fejler sjældent på grund af én stor beslutning. De fejler på grund af 20 små ting, der ikke havde en ejer: hvem godkender redirect-map, hvem tester staging, hvem opdaterer interne links, hvem holder øje med Search Console hver morgen den første uge?
Når roller og checks er en del af projektplanen, bliver SEO ikke en brandalarm. Det bliver en stabil leverance på linje med design, udvikling og indhold.
Der ligger også en oplagt mulighed i en migrering: Når fundamentet er bevaret, kan du bruge det nye site til at publicere hurtigere, bygge topic clusters mere struktureret og få mere ud af de data, du allerede har. Det kræver bare, at flytningen bliver behandlet som et præcisionsarbejde og ikke som en kosmetisk opdatering.
