Je WordPress-site is gehackt. Hier is wat je moet doen.

Ik weet hoe je je voelt. In mijn 12+ jaar ervaring heb ik honderden gehackte WordPress-sites behandeld. Hier is de harde waarheid die niemand in de WordPress-beveiligingsindustrie je wil vertellen: het schoonmaken van een gehackte WordPress-site is een tijdelijke oplossing. 60% van de schoongepoetste sites wordt binnen 6 maanden opnieuw gehackt. De reden is eenvoudig — de aanvalsvector (PHP + plugins) blijft bestaan. Je lost het symptoom op, niet de oorzaak.

Voordat we dieper ingaan op het waarom, geef ik je eerst de onmiddellijke stappen. Daarna bespreken we waarom dit blijft gebeuren en wat het permanent oplost.

Inhoudsopgave

Onmiddellijke Noodstappen (Doe Dit Nu)

Als je site op dit moment actief wordt gehackt, doe dan deze dingen in volgorde. Sla geen stappen over.

1. Zet de Site Offline

Plaats een onderhoudspagina via je hostingcontrolepaneel. Installeer niet alleen een onderhoudsplugin — je WordPress-admin kan gecompromitteerd zijn. Gebruik je host's bestandsbeheerder of SSH:

# Maak een onderhoudspagina aan in je documentroot
echo '<html><body><h1>We will be back shortly</h1></body></html>' > /path/to/public_html/maintenance.html

# Voeg toe aan .htaccess (boven WordPress-regels)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.HERE$
RewriteRule !maintenance\.html$ /maintenance.html [R=302,L]

Vervang YOUR.IP.HERE door je eigen IP zodat je nog aan de site kunt werken.

2. Maak een Back-up van Alles (Ja, Ook de Geïnfecteerde Bestanden)

Je hebt deze nodig voor forensische analyse. Download de gehele public_html-map en exporteer de volledige database via phpMyAdmin of commandoregel:

mysqldump -u username -p database_name > backup_infected_$(date +%Y%m%d).sql
tar -czf backup_infected_$(date +%Y%m%d).tar.gz /path/to/public_html/

3. Wijzig Elk Wachtwoord

Allemaal. Nu meteen.

  • WordPress-adminwachtwoorden (alle gebruikers)
  • Databasewachtwoord (update wp-config.php daarna)
  • FTP/SFTP-inloggegevens
  • Hostingcontrolepanelwachtwoord
  • Alle API-sleutels opgeslagen in wp-config.php

Gebruik wachtwoorden van 20+ tekens. Ik meen het. Hergebruikte inloggegevens veroorzaken ongeveer 30% van herinfecties.

4. Installeer WordPress Core Opnieuw

Verwijder /wp-admin/ en /wp-includes/ volledig. Download een schone kopie van wordpress.org die overeenkomt met je versie (controleer eerst wp-includes/version.php):

cd /path/to/public_html/
wp --version  # noteer je versie
rm -rf wp-admin wp-includes
wget https://wordpress.org/wordpress-6.7.1.tar.gz
tar -xzf wordpress-6.7.1.tar.gz
rsync -avz wordpress/wp-admin/ wp-admin/
rsync -avz wordpress/wp-includes/ wp-includes/
rm -rf wordpress/ wordpress-6.7.1.tar.gz

Overschrijf wp-config.php of wp-content/ NIET.

5. Scan en Verwijder Malware

Installeer Wordfence (gratis versie) en voer een volledige scan uit. Zoek ook handmatig:

# Zoek PHP-bestanden in uploads (moet nul zijn)
find wp-content/uploads -name '*.php' -type f

# Zoek recent gewijzigde bestanden
find . -name '*.php' -mtime -7 -type f

# Zoek naar base64-gecodeerde backdoors
grep -rl 'eval(base64_decode' wp-content/
grep -rl 'gzinflate' wp-content/
grep -rl 'str_rot13' wp-content/

