WordPress reactie-spam blokkeren zonder Akismet

Je reactiewachtrij loopt weer vol. Elke goedkeuringsmail is weer een casinolink, weer een "great article!" in Cyrillisch, weer een verstopte iframe. Je weet dat Akismet het standaardantwoord is. Je weet ook dat Akismet al heel lang een betaald abonnement vraagt voor commerciële sites, en dat "commercieel" ruim wordt uitgelegd: advertenties, affiliate links, donaties, e-commerce, en in de praktijk dus eigenlijk elke zakelijke website. Akismet betalen is een prima keuze. Niet betalen ook. Dit artikel is hoe je dat tweede doet zonder dat je reactiesectie een spam-billboard wordt.

Het doel is een gelaagde verdediging die de overgrote meerderheid van geautomatiseerde reactie-spam opvangt met twee gratis, AVG-vriendelijke plugins en de discussie-instellingen die standaard met WordPress meekomen. Ik laat je ook de ene developer hook zien die je moet kennen voor eigen regels, en ik vertel je eerlijk wanneer Akismet betalen tóch de juiste keuze is. Geschreven voor zowel de site-eigenaar die zijn eigen WordPress beheert als de developer die wil begrijpen wat elke laag precies doet.

Hoe reactie-spam je WordPress binnenkomt

Voordat je het blokkeert, moet je weten waar het binnenkomt. WordPress reactie-spam arriveert via twee heel verschillende deuren. De eerste is het publieke reactieformulier onder elk bericht dat reacties toestaat, dat wp-comments-post.php afhandelt. Een bot vult het formulier in en POST het. De tweede is programmatische inzending via de REST API of XML-RPC, die het HTML-formulier helemaal overslaat. Beide paden komen uit op dezelfde WordPress comment-pipeline en passeren dezelfde set checks voordat WordPress besluit of een reactie wordt goedgekeurd, in moderatie gaat, als spam gemarkeerd wordt, of weggegooid.

De centrale hook in die pipeline is pre_comment_approved. Hij wordt in wp_allow_comment() aangeroepen na de eerste goedkeuringschecks en vóór de reactie naar de database wordt geschreven. Elke anti-spamplugin die je ooit hebt gezien, Akismet incluis, haakt erop in. Sinds WordPress 4.9.0 kun je een WP_Error teruggeven vanuit dit filter, en dan slaat WordPress de database-insert volledig over. Dat is belangrijk, want een normaal "spam"-verdict slaat de rij tóch op, alleen met comment_approved = 'spam'. Bij grote aanvallen scheelt het overslaan van de insert flink aan schrijfbelasting op je database.

Hoe moderne reactie-spam er in mijn ervaring uitziet, grofweg in categorieën:

• Link-drop bots, de klassieker: algemene lofprijzing plus twee of drie backlinks naar niet-gerelateerde commerciële sites. Nog steeds het meeste volume.
• SEO-farm bots die een relevant ogend stukje tekst plakken dat ergens anders geschraapt is, met één verborgen link in een auteur-URL of binnen een BBCode-tag.
• Cyrillische of CJK spamgolven die vanuit één botnet een paar uur lang binnen stromen en dan weer verdwijnen. Meestal keyword-gericht door een script.
• Menselijke spam via content-farm services. Laag volume, hoge moeite, en elk automatisch filter mist dit. Een mens moet het modereren.

Het grootste deel van dit artikel gaat over geautomatiseerde spam, want dat is 95% van het probleem. Voor die laatste 5% is het antwoord moderatie, geen extra plugin.

Ingebouwde WordPress-bescherming

Voordat je ook maar iets installeert: zet de defaults strakker. Die staan in wp-admin > Instellingen > Reacties en geven je de beste return op vijf minuten werk.

