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

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år | Opgave | Formål |
|---|---|---|
| Dagligt (5–10 min.) | Gennemgå alarmer, backupstatus og sikkerhedsscanninger | Alt, 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 sites | Forudsigelig drift; aldrig om fredagen |
| Månedligt | Månedsrapporter samles, skrives og sendes på én gang | Synliggør arbejdet over for kunden |
| Kvartalsvis | Gennemgang af porteføljen: tidsforbrug, aftaler og teknisk gæld | Find 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:
- Opdatér aldrig hele porteføljen i ét hug. Kør testsites først og vent mindst et døgn med resten.
- Hav en fast plan for tilbagerulning: backup taget lige før driftsvinduet, og en beskrevet fremgangsmåde for at rulle en opdatering tilbage.
- Notér hændelsen i driftsloggen på alle berørte sites, og skriv en kort opsamling bagefter, så samme fejl ikke rammer igen.
- 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å
- Hub: For bureauer og freelancere
- Din standardopsætning: en genbrugelig base for nye WordPress-sites
- Vedligeholdelsesaftalen: hvad den skal indeholde, og hvad den må koste
- Staging som standard: en ændringsproces, kunderne kan stole på
- Bureau hosting til WordPress og WooCommerce – samlet hosting af kundesites hos Hostious
- WordPress serviceaftale – opdateringer og vedligeholdelse, når du ikke selv vil stå for driften
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.
Udgivet 2. september 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026
