Whitelist one trusted IP in Cloudways Bot Protection, and only after you've confirmed that Bot Protection, not Cloudflare or the origin server, returned the 403. Treat it as a narrow, temporary exception: add the address, test it, and remove it when the job is done.
That discipline matters because Cloudways documentation describes IP whitelisting for Bot Protection, separately covering specific IPs and bots. An exception for a monitoring service is also an exception for anyone who can send traffic from that address. Add the wrong range and you've switched off protection for every client behind it.
This guide walks through the order of operations: identify the blocking layer, add one IP as documented, verify the result, set a removal date, and recognize when an IP allowlist is the wrong tool entirely.
Short answer: whitelist one trusted IP, only after you confirm Bot Protection blocked it
Do these four things, in this order:
- Reproduce the 403 from the exact IP that is being blocked and capture the response body and headers.
- Decide which layer produced it: Bot Protection, Cloudflare, or the origin.
- If it was Bot Protection, add that single IP to the application's whitelist.
- Test, then schedule the entry's removal.
Skipping step 2 is the common mistake. A 403 is a status code, not a diagnosis. If you whitelist an IP in Bot Protection and the real cause was a file permission or a Cloudflare rule, nothing changes and you've still left a hole in your bot defenses.
The exception is also the last step, not the first. If a legitimate monitor, webhook sender, partner or crawler is blocked, ask whether you can fix the client first (a correct user agent, a lower request rate, a stable egress IP). The whitelist is for the case where the client is genuinely trusted and genuinely can't change.
Which layer returned your 403? Bot Protection, Cloudflare or the origin
Three different layers can return a 403 on a Cloudways-hosted application, and each has a different fix. Cloudways' own 403 Forbidden troubleshooting article covers the origin-side causes. Start there if the block doesn't look bot-related.
Use the response itself to separate them:
| Layer | What to look for | Where the fix lives |
|---|---|---|
| Cloudways Bot Protection | Block happens at the application edge of the Cloudways stack; the client is an automated source such as a monitor, script or crawler; the request succeeds from a browser on a different IP | Application > Security > Bot Protection whitelist |
| Cloudflare (if you use it in front) | Response carries Cloudflare headers such as server: cloudflare and a cf-ray value, or shows a Cloudflare error page | Cloudflare dashboard rules, not Cloudways |
| Origin or server permissions | Generic web-server 403 page; same result from every IP; often tied to file or directory permissions, ownership, or an application rule | File permissions, .htaccess, application or plugin config |
Three quick tests narrow it down:
- Same URL from a second IP. If it loads from your laptop but fails from the monitor's IP, the block is IP- or behavior-specific, which points at Bot Protection or a firewall. If it fails from everywhere, suspect the origin.
- Inspect headers. Run
curl -sI https://your-site.example/pathfrom the blocked machine. Cloudflare headers tell you the request never reached Cloudways. - Temporarily disable Bot Protection on a staging copy or at a quiet time. If the 403 disappears, Bot Protection was the layer. Re-enable it immediately. Don't leave it off.
Only when the evidence points at Bot Protection do you move to the whitelist.
How to add a Cloudways Bot Protection IP exception (as documented)
Cloudways documents the process in two articles: how to protect your applications with Bot Protection and how to whitelist IPs to bypass Bot Protection. The documented flow is:
- Select the application you want to configure.
- Make sure Bot Protection is enabled for that application.
- Open the Security tab.
- Choose Whitelist IP.
- Enter the IP address and save.
Two points deserve emphasis.
The exception is per application. You select an application first, so the allowance applies to that app's Bot Protection, not to your whole server. If a partner only needs to reach one webhook endpoint on one app, add the IP there and nowhere else.
Check the current UI and your plan before you rely on this. Menu labels and plan availability change. Confirm against the two articles above at the time you make the change, and enter the address in the format the form accepts. Don't assume range or CIDR notation is supported unless the current documentation says so. When in doubt, add individual addresses.
Why narrow beats broad: shared proxies, CDN ranges and spoofed identity
Cloudways documents whitelisting for specific IPs and bots under Bot Protection. Read that literally: once an address is on the list, requests from it skip the checks. The size of the exception is the size of the audience that can send traffic from that address.
That's why broad entries are dangerous:
- Shared proxy and VPN egress addresses. One corporate proxy or consumer VPN exit can carry thousands of unrelated users. Whitelist it and you've exempted all of them, including any scraper using the same service.
- CDN and cloud ranges. Allowing a CDN's addresses exempts every customer of that CDN who can make an outbound request through it. An attacker can rent capacity in the same range.
- Cloud function and hosting IPs. Serverless platforms hand out addresses that rotate between tenants. Today's trusted webhook sender may be tomorrow's scraper on the same address.
- Identity claimed in a header. A user agent that says it's a trusted crawler proves nothing on its own. IP is a stronger signal than a header, but only when the IP is genuinely controlled by the party you trust.
The safe pattern is one address that belongs to a party you can name, with a stated reason and an owner. If you can't say who controls the address, don't allow it.
If the address sits behind a load balancer or reverse proxy, also confirm which IP your stack actually sees. Our Nginx bot protection guide explains trusted proxy headers and real-IP handling. The same logic applies when you decide which address to enter.
Test the exception, then set a review and removal date
After saving, prove the change did what you intended and nothing more.
Test the positive case. From the whitelisted IP, repeat the exact request that failed. Confirm you now get the expected status and content, not just a different error.
Test the negative case. From an IP that isn't whitelisted, repeat a request that Bot Protection should still challenge. If it now passes, something broader than you intended was allowed.
Record the entry. Write down the IP, the application, who requested it, why, and the date. A whitelist entry with no owner becomes permanent by neglect.
Set a removal date. Pick a short window: a week for a migration test, a quarter for a standing monitor. Put the review in a calendar or ticket, not in someone's memory. At review, ask whether the client still needs the exception, whether its IP is still stable, and whether a better fix now exists. Then remove the entry through the same Security tab and re-run the negative test.
A temporary exception that lasts three years is a permanent hole you forgot about.
Controls that are not this one: server firewall, SFTP/SSH, Cloudflare WAF and WordPress plugins
Several controls sound similar and live in different places. Editing the wrong one wastes time and can weaken the wrong layer.
- Server firewall and SFTP/SSH allowlists. Cloudways manages access to the server itself (SSH, SFTP) separately. Allowing an IP there doesn't change how Bot Protection treats web requests, and a Bot Protection whitelist doesn't grant shell or file access.
- Cloudflare WAF and rules. If Cloudflare sits in front of your site, its firewall, rate limiting and bot settings act before traffic reaches Cloudways. A block from Cloudflare must be fixed in Cloudflare.
- WordPress security plugins. Plugins enforce their own IP rules, rate limits and login protection inside the application. A plugin 403 won't be cleared from the Cloudways panel. For login, XML-RPC and REST hardening, see our WordPress bot protection guide rather than loosening Bot Protection to compensate.
The diagnostic table earlier exists for this reason. Identify the layer first, then change only that layer.
When an IP allowlist is not enough: crawlers that spoof identity and bots on an existing CDN
An IP exception answers one question: is this specific address trusted? It can't answer harder ones. What about a crawler that claims a well-known identity but comes from somewhere else? What about scrapers that rotate through residential addresses, so no single IP is worth allowing or blocking?
In those cases an allowlist either blocks real clients or lets impostors through. Published research shows how wide the gap can be: on a typical news site, 84% of requests claiming to be GPTBot were fake, according to Centinel Analytica's own fake-crawler research. A rule that trusts the name rather than verifying the source would have admitted most of that traffic.
Centinel Analytica is bot and AI crawler protection that tells real visitors from scrapers that look like them, then applies allow, challenge or block policy through your existing CDN or edge. If your problem has moved from one blocked partner to scrapers that imitate real traffic, that's the layer to evaluate. The bot false positive testing guide is a useful companion for checking that legitimate visitors still get through before you tighten any policy.
Keep the exception small, and audit what the allowlist cannot see
A Bot Protection whitelist entry is a deliberate hole, so make it the smallest one that solves a proven problem: one trusted IP, on one application, tested, owned and scheduled for removal. If you find yourself maintaining a growing list of exceptions because scrapers keep imitating legitimate traffic, the allowlist isn't the fix.
Frequently asked questions
Does the Cloudways Bot Protection whitelist bypass all security checks?
Cloudways documents that whitelisted IPs bypass Bot Protection rules for the application you configure. It does not replace your server firewall, SFTP/SSH access controls, Cloudflare settings or WordPress plugin rules, which are separate layers. Keep entries to single trusted addresses and remove them when no longer needed.
How do I know if Cloudways Bot Protection caused my 403?
Test the same URL from a second IP and inspect headers with curl. If it loads elsewhere but fails from the blocked IP, and there are no Cloudflare headers, Bot Protection is a likely cause. A 403 from every IP points to origin permissions, and Cloudflare headers point to Cloudflare.
Should I whitelist a CDN or proxy IP range in Cloudways?
Avoid it. Because whitelisted IPs bypass bot-protection rules, a shared proxy or CDN range exempts every user and tenant behind those addresses, including scrapers. Do not assume range syntax is supported unless current Cloudways documentation says so. Add one address you can attribute to a named, trusted party.
How long should a Bot Protection IP exception stay in place?
Set a removal date when you add it: days for a one-off test, a quarter for a standing monitor. Record who requested it and why, then review on schedule. After removing it, confirm the client is challenged again. Unowned entries tend to become permanent, which quietly weakens protection.
What if scrapers spoof a trusted crawler identity instead of coming from one IP?
An IP allowlist cannot verify identity that attackers imitate. Centinel Analytica tells real visitors from scrapers and applies allow, challenge or block policy through your existing CDN or edge. Its research found 84% of requests claiming to be GPTBot on a typical news site were fake.