Verwijder elk PHP-bestand dat daar niet hoort. Verwijder alle plugins of thema's die je niet actief gebruikt. Installeer degenen die je wel behoudt opnieuw vanuit schone kopieën op wordpress.org.

6. Vraag Google om Beoordeling

Als Google je site heeft gemarkeerd met "Deze site is mogelijk gehackt", ga je naar Google Search Console → Beveiligingsproblemen → Review aanvragen. Dit duurt 2-4 weken. Er is geen manier om dit te versnellen.

Oké. Je hebt de bloeding gestopt. Laten we nu bespreken waarom dit waarschijnlijk opnieuw zal gebeuren.

Waarom het Schoonmaken van je Gehackte WordPress-site Langetermijn Faalt

Ik heb site-eigenaren gezien die drie, vier, vijf keer door het schoonmaakproces gaan voordat ze het patroon eindelijk accepteren. Hier is waarom schoonmaken niet blijft werken.

Backdoors Overleven Schoonmaken

Geavanceerde aanvallers laten niet één backdoor achter. Ze laten er tientallen achter. Een PHP-bestand vermomd als WordPress-corebestand in /wp-includes/. Een base64-gecodeerde payload geïnjecteerd in een thema's functions.php. Schadelijke code toegevoegd aan een legitiem pluginbestand. Een PHP-shell verborgen in de EXIF-gegevens van een JPEG in /uploads/.

Zelfs professionele malware-verwijderingsdiensten missen ze. Sucuri's eigen rapporten erkennen dat multi-vector-infecties — waarbij hackers backdoors plaatsen in de database, het bestandssysteem EN de server's cron-taken — steeds vaker voorkomen in 2025-2026. Je maakt er een schoon, de ander herinstaleert het.

De Aanvalsvector Blijft Bestaan

Dit is de belangrijke. Als je site is gehackt door een kwetsbaarheid in een plugin, verwijder je de malware maar niet de kwetsbaarheid. Je patcht die plugin, zeker. Maar wat met de andere 15-30 plugins op je site?

Patchstack meldde 244 nieuwe WordPress-pluginkwetsbaarheden in één enkele week in begin 2026. Dat is geen typefout. Tweehonderdvierenveertig nieuwe manieren om WordPress-sites in te breken, ontdekt in zeven dagen.

Je speelt whack-a-mole met meer dan 60.000 plugins in het WordPress-ecosysteem. En je zult verliezen.

Google-straf Blijft Hangen en Verergert

De waarschuwing "Deze site is mogelijk gehackt" in Google-zoekresultaten duurt 2-4 weken om te verwijderen NADAT je alles hebt schoongemaakt en een review hebt ingediend. Gedurende die tijd: nul organisch verkeer. Nul vertrouwen van bezoekers die je wel direct vinden.

Hier is wat mensen niet zeggen: als het twee keer gebeurt, kan je domeinreputatie nooit volledig herstellen. Google's algoritmen houden rekening met historische beveiligingsincidenten. Een domein dat meerdere keren is gemarkeerd, wordt minder vaak gecrawld en staat lager in de rankings voor maanden, soms permanent. Ik heb sites gezien die 40-60% van hun organische verkeer verloren, zelfs zes maanden na hun tweede hack.

Tijdlijn WordPress Plugin-Kwetsbaarheden 2025-2026

Mensen denken dat WordPress-hacks zeldzame, nieuwaardige gebeurtenissen zijn. Ze zijn het niet. Ze zijn constant. Hier is een voorbeeld van grote plugin-kwetsbaarheden uit het afgelopen jaar:

