Sådan skifter du webhotel uden nedetid og tabt mail

Annonce – sponsoreret indhold.

Når du skal skifte webhotel uden nedetid og tabt mail, er princippet enkelt: Du opbygger en komplet kopi hos den nye udbyder, mens den gamle stadig kører, tester kopien grundigt og flytter først trafik og mail, når alt er verificeret. Nedetid og tabte mails opstår næsten altid, fordi nogen skifter DNS-indstillinger for tidligt, glemmer mailkonti eller opsiger det gamle abonnement, før det nye er testet. Denne guide gennemgår, hvornår et skifte giver mening, hvad der typisk går galt, og hvordan du flytter trin for trin. Du får også en tjekliste til tiden efter flytningen, så hverken SEO, hastighed eller mail kommer til at lide.

Tegn på, at det er tid til at skifte webhotel

Mange bliver hængende hos en udbyder af vane. Hjemmesiden virker jo, og et skifte lyder besværligt. Men et webhotel er fundamentet under alt andet: indhold, design og SEO-arbejde hviler på en server, og hvis den svigter, hjælper ingen optimering ovenpå. Her er de mest typiske advarselstegn.

Hjemmesiden er langsom, selvom du har optimeret den

Hvis du har komprimeret billeder, installeret cache og ryddet op i plugins, men siden stadig er træg, ligger problemet ofte på serveren. Et typisk symptom er en lang svartid fra serveren, før siden overhovedet begynder at indlæse. Du kan se den i værktøjer som Google PageSpeed Insights eller i fanen Netværk i browserens udviklerværktøjer. En overbelastet delt server, langsomme diske eller forældet software kan gøre selv en let side sløv.

Ustabil drift og uforklarlig nedetid

Hvis hjemmesiden af og til er utilgængelig, og din udbyder ikke kan give en klar forklaring, har du et problem. Google besøger din side hele døgnet. Rammer crawleren gentagne gange fejl på serveren, kan det påvirke, hvor ofte og hvor grundigt dit site gennemgås. Samtidig mister du besøgende og i en webshop direkte omsætning.

Forældet teknik

Kører dit webhotel stadig gamle versioner af PHP, som ikke længere får sikkerhedsopdateringer, eller kan du ikke vælge nyere versioner, vokser både sikkerhedsrisikoen og risikoen for kompatibilitetsfejl med WordPress, WooCommerce og andre systemer. Tjek også, om du kan få gratis SSL-certifikat, dagligt backup-system og HTTP/2 eller nyere protokoller. Det er i dag basale forventninger.

Prisen stemmer ikke med ydelsen

Mange udbydere lokker med en lav introduktionspris, der stiger markant ved fornyelse. Sammenlign, hvad du reelt betaler om året, med, hvad du får: lagerplads, antal mailkonti, backup, support og ressourcer. Betaler du mere for mindre end det, markedet tilbyder, er det et godt argument for at skifte.

Supporten svarer langsomt eller upræcist

Det er først, når noget går galt, at du opdager, hvor god supporten er. Tager det dage at få svar, eller får du standardsvar, der ikke løser problemet, er det et tegn på, at du er blevet en nummer i køen.

Webhotellet begrænser din vækst

Hvis du løber tør for plads, ikke kan oprette flere mailkonti eller støder på loft for ressourcer, når der kommer travlhed i webshoppen, bliver webhotellet en flaskehals. Det gælder især, hvis du kører kampagner, hvor trafikken pludselig stiger.

Kobler du det til SEO, er pointen klar: Google har i flere år vægtet brugeroplevelse og sidehastighed, blandt andet gennem Core Web Vitals. Et webhotel er ikke den eneste faktor, men det er en af de få, du ikke kan optimere dig ud af, hvis serveren i bunden er for svag.

Det går typisk galt ved et skifte, og sådan undgår du besværet

De fleste frygter nedetid og tabt mail, og frygten er berettiget. Det er sjældent selve flytningen af filer, der er problemet. Fejlene opstår i detaljerne omkring. Her er de klassiske faldgruber.

DNS-skift på det forkerte tidspunkt

DNS fortæller internettet, hvilken server dit domæne peger på. Når du ændrer indstillingerne, tager det tid, før ændringen er slået igennem alle steder. I den periode kan nogle besøgende ramme den gamle server og andre den nye. Skifter du DNS, før den nye server er klar, rammer besøgende en tom eller defekt side. Det er den hyppigste årsag til synlig nedetid. Løsningen er at teste færdig, før du peger domænet.

