Vedlikehold av WordPress-nettsider

WPPoland (Mariusz Szatkowski) er vedlikehold av WordPress: daglige sikkerhetskopier, oppdateringer først i testmiljø, oppetidsovervåking hvert 1. til 5. minutt, hele døgnet. WordPress siden 2006, fjernarbeid fra Gdynia. Skriftlig tilbud etter kort brief.

#Vedlikehold av WordPress

Vedlikehold av et WordPress-nettsted er fast teknisk arbeid som avgjør om nettstedet virker, laster raskt og ikke sprer skadevare. Et nettsted uten oppdateringer samler opp sårbarheter i utvidelsene, og et nettsted uten en testet sikkerhetskopi kan miste bestillinger og fakturaer ved den første feilen hos webhotellet.

Et WordPress-nettsted går som regel ned av mange små ting ingen hadde tid til å se på: et varsel fra sikkerhetsutvidelsen som ble dempet i fjor, en utvidelse som er låst på en gammel versjon fordi den nye knakk noe i kassen, en sikkerhetskopi som har lyst grønt i to år uten at noen har prøvd å gjenopprette den. Vedlikehold er å ta disse tingene etter en plan, før de havner på samme fredag ettermiddag.

Ved overtakelser og flytting av hele oppsettet før første vedlikeholdsmåned, start med en WordPress migrasjonsvurdering. Etter flyttingen bør butikken ligge på en Store Reliability Plan, så overvåking og oppdateringer er tydelig avtalt. Er kassen allerede nede, start med WooCommerce rescue sprint før fast vedlikehold. Avgrensede revisjoner og vanskelige rettinger hører hjemme hos en WordPress-spesialist.

Jeg gjør vedlikeholdet på fjernarbeid, så bedrifter i Oslo, Bergen, Trondheim, Stavanger og resten av landet får det samme omfanget. Når nettstedet allerede er nede, trenger du reparasjon og teknisk støtte for WordPress i stedet for en fast avtale.

#Hva vedlikehold av WordPress omfatter

Vedlikeholdet består av noen faste arbeidsoppgaver. Hver av dem har en egen side med en grundig beskrivelse.

Kjerne, utvidelser og temaer oppdaterer jeg hver uke, først i testmiljøet og etter en full sikkerhetskopi, og etter oppdateringen sammenligner jeg skjermbilder fra før og etter endringen. Overgang til en nyere PHP-versjon er også med. Hovedversjoner av utvidelser går jeg gjennom hver måned, listen over utvidelser hvert kvartal. Tidsplanen, hvordan én runde foregår og hva jeg gjør når en oppdatering ødelegger noe, beskriver jeg på siden om WordPress-oppdateringer.

Overvåkingen skanner filene etter skadevare og passer på filintegriteten. Skjer det et innbrudd, jobber jeg i en fast rekkefølge: bevis, diagnose, opprydding på en kopi, nye passord, forespørsel om ny vurdering hos Google. Detaljene og pliktene overfor Datatilsynet står på siden om å fjerne skadevare fra WordPress. En grundig engangsvurdering av sikkerheten får du med en sikkerhetsrevisjon av WordPress.

Prisspenn for bedriftsnettsted og nettbutikk, hva som ligger i månedsprisen og hva jeg fakturerer separat, har jeg samlet på siden vedlikehold av WordPress, pris.

I vedlikeholdet måler jeg Core Web Vitals hver måned og passer på at resultatet ikke faller. En avgrenset forbedring av hastigheten gjør jeg som hastighetsoptimalisering av WordPress.

Målte tall for én adresse, før vi snakker om omfang, får du med WordPress nettstedsjekk.

#Slik starter vedlikeholdet

#Hvordan foregår ukentlig WordPress-vedlikehold?

Hver dag, uavhengig av tidsplanen, lages det en sikkerhetskopi, og overvåkingen sjekker oppetiden hvert 1. til 5. minutt og passer på filene.

#Hvorfor er WordPress-vedlikehold viktig?

Den første grunnen er sikkerhet. WordPress er det CMS-et flest angriper fordi flest bruker det, men tallene på angrep som sirkulerer på nettet, har sjelden en kilde som lar seg kontrollere, så dem gjentar jeg ikke. Hver utdaterte utvidelse eller hvert tema med en publisert sårbarhet er en mulig angrepsvei. Jevnlige oppdateringer stenger kjente hull før noen rekker å bruke dem.

Den andre grunnen er ytelse. Et nettsted som ikke blir fulgt opp, samler unødvendige data i databasen og laster ressurser det ikke trenger. Jevnlige målinger viser fallet før kundene merker det.