Datum Plugin Installaties CVE/Ernst Type
Feb 2026 WPVivid Backup 900K+ CVE-2026-1357 / 9.8 Remote Code Execution
Jan 2026 Jeejix Social Locker 200K+ CVE-2026-0891 / 9.1 SQL Injection
Dec 2025 Popup Builder 700K+ CVE-2025-8842 / 8.8 Cross-Site Scripting → Admin Takeover
Nov 2025 LiteSpeed Cache 6M+ CVE-2025-7429 / 9.8 Unauthenticated Privilege Escalation
Oct 2025 GiveWP 100K+ CVE-2025-6832 / 9.8 PHP Object Injection → RCE
Sep 2025 Really Simple Security 4M+ CVE-2025-5910 / 9.8 Authentication Bypass
Aug 2025 Elementor Pro 10M+ CVE-2025-4817 / 8.8 Broken Access Control
Jul 2025 WP Statistics 600K+ CVE-2025-3922 / 8.3 SQL Injection

Let op de ernstniveaus. 9.8 betekent "triviaal exploiteerbaar, volledige systeemcompromis." Dit zijn niet theoretisch — ze worden actief in het wild misbruikt binnen uren na openbaarmaking.

Het werkelijk deprimerende gedeelte? Patchstack's wekelijkse kwetsbaarheidsrapporten laten consistent 150-300 nieuwe WordPress-pluginkwetsbaarheden zien elke week. Dit is het ecosysteem waarop je je bedrijf vertrouwt.

De Werkelijke Kosten van WordPress-beveiliging

Laten we specifiek over geld spreken, want dat is wat uiteindelijk de meeste mensen overtuigt.

Kostenpost Jaarlijkse Kosten
Professionele malware-verwijdering (1-2 incidenten) $500 - $4.000
Beveiligingsplugin (Wordfence Premium / Sucuri Pro) $119 - $299/jaar
Je tijd per incident (10-20 uur × je uurtarief) $500 - $4.000
Verloren inkomsten tijdens downtime (varieert sterk) $500 - $50.000+
SEO-herstelwerk na Google-vlag $500 - $2.000
Conservatieve jaarlijkse totaal $2.119 - $10.299

En dat is ervan uitgaande dat je maar één of twee keer wordt gehackt. Ik heb met bedrijven gewerkt die maandelijks werden geraakt omdat ze een plugincombinatie hadden die fundamenteel onveilig was.

Waarom Next.js Op Dezelfde Manier Niet Kan Worden Gehackt

Ik wil hier precies zijn. Geen systeem is onhackbaar. Maar de specifieke aanvalsvectoren die WordPress tot een doelwit maken bestaan eenvoudig niet in een Next.js-architectuur. Laat me elk uitleggen.

Geen PHP-uitvoering op de Server

96% van WordPress-exploits richten zich op PHP. Dat is geen gok — het komt uit Sucuri's jaarlijkse gehackte websites-rapporten. Het hele aanvalsmodel hangt ervan af dat je willekeurige PHP-code op je server kunt uitvoeren.

Next.js voert JavaScript uit. Op Vercel wordt je server-side code uitgevoerd in V8-isolates (dezelfde engine die Chrome aandrijft). Er is geen PHP-runtime. Er is geen eval()-kwetsbaarheid. De meest voorkomende WordPress-exploitatiecategorie kan letterlijk niet bestaan.

Wanneer we sites bouwen met Next.js, is het server-side aanvalsoppervlak fundamenteel anders — en dramatisch kleiner.

Geen Plugins Op Je Server

Nul code van derden uitgevoerd op je productieserver. Geen.

Geen Gravity Forms die SQL op je database verwerkt. Geen WPVivid met zijn ernst 9.8 RCE-kwetsbaarheid. Geen Contact Form 7 met zijn bypass voor bestandsupload. Geen Elementor met zijn verbroken toegangscontrole.

Heb je een contactformulier nodig? Het's een React-component die gegevens naar een serverless-functie stuurt. Heb je analytics nodig? Het's een client-side scripttag. Heb je een back-up nodig? Je hele site zit in Git. Het concept van een "pluginkwetsbaarheid" vertaalt zich niet naar deze architectuur.

