En gratis migrering lyder enkel, men en god flytning af et WordPress-site handler om mere end at kopiere filer fra ét sted til et andet. Hvis struktur, redirects, DNS og indhold ikke bliver tænkt ind fra start, kan resultatet blive unødige driftsstop, tabt synlighed i Google eller små fejl, der først viser sig flere dage senere.
Det gælder især, når flytningen sker til en ny WordPress-hosting, og når sitet samtidig er vigtigt for salg, leads eller medlemskommunikation. Hostious tilbyder gratis migrering som en del af deres arbejde med WordPress-hosting og relaterede løsninger, men selve processen bliver altid lettere, når ejeren af sitet har styr på de vigtigste oplysninger på forhånd. Hvis du vil supplere denne artikel med praktiske guides, kan du også se Hostious’ vejledninger og fejlfinding eller læse mere på Hostious.io.
Google anbefaler ved større site moves, at man ændrer én ting ad gangen. Det er et klogt princip, også når flytningen “kun” virker som et hosting-skifte. Hvis du både skifter host, domæne, URL-struktur, tema og indhold samtidig, bliver det svært at finde årsagen, hvis noget går galt.
Det giver derfor mening at skille opgaverne ad. Først flyttes sitet stabilt. Derefter kan designændringer, nye landingssider eller større tekniske ændringer planlægges i et roligere tempo.
For mange virksomheder er det også nyttigt at afklare, hvad der faktisk flyttes. Er det kun et WordPress-site? Er det en WooCommerce-shop med ordrer? Er der også e-mail-hosting knyttet til domænet? De spørgsmål har stor betydning for både timing og test.
Før selve flytningen går i gang, er det en fordel at samle oplysningerne i én lille arbejdsplan. Det sparer tid og mindsker risikoen for, at en vigtig detalje bliver glemt.
| Punkt | Hvorfor det er vigtigt | Hvem bør afklare det |
|---|---|---|
| Backup af database og filer | Giver mulighed for gendannelse, hvis noget fejler | Siteejer eller teknisk ansvarlig |
| Adgang til WordPress, domæne og DNS | Uden adgang kan flytningen blive forsinket | Siteejer |
| URL-mapping | Gør redirects og SEO-overgang mere sikker | Teknisk ansvarlig eller SEO-ansvarlig |
| Liste over kritiske funktioner | Sikrer test af formularer, login, checkout og integrationer | Siteejer |
| Plan for e-mail og DNS | Undgår afbrudt mailtrafik ved domæneændringer | Teknisk ansvarlig |
| Tidspunkt for flytning | Mindsker risiko i travle perioder | Siteejer og driftspartner |
Selv en kort tabel som denne gør en stor forskel. Den skaber overblik, og den hjælper alle involverede med at tale om det samme.
WordPress’ egen dokumentation er tydelig på ét punkt: der bør være backup af den gamle database, før man fortsætter. Det er et minimum. En databasebackup alene er dog ikke nok, hvis du vil kunne genskabe hele sitet. WordPress peger også på, at databasebackup ikke omfatter temaer, plugins, uploads eller wp-config.php.
Det betyder i praksis, at en sikker flytning kræver både database og filer. Især billedbibliotek, specialtemaer, uploads og lokale konfigurationsfiler er afgørende. Hvis sitet er gammelt, eller hvis flere personer har arbejdet på det over tid, kan der ligge vigtige filer uden for de mest oplagte mapper.
WordPress bemærker også, at visse plugins kan konflikte med eksportprocesser og give tomme eller delvise eksportfiler. Hvis sitet tidligere har haft problemer med eksport, backup-plugin eller databaseværktøjer, bør det nævnes tidligt.
Når gratis migrering skal gå hurtigt, hjælper det meget at have disse oplysninger klar:
Hvis der skal arbejdes direkte i database, konfiguration eller søg-og-erstat-processer, bør det ske med backup og helst i staging. Det er ikke et sted, man bør improvisere på et aktivt produktion-site.
Hvis flytningen kun handler om ny hosting, og alle URL’er forbliver identiske, er SEO-opgaven som regel mindre. Men så snart domæne, undermapper, permalinks eller sprogstruktur ændres, bliver URL mapping centralt.
Google anbefaler at forberede et map fra gamle URL’er til nye URL’er, før flytningen starter. Det gælder både store sites og mindre WordPress-løsninger. Et godt URL-map er i sin enkleste form en liste, hvor hver gammel adresse peger på sin nye placering.
301 redirects bør bruges ved permanente flytninger. Google behandler dem som et signal om, at redirect-målet bør være den kanoniske version. Samtidig anbefaler Google, at redirects bevares så længe som muligt, ofte mindst ét år. Det er et punkt, mange overser, fordi flytningen føles “færdig”, så snart sitet er online.
SEO-delen handler heller ikke kun om redirects. Hvis sitet bruger canonical-tags, hreflang, XML-sitemaps eller Search Console, skal de dele også stemme med den nye struktur. Hvis ikke, risikerer du blandede signaler til søgemaskinerne.
Efter lanceringen er det værd at kontrollere disse sider og signaler:
Det er ofte på de sider, at fejl giver størst forretningsmæssig effekt.
DNS er den del af flytningen, som mange først tænker på til sidst, selv om det har direkte betydning for, hvor hurtigt ændringer slår igennem. Cloudflare dokumenterer, at en højere TTL kan give flere cachede DNS-svar og dermed hurtigere opslag. Ulempen er, at ændringer også slår langsommere igennem.
Det betyder ikke, at der findes én rigtig TTL til alle flytninger. Det betyder, at timing skal planlægges. Hvis records ændres lige før et vigtigt salgsvindue, eller hvis e-mail også er knyttet til domænet, kan en dårlig plan koste unødig uro.
Der er også forskel på record TTL og ændringer på nameserver-niveau. Hvis hele DNS-opsætningen skal skiftes, kan forløbet se anderledes ud, end hvis der kun justeres enkelte records.
En enkel tommelfingerregel er, at site, DNS og e-mail bør ses som tre forbundne spor. Når kun WordPress-hosting flyttes, er opgaven ofte ret ligetil. Når hele domænet flyttes, kræver det mere koordinering.
Det lyder banalt, men mange flytninger bliver besværlige, fordi forskellige tjenester bliver blandet sammen. Et WordPress-site kan flyttes uden at e-mail nødvendigvis skal flyttes med. En webshop kræver ofte en anden testplan end en almindelig firmaside. Og et webhotel kan indeholde flere funktioner end selve sitet.
Hvis du bruger WooCommerce, skal du tænke bredere end sider og indlæg. Ordrer, kundeprofiler, lagerlogik, betalingsflow, fragtmoduler og transaktionsmails skal kontrolleres. Her er det ofte klogt at planlægge flytningen uden for spidsbelastede tidsrum.
Hvis domænets mail også ligger hos samme leverandør, skal MX-records, SPF, DKIM og eventuelle andre DNS-poster håndteres varsomt. Den del bør være tydeligt afklaret, før nogen trykker på knappen.
Et godt afklaringsmøde før migrering handler tit om disse forskelle:
Det gør det lettere at bestille den rigtige hjælp første gang.
Når sitet er flyttet, er opgaven ikke færdig. Der skal testes systematisk, og det er her mange småfejl bliver fanget, før kunderne gør det.
Start med det vigtigste: kan forsiden loade, kan man logge ind, virker kontaktformularen, og bliver billeder vist korrekt? WordPress’ dokumentation minder om, at billedreferencer i indhold kan være gemt i post_content i wp_posts. Det betyder, at gamle absolutte URL’er kan leve videre inde i indlæg og sider, selv om resten af sitet virker.
Hvis URL’er skal opdateres i stor skala, bør det ske forsigtigt. Værktøjer som wp search-replace kan være nyttige, men bør bruges af en teknisk ansvarlig og helst på staging eller med en frisk backup klar. En forkert søg-og-erstat kan ramme serialized data, plugin-indstillinger eller referencestrukturer på uheldige måder.
SEO-testen bør også være konkret. Tjek at redirects virker, at canonical-tags peger rigtigt, at sitemap kan åbnes, og at Search Console har de korrekte egenskaber registreret. Hvis der er sprogversioner, skal hreflang også gennemgås.
Her er en kort praktisk rækkefølge, som ofte fungerer godt:
Et site kan godt se korrekt ud på overfladen og stadig have fejl under motorhjelmen. Derfor giver det mening at teste både brugeroplevelse, teknik og søgesignaler.
Når du bestiller eller planlægger gratis migrering, bliver processen mere effektiv, hvis du sender et kort samlet overblik i stedet for mange små beskeder. Det gælder især, hvis flere personer er involveret i domæne, indhold og marketing.
Du behøver ikke skrive en lang kravspecifikation. Ofte er et præcist overblik nok til, at den tekniske del kan planlægges rigtigt fra starten.
Det kan være smart at samle dette i én mail eller ét dokument:
Det er sjældent den tekniske kopi af sitet, der er den svære del. Det, der afgør om flytningen føles rolig og professionel, er som regel forberedelsen, koordineringen og testen bagefter.
Når de tre ting er på plads, bliver gratis migrering ikke bare billigere. Den bliver også markant mere tryg.
Gratis migrering og migrering uden nedetid er ikke det samme. Selve kopieringen af filer og database er sjældent det svære. Udfordringen ligger i tidsrummet mellem første kopi og det øjeblik, hvor al trafik rammer den nye server. I det vindue kan nogle besøgende stadig lande på den gamle hosting, fordi DNS-svar ligger i cache hos udbydere og browsere, og samtidig kan der opstå nye ordrer, logins og formularindsendelser, som kun findes på det gamle site.
En flytning uden mærkbar nedetid bygger derfor på tre elementer: parallel drift, hvor gammel og ny platform kører side om side, et kontrolleret trafikskift og en sidste datasynkronisering umiddelbart før skiftet. Bruger du et DNS-lag som Cloudflare, er gennemslagstiden ofte kortere, end du regner med. Cloudflare oplyser, at proxied records som standard har en Auto-TTL på 300 sekunder.
| Model | Sådan virker den | Egner sig til | Svaghed |
|---|---|---|---|
| Simpel kopiering | Sitet kopieres én gang, og DNS peges om | Små blogs og firmasider uden login og betaling | Ingen plan for det, der sker mellem kopi og stabilt DNS-skift |
| Parallel drift (blue/green) | Ny platform bygges og testes, mens den gamle er live; trafikken flyttes, når alt er valideret | Webshops, medlemssites og sites med API-integrationer | Mere arbejde og to miljøer i en periode |
Den store fordel ved parallel drift er, at du kan rulle tilbage. Fejler checkout, login eller en webhook efter skiftet, sendes trafikken tilbage til den gamle platform, mens problemet løses.
Near zero-downtime er realistisk for de fleste WordPress- og WooCommerce-sites, hvis plugin-stack og PHP-version er kendt, integrationer er kortlagt, og du accepterer et kort, planlagt cutover-vindue. Det er mindre realistisk, hvis shoppen kører kampagne, hvis checkout er stærkt tilpasset, eller hvis hosting, e-mail, CDN og domæne flyttes samme dag. Her er “næsten ingen synlig nedetid” den ærlige formulering.
To leverandører kan begge skrive “gratis migrering”, mens kun den ene tager ansvar for hele forløbet. Nogle tilbyder alene en standardimport, hvor sitet kopieres én gang, og du selv står for DNS-skift, validering og fejl i checkout eller webhooks. Brug disse ni krav, når du vurderer et tilbud:
Mangler bare ét punkt, stiger risikoen for, at migreringen er gratis, mens fejltiden bagefter bliver dyr. Hos Hostious er gratis migrering kombineret med daglig backup, staging og dansk support 24/7, hvilket er relevant, når cutover ligger uden for normal arbejdstid.
På en webshop er databasen mere følsom end temaet. Flytningen sker typisk i to faser: en første kopi, hvor filer, database og uploads overføres, mens den gamle butik stadig sælger, og en deltafase, hvor ændringerne siden første kopi overføres. På mindre WooCommerce-sites løses deltafasen ofte med en kort skrivefrys uden for spidsbelastning, så de sidste ordrer og kontodata kan flyttes sikkert.
Undgå at ændre datamodellen midt i flytningen. Skift ikke centrale plugins, tabeller eller checkout-logik, mens migreringen står på. Og husk webhooks: hvis betalingsgateway, ERP eller fragtplatform stadig sender events til den gamle hosting, kan ordrer se korrekte ud på overfladen og alligevel mangle statusopdateringer.
Det nye miljø skal testes som produktion, ikke som en pæn kopi. Åbn sitet via et preview-domæne eller din lokale hosts-fil, så du rammer den nye server uden at flytte offentlig trafik. Gennemfør hele købsrejsen med testbetaling, ordrebekræftelse, e-mail og lageropdatering, og tjek cache-headere og svartider, før du går videre. Har du staging, er det et oplagt sted at køre testen.
Kortlæg samtidig alle DNS-records, ikke kun roddomænet. A, AAAA, CNAME, MX, SPF, DKIM og subdomæner til checkout, app eller staging skal alle med. Når skiftet er gennemført, bør du måle udefra fra flere netværk og ikke kun fra kontoret eller din VPN. Lokale caches kan give et falsk billede af, at alt er slået igennem.
Skjult nedetid opstår som regel efter et vellykket DNS-skift. Forsiden loader, men ordren går ikke igennem. Login virker, men mailen kommer ikke frem. De typiske syndere er:
Modgiften er enkel: følg logs, svartider og ordreforløb de første timer efter go-live, og hold den gamle platform kørende længe nok til, at du kan verificere alt eller rulle tilbage. Det er den forskel, der afgør, om flytningen bliver en rutineopgave eller et driftstab.