Den tredje grunnen er personvern. Lekker kundeopplysninger ved et innbrudd, har eieren av nettstedet som behandlingsansvarlig plikter etter personopplysningsloven og GDPR, blant annet å melde avviket til Datatilsynet uten ugrunnet opphold og om mulig innen 72 timer. Begynner nettstedet å spre skadevare, merker Google det med en advarsel, og ifølge Google tar vurderingen etter oppryddingen fra noen dager til noen uker. Dette beskriver jeg nærmere på siden om å fjerne skadevare fra WordPress.

Den fjerde grunnen er kostnaden. Reparasjon etter et innbrudd eller gjenoppretting av data etter en feil hos webhotellet koster som regel mer enn fast vedlikehold, og kommer alltid på det verst tenkelige tidspunktet.

#Oppdateringer og sikkerhet

Sikkerhetsteamet i WordPress gir ut rettinger for sårbarheter som blir oppdaget, men en retting virker først når den er kommet ut på nettstedet ditt. Ifølge sikkerhetsteamets side er bare den nyeste versjonen av WordPress offisielt støttet. Et nettsted som står flere versjoner bak, kan bli stående uten retting.

Oppdateringene i vedlikeholdet går alltid i samme rekkefølge. Først en full sikkerhetskopi av database og filer, så oppdatering i testmiljøet, altså en kopi av nettstedet ditt, og test av de viktigste funksjonene. Etter oppdateringen sammenligner jeg skjermbilder av utvalgte undersider fra før og etter endringen, fordi en funksjonstest ikke merker en layout som har falt fra hverandre. Først når testen er bestått, går endringen til produksjon, og de neste 24 timene følger jeg ekstra med. Går noe galt, går jeg tilbake til forrige versjon fra kopien. Det var i testmiljøet WP Rocket 3.23.2.2 ble prøvd før WordPress 7.1, se WP Rocket, fatal feil i WordPress 7.1 og Cloudflare.php.

Kritiske sikkerhetsrettinger venter ikke på den ukentlige syklusen. De går først, samme vei gjennom testmiljøet, og det nøyaktige vinduet for dem skriver jeg inn i tilbudet. Om sårbarheter får jeg vite fra sårbarhetsdatabaser, blant annet WPScan og Patchstack.

#Hvordan sjekke at en WordPress-sikkerhetskopi kan gjenopprettes?

Om en sikkerhetskopi virker, vet du først når du har gjenopprettet den. UpdraftPlus, BlogVault og øyeblikksbildene hos webhotellet lager alle filer som ligger i en bøtte og ser friske ut helt til dagen de trengs. Derfor gjenoppretter jeg jevnlig en ekte sikkerhetskopi i en sandkasse, logger inn, klikker meg gjennom, kjører wp db check og bekrefter at nettstedet kommer opp igjen. Rapporten viser tilstanden til kopiene og datoen for siste prøvegjenoppretting.

Kopiene lages daglig og inkrementelt, lagres i skyen utenfor serveren til nettstedet og oppbevares i minst 30 dager. En inkrementell kopi lagrer bare endringene siden forrige kopi, så den belaster ikke serveren, men lar deg gå tilbake til flere tidspunkter. Det betyr noe når et problem blir oppdaget først etter noen dager.

Jeg følger 3-2-1-regelen med én kopi utenfor serveren. Utenfor serveren betyr en annen leverandør i en annen jurisdiksjon enn webhotellet, og aldri den samme kontoinnloggingen. Ligger nettstedet på et norsk webhotell, går kopien til en uavhengig nordisk eller europeisk leverandør med egen databehandleravtale. Databasen gjenoppretter jeg adskilt fra wp-content/uploads, slik at innhold kan rulles tilbake uten at brukerkontoer og bestillinger rulles tilbake til forrige tirsdag.

Etter et innbrudd gjenoppretter jeg en kopi først når jeg har sjekket når infeksjonen startet: en kopi fra forrige uke hjelper ikke hvis den skadelige koden har ligget på nettstedet i en måned.

#Ytelse og database

Hastigheten påvirker opplevelsen for brukerne og plasseringen i søkeresultatene, fordi Google ser på Core Web Vitals. I vedlikeholdet måler jeg dem hver måned. Faller resultatet, leter jeg etter årsaken: en ny utvidelse, større bilder, en database som vokser.

Tilstanden til databasen vurderer jeg ut fra størrelsen, spørretidene og tabellstrukturen. Jeg ser blant annet på transienter, utkast, foreldreløse metadata, manglende indekser og hvor mye som lastes automatisk fra wp_options. En eldre utvidelse som lagrer køen sin i options, kan få svartiden på serveren til å krype oppover over måneder uten at nettstedet ser ødelagt ut. Data sletter jeg først når det er bekreftet at applikasjonen ikke trenger dem.