Mail der forsvinder i overgangen

Mail er den mest underkendte del af et webhotelskift. Skifter du DNS og dermed MX-records, før mailkonti er oprettet på den nye server, bouncer indgående mails, eller de havner i en ukendt postkasse. Selv når kontiene er oprettet, er den gamle mail ofte stadig kun på den gamle server. Uden en egentlig kopi af indholdet mister du historikken i dine indbakker, sendte mails og mapper.

Manglende eller ufuldstændige filer og databaser

Ved selvflytning kopierer mange kun mappen med hjemmesidens filer og glemmer databasen. Andre overser skjulte filer som .htaccess, der styrer omdirigeringer, eller store uploadmapper, hvor overførslen er blevet afbrudt halvvejs. Resultatet er ødelagte billeder, manglende sider eller en hjemmeside, der slet ikke kan forbinde til sin database.

Konfigurationer, der ikke følger med

Absolutte stier i konfigurationsfiler, forskellige PHP-versioner, manglende PHP-udvidelser, planlagte opgaver (cron jobs) og SSL-certifikater er ting, der ikke følger automatisk med. En webshop kan fx stoppe med at sende ordrebekræftelser, fordi mailudsendelsen peger på den gamle server.

Opsigelse af det gamle webhotel for tidligt

Den dyreste fejl er at opsige det gamle abonnement, før den nye løsning er verificeret. Når kontoen er slettet, er filerne ofte væk for altid. Behold derfor det gamle webhotel i en periode efter flytningen.

Sådan slipper du for besværet

Har du ikke tid eller teknisk erfaring til selv at stå for det hele, er der en genvej. Mange udbydere tilbyder i dag gratis flytning af hjemmeside som en del af købet af et nyt webhotel. Det betyder, at udbyderens teknikere overtager det arbejde, hvor fejlene typisk opstår: overførsel af filer og databaser, oprettelse af mailkonti og test, før noget går live.

Hos Megahost foregår det fx i tre trin. Du bestiller et webhotel og får en velkomstmail med et link til flytteformularen. Herefter flytter de hjemmeside, serverindhold, webshops og mailkonti fra din gamle udbyder inden for 14 dage. Til sidst tester de, og du tjekker selv, at alt er, som det skal være, før siden lægges online. Det er netop den rækkefølge, en sikker flytning bør have. Tilbuddet er gratis, når du samtidig køber et webhotel til de almindelige priser, og det kan ikke kombineres med andre rabatter. Det gælder webhoteller, der i dag ligger på en Linux-server. Er du i tvivl om, hvad din nuværende udbyder kører, kan du skrive navnet til info@megahost.dk og få det afklaret.

Uanset hvem du vælger, bør du sikre dig, at flytningen omfatter både hjemmeside, databaser og mail, at du får lov at godkende, før DNS ændres, og at du ved, hvem der tager sig af DNS-skiftet.

Forberedelse: det skal du have styr på, før du rører ved noget

En god flytning vindes i forberedelsen. Brug en time på at kortlægge, hvad der faktisk ligger hos din nuværende udbyder. Det er dét, mange glemmer, fordi webhotellet har fungeret i årevis uden, at nogen har kigget under motorhjelmen.

Lav en inventarliste

• Domæner: Hvor er domænet registreret? Det er ofte ikke samme sted som webhotellet. For .dk-domæner administreres det via din registrator, og DK Hostmaster står for selve registret.
• DNS-zone: Hvem styrer DNS? Skriv alle eksisterende records ned: A, CNAME, MX, TXT (SPF, DKIM, verificeringer til fx Google) og eventuelle underdomæner.
• Hjemmeside og CMS: Hvilket system kører du (WordPress, Joomla, tilpasset kode), og i hvilken version? Hvilken PHP-version bruger siden?
• Databaser: Hvor mange har du, og hvilke bruges af hvad?
• Mailkonti: Alle adresser, aliaser, videresendelser, autosvar og kapaciteten på hver postkasse. Noter også, hvor mange der bruger IMAP, og hvor mange der bruger POP3.
• Webshop: Betalingsgateway, fragtintegrationer, regnskabssystem og andre tjenester, der kalder din server.
• Planlagte opgaver: Cron jobs, automatiske backups, nyhedsbreve og lignende.
• SSL: Certifikatet skal genudstedes på den nye server.

Tag en fuld backup, og gem den et andet sted

Selv om du aldrig har brug for den, er en fuld backup af filer, databaser og mail din livline. Hent den ned lokalt eller til en ekstern lagringstjeneste, så den ikke afhænger af den gamle udbyder. Tjek, at backuppen faktisk kan åbnes og indeholder det forventede.

