Cloudflare Is Enabled. Why Are Bots Still Reaching My Site?

Cloudflare is enabled, but your site still receives automated visits. Some fetch articles. Some explore endpoints. Others arrive in a browser and interact with forms.

WebDecoy works alongside Cloudflare to help you investigate the bots that reach your site. Keep your existing protection. Add evidence about what arrived, which detection signals fired, what the visitor touched, and how AI crawler activity compares with the visitors AI platforms send back.

We build WebDecoy. This guide explains that combined workflow, using our own recorded traffic to demonstrate the analytics.

Why bots can still reach a protected site

A protected site still needs to accept requests. Search crawlers, useful agents and customer integrations may be welcome. An unwanted client may also stay below a rate limit or avoid the particular rule configured for an endpoint.

Cloudflare’s own bot mitigation guide discusses malicious traffic getting through and combining signals when bots evade individual rules. Check the protection actually enabled on your zone and the action taken for the relevant request.

Cloudflare also has Bot Analytics. The available investigation features depend on the product and plan. Start with that existing evidence, then use WebDecoy to inspect additional observations from your site.

The question to answer is specific: what did this automated visitor do after it was allowed to reach this route?

Look beyond a traffic spike

A spike without sales does not establish an attack. A cloud IP does not establish malicious intent. A browser executing JavaScript does not establish a human operator.

Use evidence tied to an action:

Coverage depends on your integration. A browser script sees activity when it executes. An application integration sees requests that reach that application. An edge sensor observes traffic on its configured routes. Requests stopped before a sensor runs will not appear in that sensor’s records.

Our cache-coverage guide explains why an edge request and a WordPress log can disagree. This article focuses on investigating the activity you do observe.

A real example: crawling versus visitors returned

In a seven-day dashboard window captured on October 21, 2026, WebDecoy recorded the following activity for our own webdecoy.com property:

These figures count activity in that recorded window, rather than unique pages or today’s traffic. The seven observed referrals came from ChatGPT (2), Gemini (2), Kagi (2) and Claude (1).

Watch the actual dashboard demonstration. For another window with a persistent, inspectable artifact, open our frozen public report and its methodology. That older report has different dates and totals.

This is the extra visibility we want site owners to have: which operators fetched content, which pages they requested, and which observable visits came back. Crawl counts alone cannot answer all three questions.

This example demonstrates reporting on one WebDecoy-owned site. It does not measure Cloudflare’s detection accuracy, prove these crawlers bypassed an enabled blocking rule, or classify every crawl as abuse. Missing referral information also means we cannot identify every AI-origin visit or infer that a page was cited.

Add WebDecoy to your Cloudflare setup

Choose a public route you own and start with observation:

1. Add your site to WebDecoy. Use the property that corresponds to the hostname you want to inspect.
2. Connect Cloudflare and deploy the edge sensor. Follow the current installation guide. Check the proxied hostname, route scope, existing Worker compatibility and applicable Worker usage costs.
3. Verify reporting. Follow the guide’s reserved test-request procedure and confirm that a labeled test appears. That verifies collection on the tested route; it is separate from a real bot finding.
4. Inspect actual activity. Review detections and available actor evidence. Open AI Traffic to examine crawler activity and observed referrals. Add browser or application observation where you need that context.
5. Choose a response from the evidence. Review the scope and likely effect before enabling supported enforcement. Keep your existing Cloudflare controls in place.

For a suspected bot that got through, match the hostname, UTC time, method and path against Cloudflare’s available records. Check the action and relevant policy there. A new WebDecoy event by itself cannot establish which Cloudflare decision preceded it.

Keep Cloudflare. See what reaches your site.

WebDecoy adds a place to investigate detection signals, decoy interactions and AI traffic alongside the protection you already use. Start with a reporting installation, inspect your own activity, and use that evidence to decide what deserves a response.

Add WebDecoy to your Cloudflare setup or create your WebDecoy account.