Serviceaftale til WordPress: Hvad bør være inkluderet?

En WordPress-hjemmeside passer sjældent sig selv ret længe ad gangen. Den kan godt køre i måneder uden at nogen rører den, men det er netop dér, risikoen vokser stille og roligt: opdateringer hober sig op, et plugin får en sårbarhed, eller en ændring et andet sted gør, at noget pludselig ikke længere virker.

Som marketingansvarlig i en B2B-virksomhed har du typisk brug for ro. I praksis betyder det, at hjemmesiden skal være stabil, sikker og til at stole på, også når I har travlt med kampagner, messer, nyheder og salgsaktiviteter. En serviceaftale handler derfor mindre om “ekstra” og mere om at få drift gjort til en fast rutine med klare rammer.

Hvorfor serviceaftalen bør være en del af jeres faste drift

WordPress er et økosystem: WordPress-systemet, tema og plugins udvikler sig hele tiden. Når man venter for længe med opdateringer, bliver opgaven tungere, og sandsynligheden for kompatibilitetsfejl stiger. Det er sjældent én stor ting, der vælter læsset. Det er summen af små ting.

En serviceaftale er en måde at få styr på ansvar og rytme:

• Hvem reagerer når noget går ned?
• Hvor hurtigt?
• Hvad er “inkluderet”, og hvad er et særskilt projekt?

Når det er aftalt på forhånd, bliver der færre interne afklaringer, og I kan lettere rapportere status til ledelse og kolleger uden at skulle forklare teknik hver gang.

Hvad en god WordPress-serviceaftale typisk dækker

En serviceaftale kan være skruet sammen på mange måder, men de solide byggesten går igen. Før du sammenligner priser, er det en god idé at få overblik over, hvilke områder aftalen faktisk tager ansvar for.

Typisk vil du se disse elementer gå igen:

• Opdateringer (WordPress-system, tema, plugins)
• Sikkerhedskopi og gendannelse
• Sikkerhedstjek og scanning
• Monitorering af oppetid
• Performance og basisoptimering
• Support og responstid
• Rapportering og dokumentation
• GDPR og adgangsforhold

Nedenfor går jeg dem igennem, trin for trin, med fokus på det, der giver jer stabilitet og tryghed.

Opdateringer: Mere end “klik og håb”

Opdateringer er fundamentet. Ikke fordi nye versioner er spændende, men fordi de retter fejl, forbedrer kompatibilitet og retter sårbarheder.

Det vigtigste, du kan kigge efter i en serviceaftale, er ikke om der “opdateres”. Det er hvordan, der opdateres.

En ansvarlig proces ligner ofte dette:

1. Opdateringer planlægges i en fast kadence (ugentlig er almindeligt).
2. Ændringer testes, inden de publiceres.
3. Hvis noget går galt, er der en plan for rollback eller fejlretning.

Staging (en testkopi af hjemmesiden) er en fordel på hjemmesider med mange integrationer, specialfunktioner eller formularflows, hvor en lille fejl kan koste leads. På mere simple hjemmesider kan man ofte teste via en fast tjekliste på hjemmesiden, hvis risikoen er lav og backuppen er solid.

Sikkerhedskopi og gendannelse: Det, der redder jer, når noget “går i stykker”

Sikkerhedskopier er kun værdifulde, hvis de kan gendannes hurtigt og korrekt. Derfor bør aftalen beskrive både backup-hyppighed, opbevaring og selve gendannelsesprocessen.

Når I vurderer en aftale, så spørg konkret:

• Hvor ofte tages backup?
• Opbevares den eksternt (off-site), så den ikke ryger med, hvis serveren kompromitteres?
• Hvor langt går man tilbage (retention)?
• Hvad er forventet tid til gendannelse, hvis uheldet er ude?

Her er en mere simpel måde at sammenligne niveauer på:

Hvis jeres hjemmeside er tæt koblet på drift, leadgenerering eller kampagner, er daglig backup svært at komme udenom. Ikke fordi alt går galt ofte, men fordi I får ro, når det en dag gør.

