WordPress beveiligen — 10 stappen die echt werken (2026)

WordPress draait op 43% van alle websites wereldwijd. Dat maakt het populairder dan alle andere CMS-en bij elkaar — en precies daarom ook het meest gescande doelwit voor geautomatiseerde aanvallen. Er draaien permanent bots op het internet die miljoenen WordPress-sites per dag afstruinen op bekende zwakheden: verouderde plugins, open XML-RPC endpoints, standaard tabelnamen in de database.

Goed nieuws: de overgrote meerderheid van die aanvallen mikt op dingen die je gewoon kunt dichtzetten. Ik ruim gehackte WordPress-sites op als dagelijkse klus. Vrijwel altijd is de oorzaak hetzelfde: een plugin die maanden niet was bijgewerkt, een zwak wachtwoord zonder 2FA, of een uploads-map waar PHP in uitgevoerd kon worden. De aanvallen zelf zijn zelden slim — ze zijn geautomatiseerd en massaal. Wie zijn basis op orde heeft, valt buiten het net.

1. Updates — core, plugins én PHP

Dit is geen verrassing, maar het blijft de #1 oorzaak van gehackte WordPress-sites: verouderde software. Een kwetsbaarheid in een populaire plugin gaat soms binnen uren na de beveiligingsmelding de bots in — als jij dan nog op de oude versie draait, ben je doelwit.

Hoe dat concreet werkt: beveiligingsonderzoekers ontdekken een lek in, zeg, een contactformulier-plugin. Ze melden dit bij de pluginontwikkelaar, die een patch uitbrengt. Die patch wordt gepubliceerd op WordPress.org, inclusief release-notes die beschrijven wat er is gerepareerd. Bots lezen die release-notes automatisch en weten daarna precies wat ze moeten proberen op sites die nog niet hebben geüpdatet. De race is letterlijk op.

Wat je doet:

• WordPress core: automatische minor updates staan standaard aan — laat dat zo. Voor major updates (van 6.7 naar 6.8) eerst een backup, dan updaten. Je kunt major updates ook automatiseren via wp-config.php:
  define( 'WP_AUTO_UPDATE_CORE', true ); — maar test dat eerst op een stagingomgeving.
• Plugins en thema's: wekelijks checken via het dashboard (updates-icoontje linksboven), of stel automatische updates in per plugin. Dat doe je via Plugins → Automatisch bijwerken inschakelen. Niet alle plugins zijn stabiel genoeg voor auto-updates — bij twijfel: handmatig na backup.
• PHP-versie: WordPress draait op PHP, en ook die heeft regelmatig beveiligingslekken. PHP 7.4 en 8.0 zijn End of Life — als jouw site daar nog op draait, loop je patches mis. Check je PHP-versie via de Sitestatus-pagina in je WordPress-dashboard (Gereedschappen → Sitestatus). Updaten gaat via je hostingpanel. Zie ook: PHP-versie veilig upgraden.

2. Verwijder wat je niet gebruikt

Veel mensen denken: "die plugin staat uit, dus hij doet niets". Dat klopt niet helemaal. Een gedeactiveerde plugin staat nog steeds op je server. De bestanden zijn bereikbaar, en sommige aanvalsvectoren werken ook via gedeactiveerde plugins — ze bellen direct naar een bestand, niet via WordPress.

Hetzelfde geldt voor thema's. WordPress installeert standaard een of meerdere reserve-thema's (TwentyTwentyFour, TwentyTwentyFive). Die worden niet gebruikt, maar zitten wel op je server en moeten ook geüpdatet worden. Als ze dat niet zijn, vormen ze een lek.

Ruim op:

• Inactieve plugins → niet deactiveren maar verwijderen
• Alle thema's behalve je actieve thema en één reserve (voor als je actieve thema een fout heeft)
• Demo-content die via een thema is geïmporteerd
• De standaard "Hello World!" post en "Sample Page" — die roepen spambots aan
• Ongebruikte gebruikersaccounts, zeker als die administrator-rechten hebben

Minder code op je server = minder aanvalsvlak. Simpele rekensom.