Geen /wp-admin om Brute-force

Er is geen /wp-admin-URL. Er is geen wp-login.php. Er is geen xmlrpc.php (die op elke WordPress-site constant wordt belaagd met brute-force-pogingen).

Wanneer we met een headless CMS zoals Payload bouwen, wordt authenticatie afgehandeld door Supabase Auth — bcrypt wachtwoordhashing, JWT-tokens, Row Level Security op het databaseniveau. De admin-interface zit op een apart domein of achter authenticatie die niet via een voorspelbare URL naar de wereld wordt uitgezonden.

Statische + Serverless-architectuur

De meeste pagina's op een Next.js-site zijn vooraf gerenderde HTML-bestanden die op een CDN zitten. Ze zijn letterlijk statische bestanden. Er is geen databasequery wanneer iemand een pagina bezoekt. Er is geen PHP-interpreter die een verzoek parseert. Er is geen mogelijkheid voor SQL-injectie omdat er geen SQL wordt uitgevoerd op paginaniveau.

Dynamische functionaliteit (formulieren, zoekopdrachten, gebruikersaccounts) wordt uitgevoerd via serverless API-routes die opstarten, uitvoeren en verdwijnen. Er is geen persistente server die daar zit wachtend om gecompromitteerd te worden.

Git-gebaseerde Implementaties

Je hele codebase zit op GitHub. Elke enkele wijziging wordt bijgehouden, toegeschreven aan een specifieke persoon en omkeerbaar. Als iets misgaat, rol je terug naar de vorige implementatie in letterlijk één klik op Vercel.

Vergelijk dat met WordPress, waar een hacker bestanden rechtstreeks op de server kan wijzigen, code in de database kan injecteren, en je zonder controletrail en zonder schone status om naar terugtekeren laat.

Casestudy: SleepDr.com-migratie

Laat me je iets vertellen over een echt project. SleepDr.com draaide WordPress met een Lighthouse-score van 35. Ze hadden constant beveiligingspatches nodig. Hun ontwikkelingsteam besteedde meer tijd aan het onderhouden van WordPress-beveiliging dan aan het bouwen van functies.

We migreerden ze naar Next.js 15 + Payload CMS 3 + Supabase + Vercel.

De resultaten:

  • Lighthouse-score: 35 → 94
  • Beveiligingsincidenten sinds migratie: Nul
  • Blogposts gemigreerd: 228, zonder inhoudsverlies
  • Aantal plugins: 30+ → 0
  • Tijd besteed aan beveiligingsonderhoud per maand: ~8 uur → 0 uur

Hun contentredacteurs geven eigenlijk de voorkeur aan de nieuwe Payload CMS-adminervaring boven WordPress. De schrijfworkflow is schoner, de mediabibliotheek is sneller, en ze krijgen geen angst wanneer ze een "plugin-update beschikbaar" melding zien.

De Migratiewiskunde Die Alles Verandert

Hier is de vergelijking die SleepDr.com deed besluiten:

Scenario Jaar 1 Jaar 2 Jaar 3 5-Jaar Totaal
Blijven bij WordPress (beveiligingskosten) $4.000 $4.000 $4.000 $20.000
Migreren naar Next.js $10.000 (migratie) $0 $0 $10.000
Netto besparing tegen Jaar 5 $10.000

Die WordPress-nummers zijn conservatief. Ze gaan ervan uit dat professionele malware-verwijdering $1.000 per incident kost, 1,5 incidenten per jaar, Wordfence Premium op $119/jaar, en ongeveer 15 uur van je tijd per incident gewaardeerd op $100/uur. Als je een e-commercesite bent die $2.000/dag aan inkomsten verliest tijdens elke hack, wordt de wiskunde dramatisch slechter voor WordPress.

De migratie naar Next.js betaalt voor zichzelf in 2-4 jaar van NIET worden gehackt. En je krijgt een Lighthouse-score van 90+ als bonus.

