Et CMS-skifte føles ofte som et rent design- og driftprojekt. Du får et hurtigere backend, pænere skabeloner og måske færre plugins. Men hvis du allerede henter kunder via Google Analytics, Google Search Console og en crawl (fx Screaming Frog eller Sitebulb). Men hvis du allerede henter kunder via Google, er et CMS-skifte også en SEO-migrering, uanset om du kalder det det eller ej. Og her kan små “trivielle” fejl koste dig dyrt i synlighed, leads og omsætning.
Du kan til gengæld gøre migreringen tryg og kontrolleret, hvis du behandler den som et risikoprojekt med klare målepunkter, faste tjek og et skarpt launch-vindue. Det er præcis den disciplin, der skiller en pæn relancering fra en relancering, der også performer.
Hvad der faktisk går i stykker, når du skifter CMS
Når du skifter CMS, ændrer du næsten altid mere end du tror: URL-struktur, templates, navigation, interne links, rendering, hastighed og tekniske standardvalg. Google “ser” resultatet, ikke forklaringen.
Typiske tab opstår i tre spor:
- Din side bliver sværere at crawle eller indeksere (robots, noindex, JavaScript, manglende sitemap).
- Dine stærkeste signaler flytter sig (URL’er, interne links, canonicals, struktureret data).
- Din relevans bliver udvandet (titler, beskrivelser, headings, duplikater, tyndere indhold).
Det er sjældent én stor fejl. Det er summen af små ting, der vælter kurven.
Start med en baseline, før du rører noget
Hvis du ikke kan måle “før”, kan du ikke styre “efter”. Baseline er din sikkerhedsline, når du skal afgøre, om et udsving er normalt, kritisk eller bare en forsinkelse i Googles genindlæsning.
Du bør som minimum sikre dig et eksport-sæt, der kan sammenlignes direkte med det nye site efter launch. Det kan du hente via Google Analytics, Google Search Console og en crawl (fx Screaming Frog eller Sitebulb).
Efter en kort gennemgang af dit nuværende site kan du samle følgende, uden at gøre projektet tungt:
- Topindgangssider
- Topforespørgsler i Search Console
- Statuskoder (2xx, 3xx, 4xx, 5xx)
- Sidetitel pr. URL: nuværende titel og længde
- Meta description pr. URL: nuværende beskrivelse og CTR-indikation
- Intern linkstruktur: sider med flest interne links og vigtigste hub-sider
- Indexerbarhed: hvilke URL’er er noindex, canonicaliseret eller blokeret
- Backlinks til dine vigtigste URL’er
Når du har baselinen, kan du prioritere: Hvilke 20 til 200 sider må ikke falde? Det er dem, du designer migreringen omkring.
Risikoafdækning: tænk i “hvad kan gå galt” pr. komponent
En god migreringsplan matcher risiko til kontrolpunkt. Det lyder tørt, men det gør beslutningerne lette, når tidsplanen strammer til.
Her er en enkel måde at organisere arbejdet på, som mange teams bruger i praksis:
[markdown] | Fase | Det du kontrollerer | Hvad du skal kunne sige “ja” til | | --- | --- | --- | | Før migrering | URL-inventar, metadata, indeksstatus, performance, tracking | “Vi ved hvad der virker i dag, og hvad der ikke må gå tabt.” | | Staging | Skabeloner, rendering, crawlbarhed, canonical/hreflang, intern linkstruktur | “Det nye site kan crawles og ligner SEO-mæssigt det gamle.” | | Go-live | Redirects, robots/noindex, sitemap, tracking, kritiske fejl | “Alt det uoprettelige er på plads før DNS og trafik.” | | Efter launch | 404/500, redirect-kæder, indeksdækning, rankings, CWV | “Google finder, forstår og prioriterer de rigtige sider.” | [/markdown]Hvis du driver en SMB, er dette også måden at undgå, at SEO bliver en mavefornemmelse. Hos et specialiseret bureau som SEO.dk vil du typisk se netop denne opdeling, fordi den gør resultater målbare og hurtige at korrigere.
URL-mapping og 301-redirects: din vigtigste forsikring
Det største enkeltstående tab ved CMS-skifte kommer stadig fra URL’er, der ændrer sig uden præcise 301-redirects. Ikke “næsten rigtigt”. Præcist.
Din opgave er at lave et URL-map, hvor hver gammel URL får en destination, der matcher intentionen:
- Samme indhold, ny adresse: 301 til ny side.
- Udgået indhold, stadig behov: 301 til nærmeste relevante alternativ.
- Udgået indhold, ingen behov: 410 eller 404, men kun hvis du bevidst accepterer tabet.
Du skal også undgå to klassikere: redirect-kæder og redirect-loops. Begge dele spilder crawlbudget, forsinker signaloverførsel og kan give et vedvarende fald.
Et praktisk krav, der holder dig skarp: Hvis du tager din fulde liste af gamle URL’er og “crawlersimulerer” dem, skal du lande på en 200-side i ét hop, og den endelige side skal være den rigtige.
Metadata, skabeloner og indhold: det du ikke ser i designet
Når teams tester et staging-site, kigger de ofte på layoutet. Google kigger på HTML, struktur og konsistens. Et CMS-skifte kan nemt overskrive de elementer, der gav dig gode placeringer.
Det gælder især:
- Title-tags og meta descriptions
- H1 og overskriftslogik
- Brødkrummer og intern linkning
- Canonical-tags
- Struktureret data (schema)
- Billeders alt-tekster og filstier
Hvis du ændrer templates, så sørg for at “SEO-felterne” ikke bare findes, men også kan styres i skala. Det er her CMS-valget betyder noget. Nogle platforme giver dig fuld teknisk kontrol. Andre låser URL-mønstre og skaber uønskede varianter, som du bagefter skal rydde op i med canonicals og noindex.
Du får mest ro i maven ved at teste på URL-niveau: Tag dine vigtigste landingssider, og sammenlign gammel vs. ny HTML-output side for side. Du leder efter forskelle, ikke skønhed.
Crawlbarhed og indeksering: den stille dræber
Du kan have perfekte redirects og flotte tekster og stadig miste alt, hvis Google ikke må eller kan indeksere dit nye site.
De farligste fejl er ofte simple:
- robots.txt blokerer for meget (eller alt)
- staging-flag “discourage indexing” følger med i produktion
- sider får noindex ved en fejl
- sitemap mangler, er forældet eller indeholder redirects
- navigation bygges på en måde, hvor vigtige links ikke findes i HTML uden scripts
Når du tester staging, skal du typisk blokere indeksering. Men du skal også have en helt klar plan for, hvordan blokeringen fjernes ved launch, og hvordan du beviser, at den er væk. Ellers risikerer du at gå live med et site, der ser korrekt ud for mennesker og er usynligt for Google.
Hastighed og mobil: du må ikke bytte platform for langsommere oplevelse
Et nyt CMS er ikke automatisk hurtigere. Nogle gange får du flere scripts, tungere tema, dårligere billedhåndtering eller et tracking-setup, der rammer performance hårdt.
Det du vil opnå, er enkelt: Det nye site skal mindst matche det gamle på de vigtigste sidetyper (forside, kategori, produkt/ydelse, artikel, kontakt). Gerne bedre.
Test både mobil og desktop og kig især efter:
- LCP (største element), typisk hero-billede eller overskrift
- INP (interaktionsforsinkelse), ofte påvirket af scripts
- CLS (layout-hop), ofte påvirket af fonts og billeder
Hvis du allerede arbejder content-baseret, er performance også et content-signal: hurtige sider bliver læst, scrollet og linket til oftere. Det giver dig et bedre afsæt for vækst.
Din Go/No-Go før launch: en kort checkliste du kan bruge i mødelokalet
Når alt føles “næsten klar”, har du brug for en fast liste, der gør beslutningen objektiv. Du vil undgå at lancere på håb.
Efter du har gennemgået staging og lavet dine sidste tests, kan du bruge denne Go/No-Go som minimum:
- Redirects: gammel URL-liste lander på korrekte 200-sider uden kæder
- Robots: ingen utilsigtet blokering, og staging-regler er fjernet i produktion
- Noindex: kun de sider du bevidst har valgt, har noindex
- Sitemap: indeholder 200-URL’er (ikke redirects) og er indsendt i Search Console
- Canonical: peger på den rigtige version af hver side, især ved filtre og kategorier
- Tracking: GA/GTM og relevante tags affyrer korrekt på alle sidetyper
- Kritiske sidetyper: dine vigtigste landingssider matcher baseline på titel, H1, brødkrummer og indhold
Hvis bare én af de første tre fejler, er det ofte en No-Go. Det er billigere at udskyde 24 timer end at bruge 8 uger på at vinde tabt indeks tilbage.
De første dage efter launch: hvad du skal overvåge, og hvad du kan ignorere
Efter launch vil du næsten altid se uro. Det kan være helt normalt. Din opgave er at skelne mellem “Google omorganiserer” og “vi har et reelt teknisk læk”.
De signaler, du skal reagere hurtigt på:
- Pludselig stigning i 404 eller soft 404 i Search Console
- Mange URL’er markeret som “Crawlet, ikke indekseret” uden kendt årsag
- Store fald i impressions på dine vigtigste forespørgsler
- Uventet fald i crawl-aktivitet (kan ses i logfiler eller via crawling/indekseringsmønstre)
De signaler, du ofte kan give lidt tid:
- Små udsving i placeringer på longtail
- Midlertidige ændringer i snippet-tekst
- Let forsinkelse i indeks af nye URL’er, hvis dit sitemap lige er skiftet
Lav gerne en fast rutine i 2 til 4 uger: daglig kontrol af Search Console, ugentlig crawl af sitet, og en kort sammenligning mod din baseline. Når du arbejder sådan, bliver migreringen ikke et sats. Den bliver et styrbart projekt, hvor du retter små fejl, før de bliver til store fald.
Og når du samtidig bruger CMS-skiftet til at strukturere dit indhold bedre, med klare emneklynger og intern linklogik, kan du gå fra “bevar placeringer” til “løft placeringer” uden at vente på et mirakel.
