Tag: anti spam

If your website uses the default WordPress signup flow, spam registrations can become a real problem surprisingly quickly. Bots scan the web for open signup pages, submit fake user data, and fill WordPress sites with junk accounts that never behave like real users.

For standard WordPress websites, this usually happens through the default registration endpoint. In WordPress core, the registration URL is typically generated through wp_registration_url(), which returns wp-login.php?action=register. The Register link is shown when public registration is enabled.

That is why site owners often search for terms like standard wordpress registration forms spam, default wordpress registration form spam, or stop spam user registration wordpress. They are not looking for a page builder or a form plugin issue. They are trying to stop fake signups on the native WordPress registration flow.

In this guide, you will learn what the standard WordPress registration form is, why it gets spammed, how to protect it with CleanTalk Anti-Spam, and how to test the protection correctly.

What is a standard WordPress registration form?

A standard WordPress registration form is the default signup form managed by WordPress core rather than by a third-party membership or form-builder plugin.

On most sites, this registration flow is associated with:

wp-login.php?action=register

WordPress developer documentation confirms that wp_registration_url() returns that path. The developer reference for wp_register() also shows that the Register link is only displayed when the site has public user registration enabled.

So when we talk about standard WordPress registration forms, we mean the built-in WordPress registration flow – not a custom Elementor, WPForms, or membership-plugin form.

Why standard WordPress registration forms attract spam

The default WordPress registration page is predictable. It uses a known path, a familiar structure, and is often left open without a dedicated anti-spam layer.

That combination makes it easy for bots to detect and target. Once they find the registration page, they can create fake subscribers, junk user accounts, throwaway profiles, and low-quality signups at scale.

This is more than a cosmetic issue. Spam registrations can:

• clutter your user database,
• waste moderation time,
• pollute analytics,
• trigger unwanted email flows,
• create future abuse risks from fake accounts.

If your website depends on public registration, protecting this form should be treated as a baseline measure, not as an optional improvement.

How to protect standard WordPress registration forms from spam

One of the simplest ways to protect the default WordPress registration form is to use CleanTalk Anti-Spam for WordPress.

The official WordPress.org plugin page says the plugin stops spam registrations, and the current plugin listing shows 200,000+ active installations.

CleanTalk is built to filter spam in the background instead of forcing every visitor through visible CAPTCHA friction. That matters because public registration is often part of your growth flow, and every extra barrier can reduce the number of legitimate signups.

How to install CleanTalk Anti-Spam for WordPress

To install the Anti-Spam plugin, go to your WordPress admin panel→ Plugins→ Add New.

Then enter «СleanTalk» in the search box and click the Install button for «Spam protection, Anti-Spam, FireWall by CleanTalk».

After installing the plugin, click the «Activate»‎ button.

After it is done go to the plugin settings and click the «Get Access Key Automatically» button. Then just click the «Save Settings»‎ button.

CleanTalk’s current and older guides follow this same setup logic: install the plugin, activate it, connect it, and then let it start protecting supported forms on the site.

How to test that spam protection works

When testing form protection, do not test it while logged in as a WordPress administrator. CleanTalk documentation explicitly notes that administrator actions are not checked, so testing should be done as a regular visitor in Incognito or Private mode.

Use this process:

Open the registration page in an Incognito or Private browser tab.

Fill in the required form fields.

Use the test email address stop_email@example.com.

Submit the form.

The current CleanTalk help page and the WordPress.org plugin FAQ both use stop_email@example.com as the test email for comments, contacts, registrations, and signups. If the protection is active, the test submission should be blocked.

Why this approach is good for conversion

Many site owners try to stop spam registrations by adding visible obstacles to the signup flow. Sometimes that helps, but it can also make legitimate visitors drop off before completing registration.

A background anti-spam solution is often a better fit when registration is part of the site’s business funnel. It helps reduce fake signups without making real users solve extra challenges every time they want to create an account.

For websites that depend on community growth, lead capture, onboarding, or member access, keeping the registration form simple is almost as important as keeping it protected.

How to know whether the default WordPress form is still being abused

Some websites use a custom registration plugin but still leave the default WordPress registration path available.

That creates a hidden problem: the visible custom signup flow may look protected, while bots continue to register through the original WordPress endpoint.

If you suspect that, review your registration sources and check whether the default WordPress registration screen is still enabled. If your custom plugin fully replaces the standard flow, it is often wise to protect the custom form and disable the unused default registration route.

Using a custom registration plugin instead?

If your website uses User Registration & Membership by WPEverest instead of the default WordPress registration form, use the dedicated CleanTalk guide for that plugin:

User Registration & Membership spam protection guide
/user-registration-forms-spam-protection-for-wordpress/

This internal link is useful both for readers and for SEO, because it clearly separates two close but different intents:

• default WordPress registration spam,
• spam on a specific registration plugin.

Final thoughts

If public registration is enabled on your site, the standard WordPress registration form should not be left unprotected.

WordPress core makes the registration path predictable, and bots actively exploit predictable signup flows. CleanTalk’s WordPress plugin is built to stop spam registrations and is already widely used across WordPress sites.

If your goal is to reduce fake signups without making registration harder for real users, start by protecting the default WordPress registration form, testing it properly in Incognito mode, and closing any unused registration paths that may still be exposed.

Start protecting your registration forms with CleanTalk Anti-Spam today.

FAQ

What is the default WordPress registration URL?

By default, WordPress returns the registration URL through wp_registration_url(), which points to wp-login.php?action=register.

When does WordPress show the Register link?

The Register link is shown when public registration is enabled through the Anyone can register setting.

Does CleanTalk protect registration forms?

Yes. The official WordPress.org page for the CleanTalk plugin says it stops spam registrations.

How do I test the anti-spam protection?

Test as a logged-out visitor in an Incognito or Private tab and use stop_email@example.com. That test address is documented in current CleanTalk help and in the WordPress.org plugin FAQ.

What if I use a custom registration plugin instead of the default WordPress form?

Then it is better to use a plugin-specific guide and make sure the default WordPress registration endpoint is not still open if you no longer need it. The CleanTalk blog already has a dedicated guide for User Registration & Membership.

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.

• 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.

3.1. Cloud firewall vs in-app spam checks

Looking at the monthly report:

• February 2026:
  • Anti-Spam: 91,136,173 events
  • SpamFireWall: 738,199,535 events
• November 2025:
  • Anti-Spam: 92,113,219
  • SpamFireWall: 721,915,379

A typical pattern emerges:

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:

1. United States – 269,351,056 events (24.19%)
2. Netherlands – 150,566,461 (13.52%)
3. Germany – 66,958,677 (6.01%)
4. Russian Federation – 46,137,396 (4.14%)
5. Brazil – 40,897,099 (3.67%)
6. 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.

6. Solution: CleanTalk SpamFireWall (Cloud Filtering)

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.

1. 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.
2. 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:

1. 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.
2. 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.
     
3. 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.

3. In the search box, type: cleantalk.

4. Find “Spam protection, Honeypot, Anti-Spam by CleanTalk”.

Click Install, then Activate.

Step 2 – Connect plugin to the cloud

1. 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.

3. 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

1. Open page with your form (don’t forget to add the shortcode in the page content) in Incognito browser tab.
2. Fill out the Contact form using stop_email@example.com as sender’s email.
3. Send the form.
4. You should see a message from the Anti-Spam plugin confirming that a spam submission was blocked.

*** Forbidden. Sender blacklisted. Anti-Spam by CleanTalk. ***

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:

1. 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.”
2. 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.”
3. 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.”
4. 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.