1. Voordat een reactie verschijnt > Reactie moet handmatig worden goedgekeurd. Zet dit aan tijdens een actieve aanval. Laat het permanent aan als je zelden publiceert en de voorkeur hebt voor review in je inbox. Laat het uit als je realtime flow wil op drukke posts; de latere lagen vangen je op.
2. Voordat een reactie verschijnt > De auteur moet een eerder goedgekeurde reactie hebben. Past goed bij het vorige punt. De eerste reactie van een gebruiker wordt vastgehouden, vervolgreacties vanaf hetzelfde e-mailadres worden automatisch geplaatst. Halveert de ruis in je inbox zonder nieuwe lezers buiten te sluiten.
3. De reactie-auteur moet zijn naam en e-mailadres invullen. Geen sterke controle (bots vullen velden in), maar sluit anonieme inzendingen af en filtert een kleine klasse luie bots weg.
4. Sluit reacties op berichten ouder dan 30 dagen automatisch. Dit is de enkele instelling met de hoogste waarde in dit paneel. De meeste spam gaat op oude, geïndexeerde posts af, want die hebben PageRank en geen auteur die nog meekijkt. Reacties sluiten na 30 of 60 dagen haalt het grootste deel van je aanvalsoppervlak weg zonder je huidige posts te raken. Kies een getal dat past bij hoe lang je artikelen meestal nog nieuwe legitieme reacties krijgen.
5. Houd een reactie vast in de wachtrij als hij N of meer links bevat. Standaard staat dit op 2. Zet het op 1 als je legitieme reageerders zelden linken. Het meeste spam bevat drie of meer links, dus deze regel houdt veel tegen zonder echte gesprekken te filteren.
6. Verboden reactiesleutelwoorden (Disallowed Comment Keys). Dit is het veld dat sinds WordPress 5.5 de oude "Comment Blacklist" vervangt. Elke reactie die matcht met een keyword, frase, e-mailadres, URL of IP op deze lijst gaat rechtstreeks naar de prullenbak, komt nooit in je moderatie-wachtrij en mailt je nooit.

Dat laatste veld verdient een uitbreiding, want daar zit de meeste verwarring. Het veld wordt ondersteund door de optie disallowed_keys in de database. Als een reactie binnenkomt, draait WordPress wp_check_comment_disallowed_list() tegen de reactie aan. Die checkt naam, e-mailadres, URL, reactietekst (HTML gestript), IP en user agent tegen elke regel op je lijst. De matching is hoofdletterongevoelig en matcht op deelwoorden: als je poker op een regel zet, vang je ook "online poker casino". Dit is de snelste manier om één specifieke spamgolf te stoppen. Hamert dezelfde Cyrillische term, hetzelfde rare domein of dezelfde IP-range steeds binnen, dan zet één regel op deze lijst dat stil.

Een community-lijst die je moet kennen is splorp/wordpress-comment-blocklist, met ongeveer 35.000 patronen uit jaren van reactie-spam moderatie. Kopieer de inhoud van blacklist.txt in het veld Verboden reactiesleutelwoorden en sla op. Het is een grote lijst, maar WordPress heeft daar geen moeite mee. Behandel hem als een startset die je in de loop van de tijd bijschaaft.

Nog even één hernoeming voor developers die oude tutorials lezen. WordPress 5.5 hernoemde twee opties in het comment-moderatiepad: blacklist_keys werd disallowed_keys en comment_whitelist werd comment_previously_approved. Tegelijk werd de functie wp_blacklist_check() deprecated ten gunste van wp_check_comment_disallowed_list(). Oude code die de deprecated namen gebruikt werkt nog wel (met een notice), maar alles wat je vandaag schrijft hoort de nieuwe namen te gebruiken.

Honeypot met WP Armour

Laag twee is een honeypot. Een honeypot is een formulierveld dat voor mensen onzichtbaar is, maar wel in de broncode van de pagina staat voor een naïeve bot. Als dat veld ingevuld wordt verzonden, is de inzending spam en wordt hij gedumpt. Honeypots hebben twee killer-eigenschappen. Ze kosten legitieme reageerders nul wrijving (geen CAPTCHA, geen puzzel, geen rekensom), en ze kosten niks aan API-calls of externe afhankelijkheden.

Het probleem met de meeste honeypots is dat slimmere bots de pagina parsen, zien dat het honeypot-veld style="display:none" of type="hidden" heeft en hem gewoon overslaan. WP Armour – Honeypot Anti Spam lost dat op door het honeypot-veld met JavaScript in te voegen nádat de pagina geladen is, en door een unieke veldnaam per WordPress-installatie te gebruiken. Een bot die geen JavaScript kan draaien ziet het veld dus helemaal niet, kan het ook niet invullen, en juist die afwezigheid gebruikt WP Armour als signaal om de poging als spam te markeren. De plugin is gratis, heeft meer dan 300.000 actieve installs, is voor het laatst geüpdatet in december 2025 (versie 2.3.04) en is AVG-compliant doordat hij geen externe calls maakt.