3. Sterke wachtwoorden en tweefactor-authenticatie (2FA)

Tweefactor-authenticatie klinkt ingewikkeld, maar het is eigenlijk simpel: naast je wachtwoord geef je ook een code op die op dat moment op je telefoon staat. Die code verandert elke 30 seconden. Zelfs als iemand je wachtwoord heeft, kunnen ze zonder die code niet inloggen.

Dit is de meest effectieve maatregel die je kunt nemen voor het admin-account. Brute-force aanvallen — waarbij bots duizenden wachtwoordcombinaties proberen — worden er volledig door gesloopt. Gestolen wachtwoorden (uit een datalek bij een andere site) zijn ook nutteloos zonder de 2FA-code.

Wachtwoorden:

• Minimaal 16 tekens, gegenereerd door een wachtwoordmanager. Bitwarden is gratis en werkt prima; 1Password kost een paar euro per maand maar is friendlier in gebruik.
• Nooit hetzelfde wachtwoord voor je WordPress-account als voor je e-mail, hosting-panel, of andere diensten. Als één account lekt, moet de rest veilig blijven.
• De gebruikersnaam "admin" is het eerste wat bots proberen — gebruik die naam niet.

2FA instellen:

Installeer de plugin Two Factor — gemaakt door WordPress core-developers zelf, gratis, lichtgewicht. Na activatie ga je naar Gebruikers → Jouw profiel → Tweestapsverificatie. Kies "Time Based One-Time Password (TOTP)" en scan de QR-code met een authenticator-app op je telefoon (Google Authenticator, Authy of Microsoft Authenticator — allemaal gratis).

Sla de back-upcodes op een veilige plek op. Als je je telefoon kwijt bent zonder back-upcodes, kun je jezelf permanent buitensluiten.

4. Beperk inlogpogingen

Standaard WordPress laat iedereen oneindig vaak proberen in te loggen op /wp-login.php. Dat is een open uitnodiging voor bots die duizenden wachtwoord-combinaties per minuut proberen — ook wel een brute-force aanval genoemd.

De fix: na een X aantal mislukte pogingen blokkeert de plugin dat IP-adres voor een bepaalde tijd. Drie mislukte pogingen binnen 5 minuten → 20 minuten geblokkeerd. Zo werkt het niet meer de moeite waard voor geautomatiseerde aanvallen.

Plugins:

• Limit Login Attempts Reloaded (gratis) — simpel en effectief, meer dan 2 miljoen actieve installaties
• WP Cerber Security — iets uitgebreider, ook gratis basisversie
• Via Cloudflare — als je toch Cloudflare gebruikt (zie stap 10), kun je rate-limiting instellen op DNS-niveau vóórdat het request je server bereikt. Dat is nog effectiever.

Een uitgebreidere aanpak zonder security-plugin vind je in het artikel brute-force op wp-login.php voorkomen zonder Wordfence — inclusief .htaccess methodes en server-niveau configuratie.

5. Verberg of bescherm de admin-URL

Iedereen die ooit een WordPress-site heeft gezien, weet dat de adminpagina op /wp-admin/ of /wp-login.php staat. Inclusief alle bots. Door die URL te veranderen, vallen geautomatiseerde aanvallen in het luchtledige.

Plugin die dit doet: WPS Hide Login. Na installatie stel je in dat je loginpagina voortaan op iets willekeurigs staat, zoals /mijn-toegang-2026/. Bots die hardcoded /wp-login.php proberen, krijgen een 404 en gaan weg.

Een stap verder: HTTP basic auth bovenop je admin-URL. Dat is het browser-popup-inlogvenster dat je soms ziet op beveiligde pagina's — een tweede laag vóór de WordPress-loginpagina zelf. Dit werkt via een bestand in je /wp-admin/ map. Vraag je hoster hoe je dit kunt instellen als je er zelf niet uitkomt.

6. File editing uitzetten in wp-config.php

WordPress heeft standaard een ingebouwde editor voor thema- en plugin-bestanden, bereikbaar via het dashboard onder Weergave → Themabestandeditor. Handig voor kleine aanpassingen — maar ook een directe route voor een aanvaller die eenmaal admin-toegang heeft. Via die editor kunnen ze PHP-code schrijven in je thema, waarna ze volledige controle hebben over de server.