Kontrollér aftalen med den gamle udbyder

Læs betingelserne: Hvad er opsigelsesvarslet, og hvornår ophører abonnementet? Der kan være binding eller varsler, som betyder, at du skal opsige i god tid. Husk, at du ofte skal opsige aktivt. Flytter du til en ny udbyder, ophører den gamle ikke automatisk.

Tænk på persondata

Indeholder dit site eller din webshop persondata om kunder, er du dataansvarlig, og dit webhotel er databehandler. Sørg for en databehandleraftale med den nye udbyder, og spørg, hvor data fysisk opbevares. Datatilsynet har vejledning om databehandlere og dataansvarliges pligter. Er du i tvivl om dine forpligtelser, så få rådgivning.

Trin for trin: sådan flytter du uden nedetid

Her er en gennemprøvet rækkefølge, hvis du selv står for flytningen. Følger udbyderen din flytning, bør den foregå efter samme logik.

1. Bestil det nye webhotel, men lad domænet pege på det gamle. Du har nu to servere, og besøgende ser stadig den gamle.
2. Sænk TTL på dine DNS-records. TTL (time to live) bestemmer, hvor længe DNS-oplysninger gemmes rundt omkring. Sæt den lavt ca. et døgn før skiftet, så ændringen slår hurtigere igennem, når du peger domænet om.
3. Kopiér filerne. Brug SFTP eller SSH, hvis det er muligt, frem for almindelig FTP, og kontrollér, at alle filer, også skjulte, er med. For store sites er rsync over SSH ofte mere pålideligt end at trække alt ned og op igen.
4. Eksportér og importér databasen. Opret en ny database og bruger hos den nye udbyder, importér dump-filen, og ret forbindelsesoplysningerne i konfigurationen (i WordPress i wp-config.php).
5. Tilpas konfigurationen. Vælg samme eller en kompatibel PHP-version, aktivér nødvendige udvidelser, og kontrollér, at .htaccess eller serverregler er på plads.
6. Test den nye server, før domænet peger på den. Du kan bruge en midlertidig adresse fra udbyderen eller ændre din lokale hosts-fil, så netop din computer ser den nye server under det rigtige domænenavn. Klik rundt: forside, underside, formularer, søgning, login, kurv og checkout.
7. Flyt mailkonti og mailindhold (se næste afsnit), og test dem, før MX-records ændres.
8. Sæt webshoppen i en kort pause, hvis den er aktiv. Det forhindrer, at ordrer lander i den gamle database, mens du har kopieret den nye. Tag en frisk database-kopi lige før skiftet.
9. Peg domænet om. Enten ved at ændre A-records og MX-records i den eksisterende DNS-zone, eller ved at skifte nameservers hos domæneregistratoren. Det første giver mest kontrol og er ofte det sikreste, fordi du kan flytte én record ad gangen.
10. Overvåg i dagene efter. I en overgangsperiode kan nogle brugere stadig ramme den gamle server. Hold den derfor i drift, og tjek, at ingen nye ordrer eller formularer havner dér.
11. Opsig det gamle webhotel først, når alt er verificeret, og du har en frisk, gemt backup.

Tidspunktet betyder også noget. Vælg et tidspunkt med lav trafik, fx sent aften eller en stille ugedag, og undgå perioder med kampagner, udsalg eller deadline for regnskab, hvor en fejl koster mest. Hvor lang tid en ny hjemmeside eller en flytning kan tage, afhænger af kompleksiteten. Er du i tvivl om tidsplanen for større projekter, kan Hvor lang tid tager det at få en ny hjemmeside? give et overblik over, hvilke faser der typisk er involveret.

Mail uden tab: sådan sikrer du, at intet forsvinder

Mail er virksomhedens hverdag. Mister du indgående henvendelser i en weekend, mister du måske kunder. Derfor fortjener mail sin egen plan.

Opret konti og kopiér indholdet

Opret alle mailkonti, aliaser og videresendelser hos den nye udbyder, før du ændrer MX-records. Er kontiene sat op med IMAP, ligger mailen på serveren, og den skal kopieres dertil. Det kan ske med et værktøj, der synkroniserer fra én IMAP-server til en anden (fx imapsync), eller ved at trække mapper over i en mailklient som Outlook eller Thunderbird, der er forbundet til begge konti. Brugere med POP3 har måske kun mail liggende lokalt på computeren. Her er der ikke noget at flytte på serveren, men det er værd at få bekræftet.

