Hoe veilig jouw WordPress-website is, hangt minder af van WordPress zelf dan van wat eromheen gebeurt. Wie kan er inloggen, welke plugins draaien er, wie werkt PHP op de server bij en kun je terug als het misgaat? Hieronder staan twaalf risico's, met per risico hoe je het zelf controleert en wie het oplost.

De bekende maatregelen, zoals sterke wachtwoorden, tweestapsverificatie en een firewall, staan stap voor stap in de handleiding je WordPress-website veiliger maken. Dit artikel gaat over wat in zulke lijstjes vaak ontbreekt.

Hoe veilig is WordPress?

WordPress is veilig te gebruiken als iemand het bijhoudt. Er worden lekken in gevonden en gedicht, net als in andere software. Een website zonder enig risico bestaat niet.

Drie voorbeelden uit 2026 laten zien dat het om meer gaat dan WordPress alleen.

Juli 2026, een lek in WordPress zelf. WordPress.org bracht WordPress 7.0.2 uit voor een kritiek lek en een lek met hoge ernst, en zette voor de getroffen versies geforceerde automatische updates aan. Het Amerikaanse CISA zette beide lekken op 21 juli op zijn lijst van lekken die aantoonbaar worden misbruikt.
September 2026, weer een lek in WordPress zelf. WordPress 7.1.2 dichtte op 22 september een kritiek lek. Of iemand er op afstand code mee kon uitvoeren, hing volgens WordPress.org ook af van het actieve thema en de serveromgeving. CISA zette dit lek op 25 september op dezelfde lijst.
Oktober 2026, twee lekken in PHP. Dit keer zaten twee kritieke lekken in PHP, de programmeertaal op de server waarop WordPress draait. WordPress.org schreef dat er geen WordPress-update nodig of gepland was. De oplossing moest van de server komen.

Voor de lekken van juli en september kon de reparatie via de automatische updates van WordPress zelf komen. Voor de lekken in PHP moest iemand anders in actie komen. Wie dat bij jouw website is, is de vraag achter de meeste risico's hieronder. Wat er met PHP speelt en wat je nu doet, lees je in wat de kritieke PHP-lekken van oktober 2026 voor je website betekenen.

Zelftest in twaalf vragen

Beantwoord de twaalf vragen met ja of nee. Elk nee verwijst naar een risico verderop in dit artikel. Weet je het antwoord niet, tel het dan als nee.

Nr.	Vraag	Bij nee
1	Gebruikt iemand nog elk beheerdersaccount op je website?	Risico 1
2	Vraagt inloggen bij WordPress, je hosting en je e-mail meer dan alleen een wachtwoord?	Risico 2
3	Kunnen minstens twee mensen in je bedrijf bij je domeinnaam, DNS en e-mail?	Risico 3
4	Weet je op welke PHP-versie je website draait en wie die bijwerkt?	Risico 4
5	Weet je welke onderdelen van je website zich automatisch bijwerken en welke niet?	Risico 5
6	Gebruik je elke plugin en elk thema, en krijgen ze nog updates van de maker?	Risico 6
7	Weet je zeker dat er geen oude kopie, testsite of back-upbestand van je website online staat?	Risico 7
8	Weet je welke sleutels je website gebruikt voor betalingen, mail en koppelingen, en wie ze kent?	Risico 8
9	Heb je een back-up ooit echt teruggezet, en staat er een kopie buiten de server?	Risico 9
10	Krijg je een melding als je website offline gaat of je certificaat verloopt?	Risico 10
11	Test iemand na updates je formulieren en het afrekenen?	Risico 11
12	Staat ergens vast wie WordPress, PHP, de server, back-ups en bewaking bijhoudt?	Risico 12

Wie kan er inloggen op je website?

Vaak meer mensen dan je denkt, en niet alleen via WordPress. Elk account dat niemand meer gebruikt, en elk systeem waar je met alleen een wachtwoord binnenkomt, is een ingang die openstaat.

1. Accounts die niemand meer gebruikt