Hurtigbufferlagene velger jeg etter arkitekturen: hurtigbuffer for sider, objekter og nettleser trengs ikke alltid samtidig. Ved behov setter jeg opp CDN og bildeoptimalisering. Effekten av hver endring sammenligner jeg med en grunnmåling. Store endringer i tema eller sidearkitektur ligger utenfor vedlikeholdet; der starter jeg med hastighetsoptimalisering av WordPress.

#Overvåking, teknisk SEO og rapport

Mange av de tekniske faktorene Google tar hensyn til, avhenger av tilstanden på nettstedet: hastighet, HTTPS, riktige kanoniske adresser, XML-nettstedskart og robots.txt. I vedlikeholdet sjekker jeg at nytt innhold blir indeksert, og at Search Console ikke viser indekseringsfeil eller spor av spam etter et innbrudd.

Et infisert nettsted kan få en advarsel i Googles søkeresultater. Derfor sjekker jeg sikkerhetsvarsler, HTTPS og at sertifikatet er gyldig. Tar webhotellet seg av fornyelsen av sertifikatet, sjekker jeg også at den automatikken virker.

Den tekniske rapporten viser status for oppdateringer, oppetid, ytelse og indekseringsfeil. Den har en liste over tiltak, men erstatter ikke en innholdsstrategi eller en egen SEO-tjeneste.

#Drift av WooCommerce

En nettbutikk trenger mer enn oppdateringer. WooCommerce og betalingsutvidelsen, for eksempel Vipps MobilePay, oppdaterer jeg hver for seg innenfor samme uke, med test av hele kjøpet etter hver av dem, uten å legge inn en ekte bestilling. Da er det klart med en gang hvilken endring som eventuelt knakk noe.

Fra 1. januar 2027 skal norske bokføringspliktige utstede elektronisk faktura ved salg til andre bokføringspliktige, og frem til 2030 gjelder det i praksis når kjøperen kan motta i Peppol. Butikken lager ikke EHF-en selv, så den kommer fra en utvidelse, en fakturatjeneste eller regnskapssystemet, slik jeg beskriver i artikkelen om EHF-faktura i WooCommerce. Etter en oppdatering av en slik kobling sender jeg en testfaktura i leverandørens testmiljø. Koblinger mot ERP og CRM tester jeg i testmiljøet før endringen går ut; arkitekturen beskriver jeg i guidene om integrasjon mellom WooCommerce og ERP og API-first-utvikling med WordPress.

En butikk der hver salgsdag teller, drifter jeg på Store Reliability Plan, og en butikk med en handlekurv som ikke virker, først i en WooCommerce rescue sprint. Hvordan en butikk kan få tilbake ytelsen uten ombygging, viser en anonymisert casestudie av en WooCommerce-butikk.

#Hvilke verktøy brukes til WordPress-vedlikehold?

For mange nettsteder samtidig bruker jeg ManageWP eller MainWP, avhengig av hvordan webhotellene er satt opp. Sikkerhetskopier med kontroll utenfor serveren går via BlogVault og UpdraftPlus til en separat S3-kompatibel bøtte i en annen nordisk eller europeisk jurisdiksjon, alltid med egen databehandleravtale. Wordfence og Sucuri tar seg av filintegritet og skanning etter skadevare, og varslene går til en kanal et menneske faktisk leser. New Relic eller Better Uptime kjører syntetiske sjekker mot adressene som betyr noe (innlogging, kasse, betalingsretur, de viktigste landingssidene), ikke bare forsiden. WP-CLI er det daglige verktøyet for resten: wp db search-replace ved flytting mellom domener, wp option update for opprydding, wp transient delete --all etter endringer i oppsettet og wp cron event run når hurtigbufferen hos webhotellet har overstyrt planlagte oppgaver.

#Vedlikehold av løsninger som ikke går på WordPress

Mange bedrifter har en løsning på et annet system ved siden av WordPress, eller hele nettstedet utenfor WordPress. Jeg drifter også slike løsninger, etter samme prinsipp: kopi, testmiljø, tester, publisering i et vindu, plan for tilbakerulling.

• Drupal: sikkerhetsoppdateringer med Composer og Drush, overganger mellom versjoner, egne moduler. Drupal 10 mister sikkerhetsstøtten 9. desember 2026, som jeg beskriver i artikkelen om Drupal 10 og slutt på støtte.
• TYPO3: sikkerhetsoppdateringer, overgang til nye LTS-versjoner, utvidelser i Extbase og Fluid.
• Laravel: feilrettingsversjoner i produksjon i løpet av noen dager, sammen med oppdatering av Composer-avhengighetene, alltid på en testserver først.
• Symfony: oppgradering fra eldre versjoner, integrasjonslag mellom WordPress eller WooCommerce og ERP, CRM eller PIM.

Vedlikehold av et slikt system priser jeg etter en revisjon, fordi omfanget avhenger av versjon, antall moduler og hvem som har ansvaret for serveren. Når det ikke lenger lønner seg å holde liv i et gammelt system, vurderer vi overgang til WordPress, for eksempel fra TYPO3.

