Spam protection usually breaks down at the edges. Your main forms behave fine, then one AJAX endpoint, one checkout flow, or one internal tool starts getting blocked too often, or not blocked enough.

That is where broad site-wide settings stop being enough. In Must-Have Captcha, custom rules give you a way to tune protection for specific WordPress requests without falling back to visible challenges or disabling protection entirely.

We built custom rules for the messy reality of WordPress sites. Not every form should be judged the same way, and not every endpoint deserves the same threshold.

What custom rules actually do

Custom rules let you change how Must-Have Captcha handles specific requests based on what they are and where they come from.

You can match requests by:

  • URL
  • IP address, including CIDR ranges
  • POST data in key=value format
  • WordPress AJAX action

For each rule, you can choose a protection level such as Never Block, Basic, Normal, Strict, Block & Ignore, or No Logging.

In practice, this means you can keep your global protection level sensible, then make exceptions where they are needed. That is a better setup than forcing the whole site into Strict mode because one form is being attacked, or weakening everything because one trusted endpoint is too sensitive.

One part of this feature we like is its simplicity: rules are processed from top to bottom, and the first match wins. That gives you predictable behavior, but it also means rule order matters a lot.

Why site-wide protection levels are not always enough

A global threshold is a good default. Many sites can run well with Basic, Normal, or Strict and never touch anything else.

But WordPress sites rarely stay simple for long. A brochure site adds Contact Form 7. A store adds WooCommerce checkout and account pages. An agency site may include custom AJAX actions, lead forms, embedded tools, and admin-facing workflows.

The real problem is not just spam volume. It is variation.

Different request types carry different risk and different tolerance for false positives:

  • A public contact form may need tighter filtering
  • A checkout request may need more care because legitimate users should not be interrupted
  • An internal AJAX action may need to be trusted
  • A noisy endpoint may need blocking without filling your logs

This is where custom rules become relevant. They let you respond to the shape of your site instead of pretending every request is equivalent.

Practical scenarios where custom rules are the right tool

Whitelisting trusted endpoints

Sometimes you know a request should pass. Maybe you have a custom API-like form endpoint, a trusted internal integration, or a specific AJAX action used by your theme or plugin stack.

In that case, a rule set to Never Block is often the cleanest solution. You are not lowering protection across the whole site. You are explicitly allowing one known case.

This is usually better than switching the global threshold to Basic just to accommodate one workflow.

Tightening protection on high-risk forms

Some URLs attract more abuse than others. Contact pages, registration forms, and high-visibility landing pages often get hammered by low-quality automation.

A URL rule or POST data rule can push those requests to Strict while the rest of the site stays on Normal. For WooCommerce stores, this can be useful when attacks concentrate on a specific account or checkout-related flow.

In other words, custom rules let you be strict where the risk is real, not everywhere.

Reducing noise in high-volume attacks

There are cases where you want to block obvious junk but do not want your blocked requests database filled with repetitive garbage.

That is what Block & Ignore and No Logging are for:

  • Block & Ignore always blocks and skips storage
  • No Logging uses the normal protection logic but does not store blocked requests

That matters because logging is useful, but not every junk request deserves a permanent record.

How rule order changes the result

Custom rules are evaluated sequentially. The first rule that matches is the one that applies.

This is the most important thing to understand before you create several overlapping rules.

For example:

  • Rule 1: /contact/ set to Strict
  • Rule 2: action=submit set to Never Block

If a request to /contact/ also includes action=submit, the first matching rule wins. If the URL rule is first, the request gets Strict protection. If the POST data rule is first, it is allowed.

That is not a bug. It is how the system stays predictable.

Our recommendation is simple:

  • Put more specific rules above broader ones
  • Review older rules when adding new ones
  • Add notes so future-you knows why a rule exists

On agency-managed sites, this matters even more. Months later, a forgotten whitelist can be hard to spot unless the rule order and notes are clear.

Edge cases and what to watch out for

Custom rules are flexible, but they are not magic.

First, be careful with broad URL matches. Partial matching is useful, but if the pattern is too loose, you may affect more requests than intended.

Second, whitelisting should be deliberate. Never Block is powerful, and that is the point, but it should be used for genuinely trusted scenarios, not as a shortcut whenever a form behaves unexpectedly.

Third, if you rely on logging for review and replay, remember that Block & Ignore and No Logging reduce what gets stored. That can be the right decision for noisy attacks, but it also means less visibility later.

Finally, if your site has custom request handling, developer hooks can take this further. For example, the mhcaptcha/custom_rules, mhcaptcha/threshold, and mhcaptcha/request_type filters make it possible to tune protection programmatically when the UI rules are not enough.

Take-home message

Custom rules in Must-Have Captcha are not just an advanced setting. They are the feature that makes behavior-based protection practical on real WordPress sites with mixed traffic, custom forms, and uneven spam risk.

Used well, they help you avoid the usual bad tradeoff between overblocking and underprotecting. You keep one protection system, but apply it with more precision.

If you want to see how this fits into your own setup, explore the Must-Have Captcha product page or check our custom rules documentation.