Een oud-medewerker, een stagiair, de vorige webbouwer of een bureau dat ooit iets instelde. Hun accounts blijven bestaan tot iemand ze verwijdert. Het risico zit niet in die mensen, maar in hun wachtwoord, dat nog in een oude browser, een gedeeld document of een gelekte lijst van een andere dienst kan staan.

Kijk ook naar het e-mailadres voor beheer van je website. WordPress stuurt daar onder meer de meldingen over automatische updates naartoe. Staat daar nog het adres van iemand die vertrokken is, dan leest niemand ze. En omdat je een vergeten wachtwoord via e-mail herstelt, kan wie de mailbox van een beheerder heeft ook diens WordPress-wachtwoord opnieuw instellen.

Zo controleer je het. Ga in WordPress naar Gebruikers > Alle gebruikers en kijk welke accounts de rol Beheerder hebben. Verwijder accounts die niemand meer gebruikt en wijs hun inhoud toe aan een andere gebruiker. Wie alleen berichten schrijft, heeft genoeg aan de rol Auteur of Redacteur. Zie je een beheerder die je helemaal niet kent, dan is het geen opruimklus meer. Lees dan eerst wat je doet als je WordPress-website besmet is.

Wie lost het op? Jij, want alleen jij weet wie er nog voor je bedrijf werkt. Maak het een vast moment bij elk vertrek en bij elke wissel van bouwer. Welke rol bij welk werk past, staat in een gebruiker met de juiste rechten toevoegen.

2. Inloggen met alleen een wachtwoord

Programma's proberen op elke inlogpagina die ze vinden net zo lang wachtwoorden tot er één past. Dat heet een brute force-aanval, en die is niet op jou persoonlijk gericht. Tweestapsverificatie en een limiet op het aantal inlogpogingen houden hem tegen. Tweestapsverificatie zit niet standaard in WordPress. Daarvoor installeer je een plugin.

Maar WordPress is niet de enige deur. Het beheerpaneel van je hosting, de bestandstoegang via FTP of SFTP, je domeinregistratie en je mailbox geven vaak meer toegang dan een WordPress-account. Wie in je hostingpaneel komt, kan bij de bestanden en de database van je website, ook zonder WordPress-wachtwoord.

Zo controleer je het. Log uit en log opnieuw in via een privévenster. Vraagt WordPress alleen een wachtwoord, dan staat tweestapsverificatie niet aan. Doe dezelfde test bij je hostingpaneel, je domeinregistratie en je e-mail.

Wie lost het op? In WordPress jij of je onderhoudspartij. Bij hosting, domein en e-mail stel je het per dienst zelf in. Hoe het in WordPress werkt, lees je in tweestapsverificatie inschakelen in WordPress.

3. Domein, DNS en e-mail bij één persoon

Je domeinnaam is de basis onder je website en je e-mail. Met de DNS-instellingen bepaal je waar je website en je mail naartoe wijzen. Staat de registratie op het privéaccount van een oud-medewerker, of kent alleen je vorige bouwer het wachtwoord, dan kun je bij een probleem niets wijzigen. Ook niet als je website moet verhuizen of je mail niet meer aankomt.

Zo'n account is ook een doelwit. Krijg je een mail dat er iets dringends is met je domein of hosting, met een link om in te loggen? Die link kan naar een nagemaakte pagina leiden. Log daarom altijd zelf in via het adres dat je kent.

Zo controleer je het. Zoek uit bij welke partij je domeinnaam staat, op wiens naam en met welk account je daar inlogt. Lukt dat niemand in je bedrijf, dan is dit je eerste klus.

Wie lost het op? Jij. Zorg dat de registratie op naam van je bedrijf staat en dat minstens twee mensen erbij kunnen. Hoe je je domeinnaam en mail beschermt tegen nagemaakte mails, staat in e-mail beveiligen tegen phishing en spoofing.

Werkt alle software op je website zichzelf bij?

Nee. WordPress kan zichzelf bijwerken, maar PHP op de server gaat daar niet in mee. En plugins en thema's waarvan de maker gestopt is, of waarvan de licentie is verlopen, worden niet meer automatisch bijgewerkt.

4. Een verouderde PHP-versie op de server

