Zo werkt het
Zo werkt het: wat er met je site gebeurt als ik hem beheer
Dit is wat er met je site gebeurt als hij bij mij in beheer is, van een gewone dinsdag tot een WordPress-update die problemen geeft. Het meeste werk doet mijn eigen beheersysteem, de beslissingen neem ik.
In het kort
- Voor een update maakt mijn systeem eerst een kopie. Daarna controleert het je site. Gaat er iets mis, dan zet het die kopie automatisch terug.
- Een nieuwe plugin- of themaversie wacht bij mij drie dagen. Een beveiligingsupdate voor een lek dat actief wordt misbruikt, wacht niet zo lang.
- Elke vijf minuten kijk ik of je site bereikbaar is. Een nieuw lek in een plugin die jij gebruikt, zie ik meestal binnen minuten. Het foutenlogboek lees ik elk half uur.
- Elke dag is er een back-up van je hele site. De laatste twee weken staat elke dag klaar, daarna een wekelijkse versie tot een maand terug en een maandelijkse tot een half jaar terug.
- Grote updates doe ik met de hand. Bij twijfel beslis ik, niet mijn systeem.
Wat er bij een update gebeurt
Zo loopt een update via mijn systeem, stap voor stap. Dat gaat in de drie pakketten precies hetzelfde.
Vooraf
Mijn systeem kijkt of je site bereikbaar is, er niet al iets anders bezig is en de nieuwe versie past bij jouw versie van WordPress. Klopt er iets niet, dan begint de update niet.
-
Kopie
Daarna maakt mijn systeem een kopie van precies het onderdeel dat verandert, plus je database (snapshot). Zo ligt er een weg terug klaar, zeven dagen lang.
-
Bijwerken
Pas dan voert het de update uit, via de eigen updatemotor van WordPress, ook bij betaalde plugins. Na een update van WooCommerce of Elementor wacht het tot ook de database is bijgewerkt voordat het controleert.
-
Cache legen
Vervolgens leegt het de cache, zodat bezoekers en de controle meteen de nieuwe versie zien. Dat werkt met de cache van mijn server (AccelerateWP) en met WP Rocket.
-
Controle
Mijn systeem doet een snelle controle (smoke test) van je homepage en een paar pagina's die ik vooraf heb gekozen: laden ze, staat er geen foutmelding op en zijn er geen nieuwe ernstige fouten bijgekomen? Bij een webshop legt het ook een product in het mandje en opent het de afrekenpagina, zonder te bestellen.
Als het misgaat
Mislukt de update of de controle, dan zet een vaste regel de kopie terug: eerst de bestanden, dan de database (rollback). Kwamen er op je webshop sinds de kopie nieuwe bestellingen binnen, dan gaan alleen de bestanden terug, zodat die bestellingen blijven staan.
- Grens
- De controle kijkt naar de pagina's die ik heb gekozen, niet naar elke pagina. Een kapot formulier op een pagina die niet in die lijst staat, ziet hij dus niet. Zie jij zoiets na een update, laat het me dan even weten. Dan zet ik zo nodig de kopie van daarvoor terug.
-
Klantroute
Bij een webshop doorloopt een echte browser de route van een klant tot aan de bestelknop.
Speel de routeSluit de route
Een browser opent de homepage, kiest een product, legt het in het mandje en vult de afrekenpagina in, tot aan de knop Bestelling plaatsen. Daar stopt hij. Als het misgaat
Faalt de route, dan krijg ik een melding.
-
Nacontrole
Een half uur later kijkt mijn systeem nog een keer of je site bereikbaar is en of er nieuwe ernstige fouten zijn, voor problemen die pas met echte bezoekers zichtbaar worden.
Als het misgaat
Vindt het dan iets, dan draait er niets vanzelf terug: ik krijg een alarm en beslis zelf.
Een etmaal van je site
Ook op een dag zonder updates kijk ik op vaste momenten naar je site.
| Wanneer | Wat er gebeurt | Als het niet klopt |
|---|---|---|
| Elke 5 minuten | Ik kijk van buitenaf of je site bereikbaar is. | Alarm, ook 's nachts |
| Elk half uur | Ik lees het foutenlogboek en kijk of de geplande taken van je site nog lopen en of WordPress zelf iets kritieks meldt. Bij een webshop tel ik de bestellingen die blijven hangen. | 's Ochtends in mijn overzicht |
| 4 keer per dag | Ik maak een lijst van alles wat er op je site draait, met versienummers. | Op de tijdlijn van je site |
| Bij een nieuw lek | Ik leg het naast de versies op jouw site, meestal binnen minuten. | Alarm als het ernstig is |
| Elke nacht | Ik vergelijk de bestanden van WordPress en je gratis plugins met het origineel bij wordpress.org. Ook controleer ik je hostingaccount, zoals de schijfruimte. | 's Ochtends in mijn overzicht |
| 03:00–05:00 | De kleine updates die drie dagen hebben gewacht, met een kopie vooraf en een controle erna. | |
| 06:30 | Je site stuurt een testmail en ik controleer of die aankomt. | 's Ochtends in mijn overzicht |
| 07:00 | Ik begin mijn dag met één overzicht van wat er op al mijn sites aandacht vraagt. | |
| Op een vast schema | Bij een webshop doorloopt een echte browser de route van een klant tot aan de bestelknop, als je dat wilt. | Melding |
Wat dringend is, zoals een site die niet bereikbaar is of een ernstig lek, gaat als alarm naar mijn telefoon, ook 's nachts. De rest staat 's ochtends op volgorde in mijn overzicht. Ligt je site plat of raakt een ernstig lek je plugins, dan weet ik het dus meestal eerder dan jij.
Wat gebeurt er als mijn site niet bereikbaar is?
Elke vijf minuten bezoek ik je site van buitenaf. Is hij twee keer achter elkaar niet bereikbaar, dan gaat er een alarm naar mijn telefoon, ook 's nachts.
Als het toch misgaat
Ook met al die controles kan er iets misgaan. Dan heb ik drie vangnetten, van snel naar diep.
De kopie van vlak voor de update
Mijn systeem zet hem automatisch terug als de update of de controle mislukt. Zie jij later toch iets wat niet klopt, dan zet ik hem op jouw verzoek terug, tot zeven dagen na de update. Op een webshop zie ik vooraf of er sindsdien bestellingen zijn binnengekomen.
De dagelijkse back-ups
Die gaan tot een half jaar terug, voor je hele site: de eerste twee weken per dag, daarna per week en per maand. Daaruit zet ik losse bestanden of je hele site terug, ook als er geen update aan voorafging. Een database uit die back-up terugzetten doe ik met de hand, volgens een vaste werkwijze.
De noodingang bij een wit scherm
Crasht een plugin je hele site, dan kan ik die ene plugin overslaan nog voordat WordPress hem laadt, ook als je niet meer in het beheer komt. Daarna zet ik hem netjes uit of draai ik de update terug. Dit werkt voor plugins, niet voor een crashend thema of een kapotte database.
Herstel na een update via mijn systeem kost je niets extra. Wat er verder in de pakketten zit, lees je bij WordPress onderhoud uitbesteden.
Zo ziet terugdraaien eruit
Om te laten zien hoe terugdraaien er in het echt uitziet, heb ik op mijn eigen proefsite expres een update laten mislukken. Mijn systeem maakte eerst een kopie, voerde de update uit, zag de controle erna mislukken en zette de kopie automatisch terug. Dat is een site van mij, geen klantsite.
Mijn eigen proefsite, 22 oktober 2026. Dit scherm is van mijn systeem; klanten loggen daar niet in.
Wat ik zie en wat jij merkt
Mijn systeem heeft één gebruiker: ik. Ik zie mijn ochtendoverzicht, de alarmen en de tijdlijn van je site, met updates, wijzigingen en meldingen op datum en tijd.
Jij merkt er meestal niets van.
Je hoort van mij als er iets van jou nodig is: een licentie, een plugin die vervangen moet of een ernstig lek zonder update.
Vraag je wat er is gebeurd, dan zoek ik het precies op.
Je krijgt geen rapporten en je hoeft nergens in te loggen.
Wat het niet doet
- De controle na een update kijkt naar je homepage en een paar pagina's die ik heb gekozen, niet naar elke pagina.
- De inhoudscontrole is een vergelijking, geen virusscanner, en geldt niet voor WordPress zelf of een plugin uit een zipbestand.
- Afschermen van een bekend lek is niet oplossen: de update volgt gewoon.
- Een veranderd bestand is een signaal, geen bewijs: dan kijk ik zelf.
Een eigen systeem, een eigen server
Dat beheersysteem heb ik zelf gebouwd, omdat ik twee dingen niet meer wilde: met de hand een rondje langs elke site doen en na een update maar afwachten of alles nog werkte. Op je site staat daarvoor één klein, ondertekend stukje software van mij. Het staat alleen mijn systeem te woord en heeft geen eigen inlogaccount. Meer daarover lees je bij waarom ik een eigen beheersysteem bouwde.
Je site, je database, je back-ups en je e-mail staan op mijn eigen server in Nederland. Mijn beheersysteem draait op een aparte server in Duitsland.
Waarom een nieuwe versie drie dagen wacht
Een nieuwe plugin- of themaversie installeer ik niet op de dag dat hij verschijnt. Hij wacht eerst drie dagen (72 uur). Blijkt een versie in die dagen niet te deugen en wordt hij teruggetrokken, dan heeft je site hem niet automatisch gekregen.
Er zijn een paar bewuste uitzonderingen:
- Dicht een update een lek dat actief wordt misbruikt of een ernstig lek dat zonder inloggen te raken is, dan laat ik hem geen drie dagen wachten. Op een webshop gaat zo'n update in de eerstvolgende nacht, omdat terugdraaien daar bestellingen kan raken.
- Kleine updates van WordPress zelf (de kern, niet je plugins) wachten niet.
- Een update die wordpress.org zelf doorduwt, meestal een dringende beveiligingsupdate, gaat altijd door.
Wat het voor jou betekent: je site is niet de eerste die een nieuwe versie krijgt, maar is wel snel aan de beurt als het om een ernstig lek gaat. Wat drie dagen wachten niet vangt, is een versie die later stiekem wordt aangepast. Daarvoor is de controle hieronder.
- Wacht
- drie dagen (72 uur)
- Eerder
- een lek dat actief wordt misbruikt
- Wacht niet
- kleine updates van WordPress zelf
- Gaat altijd door
- een update die wordpress.org zelf doorduwt
Controle van de inhoud van een update
Vlak voor de installatie reken ik een vingerafdruk van het updatepakket uit. Die vergelijk ik met wat wordpress.org opgeeft. Bij een betaalde plugin vergelijk ik hem met wat mijn andere sites eerder van precies die versie kregen (hashcontrole). Wijkt de inhoud af, dan gaat die versie er niet op, krijg ik een melding en kijk ik eerst zelf.
Een update waar iemand stiekem aan heeft gezeten, komt dus niet ongemerkt op je site. Het is wel een vergelijking, geen virusscanner. De controle geldt niet voor WordPress zelf en niet voor een plugin die uit een zipbestand wordt geïnstalleerd. Staat een betaalde plugin op maar één van mijn sites, dan heb ik niets om mee te vergelijken: de eerste versie die daar binnenkomt, geldt dan als het origineel.
- Vergelijkt met
- wat wordpress.org opgeeft
- Betaalde plugin
- wat mijn andere sites eerder van precies die versie kregen
- Niet voor
- WordPress zelf; een plugin uit een zipbestand
Bekende lekken: van melding tot oplossing
Ik volg een grote openbare lijst van bekende lekken in WordPress, plugins en thema's en leg die naast de exacte versies op jouw site. Komt er een lek bij dat jouw site raakt, dan weet ik dat meestal binnen minuten.
Is het ernstig, dan gaat er een alarm naar mijn telefoon, ook 's nachts. Minder ernstige lekken staan de volgende ochtend in mijn overzicht. Ik weet wel alleen van lekken die in die lijst staan. Soms komt een lek er pas dagen na de update in.
Meestal is de update zelf de oplossing. Die loopt dan gewoon door de stappen van hierboven.
Bij Plus en Pro schermt een extra laag bekende lekken in plugins af tot er een update is: WP Guardian, met regels van Patchstack (virtual patching). Dat lukt alleen bij lekken waarvoor zo'n regel bestaat. Afgeschermd is niet opgelost: de update volgt gewoon. Tot dan blijft het lek op mijn lijst. Basis heeft die afscherming niet; daar is de update zelf de bescherming.
Is er een ernstig lek waarvoor nog geen update bestaat, dan bespreek ik met je of we de plugin uitzetten of vervangen. Dat gebeurt nooit automatisch.
Los daarvan beveiligt Imunify360 de server zelf, in elk pakket. Dat is een laag van de hosting, niet van mijn systeem.
- Bekend
- meestal binnen minuten
- Ernstig
- een alarm naar mijn telefoon, ook 's nachts
- Plus en Pro
- afgeschermd tot er een update is
- Server
- Imunify360, in elk pakket
Foutmeldingen die ik meelees
Elk half uur lees ik het logboek waarin je site zijn fouten bijhoudt. Dezelfde fout wordt bij mij één melding, met hoe vaak hij voorkomt en of hij vlak na een update begon. Meestal zie ik er ook bij welke plugin of welk thema hem veroorzaakt. Komt een fout die ik had opgelost met een nieuwe versie terug, dan zie ik hem vanzelf weer.
Ook kijk ik dan of de geplande taken van je site nog lopen (zoals geplande berichten en verzendmails) en of WordPress in zijn eigen gezondheidscheck iets kritieks meldt.
Wat het voor jou betekent: geeft een plugin een fout waardoor je contactformulier niet meer werkt, dan kan ik dat zien voordat een bezoeker erover klaagt. Maar niet elke fout komt in een logboek. Een fout die ontstaat voordat WordPress is geladen, zie ik daar bijvoorbeeld niet.
- Dezelfde fout
- één melding, met hoe vaak hij voorkomt en of hij vlak na een update begon
- Ook
- of de geplande taken van je site nog lopen; of WordPress in zijn eigen gezondheidscheck iets kritieks meldt
- Ziet hij niet
- een fout die ontstaat voordat WordPress is geladen
Wat ik van buitenaf en elke nacht controleer
Elke vijf minuten bezoek ik je site van buitenaf. Is hij twee keer achter elkaar niet bereikbaar, dan gaat er een alarm naar mijn telefoon, ook 's nachts. Mijn systeem draait op een andere server dan je site, dus ik zie het ook als mijn hostingserver zelf plat ligt.
Daarnaast houd ik bij of je certificaat (het slotje in de adresbalk) op tijd wordt vernieuwd en of je schijfruimte vol dreigt te raken. Verandert er iets aan de instellingen die bepalen waar je domeinnaam naartoe wijst (DNS), dan zie ik dat ook. En ik kijk of je domeinnaam niet verloopt.
Elke nacht vergelijk ik de bestanden van WordPress en je gratis plugins met het origineel bij wordpress.org (checksum). Is er een bestand veranderd of bijgekomen, dan kan dat betekenen dat iemand aan je site heeft gezeten. Dat is een signaal, geen bewijs: dan kijk ik zelf. Betaalde plugins en alle thema's vallen erbuiten, want daarvan heb ik geen origineel om naast te leggen.
Vier keer per dag maak ik een lijst van alles wat er op je site draait. Verandert er iets zonder dat ik het deed, dan zie ik dat op de tijdlijn van je site. Uit die lijst komen ook signalen, zoals een plugin die al twee jaar niet is bijgewerkt, een beheerdersaccount dat erbij is gekomen of een versie van de programmeertaal onder WordPress (PHP) die binnen zes maanden niet meer wordt onderhouden.
Elke dag stuurt je site een testmail en controleer ik of die aankomt.
Webshops: de route van een klant
Heb je een webshop, dan richt ik bij de start een vaste route in die een echte browser aflegt: een product kiezen, in het mandje leggen, de afrekenpagina invullen, tot aan de bestelknop. Daar stopt hij, want ik richt hem zo in dat er niet wordt besteld.
Die route draait na elke update via mijn systeem en als je wilt ook op een vast schema, van elk kwartier tot eens per week. Zo zie ik een kapotte afrekenpagina ook als er geen update was. Faalt de route, dan krijg ik een melding. Pas als een route bewezen stabiel is, stel ik hem zo in dat hij een update mag laten terugdraaien.
Verder geldt bij een webshop:
- Elke WooCommerce-update doe ik met de hand.
- Na een WooCommerce-update wacht ik tot de database is bijgewerkt voordat ik de route naspeel.
- Elk half uur kijk ik of bestellingen te lang op "in afwachting" blijven staan. Dat is vaak het eerste teken dat een betaalkoppeling stuk is. Ik zie daarbij alleen aantallen en betaalmethodes, geen namen of bedragen. Mijn systeem verandert nooit een bestelling; wat er daarna moet gebeuren, overleg ik met je.
Ging een update bij jou net mis?
Zie je na een update een wit scherm, een melding over een kritieke fout of een pagina die niet meer werkt? Doe dan dit, in deze volgorde. Stop zodra je site het weer doet.
Werk niets meer bij
Start geen update opnieuw. Schrijf op welke plugin of welk thema je het laatst hebt bijgewerkt.
Zet die plugin uit
Kom je nog in het beheer van WordPress, dan doe je dat onder Plugins. Kom je er niet in, kijk dan of je een mail van WordPress over een technisch probleem hebt gekregen: daarin staat een link waarmee je toch kunt inloggen. Lukt dat ook niet, hernoem dan de map van die plugin in
wp-content/pluginsvia het bestandsbeheer van je hostingpakket; WordPress slaat hem dan over. Was het een thema, ga dan meteen door naar stap 3.Zet de laatste back-up van vóór de update terug
Dat kan meestal via je hostingpakket; lukt dat niet, vraag het dan aan je host. Heb je een webshop, schrijf dan eerst de bestellingen van na die back-up op, want een volledige back-up terugzetten haalt ze weg.
Bij sites die ik beheer, doe ik dit zelf. Wil je dat dit voortaan niet meer jouw probleem is? Dan regel ik het onderhoud: plan een kennismaking. Liever zelf blijven onderhouden? Lees dan eerst wanneer je het zelf kunt doen.
Kom je er zelf niet uit? Dan help ik je ook eenmalig, voor €95 per uur excl. btw.
Wat ik met de hand doe
Je klikt al maanden een melding over PHP weg.
Bij mij
Een overstap naar een nieuwere PHP-versie is bij mij een grote update. Die doe ik met de hand en kijk ik vooraf na.
Grote updates plan ik zelf, op een moment dat ik erbij ben. Groot is bij mij: een nieuwe hoofdversie, een overstap naar een andere versie van de programmeertaal onder WordPress, elke WooCommerce-update en een thema-update als je thema maatwerk bevat. Ook die lopen door de stappen van hierboven. Soms maak ik eerst een testkopie van je site.
Rol ik een update over al mijn sites uit, dan gaat hij eerst naar mijn eigen proefsite als die plugin daar ook staat. Daarna volgt site voor site; bij de eerste fout stopt de reeks.
Bij het nakijken van een update zie ik op schermafbeeldingen van voor en na of er iets is verschoven, zoals een kolom of een lege plek. Dat is een hulpmiddel voor mijn eigen blik, geen alarm.
Een betaalde plugin zonder geldige licentie kan ik niet bijwerken. Dat leg ik aan je voor.
Zo stap je over
Na de kennismaking en de quickscan verhuis ik je site naar mijn server. Dat duurt één tot drie werkdagen en al die tijd blijft je site bereikbaar en blijft je e-mail werken. Een dag of twee kun je beter niets aan je site veranderen. Meestal draait je site binnen een week bij mij.
Daarna koppel ik je site aan mijn systeem en zet ik de bewaking en de back-ups aan. Bij een webshop richt ik ook de route van een klant in.
Alle sites van je pakket verhuizen mee, en je e-mail ook; een gewone verhuizing kost niets extra. Is hij ingewikkeld, bijvoorbeeld een webshop die geen moment offline mag, dan spreken we vooraf af hoe we het doen. Je bestaande mailboxen overzetten doen we in overleg. Wat het onderhoud daarna kost en wat we vastleggen, lees je in de gidsen over wat dit kost en wat we afspreken.
"(…) mijn vorige host reageerde traag en stond nooit echt klaar. De overstap naar Jorijn had ik veel eerder moeten doen. De verhuizing ging naadloos, zonder één seconde downtime (…)"
Wat ik van je nodig heb
- Een beheerdersaccount op je WordPress-site.
- Toegang tot je huidige hostingaccount of een volledige back-up van je site.
- Toegang tot de instellingen van je domeinnaam (DNS) of de gegevens van de partij waar je domein staat.
- Een lijst van je e-mailadressen op dat domein.
- De licenties van betaalde plugins en van je thema.
Wat je met je huidige host doet
- Kijk hoe lang je contract nog loopt en wat de opzegtermijn is. Veel hosters werken met jaarcontracten.
- Zeg je oude contract pas zelf op als je site bij mij draait.
- Je domeinnaam: die kan bij je huidige partij blijven en naar mijn nameservers wijzen, of naar mij verhuizen (een .nl of .com kost €19,99 per jaar excl. btw).
- Je e-mail: verhuist mee. Je bestaande mailboxen overzetten doen we in overleg.
Verlies ik posities in Google?
Je domeinnaam en de adressen van je pagina's blijven hetzelfde; alleen de server verandert. Een belofte over posities doe ik niet.
Veelgestelde vragen over updates en herstel
Kan ik meekijken in je beheersysteem?
Nee, mijn systeem heeft één gebruiker: ik. De schermafbeelding op deze pagina is van mijn eigen proefsite. Vraag je wat er is gebeurd, dan zoek ik het op in de tijdlijn van je site en vertel ik het je.
Krijg ik een melding als er iets gebeurt?
Nee, de meldingen komen bij mij binnen. Je krijgt ook geen automatische rapporten. Heb ik iets van je nodig, zoals een licentie, een plugin die vervangen moet of een besluit over een ernstig lek zonder update, dan neem ik contact met je op.
Hoe snel merk je dat mijn site gehackt is?
Daar noem ik geen tijd voor, want dat kan ik niet beloven. Wel let ik op signalen: elke nacht de vergelijking van je bestanden met het origineel bij wordpress.org, vier keer per dag de lijst van beheerders en plugins, elk half uur het foutenlogboek en op de server Imunify360. Een signaal is geen bewijs. Bij twijfel kijk ik zelf. Moet je site daarna worden opgeschoond, dan kost dat je niets extra als hij bij mij in beheer was en de oorzaak niet bij jou lag. Anders reken ik €95 per uur excl. btw.
Wat installeer je op mijn site?
Eén klein, ondertekend stukje software dat alleen mijn systeem te woord staat. Het heeft geen eigen inlogaccount en kan geen code uitvoeren die ik het toestuur. Ook dat stukje software werk ik voorzichtig bij: eerst op mijn eigen proefsite, met dezelfde controle erna en terug naar de vorige versie bij een fout. Vertrek je, dan haal ik dat stukje software en de sleutel er zelf weer af; jij hoeft niets te doen.
Wat als de controle iets mist?
De controle ziet alleen wat hij controleert. Zie jij na een update iets wat niet klopt, laat het me dan weten. Tot zeven dagen na de update zet ik de kopie van daarvoor terug. Daarna haal ik bestanden of je hele site uit de dagelijkse back-ups, tot een half jaar terug, de eerste twee weken per dag. Herstel na een update via mijn systeem kost je niets extra.
Wat betekent dit voor jouw site?
Wil je weten hoe dit er voor jouw site uitziet? Plan een kennismaking, dan bespreken we waar je site nu staat en wat ik zou doen.