Je schakelt dit uit door twee regels toe te voegen aan wp-config.php, het hoofdconfiguratiebestand van WordPress dat in de webroot staat. Zoek de regel /* That's all, stop editing! */ en zet dit erboven:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

DISALLOW_FILE_EDIT schakelt alleen de bestandseditor uit. DISALLOW_FILE_MODS gaat een stap verder: het blokkeert ook de mogelijkheid om plugins en thema's te installeren of updaten via het dashboard. Dat is veiliger, maar betekent wel dat je voor elke update via FTP of het hostingpanel moet werken — iets om over na te denken voordat je het inschakelt.

Voor de meeste sites is DISALLOW_FILE_EDIT het juiste compromis: editor weg, updates via dashboard nog mogelijk.

7. Database tabelprefix aanpassen

WordPress slaat alles op in een database, en de tabellen daarin hebben standaard namen als wp_users, wp_options, wp_posts. Die prefix wp_ kennen aanvallers ook — SQL-injectie-aanvallen zijn er soms hardcoded op ingesteld.

Door de prefix te veranderen naar iets willekeurigs (wpx7q_, mijnsite_, wat dan ook) werken die hardcoded aanvallen niet meer.

Bij een nieuwe WordPress-installatie is dit eenvoudig: in het installatieproces wordt gevraagd om een tabelprefix — verander wp_ naar iets anders. Klaar.

Bij een bestaande site is dit risicovol. De prefix staat in wp-config.php maar ook in de database zelf — in de tabel wp_usermeta en wp_options staan directe verwijzingen naar de oude naam. Een rename die niet goed gaat breekt de site compleet. Als je dit wil doen: eerst een volledige backup, dan via een plugin als "Brozzme DB Prefix Tools", en test daarna alles grondig.

Eerlijk gezegd: voor bestaande sites is dit de maatregel met de laagste winst/risico-verhouding van dit hele lijstje. Als je hier twijfelt, sla hem over en concentreer je op de andere stappen.

8. XML-RPC blokkeren

XML-RPC is een verouderd onderdeel van WordPress dat ooit bedoeld was om via desktop-apps te bloggen. Tegenwoordig gebruikt vrijwel niemand het meer voor dat doel — maar aanvallers wel, op twee manieren:

1. Brute-force via XML-RPC: via één XML-RPC request kunnen honderden wachtwoord-combinaties tegelijk geprobeerd worden. De standaard login-blokkering (stap 4) vangt dit niet altijd op.
2. DDoS-doorstuur: een aanvaller kan jouw WordPress-site als tussenschakel gebruiken om aanvallen op andere sites te sturen, via de system.multicall methode.

Controleer eerst of je het gebruikt. Jetpack van Automattic heeft XML-RPC nodig voor sommige functies. Mobiele WordPress-apps ook. Als je die niet gebruikt: blokkeer XML-RPC via .htaccess:

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Of via een plugin als Disable XML-RPC (één klik, geen configuratie). Als je twijfelt of je XML-RPC gebruikt: blokkeer het voor een week en kijk of er iets kapotgaat. Vrijwel altijd: niets.

Meer over .htaccess in het algemeen staat in het artikel .htaccess uitgelegd.

9. PHP-uitvoering blokkeren in /uploads/

Dit is de maatregel die ik in de praktijk het meest verschil zie maken bij hack-opruimingsklussen. Leg het even uit:

De map /wp-content/uploads/ is de plek waar WordPress bestanden opslaat die via het dashboard worden geüpload — afbeeldingen, PDF's, Word-documenten. Die map is noodzakelijkerwijs bereikbaar via een publieke URL (anders kunnen afbeeldingen niet worden getoond op je site). En aanvallers proberen daar misbruik van te maken door een PHP-bestand te uploaden — disguised als afbeelding, of via een lek in een upload-plugin. Eenmaal geüpload, roepen ze het PHP-bestand aan via zijn URL, en hebben ze toegang tot de server.