PHP is de programmeertaal op de server waarmee WordPress je pagina's opbouwt. Bezoekers zien het niet, maar zonder PHP draait je website niet. Elke PHP-reeks, zoals 8.3 of 8.4, krijgt tot ongeveer vier jaar na de eerste versie beveiligingsupdates. Daarna stopt het PHP-project ermee. Volgens php.net kun je dan blootstaan aan lekken die niet meer worden gedicht.

PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer, en 8.1 en ouder krijgen ze al niet meer (stand van php.net op 23 oktober 2026).

Er zijn twee soorten PHP-updates. Binnen een reeks verschijnen beveiligingsreleases, zoals 8.3.35 en daarna 8.3.36. Die horen er zo snel mogelijk op. Daarnaast moet je op tijd naar een nieuwere reeks. Die overstap test je eerst, omdat oude plugins soms niet werken met een nieuwe PHP-versie. In de systeemeisen van WordPress staat PHP 8.3 of hoger als aanbeveling. WordPress draait nog op PHP 7.4, maar volgens WordPress.org kunnen zulke oude versies je website blootstellen aan beveiligingslekken.

Het PHP-lek van oktober 2026 liet zien waarom dat telt. Voor de ondersteunde reeksen bracht PHP binnen dezelfde reeks een reparatie uit. Voor PHP 8.1 en ouder kwam er van het PHP-project geen gewone update meer.

Zo controleer je het. Ga in WordPress naar Tools > Sitediagnose > Informatie > Server en kijk bij PHP versie. Sitediagnose waarschuwt ook als je PHP-versie verouderd is.

Wie lost het op? Wie je server beheert. Beheert je hostingpartij PHP, dan moet zij de beveiligingsreleases installeren. Vraag het na als je het niet zeker weet. De overstap naar een nieuwere reeks kies je vaak zelf in het controlepaneel van je hosting. Staat je website bij ViVortis, dan hoort PHP-versiebeheer bij het onderhoud en hoef je die overstap niet zelf te doen. Websites bij ViVortis draaien op de nieuwste PHP-versie die WordPress en de plugins ondersteunen.

5. Updates die minder automatisch gaan dan je denkt

In WordPress stel je automatische updates apart in, voor WordPress zelf, per plugin en per thema. Dat WordPress zichzelf bijwerkt, zegt dus niets over je plugins en je thema.

Betaalde plugins en thema's halen hun updates op bij de maker en hebben daarvoor een actieve licentie nodig. Is die verlopen of nooit ingevuld, dan blijft de plugin op een oude versie staan zonder dat het opvalt.

Mislukt een automatische update, dan stuurt WordPress een e-mail naar het beheeradres van je website. Komt die mail binnen bij iemand die er niet meer werkt, dan weet niemand ervan (zie risico 1).

In juli 2026 zette WordPress.org de reparatie voor een kritiek lek zelf door, via het systeem voor automatische updates. Zijn automatische updates op jouw website uitgezet, door je hostingpartij, een plugin of in de configuratie, vraag dan na hoe zo'n spoedupdate bij jou terechtkomt.

Zo controleer je het. Ga naar Dashboard > Updates. Onder de versie van WordPress staat welke updates van WordPress zelf automatisch gaan. Onder Plugins > Geïnstalleerde plugins zie je per plugin of automatische updates aanstaan. Controleer bij betaalde plugins of de licentie actief is.

Wie lost het op? Jij of je onderhoudspartij. Spreek ook af op wiens naam de betaalde licenties staan, zodat ze niet verdwijnen met een vorige bouwer. Hoe je de instellingen per onderdeel kiest, lees je in automatische updates instellen in WordPress.

6. Plugins en thema's zonder onderhoud of zonder functie

Ook een plugin of thema dat je niet gebruikt, blijft code op je server waarin een lek kan zitten. Een plugin waarvan de maker gestopt is, krijgt geen reparatie meer als er een lek in wordt gevonden.

Toen we de website van BMS Energy vernieuwden, ging het aantal plugins van 24 naar 12. Een deel werd niet meer gebruikt. Elke plugin is iets dat bijgewerkt moet worden en kan botsen met de rest. Lees hoe de website van BMS Energy is opgeschoond.

