Tjekliste til hjemmeside­migrering

En hjemmesidemigrering kan dække over to ret forskellige opgaver. I det ene tilfælde flyttes den samme hjemmeside til ny hosting uden ændringer i de offentlige URL’er. I det andet ændres domænet, platformen, URL-strukturen, indholdet eller måden, siderne bliver vist på.

Begge opgaver kræver omhyggelig forberedelse, men de følger ikke den samme tjekliste. Et rent hostingskifte er først og fremmest en kontrolleret flytning af infrastrukturen. En migrering med nye URL’er eller ændret indhold kræver også en URL-plan, viderestillinger og bevarelse af de signaler, som søgemaskiner allerede forstår.

Vælg migreringstype, før planen lægges

Start med at skrive præcist ned, hvad der skal ændres.

• Samme URL’er, ny infrastruktur: Hostingudbyder, server, origin, CDN eller runtime ændres, mens besøgende fortsat bruger samme domæne og stier.
• URL’er eller levering af indhold ændres: Projektet ændrer domæne, protokol, stier, CMS, framework, rendering, skabeloner, navigation eller væsentlige dele af indholdet.

Der er ingen grund til at lave en ny plan for viderestillinger, blot fordi serveren skiftes, hvis alle offentlige URL’er forbliver uændrede. Omvendt bør et redesign eller et platformsskifte ikke behandles som et simpelt hostingskifte, hvis det ændrer sider, canonical-tags eller interne links.

Skift så vidt muligt ét større lag ad gangen. Hvis hosting, domæne, platform, indhold og design ændres i samme lancering, bliver fejl langt sværere at finde og afgrænse.

Forløb 1: Flyt hosting uden at ændre URL’er

En hostingmigrering skal flytte hjemmesiden uden at miste formularer, mail, planlagte opgaver, performance, synlighed eller administrativ adgang. Det er sjældent nok blot at kopiere filerne.

Kortlæg hele opsætningen

Dokumentér de systemer, der afhænger af den nuværende hosting:

• Domæneregistrator, DNS-udbyder og nuværende records
• Hostingkonto, serveropsætning og kontrolpanel
• Hjemmesidefiler, databaser, lagerplads og uploads
• CMS eller framework, runtime, PHP-version og udvidelser
• SSL-certifikater og måden, de fornyes på
• Regler for viderestillinger, caching, CDN, firewall og sikkerhed
• Forretningsmail, transaktionsmails og verificeringsrecords
• Cronjobs, køer, webhooks og baggrundsprocesser
• Sikkerhedskopier, opbevaringsperiode og en afprøvet gendannelse
• Formularer, betaling, booking og tredjepartsintegrationer

Det forhindrer, at en vellykket kopiering af selve hjemmesiden skjuler fejl i mail, formularer, callbacks eller baggrundsopgaver.

Klargør og test den nye infrastruktur

Klargør hjemmesiden hos den nye hostingudbyder, før offentlig trafik sendes dertil. Afhængigt af opsætningen kan testen foregå via et midlertidigt hostname, et preview-domæne, et testmiljø eller en lokal ændring i hosts-filen.

Kontrollér de sider og arbejdsgange, der betyder noget: navigation, formularer, søgning, booking, betaling, login, administration, billeder, downloads, viderestillinger, API-callbacks, planlagte opgaver og udgående mail. Bekræft også, at runtime-versioner, filrettigheder, miljøvariabler, databaseindstillinger og caching passer til applikationen.

Det nye miljø skal tillade adgang for både brugere og søgemaskiner, når det bliver offentligt. Gennemgå firewall, botbeskyttelse, begrænsning af trafik og CDN-indstillinger i stedet for at gå ud fra, at en opsætning kopieret fra en anden server passer.

Planlæg DNS, mail og skiftet af trafik

DNS kan styre langt mere end hjemmesiden. Bevar MX-records, afsendergodkendelse, verificering af tjenester og andre uvedkommende records, når webserveren ændres. Hvis Cloudflare eller et andet CDN ligger foran hostingen, skal SSL-mode, cache-regler, viderestillinger, firewall og forbindelsen til origin-serveren indgå i samme plan. Guiden til Cloudflare, caching og performance gennemgår det lag nærmere.

Lad så vidt muligt begge miljøer være tilgængelige under overgangen. Efter ændringen af DNS eller origin skal trafikken til både gammel og ny infrastruktur overvåges. Kontrollér, at vigtige sider fortsat svarer med de forventede statuskoder, og undersøg fejl, før den gamle hosting lukkes. Googles vejledning til hostingskift uden ændrede URL’er følger samme rækkefølge: klargør, skift, overvåg og luk den gamle løsning.

Forløb 2: Skift URL’er, indhold eller levering

Når offentlige URL’er eller måden, vigtigt indhold leveres på, ændres, bliver flytningen også en SEO-opgave. Eksisterende sider, links, metadata og signaler til søgerobotter skal have en tydelig destination på den nye hjemmeside.

Start med en komplet URL-oversigt