Installeren is echt install-and-forget:

1. Ga in wp-admin > Plugins > Nieuwe plugin toevoegen en zoek op "WP Armour Honeypot Anti Spam".
2. Installeer en activeer.
3. Er valt niks te configureren. De defaults werken.

De gratis versie van WP Armour beschermt het standaard WordPress-reactieformulier, het registratieformulier, BBPress en een lange lijst ondersteunde formulier-plugins: Contact Form 7, Gravity Forms (zonder AJAX en zonder multi-step), WPForms, Formidable Forms, Elementor Forms, Fluent Forms en meer. De betaalde Extended versie voegt WooCommerce Checkout, Easy Digital Downloads, Ninja Forms en Gravity Forms AJAX/multi-step toe, wat handig is om te weten als je site een van die types is.

Je weet dat het werkt als de broncode van een post na de initial load geen honeypot-veld toont, maar een veld met een willekeurige naam ná een seconde of twee in het formulier verschijnt (in DevTools > Elements zie je dat als een input die door een script is toegevoegd). Plaats daarna handmatig een reactie en die moet gewoon doorkomen.

Twee eerlijke beperkingen. WP Armour blokkeert geen menselijke spammers, want een mens ziet het formulier precies zoals een legitieme reageerder. En hij is niet compatibel met iframe-gebaseerde reactiesystemen zoals Jetpack Comments, wpDiscuz of Disqus, omdat die het native formulier vervangen door een iframe waar WP Armour niet bij kan. Gebruik je zo'n systeem, dan regelt het reactiesysteem zelf die honeypot-laag en kun je direct door naar de volgende laag.

Antispam Bee: AVG-vriendelijk heuristisch filter

Laag drie vangt op wat de honeypot mist. Sommige bots draaien wel JavaScript, sommige gerichte aanvallen zijn te slim voor veldtrucs, en je wil altijd een vangnet. Dat is wat Antispam Bee doet. Het is een heuristisch filter dat negen verschillende checks draait op elke binnenkomende reactie, alles wat verdacht lijkt markeert, en daarop handelt. De plugin is gratis voor privé én commercieel gebruik zonder limieten, heeft meer dan 700.000 actieve installs, is op 30 maart 2026 voor het laatst geüpdatet (versie 2.11.10), en is om één reden de AVG-vriendelijke default op de meeste Europese WordPress-sites: hij vereist geen API-key en stuurt standaard geen reactiedata naar een derde partij.

Installeren en configureren:

1. Ga in wp-admin > Plugins > Nieuwe plugin toevoegen en zoek op "Antispam Bee" van pluginkollektiv.
2. Installeer en activeer.
3. Ga naar wp-admin > Instellingen > Antispam Bee.
4. Zet deze aan voor een verstandige default-set:
   • Vertrouw goedgekeurde reageerders (slaat alle andere checks over voor gebruikers die al eens een goedgekeurde reactie hebben; haalt false positives voor stamgasten naar vrijwel nul).
   • Vertrouw reageerders met een Gravatar (optioneel; stuurt alleen een MD5-hash van het e-mailadres naar Gravatar, niet het e-mailadres zelf).
   • Controleer de reactietijd (markeert inzendingen die sneller binnenkomen dan een mens plausibel kan typen; toegevoegd in v2.6.4).
   • BBCode-check (vangt forum-spam patronen met [url=...] syntaxis).
   • Valideer IP-adres (lokale check).
   • Gebruik lokale spamdatabase (kruisverwijzing van IP, e-mail en URL tegen spam die eerder op je eigen site is gedetecteerd).
5. Laat Country blocking uit tenzij je een duidelijke reden hebt. Het stuurt een geanonimiseerd IP naar een externe IP2Country-service en het is makkelijk te misbruiken op een manier die legitieme internationale lezers blokkeert.
6. Laat Language filtering om dezelfde reden uit. Het stuurt reactietekst over HTTPS naar de franc taaldetectieservice, wat voor reactielichamen in een AVG grijs gebied zit, en op meertalige sites is de false-positive rate hoog.
7. Opslaan.