Wees ook voorzichtig met betaalde plugins of thema's die op een andere site gratis worden aangeboden. Je weet niet wie de code heeft aangepast, en updates van de maker krijg je niet.

Zo controleer je het. Kijk bij Plugins > Geïnstalleerde plugins welke plugins uitgeschakeld zijn en welke je niet herkent. Meldt WordPress dat een plugin niet is getest met jouw versie en krijgt hij al lang geen updates, zoek dan een alternatief dat wel wordt onderhouden. Houd naast je eigen thema alleen één standaardthema van WordPress over, als reserve, en verwijder de andere.

Wie lost het op? Je webbouwer of onderhoudspartij, omdat die weet welke plugin welke functie heeft. Weet je niet wat een plugin doet, maak dan eerst een back-up voordat je hem verwijdert.

Wat staat er op je server dat niemand meer ziet?

Soms veel meer dan de website zelf. Denk aan oude kopieën, testomgevingen, back-upbestanden en de sleutels van koppelingen. Ze vallen buiten elke update, omdat niemand weet dat ze er nog staan.

7. Vergeten kopieën, testsites en losse bestanden

Een testsite op een subdomein, een kopie in een map als /oud of /test, de installatie van je vorige website. Niemand werkt ze bij, dus ze lopen al snel achter op je echte website. Staan ze op dezelfde hosting, dan kan een lek in zo'n vergeten kopie ook je echte website raken.

Ook losse bestanden kunnen een risico zijn. Een back-upbestand in de map van je website kan soms gewoon via een webadres worden gedownload. Zo'n back-up bevat ook wp-config.php, het bestand met de verbinding naar je database. Een vergeten testbestand dat phpinfo() aanroept, toont onder meer je PHP-versie en serverinstellingen en hoort dus weg.

Tot slot de rechten op bestanden en mappen. Die bepalen wie bestanden mag lezen en wijzigen. Staan ze te ruim, dan kan er meer worden aangepast dan nodig.

Zo controleer je het. Vraag je hostingpartij of bouwer om een overzicht van alle installaties en subdomeinen op je hostingaccount. Kijk in het bestandsbeheer van je hosting of er zip- of sql-bestanden of mappen als /oud en /test in de hoofdmap staan.

Wie lost het op? Wie je hosting beheert. Weggooien is meestal de oplossing. Heb je een testomgeving nodig, werk die dan net zo bij als je echte website of zet hem achter een wachtwoord.

8. Sleutels en wachtwoorden die nooit worden vervangen

Je website praat met andere systemen, zoals je betaalprovider, de mailserver die je formulieren verstuurt, je boekhouding of je CRM. Elke koppeling werkt met een sleutel of wachtwoord dat ergens in je website staat, in de instellingen van een plugin of in wp-config.php. Zulke sleutels veranderen niet vanzelf. Zolang je ze niet vervangt, werken ze voor iedereen die ze ooit heeft gezien, ook voor een vorige bouwer.

Zo controleer je het. Maak een lijst van elke koppeling. Noteer wat het is, waar de sleutel staat, wie hem heeft aangemaakt en wanneer hij voor het laatst is vervangen. Een nieuwe sleutel maak je aan in je account bij die dienst. Daarna zet je hem in je website.

Wie lost het op? Jij en je bouwer samen. Jij hebt de accounts bij de diensten, je bouwer weet waar de sleutels in de website staan. Vervang ze in elk geval als iemand met toegang vertrekt en na een beveiligingsprobleem.

Kun je terug als het misgaat?

Alleen als je back-up compleet is, buiten de server staat en je hem ooit echt hebt teruggezet. Of een back-up werkt, weet je pas als je het een keer hebt geprobeerd.

9. Back-ups die nooit zijn teruggezet

Een volledige back-up bevat de bestanden van je website en de database, met je teksten, gebruikers en bij een webshop de bestellingen. Mist een van de twee, dan merk je dat pas als je de back-up nodig hebt.