De fix: een .htaccess bestand in de uploads-map dat PHP-uitvoering blokkeert. Ze kunnen dan nog steeds proberen iets te uploaden, maar het aanroepen via een URL geeft een 403 en doet niets.

Maak een bestand aan met de naam .htaccess in /wp-content/uploads/ met deze inhoud:

<FilesMatch "\.(php|php5|phtml|pl|py|jsp|asp|sh|cgi)$">
    Require all denied
</FilesMatch>

De uitgebreidere versie (met meerdere extensies) is bewust zo breed — aanvallers proberen ook .php5, .phtml en andere varianten als .php geblokkeerd is.

Hetzelfde .htaccess bestand kun je ook plaatsen in /wp-includes/ — die map mag ook nooit directe PHP-aanroepen van buitenaf verwerken.

10. Web Application Firewall (WAF)

Een WAF is — zonder al te veel technisch jargon — een filter tussen het internet en jouw website. Elke bezoeker die jouw site opent, gaat eerst langs de WAF. Die kijkt of het request er normaal uitziet. SQL-injectie-pogingen, bekende exploit-patronen, verzoeken van bekende malware-IP's: dat alles wordt geblokkeerd voordat het WordPress bereikt.

Er zijn drie niveaus, in oplopende kwaliteit en prijs:

Plugin-based WAF (gratis)

Wordfence (gratis) of Solid Security (gratis) installeren een WAF direct in WordPress. Ze leren van aanvallen die ze zien en blokkeren bekende patronen. Nadeel: ze draaien in PHP, dus de aanval bereikt al je server voordat hij geblokkeerd wordt. Dat kost CPU, en bij volumeaanvallen (DDoS) helpen ze niet.

Voor een gewone MKB-site of blogsite is de gratis Wordfence prima als basislaag.

Cloud-based WAF (€10–20/maand)

Cloudflare Pro (€20/maand) of Sucuri Firewall (€10/maand) filteren verkeer op DNS-niveau — aanvallen bereiken je server letterlijk niet eens. Cloudflare heeft ook een gratis plan dat al basisbescherming biedt, maar de WAF-regels zitten in het betaalde plan.

Voor webshops, sites met klantdata of sites die eerder zijn gehackt is dit mijn standaardadvies. Het prijsverschil met niets doen is verwaarloosbaar vergeleken met de schade van een hack.

Server-niveau WAF (gratis, vereist VPS)

ModSecurity met de OWASP Core Rule Set draait direct op de webserver en filtert vóór PHP. Op shared hosting is dit vaak standaard ingeschakeld (vraag je hoster). Op een VPS of dedicated server kun je het zelf configureren — dat vereist wat serverkennis maar is eenmalig werk.

De ideale opstelling: ModSecurity op servervlak + Cloudflare ervoor. Twee lagen die elkaar aanvullen.

Backups en monitoring — de vangvloer als het toch fout gaat

Geen beveiliging is 100%. Wat doe je als het ondanks alles toch misgaat?

Backups zijn je enige echte reddingslijn. Eén regel: bewaar ze op een andere locatie dan je hosting. Als je hosting-account gecompromitteerd is, is een backup die op dezelfde server staat ook gecompromitteerd. Automatische backups naar Google Drive, Dropbox of Amazon S3 zijn de standaard.

• UpdraftPlus (gratis basisversie, Premium ~€70/jaar): de meest gebruikte backup-plugin voor WordPress. Dagelijks automatisch, direct naar cloud-opslag.
• WPVivid Backup: goed alternatief, iets eenvoudiger interface.
• Test je backup: een backup waarvan je nooit hebt gecontroleerd of die ook terugzetbaar is, geeft een vals gevoel van veiligheid. Herstel hem minimaal één keer per jaar op een testomgeving.

Monitoring — weten dat je site gehackt is vóórdat een klant je belt:

• Wordfence Scan vergelijkt jouw WordPress-bestanden met de officiële versies. Als er iets onverwachts verandert, krijg je een e-mail.
• WP Activity Log houdt bij wie wat wanneer heeft gedaan in het dashboard. Bij een incident is dit goud: je kunt terugzien welk account iets heeft uitgevoerd en wanneer.
• Google Search Console: als Google malware op je site detecteert, krijg je een melding in Search Console. Abonneer op e-mailmeldingen. Zie ook: Google Search Console uitgelegd.
• Uptime-monitoring: een dienst als UptimeRobot (gratis) controleert elke 5 minuten of je site bereikbaar is en stuurt een sms of mail als dat niet zo is.

Als je toch te maken krijgt met een gehackte site: zie Chinese spam verwijderen, Japanse SEO-spam verwijderen, of pharma hack verwijderen — afhankelijk van wat je aantreft. Of schakel direct hulp in bij hack-herstel.

Veelgestelde vragen

Hoe weet ik of mijn WordPress gehackt is?

De meeste hacks zijn onzichtbaar voor de eigenaar — de site werkt gewoon, maar op de achtergrond lopen er processen die je er niet op hebt gezet. Signalen om op te letten: Google waarschuwt bezoekers voor je site (rode foutpagina), je ontvangt meldingen dat jouw domein spam verstuurt (zie dit artikel), je Google-ranking daalt plotseling, bezoekers worden doorgestuurd naar vreemde sites terwijl jij zelf niets ongewoons ziet, of er staan onbekende bestanden in je WordPress-installatie. Wordfence Scan of de site-audit tool op deze site kunnen een eerste diagnose geven.

Welke WordPress beveiligingsplugin is de beste?

Voor de meeste sites is Wordfence (gratis versie) een solide startpunt: het scant bestanden, blokkeert bekende aanvallen en geeft inzicht in het verkeer dat binnenkomt. Solid Security (vroeger iThemes Security) is een goed alternatief als je Wordfence te zwaar vindt voor je server. Beide zijn gratis en actief onderhouden. Voor serieuze bescherming — bij webshops of sites met klantdata — is een cloud-WAF (Cloudflare Pro, Sucuri) de betere investering, los van welke plugin je gebruikt.

Is WordPress standaard veilig?

De WordPress-core zelf is redelijk goed beveiligd — er zit een actief security-team achter dat snel patches uitbrengt. Het probleem zit bijna altijd in plugins, thema's of een slechte serverconfiguratie. Een verse WordPress-installatie zonder extra plugins is behoorlijk solide. Maar de meeste sites draaien tientallen plugins, waarvan sommige al jaren niet zijn bijgewerkt of nooit meer worden onderhouden. Dát is waar aanvallers op mikken, niet op de core zelf.

Hoe vaak moet ik WordPress updaten?

Minor updates (van 6.7.1 naar 6.7.2) mogen automatisch: die bevatten bijna altijd security-fixes en zelden iets dat iets breekt. Major updates (van 6.7 naar 6.8) doe je handmatig, na een backup, het liefst eerst getest op een stagingomgeving. Plugins en thema's: minimaal wekelijks checken. Bij een security-melding voor een plugin die je draait, wil je binnen 24 uur geüpdatet zijn — dat is wanneer bots actief zijn.

Wat kost het om WordPress te beveiligen?

Alles in dit stappenplan kost je alleen tijd — de plugins zijn gratis. Wil je er een cloud-WAF bij, dan kost Cloudflare Pro €20/maand en Sucuri Firewall €10/maand. Een UpdraftPlus Premium-licentie voor automatische backups naar cloud-opslag kost €70/jaar. Als je het liever uitbesteedt: ik doe complete WordPress hardening inclusief controle en documentatie voor een vast tarief — neem contact op voor een indicatie.

Mijn WordPress is gehackt — wat nu?

Niet in paniek raken en niets zomaar verwijderen. Maak eerst een backup van de huidige staat, ook van gehackte bestanden — die heb je nodig om te begrijpen wat er is binnengekomen. Check dan voor specifieke hack-varianten de kennisbank: Chinese spam, Japanse SEO-spam en pharma hack zijn de drie meest voorkomende. Als je er zelf niet uitkomt of de site is zakelijk kritiek: hack-opruimen is mijn dagelijkse werk.