Seks måneder uten
oppdateringer
Du fikk en sikkerhetsvarsling fra hostingleverandøren i forrige uke. Noe om «kritisk sårbarhet». Pluginene har oransje varsler overalt. Byrået som bygde siden svarer ikke på e-post lenger.
Vi ser dette hver eneste måned. Eierne bryr seg, men byrået gikk videre til neste prosjekt for lenge siden. WordPress vedlikehold havnet nederst på listen. Så begynte ting å gå i stykker.
Mange byråer selger jo vedlikehold som «vi trykker oppdater en gang i måneden». Krysser fingrene. Sender en faktura.
Det er ikke vedlikehold. Det er gambling.
Av hackede CMS-er er WordPress
Tid for å oppdage nedetid
Oppetidsgaranti (Pro)
Testet oppdatering via CI/CD
Tegn på at WordPress-siden din trenger profesjonelt vedlikehold
- 01
WordPress-kjernen er mer enn én versjon bak. Kjører du 6.4 når 6.7 er ute? Da har du kjente sikkerhetshull.
- 02
Plugins har oransje oppdateringsvarsler — spesielt kritisk for WooCommerce, Yoast og alt som håndterer brukerdata.
- 03
Du vet ikke hvem som har admin-tilgang. Tidligere utviklere, frilansere, den praktikanten fra 2023.
- 04
Ingen backup-rutine er verifisert. «Hostingen tar backup» er ikke en strategi.
- 05
Siden er tregere enn for et år siden. Databasen vokser, cachen fylles, plugins akkumulerer overhead.
- 06
Du har aldri hørt ordene «staging-miljø». Oppdateringer rett i produksjon er som å bytte dekk mens bilen kjører.
- 07
Byrået som bygde siden eksisterer ikke lenger. Eller svarer ikke. Eller sier «det er ikke vår nettside lenger».
Hva «testet oppdatering»
betyr i praksis
Når vi oppdaterer WordPress-kjernen eller en plugin, skjer dette: oppdateringen kjøres på staging-miljøet først — en identisk kopi av produksjonssiden. Automatiserte tester verifiserer at skjemaer, betalingsflyt, innlogging og API-integrasjoner fortsatt fungerer. Visuell regresjonstest fanger endringer i layout.
Først når alt er grønt, deployes oppdateringen til produksjon gjennom CI/CD. Ikke via WordPress-dashboardet.
Denne prosessen tar 15 minutter med automatisering. Uten den tar det tre timer manuelt — eller null minutter hos byrået som bare trykker «oppdater alt» og håper det beste.
Når nettsiden krasjer
klokken tre om natten
Det skjer. Serveren svarer ikke, databasen er korrupt, en plugin-oppdatering knekte noe. Klokken er 03:14 og nettsiden din er en hvit side.
Overvåkningssystemet vårt oppdager nedetid innen 60 sekunder. Varslingen går automatisk. En tekniker vurderer alvorlighetsgraden og starter feilsøking — ikke neste morgen, men der og da.
Er det overkill for de fleste? Ja. Og det er helt greit. For de fleste bedrifter er Basis- eller Pro-nivået riktig. Men for nettbutikker med daglig omsetning eller nettsider som er kritiske for virksomheten, er nødrespons utenfor arbeidstid verdt hver krone.
SLA-nivåer for WordPress vedlikehold
Før og etter vedlikehold
WordPress-ytelse degraderer over tid uten aktivt vedlikehold. Databasen vokser, cachen fylles, plugins akkumulerer overhead. Forskjellen mellom en vedlikeholdt og en forsømt nettside er målbar i sekunder [1].
Infrastruktur som beskytter
FrankenPHP og intelligent caching
Sikkerhetsovervåkning i dybden
Backup med verifisert gjenoppretting
Oppetidsovervåkning
Gjør det selv?
Ja, for en enkel blogg uten integrasjoner. WordPress.org har god dokumentasjon. Det finnes plugins som automatiserer deler av jobben.
Spørsmålet er om du faktisk gjør det. Hver uke. Leser changelogs. Forstår hvorfor WooCommerce 9.4 knekte betalingsplugin-en din. Har testet at backupen faktisk kan gjenopprettes.
De fleste bedriftseiere har nok å gjøre med å drive bedriften. Og det er jo poenget.
Regnestykket: én sikkerhetsincident koster minst 15 000 til 80 000 kr å rydde opp i. En nettbutikk med 50 000 kr i daglig omsetning som er nede i ett døgn taper fortjeneste som kunne dekket en SLA-avtale i et halvt år. Pluss kundetillit som er vanskeligere å sette tall på.