Automated crawlers and scraping bots are a growing problem for modern websites. While search engine bots are useful, many other crawlers generate excessive traffic, scrape content, or overload servers.
To help website owners control this type of traffic, we recently released the Anti-Crawler PHP Library by CleanTalk, an open-source tool designed to detect and limit aggressive crawlers before they cause performance problems.
The library analyzes incoming requests and applies rate-limiting logic to detect crawler-like behavior. Once a bot exceeds defined limits, the system blocks or restricts further requests.
In the first version of the library we chose SQLite as the storage backend. SQLite allowed the library to work immediately after installation without requiring additional infrastructure such as Redis or Memcached.
However, after deploying the library on our own high-traffic website cleantalk.org, we encountered an unexpected performance issue: disk load increased significantly.
The result was a simple architectural change that completely removed the disk load increase while improving scalability.
The First Version of the Anti-Crawler Library
The goal of the library was to provide a simple crawler protection mechanism for PHP applications. Typical anti-crawler logic requires storing temporary request data. Each request updates this data so the system can determine whether a visitor behaves like a normal user or an automated crawler. Because the data must be updated frequently, the storage backend plays a critical role in overall performance.
Why SQLite Was Chosen
For the initial release we selected SQLite for several reasons:
Zero configuration. SQLite is included in most PHP environments and does not require running an additional service.
Single-file storage. All data is stored in a single database file, making installation extremely simple.
Good performance for moderate workloads. SQLite performs very well for many typical web applications.
Easy deployment. Users could install the library without modifying their infrastructure.
This approach allowed the library to work immediately after installation and made it suitable for shared hosting environments. For many websites this configuration works perfectly. However, high-traffic environments behave differently.
Deploying the Library on a High-Traffic Website
After releasing the first version of the library, we deployed it on our own website https://cleantalk.org Our infrastructure handles a large volume of traffic, including both legitimate users and automated bots. Shortly after enabling the library, our monitoring systems detected something unusual. Disk Activity Increased. Server monitoring showed a noticeable increase in disk activity. After analyzing the metrics we observed: Disk load increased by approximately 30%.
This was unexpected because the library itself performs only lightweight operations. The problem was not CPU usage or memory consumption. Instead, the issue was directly related to disk I/O. Further investigation showed that the additional disk operations were coming from the SQLite database used by the anti-crawler system.
Why SQLite Became a Bottleneck
SQLite is a reliable and efficient embedded database, but its design has limitations under certain workloads. The anti-crawler system generates a very specific traffic pattern. For each HTTP request the library needs to:
read crawler counters
update request statistics
write the updated data back to storage
This means the database receives frequent write operations.
Because SQLite stores data on disk, every update results in disk activity. Under high traffic this leads to a large number of disk writes. SQLite also uses file-level locking to ensure consistency. When many requests attempt to update the database simultaneously, additional locking overhead appears.
As a result, frequent writes combined with locking increased disk activity on our production servers.
Moving the Storage Layer to Redis / KeyDB
To eliminate disk operations we needed a storage system optimized for frequent updates. The natural solution was an in-memory data store, so we added support for: Redis and KeyDB. Both systems keep data in memory and provide extremely fast read and write operations. This approach removes disk I/O and allows the crawler detection logic to update counters much more efficiently.
The Anti-Crawler PHP Library was updated to support multiple storage backends. Users can now choose between:
SQLite (default)
Redis
KeyDB
SQLite remains useful for simple deployments, while Redis or KeyDB can be enabled for high-traffic environments. The crawler detection logic itself remains unchanged — only the storage backend is replaced.
Results After Switching to Redis
After switching the storage backend to Redis on our production servers we immediately saw improvements. Disk activity returned to normal because the crawler counters were now stored in memory instead of on disk. The previous 30% increase in disk load disappeared, and request processing became faster. The Redis-based architecture also scales better under heavy traffic and avoids locking issues associated with file-based databases.
When to Use SQLite vs Redis
Both storage options remain available because they fit different environments.
SQLite works well for:
small and medium websites
environments without Redis
simple installations
Redis or KeyDB is recommended for:
high-traffic websites
infrastructure already using Redis
environments with heavy bot traffic
How to Use the Anti-Crawler PHP Library
The library is open source and available on GitHub: https://github.com/CleanTalk/php-anticrawler It can be integrated into any PHP application to detect aggressive crawlers and limit automated traffic.
Switching the storage backend of our Anti-Crawler PHP Library from SQLite to Redis/KeyDB allowed us to eliminate the disk I/O overhead that appeared under high traffic. This small architectural change removed the 30% disk load increase and made the crawler detection system faster and more scalable for busy websites.
Anti-Crawler PHP Library by CleanTalk
Protect your website from aggressive crawlers and automated scraping.
When you look at your hosting invoice, you see CPU, RAM, disk and traffic. What you don’t see is the hidden line:
How much of this is spent on spam bots instead of real users.
Today a big part of web traffic is no longer human. Bad bots:
try to register fake accounts,
submit spam through forms and comments,
hit login, XML-RPC and admin URLs thousands of times a day.
For your server, each of these bots looks like a normal visitor:
PHP runs,
WordPress and plugins load,
the database is queried,
logs and backups grow.
From a business point of view, this is pure waste: you pay for server resources that serve traffic which will never become a customer, lead or subscriber.
We can see the scale of this problem very clearly in CleanTalk’s own network.
Source https://cleantalk.org/spam-stats
the Anti-Spam layer processed about 91-220 million spam events per month at the application level,
while SpamFireWall filtered 560-740 million suspicious requests per month before they reached websites – and in May 2025 it blocked more than 11 billion requests in a single month.
In total for that period, SpamFireWall handled many times more bad requests than the Anti-Spam checks inside forms and registrations. This is exactly what “reduce server load bots create” means in practice: most of the dirty work is done in the cloud, so your own servers stay free for real visitors.
In this article, we’ll look at:
how spam bots translate into real server and hosting costs,
why blocking spam only inside WordPress is not enough if you care about performance and budget,
and how CleanTalk SpamFireWall uses cloud filtering to cut bot load before it ever reaches your infrastructure.
The goal is simple: to show spam not only as “junk content”, but as a financial line item, and to explain how CleanTalk helps you shrink that line without changing your whole tech stack.
2. Problem: Why Spam Bots Are Expensive, Not Just Annoying
Most teams think of spam bots as a nuisance: fake sign-ups, junk messages, useless comments.
From a business perspective, they’re something else entirely:
Spam bots quietly burn real server resources that you pay for – and they never become customers.
Every spam bot request looks “normal” to your infrastructure:
it opens a connection to your server,
starts PHP or your application runtime,
loads WordPress and all active plugins,
may trigger database and cache queries,
writes another line into your logs and backups.
Technically, that bot request costs almost the same as a real visitor. The only difference is outcome: there is zero chance it turns into revenue.
That’s the core of the spam bots server cost problem.
2.1. Direct server and hosting cost
If a noticeable share of your traffic is bots – and for many sites it is 20-30% or more – then the same share of your infrastructure is effectively reserved for non-humans:
CPU cycles are spent executing code for scripts, not people.
RAM is used to keep processes alive for fake sessions.
Disk I/O and storage are consumed by logs and backups of bot traffic.
The result:
you hit resource limits earlier,
you upgrade hosting plans sooner,
you pay for bigger servers than your real audience actually needs.
This is the hidden spam bots server cost: part of your hosting budget that works only to serve automated garbage traffic.
2.2. Performance and user experience
Bots don’t stand in a separate queue. They compete with your real users for the same pool of workers and database connections.
When a wave of bots hits:
pages start loading slower,
login, registration and checkout become less responsive,
time-outs and 5xx errors appear at the worst possible moment – usually when you run campaigns or receive organic peaks.
From a business angle, this shows up as:
lower conversion rates,
worse campaign performance,
and the wrong diagnosis: “we need UX changes” or “ads are not working”, when the real problem is that servers are busy talking to bots.
2.3. Security and operational noise
Bad bots are also responsible for a lot of “background noise” in security and operations:
endless login attempts and password guessing,
automated vulnerability scans,
repeated hits to admin and system URLs.
Even if these attempts fail, they still generate:
alerts and tickets,
time spent investigating suspicious spikes,
extra rules and manual blocks.
Your security and DevOps teams pay the cost in attention and hours, rather than focusing on real incidents and product reliability.
2.4. Dirty analytics and poor decisions
Finally, spam bots compromise the quality of your data:
they inflate visits and page views,
distort geography and device statistics,
pollute funnels and conversion metrics.
Marketing and product teams then make decisions based on a dataset where a significant part is not human:
overestimating interest from certain regions,
underestimating the true conversion rate of real users,
misjudging which channels are actually working.
In short, spam bots are not just about “ugly comments” or “annoying sign-ups”. They are:
extra percentage points on your hosting bill,
slower pages for real customers,
more noise for your security and ops teams,
and less reliable analytics for management.
The rest of this article will show how a cloud filter like CleanTalk SpamFireWall helps reduce server load bots create, so your infrastructure, teams and budget are focused on real visitors instead of scripts.
3. Data: What CleanTalk Sees in Real Traffic
Before we talk about solutions, it’s worth asking a simple question:
“Is this really a big enough problem to care about, or just a few spam submissions a day?”
CleanTalk’s own network data gives a very clear answer.
Across thousands of protected websites, CleanTalk records every spam event and firewall block. Between April 2025 and February 2026, the platform processed:
Anti-Spam (forms, registrations, comments): from ~86-220 million spam events per month
SpamFireWall (cloud filtering): from ~566-825 million suspicious requests per month
With a spike in May 2025, when SpamFireWall blocked more than 11 billion requests in a single month.
In other words: for every batch of spam you see at the application level, there is a much larger wave of bot traffic that can be stopped earlier – in the cloud.
SpamFireWall consistently handles 6-8× more bad requests than the Anti-Spam layer inside forms.
That means the bulk of hostile or useless traffic never needs to reach PHP, WordPress, or your database at all – as long as you filter it in the cloud first.
From a “reduce server load bots” perspective, this is the key point:
Anti-Spam removes spam content and fake accounts.
SpamFireWall removes a huge amount of bot load before your server ever has to care.
3.2. Billions of requests that never hit customers’ servers
The May 2025 numbers are a good illustration of scale:
Anti-Spam processed 108,609,819 spam events.
SpamFireWall blocked 11,001,687,601 requests in the cloud.
That’s not a rounding error or a minor optimisation. It’s roughly:
100+ million visible spam attempts vs
11 billion blocked at the edge.
Put differently:
For every spam submission cleaned up inside a form, there were hundreds of bot requests that could have reached customer servers – but didn’t.
Those 11 billion requests represent CPU, RAM, I/O and bandwidth that CleanTalk’s cloud absorbed instead of the websites themselves. That’s exactly the “spam bots server cost” that can be shifted away from your own infrastructure.
3.3. A global problem, not a local glitch
The same report also shows where spam is coming from. Between April 2025 and February 2026, the top sources of spam traffic in the CleanTalk network were:
United States – 269,351,056 events (24.19%)
Netherlands – 150,566,461 (13.52%)
Germany – 66,958,677 (6.01%)
Russian Federation – 46,137,396 (4.14%)
Brazil – 40,897,099 (3.67%)
China – 40,769,672 (3.66%) … and so on.
This reinforces an important message for decision-makers:
spam and bad bots are not an edge case or a local phenomenon,
they are a predictable, measurable part of global traffic patterns,
and they will appear on almost any public-facing site as soon as it has real traffic.
Seen through this lens, spam bots server cost stops being an abstract risk and becomes a very concrete, quantifiable component of your infrastructure spend – one that a cloud filter like CleanTalk SpamFireWall can directly reduce.
4. How Spam Bots Turn into Hosting and Performance Costs
By this point, it’s clear that bots generate a lot of traffic. The next question is simple: where exactly does this show up in your P&L and SLAs?
Spam bots don’t come with a separate invoice. Instead, their cost is spread across four areas: infrastructure, performance, security, and data.
4.1. Infrastructure: paying to serve non-customers
Every extra request from a bot pushes your infrastructure a little closer to its limits:
CPU – executing PHP, WordPress and plugin code for non-human traffic,
RAM – keeping processes and connections alive for fake sessions,
Disk & I/O – writing access logs, error logs and larger backups,
Bandwidth – sending responses that no human ever sees.
If 20-30% of your HTTP requests are bots, then 20-30% of your:
provisioned CPU capacity,
memory headroom,
and outbound traffic
is effectively reserved for traffic that cannot convert.
In practical terms, this means:
upgrading to a higher hosting plan “because we’re hitting limits”,
moving to larger VPS/instances earlier than necessary,
keeping a bigger performance buffer “just in case” – and feeding a lot of it to bots.
That is your spam bots server cost in its purest form: the part of your hosting bill that exists only because scripts keep knocking on your door.
4.2. Performance: bots competing with real users
Infrastructure cost is only half the story. The other half is user experience.
Bots don’t politely wait until your real customers are finished. They hit:
login and registration endpoints,
search and listing pages,
checkout and contact forms,
using the same worker pool and the same database connections as humans.
The result:
CPU spikes during bot waves lead to slower page loads,
application queues fill up, leading to higher TTFB,
at peak moments (campaigns, product launches, seasonal traffic), real users experience timeouts, 5xx errors or just “feels slow”.
From a business perspective, this translates into:
lower conversion rates on key funnels,
underperforming ad campaigns,
higher cost per acquisition – not because your marketing is bad, but because servers are busy serving bots instead of buyers.
If your goal is to reduce server load bots generate, this is exactly the performance win you’re aiming for: freeing capacity so that real users always get a fast, stable experience.
4.3. Security and operations: constant background noise
Many of the bots hitting your site are not just spammers, they’re also:
brute-forcing passwords,
probing for outdated plugins and known CVEs,
crawling admin and system URLs looking for weak points.
Even when they fail, they still create work:
alerts in monitoring tools,
tickets for the security or DevOps team,
time spent investigating suspicious IPs and traffic spikes,
manual IP blocks and ad-hoc firewall rules.
None of this creates value for customers. It’s necessary defensive work caused by traffic that should ideally never reach your application in the first place.
By blocking a large share of this traffic in the cloud, you don’t just protect the server – you also reduce the operational noise your teams have to deal with.
4.4. Analytics: dirty data, weaker decisions
Finally, spam bots quietly damage something very important for business: data quality.
If bot traffic is not filtered properly, it will:
inflate visits and page views,
distort geography and device breakdowns,
pollute funnels with sessions that never had a chance to convert,
drag down apparent conversion rates (“lots of traffic, few sign-ups”).
This leads to bad second-order effects:
marketing invests more into audiences and regions with heavy bot presence,
channels are misjudged (“this campaign sends junk”, when the junk is bots),
product and growth decisions are made on metrics that don’t represent real users.
Reducing bot load at the edge gives you cleaner numbers:
fewer fake sessions,
more realistic conversion rates,
better signal on which channels, markets and campaigns actually work.
Put together, this is why spam bots are more than “just annoying”:
they drive up your infrastructure spend,
reduce performance and conversion for real customers,
increase security and operations overhead,
and weaken the analytics you use to run the business.
The next step is to treat this as an architectural issue, not a form-field issue – and that’s where a cloud layer like CleanTalk SpamFireWall comes in as a tool specifically designed to cut this spam bots server cost before it reaches your servers.
5. Why CAPTCHAs and In-App Filters Don’t Reduce Server Load
At this point many teams say:
“We already use CAPTCHA and an anti-spam plugin. Aren’t we covered?”
You are covered against visible spam – fake comments, junk sign-ups, trash in your inbox. You are not covered against the server cost of bots.
The reason is simple: most traditional anti-spam and security tools work inside your application, not before it.
5.1. What actually happens with in-app spam protection
Let’s take a typical WordPress setup:
A bot submits a registration or contact form.
The request reaches your web server.
PHP starts.
WordPress loads core, theme and all active plugins.
Your anti-spam plugin (or CAPTCHA) finally checks the request and says: “This is spam, block it.”
Yes, you successfully blocked the spam submission. But from a server perspective, the heavy work has already happened:
CPU cycles were spent loading WordPress and running plugin code.
RAM was allocated for the request.
Logs were written, backups grew.
In other words:
In-app filters protect your content and users, but they do not reduce the server load bots generate.
You have solved the “we don’t want spam in our interface” problem, but not the “we don’t want to pay for serving bots” problem.
5.2. Why this matters more as bot traffic grows
When bots were rare, this distinction didn’t matter much. With bots now representing a third of global traffic, it matters a lot.
If 20-30% of your requests are bots, and every one of them:
boots your app stack,
touches your database,
sits in the same queues as real users,
then you are paying a real, recurring spam bots server cost, even if your forms are “clean”.
Symptoms you may already see:
“We keep hitting CPU or I/O limits, even though human traffic hasn’t grown that much.”
“The site slows down under spikes that don’t match our campaigns.”
“We had to upgrade hosting but didn’t see a proportional improvement in business KPIs.”
That’s what “blocking too late” looks like.
5.3. The architectural shift: from “inside the app” to “before the app”
Big infrastructure players talk a lot about moving protection to the edge:
decisions are made as close as possible to the source of traffic,
bad requests are dropped before they consume origin resources.
The same idea applies here, but with a focus on spam and bad bots.
To actually reduce server load bots create, you need a layer that:
sees the request before WordPress, PHP or your framework do,
can make a fast decision based on IP, reputation and technical signals,
and, if it’s a known bad actor, stops the request right there.
No PHP. No WordPress. No database query. No extra log entry on your side.
Only after this cloud filter says “yes”, does the request reach your application, where in-app anti-spam can handle the remaining edge cases (new bots, human spammers, borderline content).
That’s the architectural gap that CleanTalk SpamFireWall is designed to fill for CMS-driven sites.
5.4. How CleanTalk is different from “just another CAPTCHA”
So where does CleanTalk sit compared to CAPTCHAs and typical form plugins?
You can think of it this way:
CAPTCHA protects forms.
Anti-Spam protects data and user base.
SpamFireWall protects your resources – CPU, RAM, bandwidth, and the time of your teams.
All three have their place. But if your goal is not only “have less spam”, but also “pay less and perform better under load”, you need something that works before your application – not only inside it.
In the next section, we’ll look more closely at how SpamFireWall’s cloud filtering actually works and how it translates into fewer bot requests hitting your servers in day-to-day operation.
If the problem is that bots consume server resources before your application can stop them, the solution has to start before your application too.
That’s exactly what CleanTalk’s SpamFireWall is designed to do.
Instead of fighting spam bots only inside WordPress or your CMS, CleanTalk adds a cloud filtering layer in front of your site. The goal is simple:
Block as many spam/bad bots as possible in the cloud, so your servers spend their time on real users, not scripts.
In business language: it’s a way to reduce server load bots create and shrink your spam bots server cost without rebuilding your infrastructure.
6.1. Two layers working together: cloud + application
CleanTalk doesn’t replace in-app filters – it adds a second layer in front of them.
SpamFireWall – cloud layer
Checks incoming IPs and technical signals against CleanTalk’s global spam and attack database.
Blocks known spam bots, brute-force tools and abusive scanners before they reach your server.
Offloads a large volume of hostile and useless traffic to the cloud.
Anti-Spam – application layer
Runs inside WordPress / your CMS.
Analyzes actual form submissions (comments, registrations, contact forms, directory listings, etc.).
Blocks spam content, fake accounts and “fresh” spam that can’t be recognized by IP alone.
Together they form a pipeline:
Internet → SpamFireWall (CleanTalk cloud) → your server → WordPress / CMS → Anti-Spam → forms & users
For a significant share of bot traffic, the journey ends at SpamFireWall – and that’s where your savings start.
6.2. What happens when a visitor (or bot) hits your site
At a high level, each request goes through three decisions:
Cloud check (SpamFireWall)
The visitor’s IP and other technical signals are checked in the CleanTalk cloud.
If it matches known spam, attack or abuse patterns, the request is blocked at once.
Your web server, PHP and database don’t have to do any work for it.
Application check (Anti-Spam)
If the cloud layer allows the request, it reaches your site as usual.
When the visitor submits a form (sign-up, login, comment, listing, contact, etc.), that submission is checked by CleanTalk’s Anti-Spam logic.
Suspicious content is blocked; clean submissions go through.
Logging and visibility
Both layers record what they did in your CleanTalk dashboard:
how many requests SpamFireWall blocked,
how many spam submissions Anti-Spam stopped,
where spam and bots are coming from.
The key architectural shift:
Instead of letting every bot request hit WordPress and then deciding “this is spam”,
CleanTalk moves a big part of that decision upstream, into the cloud.
6.3. What this means in practice for server load
From a business viewpoint, you don’t buy SpamFireWall just to say “we have another security tool”. You buy it to change the shape of your traffic:
Fewer bot requests reach your origin.
Fewer PHP workers are tied up by bots.
Fewer database queries are caused by fake sign-ups and scans.
More CPU and memory are available for actual customers.
In CleanTalk’s own stats between April 2025 and February 2026, SpamFireWall consistently processed several times more bad requests than in-app Anti-Spam checks did – including a month with 11+ billion blocked requests. That is a direct, measurable reduction in spam bots server cost for the sites behind it.
For you, the expected effects are:
More stable performance during traffic peaks and campaigns.
Less pressure to upgrade hosting “just to survive bot waves”.
Cleaner analytics (fewer fake sessions and non-human hits).
Less spam and fewer fake accounts for your team to clean up.
In short: SpamFireWall turns “bots are just part of the internet now” into “bots are largely CleanTalk’s problem, not our servers’ problem”.
7. Implementation: How to Deploy CleanTalk SpamFireWall (WordPress Example)
The good news: you don’t need a new infrastructure project or DNS migration to start reducing bot load.
For a typical WordPress site, enabling CleanTalk + SpamFireWall is a plugin-level change, not a platform rewrite.
Below is a simple rollout plan you can hand to your tech person or agency.
7.1. What you need before you start
A working WordPress site (any theme, any hosting).
Admin access to the WordPress dashboard.
A CleanTalk account (trial or paid) – this is created automatically if you use the “Get Access Key” button.
That’s it. No DNS changes, no reverse proxies, no extra servers to maintain.
Step 1 – Install the CleanTalk Anti-Spam plugin
In the WordPress admin: 1. Go to Plugins → Add New.
2. To install the Anti-Spam plugin, go to your WordPress admin panel → Plugins → Add New.
Navigate to Settings → Anti-Spam by CleanTalk in the WordPress dashboard.
2. Click “Get Access Key Automatically”.
WordPress will contact CleanTalk, create/link your account, and insert an Access Key.
Click Save Changes.
Now:
your site can communicate with the CleanTalk cloud,
basic Anti-Spam checks for forms and comments are active.
Step 3 – Make sure SpamFireWall is enabled
The best way to text the spam protection by using a test email,
stop_email@example.com
Open page with your form (don’t forget to add the shortcode in the page content) in Incognito browser tab.
Fill out the Contact form using stop_email@example.com as sender’s email.
Send the form.
You should see a message from the Anti-Spam plugin confirming that a spam submission was blocked.
*** Forbidden. Sender blacklisted. Anti-Spam by CleanTalk. ***
If you see this message, it means CleanTalk successfully working.
Cloud Dashboard
In addition, in the Cloud Dashboard you can find extra details regarding all submissions processed by CleanTalk, including HivePress registration and Add Listing forms:
IP and email of the sender, as well as the sender’s activity history across other websites connected to the CleanTalk cloud.
Geolocation of the sender.
Date and time of the submission. Page (URL) where the form was submitted (for example, a specific listing submission page).
Cloud decision – Approved or Denied.
Cloud explanation for the decision (e.g. blacklisted email, bad IP reputation, spam text, etc.).
Tools to move the sender to Block or Allow lists so you can fine-tune HivePress spam protection.
7.2. What about other CMS and custom sites?
While this section uses WordPress as the example (because it’s the most common), CleanTalk is not limited to WordPress:
There are ready-made integrations for other popular CMS and e-commerce / forum engines.
For custom platforms, CleanTalk provides an HTTP API, so your developers can send form data to the cloud and get allow/deny decisions back.
In practice, this means you can apply the same SpamFireWall + Anti-Spam model across most of your public-facing properties, not just WordPress.
From an implementation standpoint, that’s all you need:
plugin install,
access key, enable SpamFireWall,
watch the numbers.
The heavy lifting – maintaining IP reputation, filtering billions of bot requests, and absorbing the associated server load – is handled by CleanTalk’s infrastructure, not yours.
8. Business Takeaways: How to Talk About This Inside Your Company
By now, spam bots should look less like “IT noise” and more like what they really are:
A recurring, measurable cost on your infrastructure, performance and data – that you don’t have to fully pay.
Here’s how to frame this for founders, CTOs and CFOs in clear business language.
8.1. This is not a plugin decision – it’s a cost decision
Instead of “Should we install one more plugin?”, the better question is:
How much of our server budget goes to bots, not humans?
How much of that load can we move from our servers to CleanTalk’s cloud?
You already pay for:
hosting and infrastructure capacity,
lost conversions when the site is slow,
internal time spent cleaning spam and handling security noise.
CleanTalk + SpamFireWall simply changes who carries part of that load:
fewer spam/bot requests reach your servers,
less capacity is wasted on non-customers,
more headroom is available for real users.
8.2. Four sentences you can use with leadership
You can summarise the whole story in four short statements:
Cost “A noticeable share of our server capacity is currently used to serve bots. CleanTalk’s SpamFireWall blocks a large part of that traffic in the cloud, so we can either delay upgrades or get more out of our existing hosting.”
Performance & revenue “Bots compete with real users for CPU and database connections. Reducing bot load gives us more stable page speed and conversion during campaigns and peak traffic.”
Risk & operations “Many brute-force and scanner requests never reach our app if we stop them in the cloud. That means fewer alerts, fewer incidents to check, and more time for real engineering work.”
Data & decision quality “Filtering bots earlier gives us cleaner analytics – more accurate funnel numbers, conversion rates and geo data, so we can invest in the right channels and markets.”
All of that is powered by one practical change: turning on SpamFireWall alongside CleanTalk Anti-Spam.
8.3. What success looks like
When this is working, you should see:
A clear, growing number of SpamFireWall blocks in the CleanTalk dashboard – these are requests your servers no longer process.
More stable CPU and response times during both normal days and marketing peaks.
Less manual spam moderation and fewer fake accounts for your team to chase.
Analytics that look more like human behaviour and less like random noise.
You don’t have to guess: before/after numbers from SpamFireWall and your hosting panel will tell you whether your spam bots server cost is going down.
8.4. The real decision
The internet will only have more bots, not fewer. You can’t change that – but you can choose who pays for their requests.
Option A: your own servers, hosting budget and teams.
Option B: offload a large part of that work to a cloud service that is built to absorb it.
CleanTalk’s Anti-Spam plugin plus SpamFireWall is a straightforward way to choose option B:
no DNS migration,
no new infrastructure to maintain,
just a cloud filter that sits in front of your site and lets your servers focus on humans.
That’s ultimately what this article is about:
Stop treating spam bots as “just annoying”. Start treating them as a cost centre – and then deliberately make that cost smaller.
Stop wasting server resources on spam bots
Create your CleanTalk account and let SpamFireWall block bad bots in the cloud before they reach your server — no CAPTCHA challenges and no friction for real visitors.
reCAPTCHA was a brilliant idea — for its time. It kept bots busy clicking bicycles and crosswalks while real visitors went about their day.
But as automation evolved, the balance shifted. Bots got faster. Humans got irritated. And WordPress admins got a new hobby: deleting fake leads and “test messages.”
So if you’re tired of proving you’re not a robot (to a robot), let’s look at reCAPTCHA alternatives for WordPress that actually work — without turning your site into a CAPTCHA museum.
Why reCAPTCHA Fails (and Keeps Failing)
reCAPTCHA still relies on users to prove they’re human. Meanwhile, modern bots don’t need to “see” anything — they send direct POST requests straight to your backend.
The result?
Real users get blocked.
Bots still get through.
Everyone’s annoyed.
Google tried to fix this with the score-based v3, but it often misfires — flagging genuine users as suspicious and letting obvious spam through.
CleanTalk Anti-Spam — Because Invisible Security Is the Best Kind
Instead of asking users to solve puzzles, CleanTalk Anti-Spam for WordPress checks every submission server-side — before WordPress even processes it. It analyzes IPs, behavior, and content in milliseconds.
No boxes. No pop-ups. No “spot the traffic lights.” It just works — quietly, effectively, and invisibly.
Teams that switched from reCAPTCHA to CleanTalk reported dramatically fewer spam entries and smoother user flows. As one agency put it:
We stopped debugging user complaints. Forms just started working again.
That’s the kind of silence every developer dreams of.
Cloudflare Turnstile — The Diplomatic Option
Cloudflare Turnstile is what happens when someone at Cloudflare says: “Okay, but what if the CAPTCHA didn’t make people hate us?”
It checks browser behavior in the background and lets humans through without the clicks or guessing. If your site already runs on Cloudflare, setup takes minutes.
It’s privacy-focused, lightweight, and — best of all — free. Just note: performance is best inside the Cloudflare ecosystem.
hCaptcha — Privacy With Homework
hCaptcha is the privacy-friendly alternative to Google — but still makes users identify hydrants. It’s GDPR-compliant and a direct reCAPTCHA replacement, even offering small payouts to site owners.
Still, it’s a CAPTCHA. And in 2025, asking users to do anything extra is a quick way to lose mobile conversions.
If your top priority is compliance — hCaptcha fits. If it’s UX and conversions — your visitors might disagree.
The Numbers Don’t Lie
Across thousands of WordPress sites, one trend is clear: less friction equals less spam.
CAPTCHA used to feel clever — until it started blocking real users. If you’re looking for a CAPTCHA alternative that protects your WordPress site without frustrating visitors, this article explains how CleanTalk does it differently.
According to Baymard Institute, traditional CAPTCHA can reduce form completion rates by up to 30%. Even invisible versions like reCAPTCHA or hCaptcha still cause friction and delay — which means fewer conversions and more frustrated visitors.
CleanTalk offers a modern anti-spam solution that keeps bots away without testing your users’ patience.
The Problem with Old-School CAPTCHA (and Why You Need a CAPTCHA Alternative)
CAPTCHA doesn’t just block spam — it blocks progress. Every unnecessary click is a lost second of trust. Every failed puzzle is a potential customer who decides not to try again.
Many WordPress site owners see a 25–30% drop in form completions when CAPTCHA is enabled. That’s not spam protection. That’s conversion destruction.
Even “invisible” versions like Google reCAPTCHA v3 or hCaptcha still rely on behavioral tracking and hidden scoring. They may feel lighter, but they still slow users down and send data off-site.
Security shouldn’t make visitors feel like suspects.
Why Users Are Over It
The internet has changed, but CAPTCHA hasn’t. Users expect smooth, fast, privacy-safe experiences. They want to submit, not prove.
And when your site feels like a test, they leave.
The sad part? Many owners think CAPTCHA is still necessary because “bots will flood us otherwise.” But there’s a smarter, modern CAPTCHA alternative — and it doesn’t punish your audience for being human.
CleanTalk: The CAPTCHA Alternative That Works Quietly
CleanTalk replaces the CAPTCHA wall with a silent filter. Instead of challenging users, it checks every submission in real time via cloud-based spam protection.
How it works:
Each form submission is analyzed using CleanTalk’s global spam database.
The system checks IP reputation, submission speed, and spam patterns.
Legitimate users pass instantly — no tests, no tracking, no delays.
It’s the same level of protection without punishing your audience for being human.
Want to see what happens when you remove CAPTCHA? Try CleanTalk for free — protect your WordPress site without losing users.
What Happens When You Remove CAPTCHA and Use a CAPTCHA Alternative
A client switched from reCAPTCHA to CleanTalk. Within two weeks, form completions increased by 28%, and spam disappeared almost entirely.
No code changes. No pop-ups. Just results.
That’s the key difference — you don’t lose engagement while keeping the spam out.
Invisible Security, Visible Results
CleanTalk supports every major WordPress plugin — comments, contact forms, WooCommerce checkouts, and membership systems.
You install once, activate your API key, and it just works. It doesn’t track personal data or store cookies. Everything runs in the background while your users enjoy a smoother experience.
No puzzles. No friction. No lost leads.
If you want to learn more about configuration and setup, visit our WordPress Anti-Spam Plugin page for detailed installation steps.
Final Thoughts
CAPTCHA helped when the web was simpler. But in 2025, people value privacy, speed, and trust over proof.
CleanTalk gives you both: real protection for your site and a better experience for your visitors.
Start your free trial of CleanTalk Anti-Spam plugin and experience invisible spam protection that works.
Disclaimer: reCAPTCHA™ and hCaptcha™ are trademarks of their respective owners (Google LLC and Intuition Machines, Inc.). This article is for informational purposes only and not affiliated with or endorsed by those companies.
We’re reaching out to let you know about a security vulnerability that was recently disclosed in the CleanTalk Anti-Spam plugin for WordPress. We’ve already released a fix, and we want to make sure you’re protected.
What happened?
On February 14, 2026, a vulnerability (CVE-2026-1490) was publicly disclosed affecting CleanTalk Anti-Spam plugin versions 6.71 and earlier. The issue was found in the checkWithoutToken function, which relied on reverse DNS (PTR record) resolution to verify incoming requests. An attacker could spoof a PTR record to impersonate CleanTalk servers, potentially allowing them to install unauthorized plugins on a vulnerable site. In a worst-case scenario, this could lead to remote code execution through a chain of exploits.
Here’s the important part: this vulnerability only affects sites running with an invalid or expired or missing API key. If your CleanTalk subscription is active and your API key is valid, the exploitable code path is never triggered. That said, we strongly recommend updating regardless – it’s simply good practice.
What you need to do:
Update the plugin to version 6.72 or later – the fix is already available in the WordPress plugin repository Verify your API key is active and valid in your CleanTalk dashboard at https://cleantalk.org/my or in your WP Dashboard->Settings->Anti-Spam by CleanTalk. If you have auto-updates enabled, you may already be on the latest version — but please double-check
Keeping plugins up to date is the most effective way to maintain website security.
What we’ve done on our end: We patched the checkWithoutToken function to no longer rely solely on PTR records for authorization. The updated verification process uses stronger validation methods that cannot be spoofed. The fix was released in version 6.72, which is available now.
A note from our team: We take security seriously – both yours and our own. No software is immune to vulnerabilities, but what matters is how quickly they’re addressed and how transparently they’re communicated. We identified the issue, developed a fix, and released the update promptly.
We’re also conducting an internal review of similar patterns across our codebase to prevent this class of vulnerability from recurring. If you have any questions or need assistance updating, our support team is here to help at support@cleantalk.org.
We have already talked about the launch of security service for WordPress in the previous article. Today we want to talk about the launch of heuristic analysis to detect malicious code.
The very presence of malicious code can lead to a ban in search results or a warning in the search for that the site is infected, to protect users from potentially dangerous content.
You can find malicious code on your own, but it’s a lot of work and most WordPress users do not have the necessary skills to find and remove unnecessary lines of code.
Often, the authors of malicious code disguise it, which makes it difficult to determine by its signatures. The malicious code itself can be located anywhere on the site, for example the obfuscated PHP-code in the logo.png file, and the code itself is called by one inconspicuous line in index.php. Therefore, the use of plugins to search for malicious code is preferable.
CleanTalk on the first scan scans all WordPress kernel files, plugins and themes. When rescanning, only those files that have changed since the last scan were scanned. This saves resources and increases scanning speed.
How heuristic analysis works
One of the main disadvantages of heuristic analysis is that it is quite slow, so we use it only when it is really necessary. First of all, we divide the source code into lexemes (the minimal language construct) and remove all unnecessary:
Space symbols.
Comment of different types.
Not PHP code (outside of tags <?php ?> )
Next, we recursively simplify the code until there are no “complex constructs”:
Perform concatenation of strings.
Substitution of variables into variables.
and other
Also, in the process of simplifying the code, we monitor the origin of the variables and many others.
In the end, we get a clean code that can be analyzed. It is very important that we get the code not in the form of a string, but in the form of lexemes. Thus, we know where the lexeme is a string with the desired text, and where the lexeme function is.
In the sense of finding “bad constructs” eval for us there is a difference:
<?php echo 'eval("echo \"some\"")'; ?>
— in this case there will be no lexeme T_EVAL,
there is a lexeme T_CONSTANT_ENCAPSED_STRING ‘eval (“echo \” eval\”)’
<?php eval('echo "some"'); ?>
– and here it is. And this is the version we will find.
We look for such constructs, we break them down into degrees of criticality:
Critical:
eval
include* и require*
with bad file extension
non-existent files (will be deleted in the next versions)
connecting deleted files
Dangerous
system
passthru
proc_open
exec
include* и require*
with the error suppression operator (will be deleted in the next versions)
with variables depending on POST or GET.
Suspicious
base64_encode
str_rot13
syslog
And other.
We are constantly improving this analysis: adding new constructions to search, reducing the number of false alarm, optimize the simplification of the code.
In the plans to teach it to detect and decode strings encoded in URL and BASE64 and others.
The plugin itself is available in the WordPress directory. If you are unsure how to identify, remove, or clean malware using the plugin, you can book a WordPress Malware Removal service with our Security & Pentest team.
Leaked passwords are one of the fastest-growing threats to WordPress. WordPress password leak protection helps block attackers who reuse stolen credentials from massive breaches.Security by CleanTalk now gives you a way to stop them before they log in.
What’s New: WordPress Password Leak Protection
Password Leak Protection automatically checks user credentials against public breach databases. If a password is exposed, login is denied and the user is forced to reset it on the next attempt.
Password Leak column in the Users table with clear statuses6
User experience
When a password is flagged as leaked, the next login takes the user to a compact reset form right on the login page. They enter the current password, choose a new one, confirm it, and can sign in again immediately. The leaked status is cleared after a successful change.
Dashboard banner shown when a user’s password has been leaked
Administrators can monitor security directly inside WordPress, and WordPress password leak protection adds another layer of defense. The Users table now shows a Password Leak column with three possible statuses: Not verified, Safe, or Leaked. If the system finds compromised accounts, the dashboard shows a warning banner.. For additional control, administrators can run manual checks from the Users section, and results update instantly through AJAX. Background tasks run automatically in batches, ensuring that large sites are processed without extra load.
How to enable
By default, the system keeps the feature disabled. To turn it on:
Go to in your WP Dashboard → Settings → Security by CleanTalk.
Click on Genetal settings tab.
In the Authentication and Logging In section, select and enable the option “Checking the user’s password for information leaks.”
Select which roles to cover. By default, the system includes Administrators and Editors.
Run a one-time scan in Users to get an instant baseline for current accounts.
Settings panel for enabling password leak checks and selecting roles
Why It Matters: WordPress Password Leak Protection
According to OWASP, exposed credentials are among the most dangerous security risks for web applications. Even strong passwords become unsafe once they appear in leak databases. Password Leak Protection reduces this risk by stopping logins with compromised passwords and requiring users to reset them before continuing.
Next steps
Update your CleanTalk Security Plugin to the latest version. Enable Password Leak Protection in Authentication → General Settings, choose the roles to cover, and run a one-time scan in Users to check current accounts.
If you want to strengthen your defenses further, combine Password Leak Protection with CleanTalk Anti-Spam to stop bot registrations and spam comments, and with Uptime Monitoring (ссылка) to keep track of your site’s availability around the clock.
FAQ
Which roles are checked by default? By default, Password Leak Protection applies to Administrators and Editors. You can extend coverage to other roles in Authentication → General Settings.
Does Password Leak Protection send email alerts? No. Notifications appear in the WordPress dashboard as a banner and as statuses in the Users table. There are no email alerts for leaked passwords.
If a password leaks, the system blocks the login. On the next attempt, it redirects the user to a reset form on the login page. After the user confirms a new password, the system marks their account as safe again..
How does this feature work with Brute Force Protection and 2FA? Password Leak Protection complements brute force defense and Two-Factor Authentication (2FA). Together they stop both guessed and compromised passwords, reducing the most common login risks for WordPress sites.
If you run a WordPress or WooCommerce site, WordPress fake signup protection isn’t just about convenience — fake email signups waste resources, distort analytics, and can even harm your domain reputation. According to CleanTalk’s historical stats, up to 30 % of registration spam comes from non-existent email addresses.
That means thousands of “users” who will never confirm their accounts, never receive notifications, and often trigger bounce-backs that make email servers suspicious of your site.
CleanTalk’s Email Checker verifies email existence in real time — the moment a user types or submits a form. The updated feature Non-Existent Email Notification instantly alerts users if their email is invalid, reducing failed signups and improving UX.
If the address doesn’t exist or belongs to a disposable domain, CleanTalk blocks the signup before saving it to your database — no fake profiles, no clutter.
CleanTalk routes each submitted email to its cloud service, checks validity, and returns a pass or block decision in milliseconds. In your Dashboard, blocked signups appear with status “Fake email”, letting you track spam attempts and patterns.
Real Case: 100K Fake Emails Blocked
Over time, CleanTalk has filtered massive volumes of fake email signups across WordPress websites — around 100,000 per month for large site networks.
Common examples include:
noemail@fake-domain.biz
test@nonexistmail.ru
qwerty123@mail.fake
Each could have filled your database with junk or hurt your deliverability.
Example image: entries marked “Fake email” and “Post denied” in the Anti-Spam Dashboard.
For WooCommerce Store Owners
Fake accounts are even more damaging in e-Commerce. They:
Distort conversion and sales analytics
Trigger failed transactions and undelivered order emails
Lower sender reputation and email deliverability
With CleanTalk, every checkout form is validated in real time — only real customers complete orders. Result: fewer errors, cleaner data, better performance.
Why It Matters
Fake signups lead to:
Lost communication (no confirmation or password reset)
CRM clutter and wrong email lists
High bounce rates
IP or domain blacklisting
How to Enable Fake Signup Protection
Install the CleanTalk Anti-Spam plugin (https://wordpress.org/plugins/cleantalk-spam-protect/)
Register at CleanTalk.org (https://cleantalk.org/register) and add your website
In your Dashboard, enable “Email Existence Check / Notification”
Optionally turn on “Non-Existent Email Notification” for instant feedback
This feature is included in the standard Anti-Spam plan — no coding or extra modules required.
Combine with Other CleanTalk Protections
For maximum defense, combine Email Validation with:
SpamFireWall — blocks bots before they reach forms
Extra Package — 45-day logs, country blacklists, stop-words, and alerts
Continuous Updates & UX Improvements
CleanTalk’s detection engine is updated daily. Support for encrypted SMTP improves reliability, and the Non-Existent Email Notification (released Dec 2024) now gives instant feedback, reducing typos and abandoned forms. The system evolves constantly to counter new spam tactics — you don’t need to adjust anything.
Need Help or Want to Learn More?
Have questions about WordPress fake signup protection or WooCommerce integration? Leave a comment or create a support ticket (https://cleantalk.org/my/support).
Fake email signups silently damage your site’s data, performance, and reputation. CleanTalk’s real-time email checker and instant user feedback deliver clean signups and trustworthy analytics.
Get started now — register your free trial and see how many fake accounts your site can block automatically.
A sophisticated spambot operating under the email address phil9982@bestaitools.my became one of the most active threats in late 2025. Since its discovery on November 10, 2025, this automated attacker has spammed 11,428 websites, with the last recorded activity being December 15, 2025. The CleanTalk anti-spam service currently blocks approximately 9,048 requests per day from this single email address—that’s over 375 spam attempts every hour.
Unlike obvious spam, the messages mimic legitimate customer support requests, making them difficult to detect without advanced anti-spam protection.
This bot sends seemingly mundane questions about service offerings, appearing to be from potential customers:
“Is there a referral program?”
“Do you offer maintenance plans?”
“Do you work weekends?”
“Can I pay with PayPal or other methods?”
“Do you offer support after purchase?”
“Do you offer consultations over Zoom or phone?”
“Do you offer recurring service plans?”
“Do you offer service in rural areas?”
“Can I pick up instead of delivery?”
“Can I get a service checklist after the job?”
“Can I get a quote by text or email?”
“Do you offer financing through a third party?”
It’s very difficult to tell if a message is spam based on its content. This poses the risk of you replying and having your email harvested by spammers. It’s hard to say how they’ll use it, but it’s safe to assume it could be used to send spam to websites or to try to gain access to your website account.
If you’re seeing traffic or spam submissions from this email, here’s how to stop it:
1. Use CleanTalk Anti-Spam Plugin Install the CleanTalk Anti-Spam plugin for your CMS (WordPress, Joomla, Drupal, etc.). It automatically filters requests by checking emails, IPs, and behavior against the global CleanTalk Spam Database.
This email is already blacklisted and will be blocked automatically by the plugin.
2. Manually Block the Email (if needed) If you want to block it manually in addition to using CleanTalk:
Add phil9982@bestaitools.my to your site’s block list.
Block common IPs that were used in attacks.
Monitor your server logs for repetitive POST requests.
phil9982@bestaitools.my is a known spammer attacking thousands of sites daily. By installing proper anti-spam protection like CleanTalk and staying vigilant, you can block these threats before they reach your visitors.
If you’re already using CleanTalk, rest assured — this spammer is on the blacklist and will be filtered automatically.
At CleanTalk, we regularly work with professional WordPress agencies managing business-critical websites across healthcare, infrastructure, and enterprise sectors. In these contexts, security solutions must be reliable, lightweight, and proven over time.
One such example comes from Myanmar, where a regional web development agency, Bold Label, manages multiple high-traffic and high-visibility WordPress sites for enterprise clients.
This approach reduced plugin bloat, simplified maintenance, and made security behavior predictable across different sites and industries.
Securing Medical Platforms at Scale
Healthcare websites are among the most sensitive WordPress environments. They handle patient inquiries, appointment requests, and critical informational content that must remain accessible and trustworthy.
One of the largest diagnostic centers in Myanmar operates its main website on WordPress, with ongoing management by Bold Label. CleanTalk has been actively protecting this site by blocking automated attacks, filtering spam submissions, and preventing malicious access attempts.
The result has been stable operations, clean form data, and minimal administrative overhead through an easy-to-manage dashboard. Security remains effective without interfering with legitimate patients or medical staff. See website.
Protecting Industrial and Corporate Websites
CleanTalk is equally effective for corporate and infrastructure-focused websites that face different threat profiles.
A leading powerline and electrical construction company in Myanmar relies on CleanTalk for malware protection and abuse prevention on its corporate WordPress site. Managed by Bold Label, the site serves as a key business touchpoint for partners and institutional stakeholders.
CleanTalk keeps the site clean, fast, and uncompromised, even under constant background scanning and automated threats. See website.
Why Agencies Standardize on CleanTalk
For agencies like Bold Label, WordPress security is not an upsell feature. It is part of delivery responsibility.
By standardizing on CleanTalk, agencies reduce maintenance complexity, shorten incident response time, and avoid reactive security workflows. This allows development teams to focus on performance, UX, and scalability rather than ongoing cleanup and monitoring.
Practical Security in Real Deployments
These deployments show how CleanTalk operates in real production environments, not just controlled test cases.
Across healthcare and industrial websites, CleanTalk delivers consistent protection with minimal configuration and low ongoing overhead. While these examples come from specific sectors, the same approach applies to any WordPress site that requires stable, long-term security.