Før planen for viderestillinger udarbejdes, skal de nuværende vigtige URL’er indsamles.

Brug flere kilder, fordi ingen enkelt kilde er komplet:

• Gennemgå den nuværende hjemmeside med en søgerobot
• Eksportér indekserede og indsendte sider fra Google Search Console
• Gennemgå XML-sitemaps
• Eksportér landingssider fra webanalysen
• Medtag URL’er med indgående links eller henvisningstrafik
• Medtag kampagne-, produkt-, kategori-, dokument- og billed-URL’er, hvor det er relevant
• Gennemgå serverens logfiler for URL’er, som søgerobotter og brugere stadig efterspørger

Registrér hver URL’s statuskode, kanoniske URL, indekserbarhed, titel, primære overskrift, trafik, indgående links og planlagte destination. Oversigten bliver reference for viderestillinger, test og overvågning efter lancering.

Den afdækker også eksisterende problemer. Den gamle hjemmeside kan allerede indeholde kæder af viderestillinger, duplikerede sider, forældreløst indhold eller modstridende canonical-tags. Beslut hvilke problemer der skal ryddes op i under flytningen, og hvilke der midlertidigt bør bevares for at mindske risikoen ved lanceringen.

Lav en tydelig URL-plan

Hver vigtig gammel URL skal have et bevidst resultat:

• Behold samme URL
• Viderestil til en nært 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

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

Saml forbindelsen mellem gamle og nye URL’er i et struktureret dokument, som udviklere, redaktører og SEO-ansvarlige kan dele. Medtag gammel URL, ny URL, begrundelse, status og testresultat. Det gør manglende ruter 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. En teknisk korrekt viderestilling kan ikke kompensere for, at en nyttig side erstattes af tyndt eller uvedkommende indhold.

Hold testmiljøet under kontrol

Testmiljøet skal være tilgængeligt for dem, der arbejder med det, men ikke for offentligheden og søgemaskiner.

Brug login eller adgangskontrol på netværksniveau, hvor det giver mening. Et noindex-direktiv er nyttigt som ekstra sikkerhed, men det skal fjernes før lancering. Hvis testmiljøet kun blokeres med robots.txt, kan søgerobotter 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 testmiljøets adgangskontrol fra produktionsmiljøet
• Fjern noindex fra sider, der skal kunne findes
• Bekræft at produktionens robots.txt tillader de rigtige områder
• Erstat testdomæner i canonical-tags, links, strukturerede data og sitemaps
• Fjern testopsætning til webanalyse, API-adresser og adgangsoplysninger

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

Opret viderestillinger uden kæder

Brug permanente viderestillinger 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

Kæder af viderestillinger gør forespørgsler langsommere, bruger søgemaskinernes crawlbudget og skaber flere steder, hvor flytningen kan fejle. Eksisterende eksterne links kan stadig pege på meget gamle URL’er, så tidligere viderestillinger bør gennemgås og opdateres til den endelige destination, hvor det er muligt.

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

Opdater interne signaler til de endelige URL’er

Viderestillinger er et sikkerhedsnet, ikke den foretrukne vej gennem den nye hjemmeside.

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 søgerobotter gennem den nye struktur uden unødvendige viderestillinger eller modstridende signaler.

Et sitemap bør kun indeholde kanoniske, indekserbare URL’er, der svarer korrekt. Medtag ikke viderestillinger, blokerede sider, dubletter eller manglende sider. Det hænger direkte sammen med det bredere arbejde med adgang for søgerobotter og indeksering.

Test før lancering

Gennemgå testmiljøet med en søgerobot, og sammenlign resultatet med oversigten fra den nuværende hjemmeside. Test mere end forsiden og nogle få skabeloner.

Kontrollér:

• Alle planlagte viderestillinger, når URL’er ændres
• Vigtige sider og brugerrejser
• Statuskoder og svar-headere
• Canonical-tags og robots-direktiver
• Interne links og forældreløse sider
• XML-sitemaps
• Strukturerede data
• Mobillayout og tilgængelighed
• Formularer, søgning, betaling, login og integrationer
• Hastighed og det viste indhold
• Fejlsider og manglende URL’er

Automatisér gentagelige kontroller, hvor det er muligt. Et enkelt script eller en sammenligning af rapporter fra søgerobotten kan finde hundredvis af manglende viderestillinger eller forkerte canonical-tags mere pålideligt end en manuel gennemgang.

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 sikkerhedskopier, en plan for tilbagerulning, DNS-adgang, viderestillinger, webanalyse og overvågning er klar før skiftet.

Ved lancering:

1. Sæt produktionsmiljøet og de viderestillinger, som URL-ændringerne kræver, i drift.
2. Bekræft, at testmiljøets midlertidige begrænsninger ikke er fulgt med i produktion.
3. Test et repræsentativt udvalg af vigtige gamle og nye URL’er.
4. Gennemgå den offentlige hjemmeside med en søgerobot.
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 logfiler, webanalyse, formularer, integrationer og fejlovervågning.