De Antispam Bee documentatie legt elke check in detail uit, inclusief welke externe HTTP-calls doen en welke lokaal blijven. Voor een site die nul externe calls wil is de configuratie hierboven (met Gravatar uit) volledig lokaal.

Je weet dat het werkt als je bestaande spam-wachtrij begint te vullen met reacties die in wp-admin > Reacties > Spam een Antispam Bee "reason"-annotatie hebben, en legitieme reacties van bekende reageerders blijven gewoon doorkomen.

Eén kanttekening. Antispam Bee beschermt alleen het native WordPress-reactieformulier. Hij integreert niet met Contact Form 7, Gravity Forms of welke andere formulier-plugin dan ook, en hij is niet compatibel met Jetpack Comments, wpDiscuz of Disqus (om dezelfde iframe-reden als WP Armour). Voor spam op contactformulieren is de honeypot of validatie van je formulier-plugin zelf de juiste plek. Voor reacties specifiek dekt Antispam Bee plus WP Armour het native-commentaar-scenario volledig af.

Akismet: wanneer het tóch zinnig is

Akismet is niet de vijand, het is gewoon niet gratis voor commerciële sites. De eigen supportpagina van Akismet definieert "commercieel" ruim: advertenties draaien (AdSense, Taboola), affiliate links, een live-chat plugin, een bedrijf promoten, een zakelijk domein, donaties accepteren of e-commerce draaien. Dat beleid staat al heel lang, het is geen wijziging uit de 5.0 release van juli 2022; die release zelf voegde alleen een bot-interactie observatie-feature toe. Mensen merkten de licentieregel vooral duidelijker toen Akismet rond die periode de signup-flow aanscherpte.

Heb je wel een puur persoonlijke, niet-commerciële blog, dan kun je nog steeds een gratis Akismet-key krijgen door de "pay what you can" slider helemaal op nul te zetten. Dat wordt echt ondersteund en is een redelijke keuze voor een hobbyblog: de cloud-dienst van Akismet is getraind op een enorm corpus van cross-site spampatronen en vangt dingen die lokale heuristieken missen.

Voor commerciële sites is Akismet Pro momenteel €9,95 per maand, jaarlijks gefactureerd, voor één site (Akismet versie 5.6, stand van 12 november 2025). Dat is niet duur voor een site die omzet maakt. Eerlijke redenen om het toch te betalen:

• Je wil één bekende vendor op de rol voor anti-spam en je hebt geen zin om lokale plugins te tunen.
• Je hebt een reactiesectie met hoog volume waar cross-site patroonherkenning aantoonbaar beter presteert dan lokale heuristieken.
• Je bent freelancer en levert een site op aan een niet-technische klant die geen gelaagde setup gaat onderhouden, waarbij één toggle de oplevergrens is.

Redenen om niet te betalen:

• Je commerciële site heeft bescheiden reactievolume en WP Armour plus Antispam Bee plus de Verboden reactiesleutelwoorden dekken je feitelijke aanvalspatroon.
• Je hecht aan AVG-dataflow-minimalisatie en wil niet dat reactiemetadata standaard de EU verlaten.
• Je wil vendor-onafhankelijk blijven.

Beide keuzes zijn te verdedigen. De verkeerde keuze is Akismet installeren op een commerciële site zonder betaalde key en hopen dat het niet opvalt, want de Akismet supportdocs zeggen dat non-compliance kan leiden tot directe suspensie zonder waarschuwing, en een gesuspendeerde key laat je site onbeschermd op precies het moment dat je dacht dat hij gedekt was.

Reacties uitzetten op specifieke post types of oude berichten

Soms is het eerlijke antwoord "ik wil hier gewoon geen reacties". Ook prima. WordPress laat je het op drie niveaus uitzetten.

Site-breed, via wp-admin > Instellingen > Reacties > Standaard artikel-instellingen > Mensen toestaan om reacties te plaatsen op nieuwe berichten. Als je dit uitvinkt geldt het voor elk bericht dat ná die wijziging wordt aangemaakt. Bestaande posts houden hun huidige instelling.

Per post type, via code. Om bijvoorbeeld reacties op WooCommerce-producten uit te zetten:

// In je theme functions.php of een site-specifieke mu-plugin
add_action( 'init', function () {
    remove_post_type_support( 'product', 'comments' );
    remove_post_type_support( 'product', 'trackbacks' );
}, 100 );