Waar de back-up staat, telt net zo zwaar. Staat hij alleen op dezelfde server, dan ben je hem kwijt als die server uitvalt of besmet raakt. En hoe lang back-ups bewaard blijven, bepaalt hoe ver je terug kunt. Een besmetting die je pas na weken ontdekt, zit ook in de back-ups van die weken.

Terugzetten is bovendien niet altijd verstandig. Een volledige back-up terugzetten draait ook alle wijzigingen van daarna terug, zoals nieuwe bestellingen, boekingen of aanvragen. Soms is het beter om alleen terug te zetten wat verdwenen is, en daarna na te lopen of het klopt.

Zo controleer je het. Zet een back-up een keer terug op een testomgeving en kijk of alles werkt, ook formulieren en bestellingen. Noteer hoe lang het duurde. Vraag waar de back-ups staan en hoe lang ze bewaard blijven.

Wie lost het op? Je hostingpartij of onderhoudspartij maakt de back-ups. Een proef met terugzetten vraag je apart, want die gebeurt niet vanzelf. Wat er in een back-up hoort, lees je in een back-up van je WordPress-website maken.

Merk je het op tijd als er iets misgaat?

Zonder bewaking merk je een storing pas als een klant het meldt of als er geen bestellingen meer binnenkomen. Sommige problemen zie je zelf niet eens, omdat ze alleen bij je bezoekers optreden.

10. Geen bewaking van je website

Een monitoringdienst controleert je website om de paar minuten van buitenaf en stuurt een melding als hij niet antwoordt. Zo weet je binnen minuten dat je website offline is, in plaats van na een telefoontje.

Een verlopen SSL-certificaat is ook een storing. Je bezoekers krijgen dan een waarschuwing van hun browser te zien in plaats van je website.

Malware is lastiger te zien. Een besmette website stuurt bezoekers soms alleen op mobiel door naar een andere site, of plaatst pagina's in een andere taal die je zelf nooit opent. Een malwarescan en meldingen bij gewijzigde bestanden zien meer dan je eigen ogen. Google Search Console meldt beveiligingsproblemen die Google zelf op je website vindt.

Zo controleer je het. Ga na of je een melding krijgt als je website offline gaat of je certificaat verloopt, en op welk adres die binnenkomt. Open je website af en toe op je telefoon, uitgelogd en via mobiele data.

Wie lost het op? Je onderhoudspartij, of jij met een monitoringdienst. Zorg dat meldingen binnenkomen op een adres dat iemand leest. Hoe je dat inricht, staat in de uptime van je WordPress-website monitoren.

11. Een webshop of formulier dat na een update stil stopt

Een update kan een formulier of de checkout laten stoppen zonder foutmelding. Je website ziet er normaal uit, alleen komen er geen aanvragen of bestellingen meer binnen. Bij een webshop gaat het ook om de koppeling met je betaalprovider, de orderbevestiging en de mails naar jou en je klant.

Een WooCommerce-webshop bewaart daarnaast bestellingen en klantgegevens in de database. Daardoor wegen de risico's over toegang en back-ups bij een webshop zwaarder dan bij een gewone website.

Zo controleer je het. Verstuur na updates zelf een testaanvraag via je formulier. Doe bij een webshop een testbestelling tot en met de betaling. In ons artikel over formulieren die converteren raden we aan die testaanvraag ook elke maand te doen, omdat plugins en updates formulieren geruisloos kunnen breken.

Wie lost het op? Spreek af wie na een update je formulieren en het afrekenen test. Staat dat niet in je afspraak met je onderhoudspartij, dan blijft het bij jou. Hoe je een testbestelling doet zonder het volle bedrag te betalen, staat in een testbestelling doen in WooCommerce.

Weet je wie wat onderhoudt?

Alleen als je het per laag hebt afgesproken. Bij elk risico hierboven hoort iemand die het oplost. Weet je bij een risico niet wie dat is, dan blijft het liggen.

12. Niemand weet wie welke laag bijhoudt

Bij een WordPress-website zijn meestal meerdere partijen betrokken. Jij, je hostingpartij en je webbouwer of onderhoudspartij doen elk een deel. Het gat zit ertussen, bij de taak waarvan ieder denkt dat een ander hem doet. Het PHP-lek van oktober 2026 viel precies in zo'n gat voor wie dacht dat de automatische updates van WordPress alles regelden.