#Vedlikehold ved siden av migrering, integrasjoner og revisjoner

Vedlikeholdet holder i drift det som allerede virker. Trenger nettstedet en større endring, gjør jeg den som et eget prosjekt med eget tilbud, og etterpå går nettstedet tilbake til vanlig vedlikehold.

Flytting av WordPress til en annen server omfatter kopi, overføring av database og filer, endring av DNS og kontroll etter publisering. Trenger nettstedet en annen arkitektur, gjør jeg en migrering til Next.js eller Astro. Nye integrasjoner mot ERP, CRM, betaling eller EHF er egne prosjekter; i vedlikeholdet passer jeg på at de eksisterende fortsatt virker etter oppdateringer.

Nettsteder som må dokumentere at de følger EU- og EØS-krav, starter med en revisjon: universell utforming etter WCAG, Core Web Vitals eller vurdering av NIS2 og DORA. Vedlikeholdet holder deretter resultatet av revisjonen ved like.

#Hvordan fungerer WordPress-vedlikehold for 5 til 10 nettsider med én eier?

Flere nettsteder, én eier, én ansvarlig. Slik legger jeg det opp:

• Vi starter med ett ark: hvor hvert nettsted ligger, hvem som har innloggingen til webhotell og domene, og hvilke nettsteder som er nettbutikker.
• Omfanget skrives per nettsted. En WooCommerce-butikk trenger annen oppfølging enn en enkel presentasjonsside.
• Timegrense og responstid står i tilbudet som konkrete tall, aldri som “det kommer an på”.
• Et Multisite-nettverk prises individuelt, som resten av porteføljen.
• Prisspennene står på siden vedlikehold av WordPress, pris og i prisoversikten. Prisen for porteføljen din får du i tilbudet etter en kort brief.

#Hva er med i WordPress-vedlikehold, og hva er ikke med?

#Hvordan fungerer timegrense og responstid?

Utviklertimer har en månedlig grense som settes i tilbudet, sammen med satsen for timer over grensen. Tallet står ikke her, fordi det avhenger av hvor mange nettsteder du har og hva slags de er. Ubrukte timer overføres ikke til neste måned. Arbeid utenfor omfanget får et eget tilbud og starter når du har bekreftet det.

Overvåkingen går døgnet rundt. Jeg reagerer på virkedager i arbeidstid (CET). Reaksjon betyr diagnose og plan, uten garantert responstid eller reparasjonstid. Vedlikeholdet reduserer risikoen for innbrudd, men gir ingen garanti for at nettstedet aldri blir hacket. Ansvaret mellom partene står i avtalen.

#Hva bør du spørre en vedlikeholdsleverandør om?

Tre spørsmål skiller leverandørene som holder ut, fra dem som forsvinner etter første hendelse. Når gjenopprettet dere sist en sikkerhetskopi på ekte, og ikke bare sjekket at den finnes? Hva skjer når en oppdatering tar ned produksjon en lørdag kveld: hvem ser varselet, og hvor lang tid tar det å rulle tilbake? Kan jeg se en anonymisert eksempelrapport? Er svarene vage, er arbeidsrutinene bak dem det også. Skal du bytte leverandør, les hva du bør sjekke når du bytter leverandør av vedlikehold.

#Slik jobber jeg med kode

All kode jeg rører i vedlikeholdet, ligger i versjonskontroll: rettinger i temaet, i utvidelser skrevet for bedriften og i oppsettet. WordPress-kode sjekker jeg mot WordPress Coding Standards med PHP_CodeSniffer og WPCS-reglene, og PHP-kode utenfor WordPress (Laravel, Symfony, Drupal-moduler) etter standarden PSR-12. Statisk analyse med PHPStan fanger feil før de kommer til testmiljøet. Før publisering går jeg gjennom min egen endring en gang til, adskilt fra skrivingen. Etter et år med vedlikehold har nettstedet ditt dermed en endringshistorikk som enhver annen utvikler kan overta.

#Hvem som utfører vedlikeholdet

WPPoland er Mariusz Szatkowski, senior WordPress-utvikler, med WordPress siden 2006. Jeg gjør vedlikeholdet selv: oppdateringer, kopier, overvåking og rapporter gjøres av den samme personen som du avtaler omfanget med, så du slipper å forklare nettstedet på nytt hver gang. Tilbudet skriver jeg etter en kort brief, og den første måneden starter med oppstartsrevisjonen, som er inkludert i prisen for den måneden.

Før vi blir enige om omfang, se på nettstedet selv: WordPress nettstedsjekk henter den offentlige versjonen av én adresse og oppgir målte tall, blant annet forespørslene som blokkerer første opptegning og hva de veier. Svaret kommer med en gang og krever ingen e-postadresse.