Sikkerhed: Forebyggelse og tidlig varsling

Sikkerhed i WordPress er en kombination af opdateringer, scanning og løbende opsyn. Det er helt normalt, at Marketing sidder med ansvaret for hjemmesiden, men sikkerhed kræver en rutine, der ikke afhænger af, om nogen “lige har tid”.

En serviceaftale bør derfor indeholde konkrete kontroller, ikke bare en generel formulering om “sikkerhed”.

Her er eksempler på indhold, der typisk giver værdi:

• Malware-scanning: Fast scanning (daglig eller ugentlig) og håndtering ved fund af malware
• Firewall/WAF: Filtrering af kendte angrebsmønstre, før de rammer WordPress
• Login-beskyttelse: Begrænsning af loginforsøg, 2FA, og passende adgangsroller
• Sårbarhedsoverblik: Reaktion når et plugin har en kendt sårbarhed
• Hændelseslog: Mulighed for at se, hvad der er sket, hvis noget ser forkert ud

Det er også værd at få afklaret, om aftalen inkluderer oprydning efter et angreb, og hvad “oprydning” betyder i praksis. Nogle aftaler dækker gendannelse fra backup, andre dækker fuld rens og gennemgang.

Oppetid og performance: Overvågning, der giver jer forvarsel

Oppetidsovervågning lyder simpelt, men detaljen er frekvens og respons. Der er stor forskel på at få en alarm hvert minut og at opdage et nedbrud mange timer senere.

I en B2B-kontekst er det sjældent nødvendigt med døgnovervågning for alle. Til gengæld er det en fordel, at nogen hurtigt opdaterer, hvis hjemmesiden er nede, så I ikke selv skal opdage det via en kollega eller kunde.

Performance er tilsvarende. En serviceaftale kan ikke love “hurtigste hjemmeside”, men den bør tage hånd om det basale:

• Caching og cache-helbred
• Billedstørrelser og tunge sider
• Databaseoprydning, hvis det er relevant
• Simple hastighedstjek og trend over tid

Det vigtigste er stabilitet: At hjemmesiden føles ens at bruge, og at langsomhed ikke sniger sig ind, uden at nogen reagerer.

Support og responstid: Det, der afgør jeres hverdag

Support er ofte det punkt, der skaber mest frustration, hvis det ikke er tydeligt beskrevet. Her er det ikke nok at se ordet “support” i aftalen. Du skal kunne læse:

• Hvornår kan I kontakte support (åbningstid)?
• Hvilke kanaler (mail, telefon)?
• Hvad er responstiden?
• Hvad regnes som kritisk?

En praktisk måde at tænke det på er “alvorlighed”. En kritisk fejl er, at hjemmesiden er nede, eller at kontaktformularen ikke virker. En mindre fejl kan være en visningsfejl på en underside eller et spørgsmål til en tekstblok.

Hvis aftalen også indeholder inkluderet tid til småopgaver, så få afklaret grænserne: Indholdsrettelser, billedudskiftning, opsætning af nye landingssider, sporing, cookie-banner, og den slags. Det er ikke alt, der bør ligge i drift, men det kan give god ro at have en lille fast buffer.

Rapportering og dokumentation: Noget du kan sende videre internt

Månedlig rapportering virker måske som “papirarbejde”, men for Marketing er det ofte dét, der gør det nemt at skabe opbakning.

En god rapport er kort og konkret:

• Hvad er opdateret?
• Er der fundet sikkerhedshændelser?
• Har der været nedetid?
• Er der anbefalinger eller risici, I bør tage stilling til?

Dokumentation er også jeres historik. Når nogen i virksomheden spørger “hvad skete der sidste måned, da siden var langsom?”, er det rart at kunne svare roligt og faktuelt.

GDPR: Databehandleraftale og praktiske detaljer

