Fake registrations. Repeated login attempts. Strange requests for files you never published. If you run WooCommerce, checkout abuse can add another problem to the list.
Before enabling another blocking rule, I want to answer a smaller question: can I see what triggered it?
I'm Chris, the developer behind WebDecoy. This walkthrough uses our free, open-source WordPress plugin to record a controlled request in monitor mode. Local functionality doesn't require an account or API key; connecting the cloud service is optional.
The useful part is the workflow: generate one known event, find its record, and separate detection from enforcement.
Start on one staging site
From the WordPress root, with WP-CLI available:
wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy config get mode
wp webdecoy status
You can also install WebDecoy Bot Detection through Plugins → Add New. Check the mode before testing. If the plugin is already installed, skip the installation command.
Monitor mode lets you inspect detections before applying blocking. It still executes code and writes records, so use staging to check compatibility and overhead.
If WEBDECOY_DEFAULT_MODE forces a mode in wp-config.php, the CLI won't override it. Read the command result rather than assuming the change worked.
In the status output, note:
| Field | What to check |
|---|---|
version |
Which build you're evaluating |
mode |
Confirm monitor
|
cloud |
Whether a cloud account is connected |
detections_total |
Your starting detection count |
active_blocks |
Your starting active IP-block count |
Give the logger one known event
I ran this on an isolated local WordPress site, bound to loopback at port 18079. There was no real .env file at the target path. The request exercises a default tripwire path.
TEST_BASE='http://localhost:18079'
curl -sS -A 'python-requests/2.31' \
-o /dev/null -w 'HTTP %{http_code}\n' \
"$TEST_BASE/.env"
Use your own isolated test environment, not another person's site or a path containing actual secrets. A CDN, cache, authentication layer, or WAF may stop a request before WordPress sees it.
Then check again:
wp webdecoy status
The request returned 301. The detection still happened.
Here's what the September 28 test actually produced:
| Signal | Before | After |
|---|---|---|
| Mode | monitor | monitor |
| Total detections | 0 | 1 |
| Active IP blocks | 0 | 0 |
The HTTP response was 301. The saved detection contained the tripwire_rule flag and /.env path metadata.
That is why I don't use HTTP status as my detection test. A redirect can come from another part of the request path. A recorded detection also doesn't prove that the request was blocked.
This test established that a matching record was created and the active IP-block count didn't increase. It did not measure detection accuracy, false-positive rates, checkout compatibility, or performance.
The exact environment was WordPress 7.1, PHP 8.3.33, and WebDecoy 2.10.1 at commit d386344, with no cloud connection. For this run I mounted that source checkout and activated it with wp plugin activate webdecoy; the WordPress.org installation command above is the normal distribution route. Record your version because the repository and directory package can update at different times.
Match the record, then test real workflows
In WebDecoy's detection log, correlate the timestamp, User-Agent, and detection flags with your request. On a busy site, an increased total alone won't tell you which request caused it.
Next, stay in monitor mode and exercise the workflows your visitors need:
- Log in as an administrator and an ordinary user.
- Register, reset a password, and submit a comment where those features are enabled.
- Browse through the same cache/CDN path your visitors use.
- For WooCommerce, test the journey from cart to order confirmation using a test payment environment.
Watch for detections that overlap legitimate actions. Understand those before changing enforcement. Shared IPs and reverse proxies also affect how you should interpret an address in a log.
For agencies, one representative staging site is a useful starting point. It isn't evidence that every client site, theme, checkout, and plugin combination behaves the same way.
To stop the trial:
wp plugin deactivate webdecoy
Deactivation is not uninstallation or a promise that stored logs have been erased.
Try it on a site you control
What's the most persistent unwanted traffic on your WordPress sites: login attempts, fake registrations, comment spam, or checkout abuse? If you try the workflow, I'd be interested in what was hard to interpret in the logs. Please redact IP addresses and customer information before sharing examples.
Top comments (0)