Skifte webbureau? Sådan flytter du hjemmesiden uden at miste kontrollen

Selve hjemmesiden er sjældent det sværeste at flytte.

Det er alt det, der hænger fast rundt om den.

Domænet. DNS. Mailen. En Search Console-konto oprettet på en tidligere medarbejders Gmail. Et premium-plugin, som viser sig at køre på bureauets licens. Eller den klassiske: Ingen ved helt, hvem der faktisk har adgang til hostingen.

Det opdager mange først den dag, de vil skifte webbureau.

Så hvis du sidder med spørgsmålet: Kan jeg flytte min hjemmeside til et andet bureau?

Som regel ja.

Men jeg ville ikke starte med at flytte en eneste fil.

Jeg ville starte med at finde nøglerne.

At have betalt for en hjemmeside og at eje alle rettigheder til den er ikke nødvendigvis det samme.

En hjemmeside kan bestå af tekster, billeder, design, kode, temaer, plugins, skrifttyper, integrationer og licenser, som hver især kan være underlagt forskellige aftaler.

Derfor er kontrakten med dit nuværende bureau det første sted, jeg ville kigge.

Se især efter, hvad der står om:

• kildekode og specialudvikling
• design og grafiske elementer
• tekster og billeder
• temaer og plugins
• tredjepartslicenser
• adgang til hosting og database
• hvad der sker, når samarbejdet ophører

Efter ophavsretslovens § 53 kan ophavsrettigheder overdrages helt eller delvist. At du har fået et eksemplar af noget – eller har betalt en faktura – betyder ikke i sig selv, at samtlige ophavsrettigheder automatisk følger med.

For edb-programmer lavet af en medarbejder som led i arbejdet gælder en særregel i § 59, hvor ophavsretten som udgangspunkt overgår til arbejdsgiveren. Men den bestemmelse fortæller ikke i sig selv, hvad en kunde får overdraget fra et eksternt webbureau.

Det afhænger af aftalen.

Og det er den forskel, der er værd at opdage før opsigelsen bliver sendt.

Du kan sagtens have administratoradgang til WordPress uden at kontrollere resten af hjemmesiden.

Et bureau kan eksempelvis eje licensen til et premium-tema. En funktion kan være koblet til bureauets API-konto. Eller hjemmesiden kan ligge på en platform, hvor selve systemet ikke kan flyttes.

I de tilfælde kan du måske tage domænet, teksterne, billederne og dataene med – men ikke nødvendigvis hjemmesiden én til én.

Så bliver et bureauskifte helt eller delvist en genopbygning.

Er aftalen uklar, er det værd at få den læst juridisk, inden der bliver stillet ultimative krav til den gamle leverandør. En halv times afklaring er rarere end at opdage midt i flytningen, at parterne har forstået “ejerskab” på to forskellige måder.

Hos os er udgangspunktet, at kunden ejer hjemmesiden og ikke er bundet til os. Det kan du også læse mere om på siden om professionel hjemmeside uden binding.

Når rettighederne er afklaret, begynder det digitale nøglebundt.

Her er forskellen vigtig:

Det er ikke nok, at dit bureau kan logge ind.

Din virksomhed skal selv kunne komme ind.

Start med domænet. Find ud af, hvor det er registreret, hvilken konto der administrerer det, og hvem der kan ændre oplysningerne.

Find derefter DNS. Det er her, forbindelserne mellem domæne, hjemmeside, mail og flere eksterne tjenester typisk bliver styret.

På hostingen bør virksomheden som minimum vide, hvordan den får adgang til relevante filer og databasen. På en WordPress-hjemmeside bør I have en administratorbruger, der er knyttet til en mailadresse, I selv kontrollerer.

Er der specialudvikling, så spørg også efter dokumentation, kodearkiv og nødvendige adgangsnøgler.

De små ting er ofte dem, der først bliver savnet, når den gamle leverandør ikke længere er med.

Google-konti bliver tit glemt i en hjemmesideoverdragelse, fordi hjemmesiden godt kan fungere uden dem.

Lige indtil man skal bruge dem.

I Google Search Console findes der blandt andet verificerede ejere og delegerede ejere. Jeg vil normalt sikre, at virksomheden selv har mindst én verificeret ejer via en metode og Google-konto, virksomheden kontrollerer.

Det gør det væsentligt lettere at rydde op i gamle adgange senere.

I Google Analytics bør virksomheden have administratoradgang på det relevante konto- eller ejendomsniveau.

Gennemgå samtidig:

Google Tag Manager, Google Ads, Meta, cookieplatform, CDN, formularsystem, SMTP-tjeneste, eventuelle API-tjenester og andre systemer, hjemmesiden sender data til eller modtager data fra.

Du behøver ikke kunne forklare, hvad alle systemerne laver.

Men du skal vide, hvem der har nøglen.

“Vi har backup” kan betyde meget.

Nogle gange betyder det, at nogen engang har installeret et backup-plugin.

Det er ikke helt det samme.

Ved en WordPress-side ville jeg som minimum sikre en kopi af databasen og de relevante hjemmesidefiler, herunder uploads, temaer, plugins og konfiguration.

Jeg ville også gemme den nuværende DNS-zone og dokumentere særlige serveropsætninger, cron-jobs, integrationer og andre ting, som den nye server skal kunne efterligne.

Men den vigtigste prøve er ikke, om backupfilen findes.

Det er, om hjemmesiden kan genskabes fra den.

Den sikreste flytning foregår, før almindelige besøgende opdager noget.

Klargør den nye hosting og test hjemmesiden dér, inden domænet peges om.

Kontrollér blandt andet:

• centrale sider
• billeder og downloads
• login
• formularer
• webshop og betaling, hvis relevant
• tracking
• cookiesamtykke
• eksterne integrationer
• mobilvisning

Hvis siden modtager ordrer, bookinger eller formularhenvendelser, kommer der en ekstra opgave.

Databasen står ikke stille, bare fordi I er ved at flytte.

Hvis du tager en kopi mandag og går live onsdag, kan data fra tirsdag og onsdag ligge på den gamle server. Derfor skal der være en plan for den sidste synkronisering eller et kort kontrolleret tidsrum, hvor der ikke bliver skrevet nye data til den gamle side.

Ellers kan en teknisk vellykket flytning stadig koste en ordre.

Hvis serverdelen stadig føles lidt som et teknikskab uden lys, kan du også læse vores forklaring på hvad hosting betyder for din hjemmeside.

Hjemmesiden og mailen deler ofte domæne.

De deler ikke nødvendigvis leverandør.

Det er her, en lille DNS-ændring kan få overraskende store konsekvenser.

Hvis hjemmesiden flytter til en ny server, mens mailen fortsætter i eksempelvis Microsoft 365 eller Google Workspace, skal mailopsætningen normalt blive ved med at pege samme sted.

Derfor bør hele DNS-zonen dokumenteres eller eksporteres inden flytningen.

Det gælder blandt andet A-, AAAA-, CNAME-, MX- og TXT-poster og relevante poster til SPF, DKIM, DMARC og verifikation af tredjepartstjenester.

Nogle gange.

TTL fortæller DNS-servere, hvor længe et svar må gemmes i cache.

Hvis du ved, at en bestemt DNS-post snart skal ændres, kan en lavere TTL før skiftet gøre overgangen hurtigere.

Hvor tidligt du bør ændre TTL, afhænger af den eksisterende opsætning og DNS-leverandøren. Cloudflare beskriver eksempelvis 24–48 timer før en planlagt migrering og nævner 300 sekunder som en almindelig kort migrations-TTL, mens Googles vejledning til hostingskift anbefaler at planlægge ændringen tidligere.

Pointen er derfor ikke “sæt alt til fem minutter”.

Pointen er at planlægge DNS, før det bliver akut.

Og bagefter kan TTL hæves igen, hvor det giver mening.

Så skal den nye mailplatform gøres klar først.

Opret postkasser, aliaser og nødvendige sikkerheds- og godkendelsesposter. Flyt de eksisterende mails efter mailudbyderens anbefalede metode. Test både afsendelse og modtagelse.

Først derefter skifter du de relevante DNS-poster.

Jeg ville samtidig lade den gamle mailopsætning eksistere i overgangsperioden, indtil det er tydeligt, at den ikke længere modtager noget relevant.

Der er ingen gevinst ved at være hurtigst til at slette det, der virkede i går.

Ikke nødvendigvis.

Men her skal to meget forskellige flytninger skilles ad.

Samme domæne. Samme URL’er. Ny server.

Hvis ditfirma.dk/produkt stadig hedder ditfirma.dk/produkt efter flytningen, har siden ikke skiftet offentlig adresse.

Så skal du normalt ikke lave redirects, bare fordi hostingen eller bureauet ændrer sig.

Google har en særskilt vejledning til netop hostingskift uden synlige URL-ændringer.

Opgaven er i stedet at:

klargøre og teste den nye hosting, ændre DNS, overvåge den gamle og nye server og først lukke den gamle ned, når flytningen fungerer.

Her ville jeg samtidig kontrollere, at ingen indstillinger fra testmiljøet er kommet med ud på den levende side.

