How to Detect Bot Traffic on WordPress with WebDecoy

Bots probing your WordPress site are easier to deal with when you can see what triggered a detection. WebDecoy puts that evidence inside wp-admin: inspect the requests, decide which crawlers you want to allow, and enable protection when you are ready.

Install WebDecoy on your WordPress site — free local detection, no account or API key required. You can also install directly from the official WordPress.org listing.

This walkthrough uses the released WebDecoy 2.10.5 plugin on a fresh local WordPress site. The requests are controlled tests so you can repeat the checks on your own site. They are not customer attack statistics.

Watch the installation walkthrough

Watch the full WordPress walkthrough on YouTube.

The video covers installation, monitor mode, the detection log, AI crawler controls, and a verified canary request that returns HTTP 403 under enforcement.

1. Install and activate WebDecoy

In your own WordPress dashboard:

1. Open Plugins → Add Plugin.
2. Search for WebDecoy.
3. Find WebDecoy Bot Detection – Block AI Crawlers, Spam Bots & Card Testing, published by WebDecoy.
4. Click Install Now, then Activate.
5. Open WebDecoy in the admin menu.

Prefer WP-CLI? Run this from your WordPress installation:

wp plugin install webdecoy --activate

Local detection works without creating a WebDecoy account or connecting the optional cloud integration. Follow the current requirements on the WordPress.org listing when checking compatibility with your host.

2. Review traffic in monitor mode

A fresh install starts in monitor mode. Detection and logging are active, while enforcement is off. The settings page displays a banner explaining that nothing is being blocked.

Leave this mode on while you inspect your normal traffic. Visit important pages, submit a legitimate form, and check the login or checkout flows that matter to your site. Look at the detections alongside what you actually did; a score needs context.

An empty log is not evidence of a failed installation. A quiet site may have no matching requests yet. Use the controlled check below to verify that a request reaches the plugin and appears in the log.

3. Trigger your own canary and inspect the detection

Open WebDecoy → Detections. On our fresh installation, the empty state displayed a canary URL for that site. Use the exact address shown by your installation; every site has its own value.

For a command-line check, replace the example below with your own URL:

curl -i -A 'WebDecoy-Tutorial-Probe/1.0' \
  'https://your-site.example/__wd/YOUR_CANARY_VALUE'

Only run this against a site you own or are authorized to test. Return to Detections and inspect the recorded request.

In our local test, canary checks appeared with a score of 100 and a High label. With monitor mode enabled, the exact canary request finished with a WordPress 404 response and was logged. Detection did not mean the request had been blocked.

The counters in the video are test requests from one local Docker gateway. Multiple entries do not establish multiple bots or attackers. On a live site, compare timestamps, request details, and the relevant network or application logs before drawing conclusions about activity.

Detect AI crawlers on WordPress

AI crawler detection needs a request source that actually sees the crawler. Install the WordPress plugin to inspect requests that reach WordPress PHP. A browser analytics tag alone cannot observe a crawler that never executes JavaScript. Requests served entirely by a CDN or full-page cache need observation at that layer.

Start with the question you want to answer:

A user agent naming GPTBot, ClaudeBot or PerplexityBot is a declaration, not proof of the requesting organization’s identity. A crawler visit also does not prove your page was cited or that a person visited from an AI answer.

Choose how to handle AI crawlers

Open WebDecoy → Settings → Good Bots. Search engines, social preview bots, and AI crawlers have separate controls.

AI crawlers are allowed by default. Review Block AI crawlers before enabling it. In the current policy, recognized AI search crawlers such as OAI-SearchBot, Claude-SearchBot and PerplexityBot remain allowed; training crawlers and assistants fetching for a person are treated differently. Use the custom allowlist when you want a specific recognized agent to pass. Check the current plugin documentation for policy details.

Monitor mode records without enforcing. Turn enforcement on only after reviewing the policy and testing the crawlers and ordinary site flows you want to allow.

Verify detection with a labeled test

For this walkthrough, we sent a simulated request with a GPTBot user agent after selecting the AI blocking policy. It was recorded at 100 / Critical. That demonstrates recognition and policy scoring for the declared user agent. It does not prove the request originated from OpenAI: user-agent strings can be copied.

The simulated request returned 200 in our Docker environment because the plugin refused an automatic IP ban against its private gateway address. We verified the refusal reason: reserved, private, or loopback address. We did not change proxy trust or spoof a public visitor IP to manufacture a blocking result.

Keep AI crawling and referral traffic separate

Local protection works without a WebDecoy account. Connecting the optional cloud integration adds centralized reporting, including the visits with recognized AI referrers that the plugin reports. Visits without observable referral attribution remain unattributed.

For the reporting workflow, see WebDecoy’s AI traffic analytics. For a broader view of coverage, see which sensors can observe non-JavaScript crawlers.

Install the free WordPress plugin to inspect traffic on your own site, or open your WordPress installer.

5. Enable protection and repeat the test

After reviewing the traffic you expect to allow:

1. Open WebDecoy → Settings → Blocking.
2. Turn Monitor mode off.
3. Review the block action and your other settings.
4. Save Changes.
5. Repeat the exact canary request and test a normal page.

Our controlled test produced these results:

This verifies the canary detection and refusal flow in the tested installation. It is not a claim that every automated request will be detected or blocked. Check legitimate login, form submission, and checkout behavior after changing your own policy.

Check proxy and cache coverage

If your site runs behind a reverse proxy, use the plugin’s Client IP / Reverse Proxy settings for your actual infrastructure. Trust only your real proxy addresses or supported provider setup. A copied forwarding header is not reliable evidence of a visitor’s IP.

Also consider where the request is served. A page delivered entirely from an upstream cache may never execute WordPress PHP, so the WordPress plugin cannot inspect that request there. Test the routes you need to protect and use your edge logs to understand traffic that never reaches WordPress.

For a deeper explanation of the deception layer, see how WebDecoy uses hidden links and tripwires on WordPress.

Put bot detection on your own site

Install WebDecoy, inspect the first detections in wp-admin, and choose your protection and AI crawler settings. The useful outcome is a working installation on your site, with evidence you can review.

The plugin is open source: WordPress.org · GitHub.

Originally published for the v2.0 release; updated with a recorded installation and controlled tests of v2.10.5.

Protect other entry points: WordPress registration spam · WooCommerce card-testing checks.