Planlæg MX-skiftet

MX-records fortæller, hvor mail til dit domæne skal leveres. Når du skifter dem, vil nogle afsendere i en periode stadig levere til den gamle server. Derfor skal begge servere køre, og du bør efter skiftet synkronisere indbakkerne igen for at fange mails, der landede hos den gamle udbyder under overgangen. Med lav TTL bliver overgangsperioden kortere.

Husk SPF, DKIM og DMARC

Disse TXT-records dokumenterer, at mails fra dit domæne er legitime. Skifter du server uden at opdatere dem, risikerer dine udgående mails at havne i spam eller blive afvist. Spørg den nye udbyder, hvilke SPF-oplysninger og DKIM-nøgler der skal bruges, og indsæt dem i DNS. Bruger du eksterne tjenester til nyhedsbreve, CRM eller fakturering, skal de fortsat være godkendt i din SPF-record.

Opdatér mailklienter og mobiler

Medarbejdernes programmer skal måske have nye servernavne, porte og krypteringsindstillinger. Lav en kort vejledning og test på mindst én computer og én telefon, før du giver besked til alle. Hvis du ikke sender samtidig fra to servere, undgår du dobbelt arbejde med at finde sendte mails.

Test begge retninger

Send en mail fra en ekstern adresse (fx Gmail) til hver central adresse, og svar tilbage. Tjek også, at kontaktformularer på hjemmesiden afleverer mails til de rigtige modtagere, da de ofte bruger serverens egen mailfunktion.

Webshop og dynamiske sider kræver ekstra omhu

En statisk informationsside kan flyttes forholdsvis enkelt. En webshop har flere bevægelige dele, og her koster fejl rigtige penge.

• Ordrer midt i flytningen: Ordrer, der lægges i den gamle database, mens du tester den nye, forsvinder ved skiftet. Planlæg et kort tidsvindue, hvor du tager en frisk database-kopi og straks efter peger domænet om. Alternativt kan du midlertidigt lukke for ordrer.
• Betalingsløsning: Betalingsudbydere sender ofte kald tilbage til din server (callbacks), og nogle kræver, at serverens IP-adresse godkendes. Kontrollér det, og test en rigtig betaling eller en testbetaling.
• Integrationer: Regnskabsprogram, lagersystem, fragtmodul og prissammenligninger kan være sat op mod din gamle server eller mod IP-adresser. Gennemgå dem én for én.
• Automatiske mails: Ordrebekræftelser, glemt adgangskode og kvitteringer skal ankomme, og ikke havne i spam. Test dem.
• Sikkerhed: Sørg for, at SSL-certifikatet er aktivt, så hele checkout kører på https uden advarsler om blandet indhold.

Skifte webhotel og SEO: sådan undgår du at miste placeringer

Et webhotelskifte påvirker ikke i sig selv dine placeringer negativt. Faktisk kan en hurtigere og mere stabil server hjælpe. Men fejl under flytningen kan skade, især hvis siden er nede, når Google kommer forbi, eller URL’er pludselig ændrer sig.

Hold URL-strukturen uændret

Dine sider skal ligge på præcis de samme adresser som før. Kontrollér permalinks, trailing slashes og omdirigeringer i .htaccess. Ændrer du URL’er, skal du sætte 301-omdirigeringer op fra de gamle til de nye.

Undgå at blokere Google ved en fejl

Under testen af den nye server aktiverer mange en indstilling, der beder søgemaskiner om ikke at indeksere siden, fx "Afskrækker søgemaskiner fra at indeksere dette websted" i WordPress, eller en robots.txt med Disallow: /. Glemmer du at fjerne den, når siden går live, forsvinder du fra Google. Det er en af de mest almindelige og dyre fejl. Tjek robots.txt og noindex-tags, før og efter skiftet.

Hold øje med crawlfejl

Google Search Console viser, om Google har problemer med at hente dine sider, og om serveren svarer korrekt. Kig på rapporten over sideindeksering og crawlstatistik i dagene efter skiftet. Opstår der pludselig serverfejl eller en stigning i 404-fejl, er det et tegn på, at noget ikke blev flyttet korrekt.

Hold SEO-indsatsen kørende

Mens du flytter, skal du ikke stoppe resten af dit arbejde, men du bør vente med større ændringer af indhold og struktur, til flytningen er stabil. Så kan du se tydeligt, hvad der skyldes skiftet, og hvad der skyldes noget andet. Hvis du overvejer, hvor du skal bruge din indsats efter skiftet, kan E-mail marketing eller SEO: hvad skal du satse på først hjælpe dig med at prioritere.

