Sådan migrerer du et domæne uden at ødelægge dine søgerangeringer

At skifte domæne er et af de få SEO-projekter, hvor en teknisk lille fejl meget hurtigt kan blive meget synlig. Et manglende redirect, en blokeret crawl-sti eller en glemt canonical kan forvandle en ligetil rebranding til uger med ustabile placeringer.

En vis bevægelse er normal. Søgemaskiner skal bruge tid på at crawle de gamle URL'er, opdage redirects, behandle signaler og få det nye domæne på plads i indekset. Målet er ikke at undgå ethvert dyk. Målet er at gøre migreringen kedelig: én gammel URL peger på én tilsvarende ny URL, serveren svarer klart, og intet vigtigt forsvinder.

Start med en inventory, ikke en redirect-regel

Den mest almindelige fejl ved migrering er at behandle den som en serverkonfigurationsopgave. Det er den ikke. Det er en informationsarkitekturopgave, som tilfældigvis ender i serverkonfiguration.

Før du rører ved DNS, skal du opbygge en liste over URL'er, der betyder noget:

• URL'er, der modtager organisk trafik
• URL'er med eksterne backlinks
• URL'er, der konverterer, genererer leads eller understøtter kampagner
• Canonical-URL'er, der aktuelt findes i dit XML-sitemap
• PDF'er, billeder og downloadbare filer, der linkes til eksternt
• Værdifulde legacy-URL'er, som måske ikke fremgår af den nuværende navigation

For hver gammel URL skal du tildele en destination på det nye domæne. I de fleste tilfælde bør den destination være den samme side med samme intention. Hvis /pricing bliver til https://newdomain.com/pricing, er det enkelt. Hvis tre gamle produktsider bliver samlet til én ny guide, skal du dokumentere den beslutning bevidst.

Undgå det dovne mønster: at redirecte alt til den nye forside. Det er bekvemt, men det smider relevans væk. Både søgemaskiner og brugere forventer, at destinationen besvarer det samme behov som den oprindelige URL.

Bevar URL-strukturen, hvor du kan

En domænemigrering er lettere, når stierne forbliver stabile. At flytte fra oldsite.com/blog/example til newsite.com/blog/example er langt renere end at ændre domæne, CMS, slugs, mappestruktur og indhold på samme tid.

Nogle gange gør et redesign eller en CMS-migrering URL-ændringer uundgåelige. Hvis det er tilfældet, så adskil beslutningerne:

1. Hvad ændrer sig, fordi domænet ændrer sig?
2. Hvad ændrer sig, fordi sitestrukturen ændrer sig?
3. Hvad bliver slettet, samlet eller omskrevet?

Jo flere variabler du introducerer, desto sværere bliver det at diagnosticere problemer senere. Hvis migreringen er vigtig, og det nuværende site klarer sig godt, bør du overveje at flytte domænet først og redesigne senere.

Brug permanente redirects med ét hop

Til en reel domænemigrering skal du bruge server-side 301- eller 308-redirects fra gamle URL'er til deres nye ækvivalenter. Midlertidige redirects er til midlertidige situationer. JavaScript-redirects, meta refreshes og soft redirects er svagere signaler og lettere at ødelægge.

Dine redirect-mål er enkle:

• Hver vigtig gammel URL returnerer et permanent redirect.
• Hvert redirect går direkte til den endelige destination.
• HTTP redirecter rent til HTTPS.
• www- og non-www-varianter håndteres konsistent.
• Redirects afhænger ikke af skrøbelig query-string-adfærd, medmindre det er nødvendigt.

En dårlig kæde ser sådan ud:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Den lander måske til sidst på den rigtige side, men den er langsom, sværere at crawle og mere tilbøjelig til at skjule fejl. Sigt efter ét hop fra hver gammel variant til den endelige nye URL.

Når du validerer adfærd, skal du inspicere de faktiske HTTP-svar i stedet for at stole på det, browseren viser. Vores guide til debugging af redirects og HTTP headers i produktion er nyttig her, fordi browsere er for høflige: de følger kæden og skjuler de rodede dele.