Zo controleer je het. Schrijf bij elke laag de naam van een persoon of bedrijf. Het gaat om WordPress zelf, plugins en thema's, PHP, de server en bestandsrechten, back-ups en terugzetten, bewaking en malwarescans, accounts, domein en sleutels, en het testen na updates. Staat er bij een laag niemand, dan heb je je eerste actiepunt.

Wie lost het op? Jij, want alleen jij maakt afspraken met alle partijen. In juli en september zaten de kritieke lekken in WordPress, in oktober in PHP, en een volgend lek kan in een plugin zitten. Met vaste afspraken per laag hoef je niet bij elk lek opnieuw uit te zoeken wie er aan zet is.

Wat lost websiteonderhoud wel en niet op?

Onderhoud kan een groot deel van de lagen hierboven overnemen, zoals updates, back-ups en bewaking. De toegang binnen je bedrijf, je domeinnaam en je eigen mailbox blijven bij jou, en geen onderhoudspartij kan beloven dat je website nooit een probleem krijgt. Wat erin zit, verschilt per aanbieder, dus vraag per laag na of hij erbij hoort, ook PHP en de server. Twijfel je of je het zelf doet, lees dan wat zelf onderhouden aan tijd en risico vraagt.

Bij ViVortis zitten updates van WordPress, thema en plugins, dagelijkse back-ups, beveiliging, bewaking en PHP-versiebeheer in WordPress onderhoud, samen met hosting en zakelijke e-mail. We voeren updates gecontroleerd uit, met een back-up vooraf en een controle achteraf. Een update is pas klaar als je website daarna nog werkt. Het pakket kost €69 per maand excl. btw en begint met een gratis websitecheck. Staat je website nu ergens anders, dan verhuizen we hem eerst naar onze hosting, voor eenmalig €397 excl. btw. Vraag een gratis websitecheck aan.

Is een website met alle updates onkwetsbaar?

Nee. Een update dicht alleen een lek dat al bekend en gerepareerd is. Tussen het moment dat een lek wordt ontdekt en het moment dat de reparatie er is, ben je ook met alles bijgewerkt kwetsbaar.

Het PHP-lek van oktober 2026 laat zien hoe lang dat kan duren. Volgens de PHP Foundation zag een PHP-ontwikkelaar de eerste tekenen van een van de twee lekken al in 2024. Op 11 augustus 2026 meldde het beveiligingsbedrijf Calif dat het lek te misbruiken was om op afstand code uit te voeren. OpenAI meldde los daarvan dezelfde oorzaak. De reparatie kwam op 21 oktober uit. Wie tot die dag alles netjes had bijgewerkt, draaide toch een versie met het lek.

Daarnaast dekken updates maar een deel van de risico's in dit artikel. Een oud beheerdersaccount, een back-up in de verkeerde map of een sleutel die een vorige bouwer kent, verdwijnt niet met een update.

Ook een firewall vervangt de update niet. Cloudflare, dat in oktober 2026 eigen firewallregels tegen het PHP-lek uitrolde, raadde klanten aan om PHP ook met die regels bij te werken. Een firewall is een extra laag naast de update.

Veiligheid draait daarom om twee dingen. De kans op een probleem klein houden, en snel kunnen handelen als het toch gebeurt. Dat tweede vraagt back-ups die werken, bewaking en een afspraak over wie ingrijpt.

Hoe merk je dat er al iets mis is?

Let op een waarschuwing van Google of je browser en op pagina's of beheerders die je niet kent. Ook doorverwijzingen naar vreemde sites, een melding van je hostingpartij over malware of misbruik en bezoekers die zeggen dat hun virusscanner alarm slaat, zijn signalen. Zie je zoiets, handel dan snel en in de goede volgorde.

WordPress-website gehackt? Dit doe je eerst

Denk je dat je website gehackt is, blijf dan rustig en werk in een vaste volgorde. Schrijf op wat je ziet, meld het bij wie je website beheert en beperk de schade. Ga niet meteen zelf bestanden verwijderen of een oude back-up terugzetten, want dan kunnen sporen en recente gegevens verloren gaan. Die volgorde volgt grotendeels de stappen die WordPress.org na een inbraak aanraadt.