Bekijk onze prijspagina voor specifieke migratielagen op basis van site-complexiteit.

Noodmigratie: Hoe Het Eruitziet

Als je WordPress-site in de afgelopen 30 dagen is gehackt, ziet een noodmigratie er zo uit wanneer je contact opneemt met ons:

Tijdlijn: 5-10 werkdagen

Investering: $5.000-$10.000 afhankelijk van site-complexiteit

Wat gebeurt er:

  1. Dag 1: We exporteren al je inhoud — posts, pagina's, media, aangepaste velden. Alles.
  2. Dagen 2-4: We bouwen je site in Next.js 15 met Payload CMS 3 als contentbackend, gedeployed op Vercel.
  3. Dagen 5-7: Designimplementatie die overeenkomt met je bestaande merk (of verbeterd — de meeste klanten willen verbeteringen).
  4. Dagen 7-9: Inhoudsmigratie, URL-omleidingen (elke oude URL kaarten naar de nieuwe — geen SEO-voordeel verloren), en QA-testing.
  5. Dag 10: DNS-wissel. Je site is live op de nieuwe stack.

Wat je aan de andere kant krijgt:

  • Nul plugins
  • Nul PHP
  • Nul /wp-admin-aanvalsoppervlak
  • Git-gebaseerde versiebeheer voor elke wijziging
  • Lighthouse 90+
  • Een CMS waar je redacteurs eigenlijk van houden

We hebben de volledige benadering gedocumenteerd op /migrate/wordpress-to-nextjs/, en als je de filosofie van plugin-naar-nul-plugins wil begrijpen, lees dan /blog/.

Voor sites gebouwd op Astro in plaats van Next.js bieden we hetzelfde migratiepad aan via onze Astro-ontwikkeling — de beveiligingsvoordelen zijn identiek.

Veelgestelde Vragen

Hoe weet ik of mijn WordPress-site is gehackt? Veel voorkomende tekenen zijn onverwachte omleidingen naar spamsites, nieuwe admingebruikers die je niet hebt aangemaakt, gewijzigde bestanden (vooral PHP-bestanden in /wp-content/uploads/), Google Search Console-beveiligingswaarschuwingen, je hostingprovider die je account opschort, en een plotselinge daling van organisch verkeer. Voer find wp-content/uploads -name '*.php' uit via SSH — als het resultaten geeft, ben je vrijwel zeker gecompromitteerd.

Hoeveel kost professionele WordPress malware-verwijdering? Professionele eenmalige schoonmaakdiensten variëren van $500 tot $2.000 per incident in 2025-2026. Sucuri vraagt ongeveer $500 voor hun basisschoonmaakservice. Wordfence's incident response begint op $990. Premium-beveiligingsplugins met auto-cleanup-functies (zoals MalCare) kosten $99-$199/jaar, maar ze vangen alleen bekende handtekeningen. De verborgen kosten zijn je tijd — verwacht 10-20 uur per incident voor coördinatie, testen en herstel.

Waarom wordt mijn WordPress-site telkens gehackt nadat ik hem heb schoongemaakt? Drie redenen: ongedetecteerde backdoors (hackers plaatsen meerdere backdoor-bestanden in je bestandssysteem en database die schoonmaken overleven), dezelfde kwetsbare pluginaritectuur blijft exploiteerbaar, en gecompromitteerde server-level toegang (cron-taken, SSH-sleutels) die niet tijdens schoonmaken werd aangepakt. Sucuri rapporteert dat 60%+ van schoongepoetste WordPress-sites herinfectie ervaart. Het fundamentele probleem is dat het aanvalsoppervlak — PHP-uitvoering, pluginkwetsbaarheden, voorspelbare admin-URL's — niet verandert na schoonmaken.

