Onboarding af nyt kundesite: tjeklisten før du overtager ansvaret

Kort svar: Når du skal overtage et WordPress-site, starter du med en komplet, urørt kopi af filer og database, før du ændrer noget. Derefter kortlægger og rydder du op i adgange, laver en teknisk gennemgang med et kort tilstandsnotat til kunden og får aftalerne på plads (vedligehold, databehandleraftale og ejerskab). Den første måned bruger du på at flytte sitet ind i dine faste rutiner og sende den første rapport. Så er du ansvarlig for sitets fremtid – ikke for dets fortid.

Fagligt gennemgået: 2. oktober 2026

Det mest sårbare tidspunkt i et driftssamarbejde er dag ét. Du overtager et site, du ikke kender, med en historik, ingen har fortalt dig om – og fra nu af bliver alt, der går galt, betragtet som “dit”. En fast onboarding-tjekliste flytter dig fra håb til viden.

Tjeklisten herunder virker, uanset om sitet kommer fra kunden selv, fra en freelancer eller fra et andet bureau. Den tager typisk et par timer for et almindeligt site og noget længere for en webshop med mange integrationer.

Før du ændrer noget: Opdatér ikke plugins, skift ikke tema og ryd ikke op, før du har en komplet kopi af både filer og database liggende et sted, som kun du har adgang til. Alt, du ændrer før det tidspunkt, kan ikke længere skelnes fra den tilstand, du overtog.

1. Nulpunktet: kopi og baseline

Tag en komplet kopi (filer og database), og gem den urørt. Den er dit bevis for, hvordan sitet så ud, da du overtog det, og dit faldbæk, hvis noget går galt i starten. Gem kopien uden for den nuværende hosting – hvis hostingaftalen opsiges, forsvinder backups dér ofte med den.

Tag samtidig baseline-målinger: svartid (TTFB), Core Web Vitals, oppetid, placeringer på de vigtigste søgeord og antal fejl i error-loggen. Så kan du senere dokumentere din effekt i månedsrapporterne i stedet for blot at påstå den.

Nulpunktet er også forventningsafstemning: kunden skal kunne se, at gamle problemer er arv og ikke dit værk – og kopien beviser det. Har du SSH-adgang, kan WP-CLI give dig et hurtigt øjebliksbillede, som du gemmer sammen med kopien:

wp core version
wp core verify-checksums
wp plugin list --fields=name,status,version,update
wp theme list
wp user list --role=administrator --fields=ID,user_login,user_email
wp db export nulpunkt-$(date +%F).sql

wp core verify-checksums sammenligner kernefilerne med de officielle filer fra WordPress.org og afslører ændrede eller ukendte kernefiler – et tidligt tegn på, at sitet har været kompromitteret eller “lappet” direkte i koden.

2. Adgange: overblik og oprydning

Kortlæg alle adgange: WordPress-brugere (hvem er administrator – og hvorfor?), hosting og kontrolpanel, domæne og DNS, betalings- og fragtkonti, analyseværktøjer, Search Console, mailsystem og eventuelle SFTP- eller SSH-brugere. Typiske fund er tidligere medarbejdere, gamle bureauer og “test”-brugere med fulde rettigheder.

Oprydningen følger altid samme mønster:

• Luk konti, som ingen længere bruger – efter aftale med kunden.
• Nedgradér brugere, der har flere rettigheder end deres opgave kræver.
• Aktivér totrinslogin (2FA) på alle administratoradgange.
• Skift adgangskoder og API-nøgler, som den tidligere leverandør har kendt.
• Læg alle adgange i en kodeords-manager efter principperne i guiden til adgangsstyring.

Afklar også med kunden, hvem der fremover må ændre i produktion. Driftsansvar uden ændringskontrol er en fælde – det er en af de forudsætninger, vedligeholdelsesaftalen skal gøre tydelig.

3. Den tekniske gennemgang

Lav en systematisk runde, og notér resultatet punkt for punkt. Tabellen herunder er en god minimumsliste:

Område	Hvad du kontrollerer	Typisk fund
Versioner	WordPress, PHP, tema og plugins – og hvor langt bagud de er	PHP-version uden sikkerhedsopdateringer; sitet bør køre PHP 8.3 eller 8.4
Plugins	Inaktive, forladte eller dobbelte plugins	Tre plugins til det samme, ét uden opdateringer i årevis
Sårbarheder	Kendte sårbarheder i installerede versioner	Sårbart plugin, der ikke er opdateret
Backup	Findes den, hvor ligger den, og kan den gendannes?	Backup på samme server – eller slet ingen
SSL og domæne	Certifikatets fornyelse, domænets udløb og ejerskab	Domænet står i en tidligere ansats navn
Mail	Formularer, SPF, DKIM og DMARC	Kontaktformularen sender fra en adresse uden SPF
Cache og hastighed	Cachelag, billedstørrelser og tunge scripts	To cache-plugins oven i hinanden
Webshop	Testkøb, ordremails, betalings- og fragtintegrationer	Callback fra betalingsgateway fejler

