Catch WordPress bots without an account: a five-check WebDecoy setup
If fake registrations, comment spam or checkout automation are hitting your site, installing a plugin is only the first step. The useful question is: can you verify what it sees on your actual stack? Iβm on the WebDecoy
If fake registrations, comment spam or checkout automation are hitting your site, installing a plugin is only the first step. The useful question is: can you verify what it sees on your actual stack?
Iβm on the WebDecoy team. This is a practical acceptance test for our free WordPress plugin, which runs locally without an account or API key. Start on staging, in monitor mode.
1. Install, then confirm the mode
In wp-admin, open Plugins β Add New, search for WebDecoy, and install and activate it. The plugin author is WebDecoy. You can also use WP-CLI:
wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy config list
wp webdecoy status
Monitor mode records detections without enforcing blocks. Confirm the setting before testing. Keep a note of your existing security plugins and cache configuration so you know what else can affect a result.
2. Exercise a normal visitor journey
Use a private browser window. Try the WordPress flows your site actually uses: opening a page, submitting a legitimate comment, logging in and registering if registration is enabled.
On a WooCommerce staging store, use your payment providerβs sandbox to test checkout. Never use live card transactions to simulate an attack.
Record whether the action completed, what the visitor saw and whether WebDecoy logged anything. A clean-looking home page does not verify registration or checkout.
3. Verify a controlled detection
On a staging form protected by WebDecoy, inspect the actual rendered honeypot field. Make a controlled test submission that populates that field, then check the pluginβs local detection log.
Compare the event time and request path with your test. In monitor mode you are checking observation, not expecting enforcement. If the event is missing, investigate the form integration and request path before assuming protection.
Use the field your installation actually renders; do not copy a guessed field name. Third-party form builders need their own compatibility check.
4. Test through the cache and proxy
Repeat a normal page request with the cache cold and warm. Check your host or CDNβs response headers to establish which request was a cache hit.
A request served entirely by an edge cache may never reach WordPress PHP. Browser-side reporting and server-side inspection are separate paths; verify both. Also verify how the real client address is passed through your trusted proxy before relying on IP-based limits.
5. Decide from evidence
Keep a short test record:
| Test | What to record |
|---|---|
| Normal visitor | Completed action and unexpected events |
| Controlled honeypot submission | Matching local detection |
| Cache hit and miss | Which layer observed each request |
| Sandbox checkout | Successful normal flow and relevant logs |
If you have not observed the path you care about, keep investigating in monitor mode. If you later enable enforcement, rerun the legitimate flows immediately. A bot signal is useful evidence; it is not a guarantee that every automated request is malicious.
The core plugin includes local logs, comment/login/registration protections, honeypot signals and WooCommerce checkout features. Connecting WebDecoy Cloud is optional. You can evaluate local behavior without creating a cloud account.
Install WebDecoy from WordPress.org and try these checks on one site. If a step behaves differently on your stack, share the WordPress, PHP, form and cache versions and a sanitized description of the result. Do not post visitor IP addresses, credentials or private logs.
Prepared with AI assistance.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.