Cloudflare: protect your domain from bots

Illustration: filtering automated abuse while keeping your website accessible.

Spam submissions and repeated login attempts waste time and server resources. A slow or unavailable website can also interrupt genuine customer enquiries. Cloudflare can provide a useful protective layer in front of your hosting, alongside application security and regular maintenance.

This guide reflects Cloudflare documentation checked on November 1, 2026. The rules below are starting examples to adapt to your website, not a promise to stop every bot.

Why Cloudflare matters for your domain

Cloudflare can manage your DNS and proxy website traffic through its network, enabling caching and security controls before requests reach your server. DNS-only records do not receive that proxy protection. Review the difference in Cloudflare’s domain onboarding guide.

Keep your hosting patched, maintain backups and protect administrator accounts too. A filtering service does not repair vulnerable application code.

Connect your domain without breaking the website

1. Add your domain to Cloudflare and select a plan. Check every imported DNS record, including the main domain, www, email and verification records. Preserve MX, SPF, DKIM and DMARC values; mail server hostnames generally stay DNS only.
2. Set supported website A, AAAA or CNAME records to Proxied. Verify your hosting provider supports this setup. Follow the onboarding checklist.
3. Replace the nameservers at your registrar with those assigned by Cloudflare. If DNSSEC is enabled, follow the migration procedure before switching, then re-enable it after activation. See the full DNS setup instructions.
4. Use Full (strict) TLS after confirming your origin supports HTTPS with an unexpired, hostname-matching certificate from a trusted authority or Cloudflare Origin CA. Confirm the visitor-facing certificate is active too. See Full (strict) requirements.

Test the website, email, contact forms and checkout after the change.

Choose the bot protection your plan supports

On Free, enable Bot Fight Mode under Security settings, filtering by Bot traffic. Test integrations immediately: it can challenge legitimate automated clients, and custom Skip rules cannot bypass it. If it breaks required traffic, disable it while assessing a suitable alternative. See Bot Fight Mode limitations.

Super Bot Fight Mode on eligible paid plans supports more granular exceptions. Enterprise Bot Management provides additional controls. Check bot plan availability before copying advice that uses a bot score field.

Set targeted anti-bot rules

In Security > Security rules > Create rule > Custom rules, give each rule a clear name, select its conditions and action, then review its position among existing rules. Cloudflare documents the custom-rule editor.

Rule 1: challenge visits to the login page

For a browser-based login at /login, combine these conditions with AND:

• URI Path equals /login.
• Request Method equals GET.
• Known Bots equals false, corresponding to not cf.client.bot.
• Action: Managed Challenge.

This example challenges matching visitors; it does not prove they are malicious. Replace /login with your actual path, such as /wp-login.php for WordPress, and include a trailing-slash variant if your application uses one. Restrict the rule to the relevant hostname if the zone contains several websites. The known-bot field identifies recognized good bots, not every legitimate automated client.

Rule 2: rate-limit repeated login requests

Create a separate rate limiting rule matching the real login path and excluding known bots. Count by source IP. Choose a supported time window and a threshold above your measured normal usage, then a short Block duration available on your plan. Begin with one endpoint and review the results before tightening it.

On Free, available matching fields are limited to Path and Verified Bot; method filtering requires a suitable higher plan. Shared office IPs can group several customers together. Rate limiting is also not an exact request cap. See availability and limitations and configuration parameters.

Rule 3: protect forms with Turnstile

Add Turnstile to contact or registration forms. Your backend must validate the token through Siteverify and reject invalid submissions before processing them. A visible widget alone is insufficient. Follow server-side validation.

Keep protection useful after setup

Check security events and test on mobile, including login, search crawlers, monitoring, payment callbacks and APIs. Browser challenges are unsuitable for many machine-to-machine requests. Narrow rules or use supported exceptions for verified integrations instead of trusting a User-Agent string or skipping all security checks.

Ask your host how to prevent direct access to the origin from bypassing Cloudflare, while preserving maintenance access. Cloudflare describes options in its origin protection guide.

Review rules when your website or integrations change. Effective bot protection should reduce abuse while letting customers complete the actions your business depends on.