En hostingflytning uden SEO-plan kan koste dig uger af trafik. Ikke dage — uger.

Det sker ikke fordi Google straffer dig for at skifte hosting. Det sker fordi fejl opstaplet under migrationen — forkerte redirects, forsinket SSL, en robots.txt der blokerer crawling — kan holde Googlebot ude af dit site i lang tid, mens du venter på at forstå, hvad der gik galt.

Det behøver ikke ske. Her er, hvad du skal gøre — og hvad du ikke må gøre.

Hvorfor hosting-migrationer faktisk påvirker SEO

Lad os starte med det grundlæggende.

Google er ikke magisk. Googlebot besøger dit site med jævne mellemrum, crawler dine sider og opdaterer sit index. Hvis dit site er nede, svarer med forkerte HTTP statuskoder, eller blokerer bot-adgang under flytningen, afspejles det direkte i indekseringen.

Det, der koster flest rangeringer under en hostingflytning, er ikke selve flytningen — det er dagene og ugerne efter, når fejl opdages langsomt og rettes én ad gangen.

Planlægning løser det.

Fase 1: Før flytningen

Begynd mindst én uge før den planlagte flytningsdato.

Lav et baseline-crawl

Crawl dit nuværende site med et tool som Screaming Frog eller Sitebulb. Gem output som CSV. Du har brug for det bagefter for at sammenligne.

Notér specifikt:

• Alle sider med 200-status (dem du forventer at beholde)
• Eksisterende redirects — hvor peger de hen?
• Eventuelle 404-sider der allerede er i indexet

Crawl budget er relevant her: store sites med mange sider skal sikre, at den nye server kan håndtere Googlebots crawlrate uden at throttle forbindelser.

Screenshot GSC

Tag en screenshot af Google Search Console — specifikt:

• Organisk trafik de seneste 3 måneder
• Index coverage (inkl. antal indekserede sider)
• Core Web Vitals

Det er dit referencepunkt. Hvis noget ændrer sig dramatisk i de første to uger efter flytning, ved du, hvad “normalt” ser ud.

Forbered SSL

HTTPS og SSL skal være klar på den nye server inden du skifter DNS. Ikke bagefter.

Årsagen: hvis du skifter DNS, og SSL ikke er aktivt fra minut ét, serverer dit site enten HTTP (dårligt for SEO, dårligt for brugere) eller fejl. Google er ikke nådig over for sites, der pludselig bliver usikre.

Bestil eller installér certifikatet. Test det på staging. Bekræft at det er aktivt, inden du rører DNS.

Gem en kopi af robots.txt

Det lyder banalt. Men en fejl i robots.txt kan blokere Googlebot fra hele dit site — og den fejl opdages typisk ikke med det samme.

Gem den eksisterende fil. Sæt den klar til at deploye på den nye server med det samme.

Fase 2: Under flytningen

Hold forandringerne til et minimum. Jo færre variabler, jo lettere er fejlfinding.

Nedsæt DNS TTL i god tid

TTL (Time to Live) bestemmer, hvor lang tid DNS-servere cacher din records. Standardværdien er typisk 3600 sekunder (1 time) eller højere.

Skru TTL ned til 300 sekunder (5 minutter) mindst 24–48 timer inden du skifter. Det betyder, at DNS propagation sker hurtigere, når du faktisk skifter — og at fejl kan rettes hurtigere.

Glem ikke at skrue TTL op igen efter flytningen er bekræftet stabil.

Test på staging — ikke på live

Kør dit site på den nye server som staging, inden du skifter DNS. Tjek at alle sider loader korrekt. Tjek at SSL virker. Tjek at formularer, logins og eventuelle dynamiske elementer fungerer.

En fejl fundet på staging tager minutter at rette. Den samme fejl fundet live tager timer — og den rammer dine brugere og Googlebot undervejs.

Rør ikke redirects under flytningen

