START here

Stopping WordPress comment and search spam with CloudFlare

How to prevent WordPress spam comments (and DDOS by abusing the search option) using CloudFlare, without relying on Google and its reCAPTCHA system, and why I think that’s such a brilliant idea? 🙂

Table Of Contents (T.O.C.):

  1. Why I opted for CloudFlare instead of Google’s reCAPTCHA
  2. Blocking SPAM using CloudFlare’s JS challenge
  3. Preventing comment and contact form spam
  4. Conclusion
  5. Search form spam prevention

1. Why I opted for CloudFlare instead of Google’s reCAPTCHA

I already wrote an article about how to stop WordPress comment spam. Most of the info I shared there still stands, especially the part about configuring WordPress anti-spam settings, and using The SEO Framework Pro’s Honeypot extension.

However, I wanted to not rely on Honeypot alone, but to create an extra layer and reduce the number of spam bots that post a comment (regardless of the fact that they all get sent to the spam box immediately).

Google’s reCAPTCHA does a decent job with this, but it slows down the site’s performance to a degree, and solving the captcha images is a hassle for any legit visitors. Now, I’ve been using CloudFlare’s free tier for years (and gave the CloudFlare Pro and WordPress APO a test in the meantime). So, I decided to see if I could use CloudFlare to prevent some spam from reaching my site.

If you are new to CloudFlare, I already covered these topics to help you get started:

The here-described methods require that CloudFlare’s proxy is active for your website.

– T.O.C. –

2. Blocking SPAM using CloudFlare’s JS challenge

Even with the free tier, I can still configure 5 CloudFlare firewall rules. Since many bots can not process JavaScript, creating a JavaScript challenge on the DNS level could block most of those.

First thing is to figure out the relevant “handle” to use for the firewall rule. Pressing F12 on your browser and looking at the network tab when posting a comment shows the needed info:

Figuring out the URI for posting WordPress comments
Figuring out the URI for posting WordPress comments
Picture 1

Now, we need to log into the CloudFlare’s dashboard and go to:
Security -> WAF
Then click on the “+ Create rule” button and create the following rule:

JavaScript challenge firewall rule
JavaScript challenge firewall rule
Picture 2

For easier copy-pasting:

  • Field: URI Path
  • Operator: contains
  • Value: wp-comments-post.php

JS challenge will not bother your legit readers with solving puzzles like “click on all the boat pictures on the screen” and similar. It will just show a brief notification (a few seconds):

JavaScript challenge firewall rule activated and working as intended
JavaScript challenge firewall rule activated and working as intended
Picture 3

You can test this (to confirm it works) by opening an incognito browser window (CTRL+SHIFT+N) and trying to post a comment on your site.

If you have more than one firewall rule, only one of those will be activated: the first rule whose criteria are met.

For example, if you have another rule that is triggered if say “Referrer matches your website’s domain,” that criteria may be satisfied when someone tries to post a comment. And, if that rule is placed above the anti-spam rule we’ve just created, your anti-spam rule will never work, it will never get triggered.

However, since only posting comments satisfies the criteria “URI-Path contains wp-comments-post.php” rule, the solution is to place this rule on top, since no other event will trigger this rule (allowing us to have well-functioning other firewall rules).

Apart from the list order, there is also priority order for CloudFlare firewall rule execution (CloudFlare knowledge base link).

If this sounds a bit confusing, don’t sweat it, just place the here-described rule at the top and see if it works after an hour or so. How to confirm it works? It will show stats:

Checking to confirm that the firewall rule gets triggered
Checking to confirm that the firewall rule gets triggered
Picture 4

If you’ve done it all correctly, you will be able to confirm that your firewall rule gets triggered as easily as social justice warriors. 🙂

Firewall rules work nicely alongside CloudFlare Zero Trust security settings and rules.

– T.O.C. –

3. Preventing comment and contact form spam

You could make a rule similar to the above-described one to prevent your website’s contact form spam.

The first thing you need to do is figure out which link or URI is used for your contact form. For example, my sites have “/newsletter/” in their newsletter subscription links. So, I could just append that to the existing firewall rule, using the “OR” option to add additional criteria to the existing firewall rule:

Adding more criteria ("triggers") to an existing firewall rule
Adding more criteria (“triggers”) to an existing firewall rule
Picture 5

– T.O.C. –

4. Conclusion

Using the here-described method provides a very good spam protection. It is also a lot more comfortable to use for the visitors – no boring CAPTCHA challenges to solve.

Also, it unloads your hosting server, because the check is executed by CloudFlare before reaching your server: if the challenge fails (i.e. it’s most probably a bot), your server doesn’t even receive the “comment attempt.”

Based on my experience so far, this can effectively replace any anti-spam WordPress plugins, and it is always better to have fewer plugins.
Having said this, I still love the TSF plugin which is the best SEO plugin I’ve tried so far, and its Honeypot anti-spam extension is super light weight, and a nice extra layer to catch any spammers who “slip through” the firewall protection so I don’t get bothered with dozens for “approve new comment” email notifications.

If you have any questions, additions or corrections, please use the comment section below. 🙂
You could also join the discussion on this topic on my favourite IT-related forum, LowEndSpirit:
WordPress comment and contact form spam blocking using Cloudflare (the LES forum discussion link).

– T.O.C. –

5. Search form spam prevention

Almost forgot to mention this little bugger. See, even if you disable any search icons on your site, anyone can add “?s=” (or “/search/”) to the end of your site’s URL and make WordPress execute a search. For example: wordpress theme

That’s why it’s a good idea to add these to your rules (the ones shown in picture 5 above):

  • URI Full | contains | ?s=
  • URI Path | contains | /search/

You could also add this to your robots.txt file (what is the “robots.txt” file and how to make it?):

User-agent: *
Disallow: *?s=*
Allow: /

That will tell Google (and other search engines and web crawlers) not to visit or index any search results pages of your website.

– T.O.C. –

Please use the forum for any comments or questions.

If you've found any errors or lacking information in the article(s) - please let me know by commenting on the BikeGremlin forum.
You can comment anonymously (by registering with any name/nickname), but I think it is good to publicly document all the article additions (and especially corrections) - even if their author chooses to remain anonymous.

Skip to content