Planen for tilbagerulning bør fastlægge, hvilke fejl der skal føre til, at det gamle system gendannes. Uden den beslutning på forhånd kan kritiske timer efter lanceringen blive brugt på at diskutere, om et problem er alvorligt nok.

Overvåg efter lancering

Arbejdet med flytningen fortsætter, efter den nye hjemmeside er offentliggjort.

Hold øje med:

• Rapporter om indeksering og søgerobotternes aktivitet
• Organiske landingssider og søgetrafik
• 404-, 500- og viderestillingssvar
• Serverens logfiler og søgerobotternes aktivitet
• Behandling af sitemaps
• Valg af canonical
• Placeringer for vigtige søgninger
• Konvertering og gennemførte formularer
• Hastighed og Core Web Vitals

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

Guiden til kvalitetssikring og afstemning af konverteringssporing giver de konkrete kontroller, der viser, om formularer, bookinger, køb, kampagnedata og virksomhedens faktiske henvendelser kom sikkert gennem flytningen.

Almindelige fejl ved migrering

De samme undgåelige problemer går igen:

• Opgaven skelner ikke mellem et hostingskifte og en migrering med nye URL’er
• DNS-ændringer overskriver records til mail eller verificering
• Formularer, køer, cronjobs eller API-callbacks bliver ikke testet på den nye hosting
• Planen for viderestillinger påbegyndes for sent
• Alle gamle URL’er sendes til forsiden
• Interne links peger stadig gennem viderestillinger
• Produktion lanceres med noindex
• Canonical-tags eller strukturerede data henviser stadig til testmiljøet
• Værdifuldt indhold fjernes uden en tilsvarende side
• Rendering med JavaScript skjuler vigtigt indhold
• Sitemappet indeholder viderestillinger og fejl
• Sporing eller vigtige trin frem mod en henvendelse holder op med at virke
• Ingen overvåger hjemmesiden efter lancering

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

Ofte stillede spørgsmål

Er en hostingmigrering kun et spørgsmål om at kopiere hjemmesidens filer?

Nej. Database, runtime, DNS, mailrecords, SSL, caching, sikkerhedskopier, planlagte opgaver, formularer og integrationer kan alle afhænge af det nuværende miljø. De skal kortlægges og testes, selv om alle offentlige URL’er forbliver de samme.

Kan en DNS-ændring under en hostingmigrering påvirke virksomhedens mail?

Ja. DNS kan også styre maillevering, afsendergodkendelse, verificering af tjenester og andre systemer. Bevar de records, og ændr kun de værdier, som selve skiftet af webserver kræver.

Bør alle fjernede URL’er omdirigeres til forsiden?

Nej. En omdirigering bør føre til en side, der opfylder omtrent samme intention som originalen. At omdirigere alt til forsiden giver en dårlig oplevelse og kan blive behandlet som en soft 404 af søgemaskiner.

Er det nok at blokere et testmiljø med robots.txt for at holde det ude af søgeresultater?

Nej. En blokering med robots.txt alene kan forhindre søgerobotter i nogensinde at se et noindex-direktiv på siden, og det beskytter ikke privat indhold mod nogen, der allerede kender URL’en. Login eller adgangskontrol på netværksniveau er også nødvendigt.

Stabiliserer placeringerne i søgning sig med det samme efter en migrering lanceres?

Ikke nødvendigvis. Nogle udsving er normale, mens søgemaskinerne gennemgår hjemmesiden igen og behandler ændringerne, men det er noget andet end en teknisk fejl, som stadig bør undersøges hurtigt frem for at blive afskrevet som midlertidig.

Tjekliste til migreringen

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

• Migreringstypen og alle planlagte ændringer er dokumenteret
• Hosting, DNS, mail, runtime, sikkerhedskopier, planlagte opgaver og integrationer er kortlagt, hvor det er relevant
• Den nye infrastruktur og vigtige brugerrejser er testet, før offentlig trafik flyttes
• Den eksisterende URL-oversigt er komplet nok til at beskytte vigtige sider, når URL’er eller indhold ændres
• Hver vigtig gammel URL har et testet resultat, når viderestillinger er nødvendige
• Viderestillinger peger direkte på relevante endelige URL’er uden kæder
• Ændringer i indhold og metadata er bevidste
• Interne links, canonical-tags, sprogalternativer, strukturerede data og sitemaps bruger produktions-URL’er
• Testmiljøets midlertidige begrænsninger er fjernet fra produktion
• Vigtige brugerrejser og integrationer virker
• Webanalyse og overvågning er aktive
• Sikkerhedskopier og fremgangsmåden for tilbagerulning er klar
• Ansvar og kontrol efter lancering er aftalt

Godt arbejde med en flytning består primært af forberedelse, tydelige beslutninger og omhyggelig kontrol. Den synlige lancering kan ske på én dag, men stabilitet og synlighed afhænger af arbejdet før og efter den. Hvis en virksomhedshjemmeside står foran et skift af hosting, platform, domæne eller URL-struktur, kan du sende mig den nuværende opsætning, den planlagte destination og den forventede lanceringsdato, før migreringsplanen låses.