Automatisch op oude berichten, via de al genoemde discussie-instelling: "Sluit reacties op berichten ouder dan N dagen automatisch". Dit is de instelling die de meeste sites zouden moeten aanzetten, ook als ze wél nieuwe reacties op verse posts willen. Kies een getal dat past bij hoe lang gesprekken op je posts meestal nog leven (30 dagen werkt voor de meeste blogs, 90 voor langere technische content).

Wat de "reacties volledig uit"-gedachte mist, is dat de meeste spam op oude geïndexeerde posts afkomt. Reacties sluiten na 30 dagen haalt het grootste deel van je aanvalsoppervlak weg en houdt de commentaar-ervaring overeind op de posts waar hij ertoe doet. Bijna altijd een betere default dan een site-brede uit-knop.

De developer hook: eigen regels met pre_comment_approved

Heb je een eigen regel nodig die nergens hierboven in past (elke reactie met een specifieke frase blokkeren, reacties van een bekende probleem-IP-range tegenhouden, een minimum-reactielengte afdwingen), dan is het filter pre_comment_approved de nette plek. Een kleine mu-plugin is de juiste container:

<?php
// wp-content/mu-plugins/comment-custom-rules.php
// Draait voordat een reactie naar de database wordt geschreven.
// Return 1 om goed te keuren, 0 om vast te houden, 'spam' om te
// markeren, 'trash' om weg te gooien, of een WP_Error om de insert
// helemaal over te slaan.
add_filter( 'pre_comment_approved', function ( $approved, $commentdata ) {
    // Al door een eerder filter besloten (Akismet, Antispam Bee, etc.)
    if ( is_wp_error( $approved ) || 'spam' === $approved ) {
        return $approved;
    }

    $content = isset( $commentdata['comment_content'] )
        ? $commentdata['comment_content']
        : '';

    // Gooi reacties met meer dan 3 URL's volledig weg.
    // preg_match_all geeft het aantal URL's terug; drempel is jouw keuze.
    if ( preg_match_all( '#https?://#i', $content ) > 3 ) {
        return new WP_Error(
            'too_many_links',
            'Reactie bevat te veel links.'
        );
    }

    return $approved;
}, 20, 2 );

Twee details doen er toe. Ten eerste slaat het teruggeven van een WP_Error de database-insert over, wat sinds WordPress 4.9.0 wordt ondersteund juist voor anti-spamfilters die verkeer willen droppen zonder op te slaan. Voor low-volume sites is dat micro-optimalisatie, voor sites onder actieve aanval scheelt het flink aan database-writes. Ten tweede zet priority 20 je filter ná Akismet (priority 1) en ná Antispam Bee, waardoor hun beslissingen winnen als zij eerder vuurden. Dat is meestal wat je wilt: een defense-in-depth laag die je eigen regels toevoegt zonder de plugins tegen te werken.

Wees zuinig met deze hook. Elke regel die je toevoegt moet je ook onderhouden, en elke false positive is een lezer die je zonder waarschuwing de mond snoerde. Log je rejections eerst een week voordat je ze op "echt weggooien" zet.

WooCommerce productreview-spam

WooCommerce productreviews zijn reacties, dus alles hierboven is van toepassing, met één draai. Het veld dat de ergste overtreders op reviews vangt is Verboden reactiesleutelwoorden plus de regel "houd reacties met N links vast", want de meeste review-spam is dunne loftuiting met een link. De honeypot-laag (WP Armour) dekt ook het productreview-formulier af voor de meeste WooCommerce-installaties (de gratis versie ondersteunt WooCommerce Reviews Pro; de Extended versie voegt WooCommerce Checkout en andere commerce flows expliciet toe).

Wil je dat alleen geverifieerde kopers reviews kunnen achterlaten, dan heeft WooCommerce zelf een instelling op wp-admin > WooCommerce > Instellingen > Producten > Reviews > Toon "geverifieerde eigenaar"-label bij klantreviews. De strakkere variant is dat alleen geverifieerde eigenaren überhaupt reviews mogen plaatsen, wat de meeste review-spam in één klap elimineert ten koste van reviews van gebruikers die off-site hebben gekocht (of het cadeau hebben gekregen) en wilden reageren. Voor de meeste webshops is die trade-off het waard.