Schrijf op wat je ziet en wanneer. Wat klopt er niet, sinds wanneer, en wat is er kort daarvoor veranderd, zoals een nieuwe plugin of een update? Wie je ook helpt, heeft deze gegevens nodig.
Meld het bij wie je website beheert. Je hostingpartij kan zien of het om een inbraak gaat of om een storing, en bij gedeelde hosting kan het verder gaan dan jouw website. Ben je klant van ViVortis, maak dan via de helpdesk een ticket aan met prioriteit Urgent.
Beperk de schade. Zet je website in onderhoudsmodus of laat hem tijdelijk offline halen, zeker bij een webshop of als bezoekers naar een vreemde website worden doorgestuurd.
Laat een kopie maken van de huidige staat. Ook een besmette kopie helpt bij het onderzoek naar hoe iemand binnenkwam. Een volledige back-up terugzetten draait bovendien recente bestellingen en aanvragen terug.
Wijzig je wachtwoorden vanaf een apparaat dat je vertrouwt. Denk aan WordPress, je hostingpaneel, FTP of SFTP, de database en je e-mail. Scan ook je eigen computer op malware, want soms worden inloggegevens daar afgevangen. Wijzig de wachtwoorden na het opschonen nog een keer.
Ga na of er persoonsgegevens kunnen zijn uitgelekt. Is dat zo, dan moet je dat in veel gevallen binnen 72 uur melden bij de Autoriteit Persoonsgegevens. Je hoeft niet te wachten tot alles is uitgezocht. In haar advies aan WordPress-gebruikers van augustus 2026 wijst de AP erop dat ook een voorlopige melding kan.

Daarna volgt het opschonen. Malware en onbekende beheerders gaan eruit, het lek gaat dicht en alles wordt bijgewerkt. Wil je dat zelf doen, volg dan de stappen bij een besmette WordPress-website. Wil je het laten oplossen, lees dan over website herstellen en beveiligen. Daar begint het met een eerste analyse en een back-up voor onderzoek.

Veelgestelde vragen

Is een beveiligingsplugin genoeg?

Nee. Een beveiligingsplugin draait binnen WordPress. Hij helpt tegen aanvallen op je inlogpagina en meldt gewijzigde bestanden. Maar hij werkt PHP niet bij, maakt geen back-up buiten de server en ruimt geen oude accounts op. Welke plugins er zijn en wat ze doen, staat in beveiligingsplugins voor WordPress vergeleken.

Is WordPress minder veilig dan een websitebouwer?

Het is een ander model. Bij een websitebouwer regelt de aanbieder de software en de server. Bij WordPress doe je dat zelf of laat je het doen door een onderhoudspartij. Dat geeft meer vrijheid, maar ook meer om bij te houden. Welke keuze bij je past, lees je in JouwWeb of WordPress.

Hoe vaak moet ik mijn website controleren?

Kijk minimaal één keer per week onder Dashboard > Updates en voer beveiligingsupdates direct uit. Loop de zelftest uit dit artikel opnieuw na als iemand met toegang vertrekt, als je van bouwer of hostingpartij wisselt en na elk beveiligingsprobleem.

Is mijn website veilig als hij een SSL-certificaat heeft?

Niet alleen daardoor. Een SSL-certificaat zorgt dat wat een bezoeker invult, zoals een wachtwoord of een formulier, versleuteld over internet gaat. Tegen zwakke wachtwoorden, verouderde plugins of een lek in PHP helpt het niet. Meer hierover lees je in wat een SSL-certificaat is.

Wat kost herstel als het toch misgaat?

Bij ViVortis kost herstel na malware of ongewenste toegang vanaf €249 excl. btw, eenmalig per herstel. Na de eerste analyse krijg je één vaste prijs. Die hangt af van hoe groot de besmetting is en of er een bruikbare back-up is. Lees ook wat herstel na malware inhoudt.

Hoe veilig is jouw WordPress-website? 12 risico's om zelf na te lopen