Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
[email protected]
Bureau og freelance 7 min. læsning Opdateret 3. oktober 2026

Drift af 20+ kundesites: værktøjer og rutiner, der skalerer

Drift af kundesites i skala: standardopsætning, centralt dashboard, faste driftsvinduer og dokumentation pr. site – 20+ WordPress-sites på timer om ugen.

Drift af 20+ kundesites: værktøjer og rutiner, der skalerer

Kort svar: Fra omkring 10 kundesites knækker håndholdt drift: opdateringer tager dage, overblikket bor i hovedet, og ét glemt site bliver til én hacket kunde. Skalerbar drift står på fire ben: én standardopsætning, ét centralt værktøj til opdateringer og overvågning, faste driftsvinduer med test først og dokumentation pr. site, så enhver på holdet kan tage over. Målet er drift målt i timer om ugen – ikke i dårlig samvittighed.

Fagligt gennemgået: 2. oktober 2026

Tyve sites, der hver „bare lige“ skal opdateres, tjekkes og holdes i live, er et fuldtidsjob – eller en eftermiddag om ugen, afhængigt af systemet bag. Denne guide beskriver systemet: standardisering, centrale værktøjer, rytmen og dokumentationen, der gør 20+ kundesites til rolig rutinedrift.

Guiden er skrevet til freelancere og mindre bureauer, der er vokset fra en håndfuld sites og mærker, at driften begynder at æde tiden til nye projekter.

Vigtigt: Indfør ét ben ad gangen. Starter du med at flytte alle sites til et nyt dashboard, ny hosting og ny opdateringsrytme samme uge, bliver det svært at se, hvad der giver fejl, når noget går galt.

1. Standardisér: færre varianter, færre fejl

Kompleksiteten i en portefølje er ikke antallet af sites – det er antallet af forskelle. Fem page buildere, tolv formularplugins og tre cache-løsninger giver hundredvis af kombinationer, der kan gå i stykker på hver sin måde.

Definér din standardopsætning – én builder, ét formularplugin, ét SEO-plugin, én cache-løsning og én sikkerhedsopsætning – og kør alle nye projekter på den. Arvede sites konverteres gradvist, når der alligevel skal laves en større opgave, eller de får en afvigelsesnote, så forskellen i det mindste er kendt (se guiden om det nedarvede site).

Standarden er ikke kun plugins. Den dækker også:

  • PHP-version: hold porteføljen på en aktuel, understøttet version (i dag PHP 8.3 eller 8.4) og planlæg skiftet samlet, når en ny version er moden.
  • Brugere og roller: samme navngivning af bureauets administratorkonti og totrinslogin på dem alle.
  • Backup og overvågning: samme opsætning på alle sites, så du ved, hvor du skal kigge, når noget fejler.
  • Licenser: premium-plugins samlet på bureauets konti, så fornyelser ikke afhænger af den enkelte kunde.

2. Det centrale værktøj

Fra få sites og op er et administrationsværktøj nødvendigt: et værktøj som MainWP eller ManageWP, eller hostingplatformens egen flersidestyring. Du får ét dashboard med alle sites, versioner, opdateringsstatus og oppetid. Så er „hvilke sites kører den sårbare plugin-version?“ et opslag – ikke en eftermiddag med klikken rundt.

Kombinér dashboardet med central overvågning af både oppetid og funktioner som formularer og checkout, og brug WP-CLI til masseoperationer (se WP-CLI for begyndere). Et eksempel på et typisk WP-CLI-tjek på tværs af sites:

wp plugin list --update=available --fields=name,version,update_version
wp core verify-checksums
wp plugin verify-checksums --all

Saml også hostingen, hvor det giver mening. Tyve sites hos tyve udbydere er tyve supportnumre, tyve kontrolpaneler og tyve forskellige backupløsninger. Jo færre platforme, desto færre ting at holde styr på – og desto hurtigere kan du hjælpe en kunde, når noget går galt.

Det vigtigste krav til værktøjerne er dækning: alle sites skal være med. Det site, der ikke står i dashboardet, er netop det, der bliver glemt i en opdateringsrunde.

3. Rytmen: driftsvinduer og kadence

Ugerytme for drift af mange kundesites: sikkerhedsopdateringer straks, øvrige i fast driftsvindue efter test, månedlig rapport

Fast rytme slår ad hoc. En opdeling, der fungerer for mange:

  • Sikkerhedsopdateringer håndteres straks. Automatiske opdateringer på patch-niveau for WordPress-kernen og udvalgte plugins er en stor hjælp.
  • Øvrige opdateringer samles i ét ugentligt driftsvindue – først på dine egne sites eller testsites, dagen efter på porteføljen, så fejlbehæftede udgivelser fanges, før kunderne mærker dem.
  • Større spring som en ny hovedversion af WooCommerce eller en ny PHP-version planlægges pr. site med test på staging.

