SEO-tjekliste til website-migrering

En website-migrering er ikke kun et design- eller udviklingsprojekt. Det er også en ændring af de URL’er, det indhold, de interne links, metadata og tekniske signaler, som søgemaskiner allerede forstår.

Når signalerne flyttes omhyggeligt, kan en ny platform lanceres med begrænset uro. Når de behandles som en afsluttende SEO-opgave, kan vigtige sider forsvinde, redirects pege forkert, og søgemaskiner må forsøge at forstå den nye struktur ud fra mangelfulde oplysninger.

Hvad tæller som en website-migrering?

En migrering er mere end flytning til et nyt domæne. Der opstår SEO-risiko, hver gang vigtige URL’er eller måden, indhold leveres på, ændres.

Almindelige migreringer omfatter:

• Flytning til et nyt CMS eller framework
• Redesign med ændringer i skabeloner
• Ændring af domæne, subdomæne eller protokol
• Omlægning af kategorier og URL-struktur
• Sammenlægning af flere websites
• Skift fra client-side rendering til server-renderede eller statiske sider
• Fjernelse, sammenlægning eller omskrivning af store mængder indhold

Jo større ændringen er, desto vigtigere er det at opdele migreringen i tydelige trin. Hvis domæne, platform, indhold, navigation og visuelt design ændres samtidig, bliver problemer sværere at isolere.

Start med en komplet URL-oversigt

Før redirect-planen bygges, skal de nuværende vigtige URL’er indsamles.

Brug flere kilder, fordi ingen enkelt kilde er komplet:

• Crawl det nuværende website
• Eksportér indekserede og indsendte sider fra Google Search Console
• Gennemgå XML-sitemaps
• Eksportér landingssider fra analytics
• Medtag URL’er med backlinks eller henvisningstrafik
• Medtag kampagne-, produkt-, kategori-, dokument- og billed-URL’er, hvor det er relevant
• Gennemgå serverlogs for URL’er, som crawlere og brugere stadig efterspørger

Registrér hver URL’s statuskode, canonical-mål, indekserbarhed, titel, primære overskrift, trafik, backlinks og planlagte destination. Oversigten bliver reference for redirects, test og overvågning efter lancering.

Den afdækker også eksisterende problemer. Det gamle website kan allerede indeholde redirect-kæder, duplikerede sider, forældreløst indhold eller modstridende canonical-signaler. Beslut hvilke problemer der skal ryddes op i under migreringen, og hvilke der midlertidigt bør bevares for at begrænse lanceringsrisikoen.

Lav en tydelig URL-plan

Hver vigtig gammel URL skal have et bevidst resultat:

• Behold samme URL
• Redirect til en tæt tilsvarende side
• Saml indholdet på en stærkere relevant side
• Returnér en reel 404 Not Found eller 410 Gone, når der ikke findes en erstatning

Redirect ikke alle fjernede URL’er til forsiden. Et redirect bør føre brugere og søgemaskiner til en side, der omtrent opfylder samme formål. Irrelevante redirects giver en dårlig oplevelse og kan blive behandlet som soft 404-fejl.

Hold mappingen i et struktureret dokument, som udvikling, indhold og SEO kan dele. Medtag gammel URL, ny URL, begrundelse, implementeringsstatus og testresultat. Det gør manglende routes og tilfældige beslutninger synlige før lancering.

Bevar de signaler, der stadig betyder noget

En migrering indeholder ofte forbedringer, men nyttige eksisterende signaler bør ikke forsvinde ved et uheld.

Sammenlign den gamle og nye version af vigtige sider:

• Primært indhold og formål
• Sidetitel og metabeskrivelse
• Primær overskrift og overskriftsstruktur
• Interne links
• Canonical-URL
• Robots-direktiver
• Strukturerede data
• Sprogalternativer
• Billeder, alt-tekster og downloadfiler

Den nye side behøver ikke være identisk, men den skal fortsat tydeligt opfylde årsagen til, at den gamle side fik placeringer eller trafik. Et teknisk korrekt redirect kan ikke kompensere for, at en nyttig side erstattes af tyndt eller uvedkommende indhold.

Hold staging under kontrol

Staging-sitet skal være tilgængeligt for dem, der tester det, men ikke for offentligheden og søgemaskiner.

Brug login eller adgangskontrol på netværksniveau, hvor det er praktisk. Et noindex-direktiv er nyttigt som ekstra sikkerhed, men det skal fjernes før lancering. Hvis staging kun blokeres med robots.txt, kan crawlere blive forhindret i at se noindex, og privat indhold beskyttes ikke mod personer, der kender URL’en.

Lav et specifikt lanceringstjek for midlertidige kontroller:

• Fjern staging-login fra produktionsmiljøet
• Fjern noindex fra sider, der skal kunne findes
• Bekræft at produktionens robots.txt tillader de rigtige områder
• Erstat staging-domæner i canonicals, links, schema og sitemaps
• Fjern test-analytics, API-endpoints og adgangsoplysninger

Midlertidige migreringsindstillinger har en tendens til at blive permanente produktionsproblemer, hvis de ikke følges eksplicit.

Implementér redirects uden kæder

Brug permanente redirects på serverniveau til URL’er, der er flyttet permanent. Peg hver gammel URL direkte på dens endelige destination i stedet for at sende den gennem tidligere versioner.

Eksempel:

gammel URL -> endelig ny URL

Undgå:

gammel URL -> URL fra tidligere redesign -> HTTP-version -> endelig ny URL

Redirect-kæder gør forespørgsler langsommere, bruger crawlressourcer og skaber flere steder, hvor migreringen kan fejle. Eksisterende eksterne links kan stadig pege på meget gamle URL’er, så historiske redirects bør gennemgås og opdateres til den endelige destination, hvor det er muligt.

Googles vejledning til website-flytninger med URL-ændringer anbefaler at beholde redirects så længe som muligt og generelt mindst ét år. I praksis kan nyttige redirects bevares længere, når gamle links og bogmærker stadig eksisterer.

Opdater interne signaler til de endelige URL’er

Redirects er et sikkerhedsnet, ikke den foretrukne vej gennem det nye website.

Opdater interne links, navigation, canonical-tags, hreflang-referencer, strukturerede data og XML-sitemaps, så de peger direkte på de endelige produktions-URL’er. Det hjælper brugere og crawlere gennem den nye struktur uden unødvendige redirects eller modstridende signaler.

Et sitemap bør kun indeholde kanoniske, indekserbare URL’er med succesfulde svar. Medtag ikke redirects, blokerede sider, dubletter eller manglende sider. Det hænger direkte sammen med det bredere arbejde med crawlability og indeksering.

Test før lancering

Crawl staging-sitet, og sammenlign det med oversigten fra den nuværende produktion. Test mere end forsiden og nogle få skabeloner.

Kontrollér:

• Alle planlagte redirects
• Vigtige sider og brugerrejser
• Statuskoder og response headers
• Canonicals og robots-direktiver
• Interne links og forældreløse sider
• XML-sitemaps
• Strukturerede data
• Mobillayout og tilgængelighed
• Formularer, søgning, checkout, login og integrationer
• Performance og renderet indhold
• Fejlsider og manglende URL’er

Automatisér gentagelige kontroller, hvor det er muligt. Et enkelt script eller en sammenligning af crawler-eksporter kan finde hundredvis af manglende redirects eller forkerte canonicals mere pålideligt end manuel browsing.

Hold lanceringen kontrolleret

Undgå at lancere umiddelbart før en weekend, ferie eller periode, hvor de rette personer ikke kan reagere. Sørg for, at backups, rollback-trin, DNS-adgang, redirect-konfiguration, analytics og overvågning er klar før skiftet.

Ved lancering:

1. Udgiv produktionssitet og redirect-reglerne.
2. Bekræft at midlertidige staging-kontroller er væk fra produktion.
3. Test et repræsentativt udvalg af vigtige gamle og nye URL’er.
4. Crawl det offentlige website.
5. Indsend det nye sitemap.
6. Brug Search Consoles Change of Address-værktøj ved domæneflytning, når værktøjet er relevant.
7. Kontrollér logs, analytics, formularer, integrationer og fejlovervågning.

En rollback-plan bør definere, hvad der skal fejle, før det gamle system gendannes. Uden den beslutning på forhånd kan kritiske lanceringstimer blive brugt på at diskutere, om et problem er alvorligt nok.

Overvåg efter lancering

Migreringsarbejdet fortsætter, efter det nye site er offentligt.

Hold øje med:

• Indekserings- og crawlrapporter
• Organiske landingssider og søgetrafik
• 404-, 500- og redirect-svar
• Serverlogs og crawleraktivitet
• Behandling af sitemaps
• Valg af canonical
• Placeringer for vigtige søgninger
• Konvertering og gennemførte formularer
• Performance og Core Web Vitals

Sammenlign resultaterne med de målinger, der blev indsamlet før migreringen. Nogle udsving er normale, mens søgemaskiner crawler og behandler ændringerne, men tekniske fejl bør undersøges hurtigt frem for at blive afvist som midlertidige.

Almindelige fejl ved migrering

De samme undgåelige problemer går igen:

• Redirect-planen startes for sent
• Alle gamle URL’er sendes til forsiden
• Interne links peger stadig gennem redirects
• Produktion lanceres med noindex
• Canonicals eller schema henviser stadig til staging
• Værdifuldt indhold fjernes uden en tilsvarende side
• JavaScript-rendering skjuler vigtigt indhold
• Sitemappet indeholder redirects og fejl
• Tracking eller konverteringsflows holder op med at virke
• Ingen overvåger sitet efter lancering

En migrering behøver ikke bevare alle svagheder fra det gamle website. Den skal bevare den værdi, som brugere og søgemaskiner allerede er afhængige af, mens den underliggende platform ændres.

Tjekliste til migreringen

Før lanceringen godkendes, bør det bekræftes, at:

• Den eksisterende URL-oversigt er komplet nok til at beskytte vigtige sider
• Hver vigtig gammel URL har et testet resultat
• Redirects peger direkte på relevante endelige URL’er
• Ændringer i indhold og metadata er bevidste
• Interne links, canonicals, sprogalternativer, schema og sitemaps bruger produktions-URL’er
• Midlertidige staging-kontroller er fjernet fra produktion
• Vigtige brugerrejser og integrationer virker
• Analytics og overvågning er aktive
• Backups og rollback-trin er klar
• Ansvar og kontrol efter lancering er aftalt

Godt migreringsarbejde består primært af forberedelse, tydelige beslutninger og omhyggelig kontrol. Den synlige lancering kan ske på én dag, men bevarelsen af synlighed afhænger af arbejdet før og efter den.