Forbered DNS og certifikater før lancering

DNS overfører ikke direkte rangeringer, men dårlig DNS kan få en migrering til at se ødelagt ud. Sænk TTL-værdier før lanceringsvinduet, så ændringer propagerer mere forudsigeligt. Bekræft, at det nye domæne har korrekte records til webtrafik, email og eventuelle nødvendige subdomains.

Du har også brug for gyldige TLS-certifikater til begge domæner. Det er let at overse. Det gamle domæne skal stadig kunne levere HTTPS-redirects efter migreringen. Hvis certifikatet udløber, kan brugere og crawlere møde browseradvarsler, før de nogensinde når det nye site.

Hvis flytningen påvirker email, må du ikke behandle det som en eftertanke. Domæneændringer ødelægger ofte SPF, DKIM, DMARC, MX records, tracking links og transactional mail. Hvis du vil have en genopfriskning af de records, der betyder noget, kan du se vores udviklervenlige guide til MX, SPF, DKIM og DMARC.

Tjek canonicals, interne links og sitemaps

Efter lancering bør det nye domæne opføre sig, som om det altid har været indholdets canonical-hjem.

Det betyder:

• Canonical-tags peger på de nye URL'er, ikke det gamle domæne.
• Interne links bruger det nye domæne eller root-relative paths.
• XML-sitemaps indeholder kun endelige, indekserbare nye URL'er.
• hreflang-annotations, hvis de bruges, refererer til de nye URL'er.
• Open Graph, structured data og alternate links er opdateret.
• Robots.txt blokerer ikke vigtige sektioner.

Publicér ikke et sitemap fyldt med gamle URL'er og forvent, at redirects rydder op. Et sitemap bør være en liste over URL'er, du ønsker indekseret. Efter en migrering betyder det endelige URL'er på det nye domæne.

Hold også øje med canonical-modsigelser. En side, der redirecter fra gammel til ny, men har en canonical, der peger tilbage på det gamle domæne, sender blandede signaler. Søgemaskiner kan normalt arbejde sig igennem en vis inkonsistens, men du bør ikke bede dem om det.

Ændr ikke alt på lanceringsdagen

En migrering er allerede en stor nok begivenhed. Hvis det er muligt, bør du undgå at kombinere den med større indholdsbeskæring, omskrivning af templates, navigationsændringer, ændringer i JavaScript-rendering eller en ny performance-profil.

Det er ikke overtro. Det er debugging-disciplin. Hvis rangeringer falder efter lancering, skal du vide, om årsagen er redirect-mapping, crawl-adgang, ændret indhold, langsommere rendering, manglende structured data eller noget andet.

Hold den indledende lancering så tæt på det gamle site som praktisk muligt. Når det nye domæne er stabilt, kan du lave større redaktionelle og designmæssige ændringer i mindre batches.

Fortæl søgemaskiner, hvad der er ændret

I Google Search Console skal du verificere både det gamle og det nye domæne. Brug derefter Change of Address tool, når flytningen er en ændring på domæneniveau, og indholdet flytter til et nyt domæne. Indsend det nye sitemap efter lancering.

Dette erstatter ikke redirects. Det understøtter dem. Søgemaskiner har stadig brug for crawlbare, vedvarende redirects for at forstå mappingen på URL-niveau.

For Bing og andre søgemaskiner skal du bruge deres webmaster tools, hvor de er tilgængelige. Opdater også de steder, du kontrollerer: sociale profiler, virksomhedsprofiler, annoncedestinationer, email footers, dokumentation, partnerlinks og canonical-referencer i syndikeret indhold.

Eksterne links bliver ikke alle opdateret, og det er fint. Men de vigtigste bør blive det. Hvis en stor partner, app marketplace, dokumentationsportal eller presseside linker til det gamle domæne, så bed om en opdatering.

Overvåg de rigtige ting efter lancering

De første par dage efter migreringen bør være aktiv overvågning, ikke fejring.

