In dit artikel
- Wat is WordPress onderhoud precies?
- Wat zit er in ons WordPress onderhoud?
- Wat gebeurt er als je WordPress-site kapotgaat?
- Zelf doen, een goedkoop pakket of een SLA: wat past bij jou?
- Ben je een WordPress specialist als je geen WordPress-sites bouwt?
- Waarom is onderhoud bij ons de eerste stap naar een overstap?
- Hoe neem je het WordPress-onderhoud over van je huidige partij?
- Veelgestelde vragen
Ik ben Yassine Seghrouchni, samen met Joey van Vliet oprichter van Your Tech Club in Amsterdam. Your Tech Club is door Kiwa gecertificeerd voor ISO 27001 en ISO 9001, en onze werkwijze is daaromheen ingericht.
Wat je bij oudere WordPress-sites vaak ziet: plugins die niemand meer gebruikt maar die nog wel op de server staan, en beheerders van wie niemand meer weet wie het zijn. Daar begint de overnamecheck dan ook mee.
Wat is WordPress onderhoud precies?
WordPress onderhoud is het vaste, terugkerende werk dat een WordPress-site veilig en werkend houdt. Denk aan updates van WordPress zelf, van plugins en van het thema, plus back-ups, beveiligingsbewaking en uptime-controle. Goed onderhoud test elke update eerst in een kopie van je site, zodat je bezoekers nooit de proefpersoon zijn.
Het klinkt saai, en dat is het ook. Juist daarom gaat het vaak mis. Iemand bouwt een site, iedereen is blij, en daarna kijkt er twee jaar niemand meer naar. Ondertussen staan er twintig plugins op die elk hun eigen updates vragen.
De cijfers laten zien waarom dat riskant is. Volgens Patchstack kwamen er in 2025 11.334 nieuwe kwetsbaarheden in het WordPress-ecosysteem bij, 42% meer dan in 2024. Daarvan zat 91% in plugins en 9% in thema's; WordPress zelf had er maar 6. Bovendien had 46% nog geen oplossing van de maker toen het lek openbaar werd (Patchstack, State of WordPress Security in 2026, bijgewerkt februari 2026).
Het risico zit dus vooral in de plugins die jij of je vorige bouwer installeerde. Niet in WordPress zelf.
Wat zit er in ons WordPress onderhoud?
Een SLA met vaste onderdelen: updates, bewaking, back-ups los van de server, beveiliging en een termijn om een kritiek lek te dichten. Daaronder draaien meerdere monitoringtools en een website-agent die versies, meldingen en nieuws over lekken naloopt. Hoe vaak we wat doen, hangt af van je site. Die frequenties en termijnen leggen we per site vast in de SLA.
| Onderdeel | Wat we doen | Wat jij ervan merkt |
|---|---|---|
| Updates | WordPress, thema, plugins, PHP-versie en server bijhouden | Updates plannen we zo dat je er zo min mogelijk van merkt |
| Bewaking | Meerdere monitoringtools letten op bereikbaarheid, snelheid en afwijkingen | Bij iets kritieks krijgt de juiste persoon direct een melding op mobiel of per sms |
| Back-ups | Los van je server, met een frequentie en een terugzetprocedure uit de SLA | Na een inbraak of een mislukte update is er een schone versie |
| Website-agent | Loopt versies, klaarstaande updates, nieuws over lekken en meldingen van de bewaking na | Een developer krijgt een melding met context; de agent wijzigt niets live |
| Beveiliging | Nieuws over lekken volgen, letten op ongewone activiteit, rechten beperken | Bij een kritiek lek telt elk uur, en dat staat in de SLA |
| Dashboard en rapportage | Meldingen uit de bewaking op één plek, plus een vaste rapportage | Je ziet zelf wat er is bijgewerkt, wat de bewaking zag en wat er nog speelt |
| Plan voor later | Bespreken of WordPress nog de juiste basis is | Een kort gesprek over de overstap, als je dat wilt |
Een paar keuzes licht ik toe, omdat daar het verschil zit met goedkoop onderhoud.
Een update kan meer raken dan je denkt. Een plugin-update breekt soms je contactformulier of de betaalstap van je WooCommerce-shop. Mijn advies, ook als je het onderhoud zelf doet: test een grote update eerst op een kopie van je site, en zorg voor een back-up die je echt kunt terugzetten.
Back-ups los van de server. Een back-up op dezelfde server als je site is weg op het moment dat je hem nodig hebt. En een back-up die je nooit hebt teruggezet, is een hoop. Daarom leggen we de terugzetprocedure vast in de SLA.
Ook de server telt mee. WordPress draait op PHP. Draait je site nog op PHP 8.2, dan krijgt die versie na 31 december 2026 geen beveiligingsupdates meer (php.net, Supported Versions, geraadpleegd november 2026). Hoe snel zoiets gevolgen heeft, zag je op 21 oktober 2026. Toen moesten servers in heel Nederland met spoed een nieuwe PHP-versie krijgen. Bij ons draaien meerdere klantprojecten op PHP. Die dag hebben we ze één voor één bekeken en per project met de klant gekozen: tijdelijk offline tot de update er was, of online met de risico's in beeld. Lees daarover meer in het PHP-lek op je website.
De agent waarschuwt, een mens beslist. De website-agent is software die versies, lekken en meldingen naloopt. Hij zet nooit zelf iets op je live site. Een developer beslist wat er gebeurt, en wanneer. Hoe dat werkt, staat bij website-onderhoud met een SLA.
Een veelvoorkomend scenario: een plugin-update gaat op vrijdagmiddag direct op de live site, het contactformulier verstuurt niets meer en niemand merkt het tot er maandag geen aanvragen binnen zijn. Bewaking en een back-up die je kunt terugzetten, maken dan het verschil.
Wat gebeurt er als je WordPress-site kapotgaat?
Dan volgen we vijf vaste stappen: melden, bevestigen, oorzaak zoeken, herstellen en uitleggen. De termijnen per prioriteit staan in je WordPress onderhoudscontract. Een SLA (service level agreement) is een afspraak waarin staat wat je leverancier doet, binnen welke termijn en hoe je daarover hoort. "Zo snel mogelijk" staat er dus niet in.
- Melding. Die komt van onze bewaking, van de website-agent of van jou.
- Bevestiging. Binnen de termijn uit de SLA hoor je dat we ermee bezig zijn en wie het oppakt.
- Oorzaak. We kijken wat er veranderde: een update, de server of een aanval.
- Herstel. Is dat het snelst, dan zetten we eerst de laatste goede back-up terug. Daarna lossen we de oorzaak op.
- Uitleg. Je krijgt kort op papier wat er gebeurde en wat we veranderen zodat het niet nog eens gebeurt.
| Prioriteit | Voorbeeld | Wat de SLA vastlegt |
|---|---|---|
| Kritiek | Site onbereikbaar, betalen werkt niet, site gehackt, kritiek lek | Een termijn om het lek te dichten of de site te herstellen, niet alleen om terug te bellen |
| Hoog | Formulier of zoekfunctie werkt niet | Een termijn om het op te pakken en wie je daarover informeert |
| Normaal | Kleine aanpassing of vraag | Wanneer we het inplannen |
De termijnen zelf spreken we per site af, want een webshop met koppelingen vraagt iets anders dan een site met vijf pagina's.
Mijn mening: een onderhoudscontract zonder termijnen is een abonnement op goede bedoelingen. En een reactietijd alleen zegt weinig. Vraag naar een belofte over het dichten van een lek, niet alleen over het terugbellen.
Zelf doen, een goedkoop pakket of een SLA: wat past bij jou?
Zelf doen kan prima bij een kleine site met weinig plugins en iemand die er tijd voor heeft. Een goedkoop pakket past bij een visitekaartje-site waar een dag stilstand weinig kost. Draait je site leads of omzet, of hangt hij aan je boekhouding of voorraad, dan wil je WordPress beheer met een SLA en vaste termijnen.
| Zelf doen | Goedkoop pakket | SLA met website-agent | |
|---|---|---|---|
| Updates | Jij klikt op "bijwerken" | Vaak automatisch, direct op de live site | Gepland, met een developer die beslist |
| Back-ups | Als je eraan denkt | Vraag waar ze staan | Los van de server, met een terugzetprocedure in de SLA |
| Als het misgaat | Jij zoekt het uit, of je belt iemand met spoed | Vaak hulp zonder vaste termijn, of herstel tegen een los tarief | Vaste termijn per prioriteit in de SLA, ook om een lek te dichten |
| Wie let op | Jij | Een systeem | Meerdere monitoringtools en een website-agent, een developer beslist |
| Server en PHP | Jouw hosting, jouw zorg | Vaak buiten het pakket | Onderdeel van het onderhoud |
| Plan voor later | Geen | Geen | Gesprek over blijven of overstappen |
| Past bij | Kleine site, iemand met tijd en kennis | Eenvoudige site, stilstand kost weinig | Site met leads, webshop of koppelingen |
Doe je het liever zelf? Prima. Houd dan in elk geval deze regels aan:
- Update nooit op vrijdagmiddag of vlak voor een drukke periode.
- Maak vóór elke update een back-up en bewaar die buiten je server.
- Verwijder plugins die je niet gebruikt, ook als ze uitgeschakeld zijn.
- Schrijf op wie toegang heeft tot WordPress, de hosting en het domein.
Wat ik níet zou doen: automatische updates aanzetten op een webshop en hopen dat het goed gaat. Op een eenvoudige blog is dat een redelijke gok. Bij een betaalstap niet.
Ben je een WordPress specialist als je geen WordPress-sites bouwt?
Voor onderhoud wel, voor nieuwbouw niet meer. We hebben in het verleden zelf WordPress-sites gebouwd, en die onderhouden we nog steeds. Nieuwe WordPress-sites bouwen we niet meer: nieuwe websites maken we op maat met Next.js, Strapi of Laravel, of op Shopify. Bestaande WordPress- en WooCommerce-sites nemen we wel over. Zoek je een WordPress specialist die een nieuwe WordPress-site bouwt, dan zijn wij niet de juiste partij.
Dat zeg ik liever nu dan in een offerte. WordPress is prima voor een eenvoudige site met een blog. Maar ons team werkt elke dag in maatwerk en Shopify, en daar zijn we beter in. Voor onderhoud ligt dat anders. Je site bestaat al en werkt. Dan is het onverstandig om alles weg te gooien, alleen omdat wij liever in een andere techniek bouwen.
We weten ook hoe het voelt om van WordPress af te gaan. Onze eigen site, yourtechclub.nl, draaide op WordPress en staat sinds september 2026 op Next.js. Volgens de sitemap van 19 september 2026 had de oude site 168 geïndexeerde adressen. Van 115 daarvan bestond de pagina niet meer, dus die kregen elk een redirect naar de pagina die er inhoudelijk het dichtst bij ligt. Blogposts zonder opvolger wijzen naar de dienst waar ze over gingen, niet blind naar de homepage. Toch was het niet in één keer goed. Een maand later vond een check in Ahrefs nog drie 404's, en oude adressen met een slash aan het eind liepen in twee sprongen naar hun doel in plaats van één. Dat hebben we toen rechtgezet.
Waarom is onderhoud bij ons de eerste stap naar een overstap?
Omdat je pas goed kunt kiezen als je weet hoe je site ervoor staat. Na een paar maanden onderhoud weten we welke plugins je nodig hebt, wat er stuk gaat en wat je team elke week met de hand doet. Dan maken we samen een plan: blijven op WordPress, of overstappen naar een site die meer voor je doet.
Die overstap noemen we de WordPress-overstap. Je krijgt dan een maatwerk-site met een headless CMS, Next.js met Strapi, waar je redactie zelf in werkt. Alle oude URL's krijgen een redirect, zodat je je plek in Google houdt. Formulieren landen rechtstreeks in je CRM. En de eerste digitale medewerker gaat aan de slag: AI die leads kwalificeert, offertes voorbereidt of klantvragen beantwoordt. Daarna beheren we de site met een website-agent en een SLA, net als nu.
We adviseren de overstap meestal bij een van deze signalen:
- De site leunt op plugins die geen updates meer krijgen.
- Elke kleine wijziging kost uren, of je redactie durft niets meer aan te raken.
- Leads uit je formulieren komen in een mailbox en niet in je CRM.
- Je hosting draait nog PHP 8.2 of ouder, en upgraden breekt je thema.
Wat ik níet zou doen: overstappen omdat iemand zegt dat WordPress "verouderd" is. Een overstap kost geld en tijd, dus hij moet iets opleveren. Daarom begint het grotere plan vaak met de AI Opportunity Audit: resultaat binnen vijf werkdagen, en het rapport noemt ook waar AI geen goed idee is.
Voorbeelden zie je in de case over een headless CMS met Strapi en Next.js en de case van WooCommerce naar Shopify.
Ik zou dat plan niet te vroeg maken. Na de overnamecheck weet je wat er achterstallig is. Na een paar maanden onderhoud weet je ook hoe vaak er iets breekt en hoeveel tijd wijzigingen kosten. Dan kies je tussen blijven en overstappen op basis van wat je ziet, niet op gevoel.
Hoe neem je het WordPress-onderhoud over van je huidige partij?
In vier stappen, en de eerste is een overnamecheck. Daarin kijken we waar je site draait, welke PHP- en WordPress-versies erop staan, welke plugins er draaien, waar de back-ups staan en wie er toegang heeft. Blijkt er achterstallig onderhoud, zoals een PHP-versie zonder beveiligingsupdates, dan hoor je dat eerst. Dat lossen we op voordat de SLA ingaat.
- Overnamecheck. Hosting, versies, plugins, back-ups en toegang. Daarna hoor je wat er achterstallig is.
- SLA afspreken. Wat inbegrepen is, wie je belt, binnen welke termijn een kritiek lek dicht moet en hoe je daarover hoort.
- Inrichten. Bewaking, back-ups los van de server, de website-agent en wie welke melding krijgt.
- Doorlopend onderhoud. Updates, meldingen en een vaste rapportage over wat er is gedaan, wat de bewaking zag en wat er nog speelt.
Je huidige partij hoeft daar weinig voor te doen. Meestal is toegang tot WordPress, de hosting en het domein genoeg. Lastiger wordt het als je hosting op naam van je vorige bouwer staat. Ook dat lossen we op, maar plan er dan wat extra tijd voor.