Kontrollér især SSL og certifikatfornyelse, mail-leverbarhed og – for shops – en fuld testkøbsrunde. En forældet PHP-version er ofte det mest kritiske enkeltfund: opgraderingen skal planlægges og testes på staging, fordi gamle plugins kan fejle på PHP 8.x.

Tilstandsnotatet til kunden

Resultatet samles i et kort tilstandsnotat: her står sitet, her er de tre vigtigste risici, og det her anbefaler vi først. Hold det på én til to sider og skriv i kundesprog – “betalingsmodulet er tre år bagud og har en kendt sårbarhed” siger mere end en liste med versionsnumre.

Notatet er både forventningsafstemning og din første synlige leverance. Lad kunden bekræfte modtagelsen skriftligt, fx med et kort svar på mailen. Så er der ingen tvivl om, hvad der var arv, hvis en af de nævnte risici senere bliver til et problem.

4. Aftalerne og forventningerne

Før driften starter, skal tre aftaler være på plads: vedligeholdelsesaftalen underskrevet, databehandleraftalen indgået og ejerskabet af domæne, hosting og indhold bekræftet.

Hold desuden én forventningssamtale: hvad kan kunden forvente hvornår (svartider, driftsvinduer, hvad der er inkluderet), og hvad forventer du (én kontaktperson, ændringer via jer, besked før kampagner med meget trafik)?

Overtager du fra et andet bureau, hører guiden til det nedarvede site til her – inklusive den diplomatiske del. Du behøver ikke tale forgængeren ned; tilstandsnotatet taler for sig selv.

5. Dokumentationssiden fra dag ét

Opret sitets dokumentationsside, mens du har overblikket frisk. Den skal mindst indeholde: hvor sitet hostes, hvem der ejer domænet, hvilke integrationer der findes (betaling, fragt, regnskab, nyhedsbrev), hvor backup ligger, særlige plugins eller tilpasninger og kontaktpersoner hos kunden.

Opret samtidig en ændringslog, hvor første linje er “overtaget pr. dato, nulpunktskopi gemt”. Den side er det, der gør, at en kollega – eller dig selv om et år – kan tage over uden arkæologi.

6. De første 30 dage

Når tjeklisten er i hus, begynder arbejdet med at gøre sitet til dit ansvar i praksis. Brug den første måned på disse ting:

1. Flyt sitet ind i dit standardmiljø, hvis det er aftalt – flyt det uden nedetid. WordPress hosting hos Hostious inkluderer gratis migrering.
2. Luk de kritiske fund fra tilstandsnotatet: opdateringsefterslæb, manglende overvågning og åbenlyse sikkerhedshuller.
3. Sæt sitet ind i din centrale overvågning og opdateringsrytme, så det følger samme proces som resten af porteføljen.
4. Test, at backup kan gendannes – ikke kun at den bliver taget.
5. Send den første rapport med før/efter-tal: det overtog vi, det har vi gjort, det anbefaler vi som det næste.

Kunden har lige skiftet leverandør og er ekstra opmærksom. Den første måned afgør, om skiftet føles som en lettelse eller som mere af det samme. Afstem derfor forventningerne én gang til: hvad ligger i aftalen, hvad koster ekstra, og hvem kontakter hvem, når noget haster?

Sæt til sidst en kalenderaftale med dig selv på dag 30: er alle punkter fra tjeklisten lukket, er dokumentationssiden skrevet, og har kunden fået den første rapport? Først når de tre ting er på plads, er onboardingen færdig, og sitet er en del af den almindelige drift.

Læs også

• Hub: For bureauer og freelancere
• Det nedarvede site: håndtér teknisk gæld fra det forrige bureau
• Adgangsstyring i teams: roller, 2FA og deling uden fælles kodeord
• Flyt et kundesite uden nedetid
• Offboarding: sådan afleverer du et kundesite ordentligt
• Bureau hosting til WordPress og WooCommerce – samlet drift af kundesites hos Hostious

Ofte stillede spørgsmål om at overtage et WordPress-site

Hvad er det vigtigste første skridt?

En komplet, urørt kopi af filer og database, før du ændrer noget. Den er dit nulpunkt, dit faldbæk og dit bevis for, hvad der var arv.

Skal jeg påtage mig ansvar for gamle fejl?

Nej. Tilstandsnotatet dokumenterer arven og adskiller den fra dit arbejde. Du er ansvarlig for sitets fremtid, ikke dets fortid – forudsat at kunden har fået notatet.

Hvor lang tid tager en ordentlig onboarding?

Selve tjeklisten tager typisk 1–3 timer for et almindeligt site. Indflytning i dit standardmiljø og lukning af kritiske fund planlægges over den første måned.

Hvad gør jeg, hvis den tidligere leverandør ikke vil udlevere adgange?

Start med det, kunden selv ejer: domænet hos registratoren, hostingkontoen og administratoradgangen til WordPress. Har kunden ikke adgang til de tre, skal det løses først, fordi alt andet afhænger af dem.