Hvis leverandøren har adgang til jeres WordPress-admin, logfiler, formularindsendelser eller brugerdata, er der typisk tale om databehandling. Så bør der være en databehandleraftale på plads (GDPR art. 28), og I bør få beskrevet de tekniske og organisatoriske foranstaltninger.

Det behøver ikke være tungt, men det skal være tydeligt:

• Adgangsstyring (roller, 2FA)
• Hvem der kan tilgå hvad
• Hvordan backup opbevares
• Hvordan I håndterer sletning, hvis en person beder om det
• Hvem der opdaterer cookie-løsning og privatlivstekster, når jura eller setup ændrer sig

Mange B2B-hjemmesider indsamler færre data end webshops, men kontaktformularer og tracking er stadig persondata i praksis. Derfor giver det mening at have GDPR som et fast punkt i driften.

Sådan vurderer du, hvilket niveau I har brug for

Det er fristende at vælge ud fra pris, men det giver bedre ro at vælge ud fra risiko og afhængighed: Hvor meget betyder hjemmesiden for jeres pipeline, og hvor hurtigt skal I kunne reagere?

Her er en enkel proces, du kan bruge internt:

1. Kortlæg kritiske funktioner (kontaktformular, booking, leadflow, integrationer).
2. Vurder konsekvens ved nedbrud (timer, en dag, flere dage).
3. Vælg backup- og monitoreringsniveau ud fra konsekvensen.
4. Aftal responstid og eskalering, så I ved hvem der gør hvad.
5. Aftal rapportering, så du kan følge med uden at bruge unødig tid.

Når du har de fem punkter på plads, bliver det lettere at læse en serviceaftale og se, om den passer til jeres virkelighed.

Hvad der ofte ikke er inkluderet, og som bør stå tydeligt

Det skaber tryghed, når begrænsninger er skrevet klart. Ellers opstår der typisk misforståelser midt i en travl uge.

En serviceaftale dækker ofte drift og vedligehold, men ikke nødvendigvis:

• Ny funktionalitet og større designændringer
• Udvikling af specialplugins
• Omfattende SEO-arbejde og indholdsproduktion
• Oprydning i et meget tungt plugin-landskab uden for aftalt scope
• Større tracking-opsætninger og server-side tagging
• Flytning mellem hostingmiljøer, hvis det ikke er en del af aftalen

Der er ikke noget galt i, at de ting ligger udenfor. Det vigtige er, at det står sort på hvidt, og at der er en enkel måde at tilkøbe hjælp på, når behovet opstår.

Onboarding: start rigtigt, så driften bliver stabil

En god serviceaftale starter sjældent den dag, abonnementsbetalingen starter. Den starter med en kort teknisk gennemgang.

Det er her, man får ryddet op i det, der ellers giver støj senere: Gamle plugins, uklar adgangsstyring, manglende licenser, og uklare ejerskaber af domæne og hosting.

Jeg plejer at tænke onboarding som tre enkle trin:

Først adgang og sikkerhed (roller, 2FA, hvem ejer hvad).

Så backup, monitorering og opdateringsrutine.

Til sidst en fast måde at kommunikere på, så du ved, hvor du sender en fejl, og hvad du kan forvente af svar.

En enkelt sætning, som ofte gør en stor forskel, er: “Hvem har det sidste ord, når der skal tages tekniske beslutninger?” Det er rart at have afklaret, før der står en situation.

Når noget går galt: Beredskab uden uro

Der kommer en dag, hvor noget ikke virker. Det er ikke et tegn på, at nogen har gjort noget forkert. Det er et vilkår ved et system, der består af mange dele.

Det, der adskiller en tryg drift fra brandslukning, er beredskabet:

• I ved, at der findes en ny backup.
• I ved, hvem der reagerer.
• I ved, hvad der sker først (stop skade, gendan drift, forklar årsag bagefter).

Hvis du vil gøre det helt konkret i jeres team, kan du gemme en kort “driftskontakt” internt: Link til status, supportmail, og hvem der skal informeres, hvis hjemmesiden er nede. Det giver ro, også når du ikke selv er på kontoret.