Det skal du selv tjekke efter flytningen

Også hvis udbyderen har gennemført flytningen, er det klogt selv at kontrollere resultatet, før du opsiger det gamle webhotel. Her er en praktisk tjekliste.

Hastighed og performance

• Test forsiden, en kategoriside og en produkt- eller artikelside i Google PageSpeed Insights. Sammenlign med dine målinger fra før flytningen, hvis du har dem.
• Tjek serverens svartid og Core Web Vitals. Se, om svartiden er faldet.
• Prøv siden fra mobil på mobilnet, ikke kun fra dit kontor.
• Kontrollér, at cache, komprimering og billedoptimering stadig fungerer, da de kan afhænge af serverindstillinger.

Mail

• Send og modtag fra alle vigtige adresser, og tjek, at mails ikke havner i spam.
• Kontrollér, at gamle mails i indbakke og mapper er til stede.
• Test automatiske mails fra hjemmesiden og webshoppen.
• Bekræft SPF, DKIM og DMARC med et online mailtest-værktøj.
• Tjek, at videresendelser, aliaser og autosvar virker.

Funktioner og indhold

• Gennemgå siderne manuelt, og se efter manglende billeder, ødelagte layouts og døde links.
• Test formularer, søgefunktion, login, kurv og betaling.
• Kontrollér, at SSL-certifikatet er gyldigt, og at alle sider vises uden advarsler.

SEO og placeringer

• Tjek Google Search Console for serverfejl, 404-sider og indekseringsproblemer.
• Indsend sitemap’et igen, og kontrollér, at robots.txt ikke blokerer noget ved en fejl.
• Følg dine vigtigste søgeord i en rank-tracker i de følgende uger. Små udsving er normale, men et vedvarende fald bør undersøges.
• Kør en crawl af sitet med et værktøj som Screaming Frog for at finde omdirigeringsfejl og ødelagte links.

Oprydning og afslutning

• Sæt TTL tilbage til et normalt niveau.
• Tag en ny backup fra det nye webhotel, og kontrollér, at automatiske backups kører.
• Behold det gamle webhotel i en periode, og opsig det først, når alt er bekræftet.
• Dokumentér den nye opsætning: loginoplysninger, DNS-records og kontaktinformation til support.

Ofte stillede spørgsmål

Hvor lang tid tager det at skifte webhotel?

Det afhænger af størrelsen og kompleksiteten. En lille hjemmeside kan være flyttet på få timer, mens en stor webshop med mange mailkonti kræver mere forberedelse og test. Hvis du bruger en flytteservice, oplyser udbyderen typisk en frist. Hos Megahost sker flytningen inden for 14 dage, og du godkender, før siden går live. Selve DNS-skiftet slår normalt igennem i løbet af nogle timer, men det kan i nogle tilfælde tage længere.

Kan jeg skifte webhotel uden nedetid?

Ja, hvis du kører gammelt og nyt webhotel parallelt, tester den nye løsning grundigt og først derefter peger domænet om. Med lav TTL og et passende tidspunkt kan overgangen foregå, uden at besøgende mærker det. En kort periode kan nogle brugere dog se den gamle version, så begge servere skal være i drift under skiftet.

Mister jeg mine mails, når jeg skifter webhotel?

Ikke hvis du opretter kontiene på forhånd, kopierer indholdet og først derefter ændrer MX-records. Husk at synkronisere igen efter skiftet, så du får mails med, der nåede den gamle server i overgangen. Opdatér også SPF, DKIM og DMARC, så dine udgående mails ikke havner i spam.

Påvirker et webhotelskifte mine placeringer i Google?

Det behøver det ikke at gøre. Holder du URL’erne uændrede, undgår du at blokere søgemaskiner med noindex eller robots.txt, og er siden tilgængelig under hele flytningen, er risikoen lille. Et hurtigere og mere stabilt webhotel kan i bedste fald forbedre brugeroplevelsen og dermed gavne dine SEO-resultater. Følg Google Search Console tæt de første uger.

Hvad skal jeg gøre med mit gamle webhotel, når flytningen er færdig?

Behold det i en periode, til du har kontrolleret hjemmeside, webshop, mail og SEO på den nye server, og du har en frisk backup. Opsig det derefter aktivt hos den gamle udbyder, og tjek opsigelsesvarsel og betingelser, så du ikke betaler for en periode, du ikke bruger.