Tjek:

• Server logs for crawl-aktivitet på gamle og nye domæner
• 404'er og uventede 5xx-fejl
• Redirect-kæder og loops
• Indekseringsstatus i Search Console
• Opdagelse og behandling af sitemap
• Organiske landingssider og query-mønstre
• Konverteringsstier, der afhænger af gamle URL'er
• Analytics-filtre og referral exclusions

Forvent støj i rapporteringen. Nogle analytics-værktøjer behandler det nye domæne som en ny property, medmindre de er konfigureret korrekt. Nogle dashboards sammenligner trafik på det gamle domæne med trafik på det nye domæne og får migreringen til at se værre ud, end den er.

Søgesynlighed kan svinge i nogle uger. Det, du ikke ønsker, er et mønster, hvor værdifulde gamle URL'er bliver crawlet gentagne gange, men ikke redirectet korrekt, eller hvor nye sider opdages, men markeres som dubletter af det gamle domæne.

Performance bør heller ikke ignoreres. Hvis det nye domæne lanceres med tungere templates, ødelagt caching eller uoptimerede assets, kan brugerne opleve migreringen som en opbremsning. Hvis du bruger Lighthouse som en del af dine tjek, så læs det med prioriteter for øje; vores artikel om hvordan du læser en Lighthouse-rapport uden at gå i panik forklarer, hvordan du adskiller væsentlige problemer fra støj.

Behold det gamle domæne i lang tid

Lad ikke det gamle domæne udløbe, efter migreringen “virker.” Hold det registreret, hold certifikater gyldige, og hold redirects kørende så længe som muligt. I praksis betyder det ofte år.

Gamle links bliver ved med at eksistere i blogindlæg, bogmærker, dokumentation, PDF'er, emails og sociale opslag. Redirects er broen mellem det historiske fodaftryk og det nye domæne. Hvis du slår dem fra for tidligt, ødelægger du brugernes veje og spilder opsamlede signaler.

Gem også en kopi af dit redirect-map og dine lanceringsnoter. Seks måneder senere, når nogen spørger, hvorfor en legacy-URL opfører sig på en bestemt måde, vil du være glad for, at du dokumenterede det.

<!-- tool-cta:start -->

💡 Prøv dette: Efter overgangen skal du spore dine gamle URL'er gennem Redirect Checker for at bekræfte, at hver enkelt lander på den rigtige nye side med ét enkelt 301-hop.

<!-- tool-cta:end -->

En fornuftig tjekliste til migrering

Før lancering:

• Verificer begge domæner i Search Console.
• Crawl det nuværende site og eksportér vigtige URL'er.
• Byg et én-til-én redirect-map.
• Sænk DNS TTLs.
• Forbered TLS-certifikater til gamle og nye domæner.
• Opdater canonicals, interne links, hreflang, structured data og sitemaps.
• Test redirects i staging eller et kontrolleret miljø.

På lanceringsdagen:

• Deploy redirects.
• Bekræft HTTP-til-HTTPS-adfærd.
• Test vigtige URL-eksempler fra hver template-type.
• Indsend det nye sitemap.
• Brug Change of Address tool, hvor det er relevant.
• Hold øje med serverfejl, redirect-loops og blokerede ressourcer.

Efter lancering:

• Overvåg crawl-fejl og indekseringsrapporter.
• Opdater vigtige eksterne links, hvor du kan.
• Sammenlign trafik efter landingssidens intention, ikke kun domænetotaler.
• Hold redirects live på ubestemt tid.
• Udskyd urelaterede redesign- eller indholdseksperimenter, indtil flytningen er stabiliseret.

Domænemigreringer er ikke risikofri, men de kan håndteres. Rangeringer lider typisk, når migreringen sender uklare signaler: manglende redirects, ændret indhold, modstridende canonicals, blokerede crawlere eller et glemt gammelt domæne. Giv søgemaskiner og brugere et klart kort, og flytningen bliver langt mindre dramatisk.