Efter hvert vindue bør en automatisk stikprøve tjekke det vigtigste: loader forsiden, svarer kontaktformularen, og kan der lægges en vare i kurven? Det er hurtigere og mere pålideligt end manuel gennemklikning.

Rytmen er også kundekommunikation. „Opdateringer sker tirsdage“ lyder professionelt; „når vi når det“ gør ikke.

4. Ugens og månedens rytme

Skalerbar drift er i sidste ende en kalender. En rytme, der fungerer for mange bureauer:

HvornårOpgaveFormål
Dagligt (5–10 min.)Gennemgå alarmer, backupstatus og sikkerhedsscanningerAlt, der kræver handling, bliver til en opgave – ikke til improvisation
Ugentligt (fast dag, fx tirsdag formiddag)Opdateringer i batch fra dashboardet, derefter stikprøver på kritiske sitesForudsigelig drift; aldrig om fredagen
MånedligtMånedsrapporter samles, skrives og sendes på én gangSynliggør arbejdet over for kunden
KvartalsvisGennemgang af porteføljen: tidsforbrug, aftaler og teknisk gældFind de sites, der koster mere, end de indbringer

Rytmen gør to ting på én gang: Den fjerner beslutningstrætheden („hvad skal jeg lave nu?“), og den gør driften målbar. Du ved, hvad en uge koster, og kan prissætte derefter.

Beskyt rytmen, som var den en kundeaftale. Akutte sager må naturligvis bryde den, men „kan du ikke lige“-opgaver må ikke. De samles op og køres på de faste dage – ellers ender ugen som én lang afbrydelse, og du er tilbage, hvor du startede: travl, men uden overblik.

5. Dokumentation pr. site

Lav én side pr. kunde ud fra en fast skabelon. Den bør indeholde:

  • Hosting og adgange – selve adgangskoderne ligger i password-manageren, aldrig i dokumentet.
  • Særlige plugins og afvigelser fra standardopsætningen.
  • Integrationer og hvor deres nøgler administreres.
  • Kontaktpersoner hos kunden og aftaleniveau.
  • Driftsloggen: hvad blev ændret hvornår (se ændringsloggen).

Formålet er stedfortræder-testen: Kan en kollega overtage sitet i morgen uden at ringe til dig? Det er samtidig dit beredskab ved offboarding – og en stor del af det, kunden reelt betaler for: at sitet ikke afhænger af én persons hukommelse.

6. Når noget går galt på tværs af porteføljen

Jo flere ens sites du har, desto større er risikoen for, at én fejl rammer mange på én gang – en plugin-opdatering med en fejl, en udløbet licens eller en ændring hos en tredjepartstjeneste. Standardisering gør porteføljen nemmere at drive, men også mere sårbar over for fælles fejl. Derfor:

  1. Opdatér aldrig hele porteføljen i ét hug. Kør testsites først og vent mindst et døgn med resten.
  2. Hav en fast plan for tilbagerulning: backup taget lige før driftsvinduet, og en beskrevet fremgangsmåde for at rulle en opdatering tilbage.
  3. Notér hændelsen i driftsloggen på alle berørte sites, og skriv en kort opsamling bagefter, så samme fejl ikke rammer igen.
  4. Kommunikér samlet: Er flere kunder ramt, så send én klar besked med status og forventet løsning frem for at svare enkeltvis.

7. Økonomien i skalerbar drift

Regn på timeforbruget pr. site pr. måned før og efter systematiseringen. For standardsites falder det typisk mærkbart, og det er marginen i dine vedligeholdelsesaftaler: et forudsigeligt månedligt beløb ind og en faldende omkostning pr. site ud.

Reinvestér noget af gevinsten i porteføljens svageste sites – de arvede og de afvigende. Det er dem, der æder beredskabstid. Og mål det vigtigste tal: hændelser pr. måned på tværs af porteføljen. Når det falder, mens antallet af sites stiger, har du bevist, at driften skalerer.

Læs også

Ofte stillede spørgsmål om drift af kundesites

Hvilket værktøj skal jeg bruge til mange sites?

Et centralt dashboard som MainWP, ManageWP eller hostingens flersidestyring, kombineret med central overvågning og WP-CLI til masseoperationer. Det vigtigste er, at alle sites er med i det.

Skal alle kundesites opdateres samtidig?

I samme rytme, men forskudt: testsites først og porteføljen dagen efter. Sikkerhedsopdateringer håndteres dog straks.

Hvor mange sites kan én person drifte?

Det afhænger af sitenes kompleksitet og aftalerne. Håndholdt drift bliver typisk uoverskuelig ved 10–15 sites, mens standardopsætning, centralt værktøj og fast rytme kan flytte grænsen betydeligt – så bliver support og projekter flaskehalsen, ikke selve driften.

Hvad skal dokumentationen for et kundesite indeholde?

Hosting og adgange (henvisning til password-manageren), afvigelser fra standardopsætningen, integrationer, kontaktpersoner, aftaleniveau og en driftslog. Testen er, om en kollega kan overtage sitet uden at spørge dig.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 2. september 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026