Et glemt noindex kan være en meget lille tekststreng med et meget stort efterspil.

Kontrollér derfor blandt andet:

• HTTP-statuskoder
• robots.txt
• noindex-indstillinger
• canonical-tags
• XML-sitemap
• interne links
• tracking
• Search Console

Nye URL’er eller nyt domæne

Så bliver opgaven en anden.

Hvis gamle URL’er forsvinder, bør de kortlægges til de mest relevante nye adresser.

Google anbefaler permanente serverbaserede redirects – typisk 301 eller 308 – fra gammel URL til den endelige nye URL.

Ikke gammel side → mellemstation → ny side.

Direkte er bedre.

Og hvis en gammel produktside får en ny produktside, skal den som udgangspunkt ikke bare sendes til forsiden, fordi det er lettere.

Redirectet skal give mening for den person, der klikker på et gammelt link.

Google anbefaler desuden at beholde redirects efter en flytning i mindst ét år. For brugernes skyld kan det give mening at lade dem eksistere længere.

Opdatér samtidig interne links, canonical-tags og sitemap til de nye adresser.

Nyt domæne? Så kommer Search Console også med på flyttelæsset

Hvis hele websitet flyttes fra ét domæne til et andet, kan Search Consoles værktøj til adresseændring bruges som en del af processen.

Det bruges efter, at flytningen og redirects er etableret.

Værktøjet skal derimod ikke bruges ved et almindeligt hostingskift, hvor URL’erne er de samme.

Det skal heller ikke bruges til almindelige stiændringer som:

ditfirma.dk/gammel-side/

til

ditfirma.dk/ny-side/

Her er redirects, sitemap og den øvrige tekniske opsætning det relevante arbejde.

Google beskriver også midlertidige udsving i synlighed som normale ved større websiteflytninger. Det betyder ikke, at enhver trafiknedgang skal accepteres med et skuldertræk.

Det betyder, at du skal kunne skelne mellem forventelig genbehandling og noget, der faktisk er gået i stykker.

WordPress kan kopieres.

Det kan en database også.

Det svære opstår, når ingen helt ved, hvem der ejer hvad.

Når domænet står ét sted, DNS et andet, mail et tredje, og den eneste verificerede ejer i Search Console er en person, der stoppede for halvandet år siden.

Derfor er et godt bureauskifte næsten kedeligt.

Adgangene er kendte. Rettighederne er klare. Backuppen virker. DNS er dokumenteret. Den nye server er testet.

Og på et bestemt tidspunkt bliver trafikken sendt det nye sted hen.

Ikke noget drama.

Bare en række velplacerede flueben.

Når du vælger webbureau, er det oplagt at spørge til design, pris, SEO og tidsplan.

Jeg ville også stille et andet spørgsmål:

Hvad sker der, hvis vi en dag ikke vil arbejde sammen længere?

Kan du tage hjemmesiden med?

Har du adgang til domæne, hosting og data?

Hvad sker der med betalte plugins?

Kan en anden udvikler fortsætte arbejdet?

Det er ikke et negativt spørgsmål.

Det er et voksent spørgsmål.

Hos næmt.nu er 100 % ejerskab og ingen binding en del af den måde, vi sælger hjemmesider på. Hvis en kunde en dag vil videre, skal det være teknikken, der skal flyttes – ikke kunden, der skal forhandle sig til at få sin egen hjemmeside med.

Start ikke med opsigelsen.

Start med et overblik.

Få samlet oplysninger om domæne, DNS, hosting, CMS, database, mail, Search Console, Analytics, Tag Manager og de tjenester, der hænger sammen med hjemmesiden.

Sammenhold det med aftalen.

Så kan et nyt bureau ret hurtigt se, hvad der kan flyttes direkte, hvad der kræver nye licenser, og hvor der mangler en nøgle.

Hvis du står med en hjemmeside, hvor du ikke ved, hvad du ejer, eller hvad der sker med mail og Google, når den bliver flyttet, så send os det, du har.

Vi finder hellere hullerne, før nogen rører DNS.

• Retsinformation – Ophavsretsloven (§ 53 og § 59 er relevante for rettigheder og edb-programmer)
• Google Search Central – skift af hosting uden URL-ændringer
• Google Search Central – flytning med ændrede URL’er eller domæne
• Google Search Central – 301-, 308- og andre redirects
• Google Search Console – ejere, brugere og tilladelser
• Google Search Console – værktøj til adresseændring
• Google Analytics – bruger- og administratoradgang
• Cloudflare – DNS og TTL før en migrering