Redirects er et eget kapitel. Under selve hostingflytningen er reglen enkel: ingen redirect-ændringer.

Flyt din eksisterende redirect-struktur uændret til den nye server. Bekræft at den virker. Vent med at ændre i redirect-logikken, til du ved at flytningen er stabil.

Hvis du ændrer redirects og skifter DNS på samme tid, ved du ikke, hvad der forårsager problemer, hvis noget går galt.

Fase 3: Efter flytningen

De første 72 timer er afgørende.

Hvad er realistisk for DNS propagation?

Forvent 1–24 timer til fuld propagation — typisk 2–6 timer, hvis du har skruet TTL ned. Men propagationen sker ikke ens overalt i verden. Tjek med et tool som WhatsMyDNS, om din nye IP er synlig fra forskellige lokationer.

Mens propagationen foregår, vil nogle besøgende se den gamle server og andre den nye. Det er normalt og ufarligt — hvis begge servere fungerer korrekt.

Tjek Googlebot i server logs

Inden for 24–48 timer bør du se Googlebot-aktivitet i din nye servers logs. Bekræft:

• At Googlebot faktisk besøger sitet
• At den modtager 200-statuskoder på de vigtigste sider
• At ingen crawler-fejl er opstået

Hvis Googlebot ikke dukker op, er robots.txt et sandsynligt problem. Tjek det med det samme.

Re-submit sitemap i GSC

XML sitemap skal genindsendes i Google Search Console efter flytningen. Ikke fordi det er strengt nødvendigt, men fordi det signalerer til Google, at dit site er klar til at crawles på ny — og det fremskynder re-indekseringen.

Bekræft at sitemap-URL’en er korrekt og tilgængelig. Tjek for eventuelle fejl i GSC’s sitemap-rapport.

De fejl der faktisk koster rangeringer

Her er, hvad jeg ser gå galt igen og igen.

301 ændret til 302. En 301-redirect er permanent og overfører link equity. En 302 er midlertidig og gør ikke. Mange servere returnerer 302 som standard — tjek at dine vigtige redirects er 301.

SSL-certifikatet forsinkes. Flytning sker, SSL er ikke klar endnu, sitet serverer HTTP. Google ser et site, der tidligere var HTTPS, nu servere usikkert. Det registreres som et negativt signal.

robots.txt blokerer crawling under migration. En staging-version af robots.txt med Disallow: / deployes til live. Googlebot holdes ude. Det opdages ikke i tre dage. Alt tab af indeksering i den periode er reelt.

HTTP statuskoder tjekkes ikke. Servere der returnerer 500-fejl, 403-fejl eller andre ikke-200-koder på sider, der burde eksistere. Et hurtigt post-migration crawl hadnler det.

Manglende post-migration crawl. Alt virker visuelt — men crawleren ser noget andet. Kør et nyt crawl dagen efter flytning og sammenlign med dit baseline. Forskelle er fejl, der skal rettes.

Den komplette tjekliste

FØR flytning:

• Crawl og gem baseline som CSV
• Screenshot af GSC (trafik + index coverage)
• SSL-certifikat klargjort og testet på ny server
• Kopi af robots.txt gemt og klar til deploy
• TTL skruet ned til 300 sek (24–48 timer i forvejen)

UNDER flytning:

• Test på staging — godkend alle sider
• Deploy robots.txt (tjek den ikke blokerer crawling)
• Aktiver SSL inden DNS-skift
• Skift DNS — rør ikke redirects

EFTER flytning:

• Tjek DNS propagation med WhatsMyDNS
• Bekræft Googlebot i server logs (inden for 48 timer)
• Kør nyt crawl og sammenlign med baseline
• Re-submit sitemap i GSC
• Tjek GSC for crawl-fejl efter 3–5 dage
• Skru TTL op igen

En hostingflytning er ikke farlig for SEO. En uforberedt hostingflytning er.

Forskellen er denne liste.