Mythes die je gewoon kunt laten varen

Een kort lijstje van dingen die mensen proberen en die niet helpen, en waarom.

"CAPTCHA's stoppen alle spambots." Vroeger wel. Moderne bots lossen reCAPTCHA v2 challenges op, en reCAPTCHA v3 is een onzichtbare score die legitieme gebruikers verkeerd kan classificeren. CAPTCHA's voegen ook wrijving toe voor lezers, wat het tegenovergestelde is van waarvoor een reactiesectie dient. De WP Armour FAQ zegt het recht voor zijn raap: bots hebben geleerd captchas op te lossen, dus captchas zijn niet meer effectief. Honeypots en interactie-observatie doen nu het werk.

"Reacties helemaal uitzetten is de makkelijkste oplossing." Dat is de kernoptie en die is overkill als "reacties sluiten na 30 dagen" al het meeste aanvalsoppervlak weghaalt. Wil je écht geen enkele reactie, dan is site-breed uitzetten prima. Maar grijp er niet naar omdat je moe bent van spam: probeer eerst oude posts te sluiten.

"Akismet is de enige betrouwbare anti-spamoptie." Niet waar. Een gelaagde setup van de ingebouwde discussie-instellingen, WP Armour en Antispam Bee dekt het overgrote deel van de geautomatiseerde spam op het overgrote deel van de sites, tegen nul kosten en nul externe dataflow. Akismet is een redelijke keuze voor persoonlijke blogs (gratis) en voor specifieke commerciële gevallen (zie hierboven). De enige is het niet.

"Eén grote blocklist vangt alles voor altijd." Een blocklist is een startpunt, geen permanente oplossing. Spam-keywords veranderen, domeinen rouleren en een verouderde lijst blokkeert legitieme woorden die per ongeluk in het spamcorpus belanden. Loop je Verboden reactiesleutelwoorden elk kwartaal even na en schrap wat op een false positive lijkt.

Wanneer je hulp moet inschakelen

Schakel hulp in als een van deze waar is, en verzamel eerst onderstaand lijstje.

• WP Armour en Antispam Bee staan allebei geïnstalleerd en je spam-wachtrij vult sneller dan je hem kunt leegmaken. De aanval omzeilt waarschijnlijk de honeypot-laag (menselijke spammers, JS-draaiende bots) en vraagt om Akismet Pro of een rate limit op /wp-comments-post.php op webserverniveau.
• PHP workers lopen vol tijdens de spamgolven. Zie de hoog CPU-gebruik op WordPress aanpak; dat is het downstream-effect van een ongemitigeerde spamstroom.
• Je hebt een eigen pre_comment_approved-regel uitgerold en legitieme reacties verdwijnen stilletjes. Draai de regel eerst terug, bekijk je rejection-log en zet daarna een zachtere versie in.
• Reacties worden geplaatst vanuit geauthenticeerde accounts die je niet hebt aangemaakt, of berichtinhoud wordt via reacties aangepast. Dit is geen spam maar een compromittering. Ga over op de incident-flow in WordPress beveiliging verharden.

Verzamel voordat je het vraagt:

• De WordPress-versie, PHP-versie en actief thema.
• Een lijst actieve plugins met versies (wp plugin list --format=csv of wp-admin > Plugins).
• Een screenshot van wp-admin > Instellingen > Reacties zodat de huidige baseline zichtbaar is.
• Een telling van spam-reacties per uur over de laatste dag (wp comment list --status=spam --format=count via WP-CLI, of handmatig via wp-admin > Reacties > Spam).
• Een sample van vijf tot tien spamreacties (naam, e-mail, URL, body). Anonimiseer waar nodig.
• Of je Jetpack Comments, wpDiscuz, Disqus of het native reactieformulier gebruikt.
• De nginx- of Apache-toegangslogregels voor /wp-comments-post.php tijdens een spam-piek, als je serverniveau hebt.

Heb je juist de bredere security-context nodig, dan is WordPress beveiliging verharden het begeleidende artikel dat reactie-spam in een bredere hardening-checklist plaatst, en brute force protectie in WordPress dekt de andere high-traffic endpoints (wp-login.php en xmlrpc.php) met dezelfde gelaagde aanpak als hier.