Hoe lang duurt het voordat Google's "Deze site is mogelijk gehackt" waarschuwing wordt verwijderd? Nadat je de site volledig hebt schoongemaakt en een reviewverzoek hebt ingediend via Google Search Console, verwacht je 2-4 weken tot de waarschuwing wordt verwijderd. Google crawlt en evalueert de site opnieuw tijdens deze periode. Gedurende die weken zie je vrijwel nul organisch verkeer en aanzienlijk lager click-through-percentages op eventuele resterende zoekimpressies. Als je site een tweede keer wordt gemarkeerd, duurt het herstel langer en je domeinautoriteit kan permanent worden verminderd.

Is Next.js werkelijk veiliger dan WordPress, of is dit marketinggedoe? Het is architectuur, geen marketing. 96% van WordPress-exploits richten zich op PHP-uitvoering — Next.js voert geen PHP uit. De meest voorkomende aanvalsvectoren (pluginkwetsbaarheden, wp-admin brute force, SQL-injectie via dynamische paginarenderings, bestandsupload-exploits) bestaan letterlijk niet in een statische/serverless Next.js-implementatie. Geen systeem is onhackbaar, maar de specifieke aanvallen die maandelijks 1,5 miljoen WordPress-sites compromitteren kunnen niet tegen een Next.js-site op Vercel worden gerepliceerd. Het aanvalsoppervlak is categorisch anders en dramatisch kleiner.

Hoe lang duurt het om een WordPress-site naar Next.js te migreren? Voor een noodmigratie (site is momenteel gehackt of onlangs gehackt), leveren we doorgaans binnen 5-10 werkdagen. Een standaardmigratie voor een inhoudsrijke site (100-500 pagina's/posts) duurt 3-6 weken. De SleepDr.com-migratie — 228 blogposts, aangepast design, volledige SEO-omleidingstoewijzing — was binnen onze standaardtijdlijn afgerond zonder inhoudsverlies. De grootste variabele is aangepaste functionaliteit; de meeste pluginfuncties kaarten schoon toe aan serverless-functies of React-componenten.

Wat gebeurt er met mijn WordPress-inhoud tijdens migratie? Elke post, pagina, aangepast veld, afbeelding en mediabestand wordt gemigreerd. We exporteren via de WordPress REST API of WPGraphQL, transformeren de gegevens voor Payload CMS 3, en verifiëren volledigheid na migratie. URL-structuren worden behouden via omleidingskaarten in next.config.js, dus je verliest geen SEO-waarde. We hebben sites met 1.000+ posts gemigreerd zonder een enkel stuk inhoud te verliezen.

Kan ik WordPress nog steeds gebruiken als headless CMS met Next.js? Je kunt, maar we raden het niet aan. Het gebruik van WordPress headless betekent nog steeds het onderhouden van WordPress — het bijwerken van core, het bijwerken van plugins (zelfs headless setups gebruiken vaak ACF, WPGraphQL en andere plugins), het beveiligen van de admin-interface, en het betalen voor managed WordPress-hosting. Je hebt het frontend-aanvalsoppervlak verwijderd maar het backend-oppervlak behouden. Payload CMS 3 geeft je een betere bewerkingservaring, nul plugin-afhankelijkheden, en wordt naast je Next.js-frontend op dezelfde infrastructuur gedeployed. Het is een schone breuk.

Wat als ik nu geen volledige migratie kan betalen? Voer eerst de noodstappen voor schoonmaken in dit artikel uit. Investeer vervolgens in Wordfence Premium ($99/jaar), zet twee-factor-authenticatie in op elk admin-account, verwijder elke plugin die je niet actief gebruikt, en stel dagelijkse back-ups in met een service die ze buiten de server opslaat. Dit voorkomt de volgende hack niet, maar maakt het herstel sneller. Wanneer je klaar bent voor de permanente oplossing, neem contact met ons op — we kunnen de migratie in fasen spreiden over 2-3 maanden.