HostGator's Hidden Cloudflare Silently Blocks Googlebot on Your WordPress Site

HostGator and other Endurance-brand shared hosts silently run their own Cloudflare instance in front of your origin server. When you add your own Cloudflare on top, you end up with two stacked Cloudflares. The upstream one, on infrastructure you don’t own, issues Managed Challenges to Googlebot — and no WAF rule, no Pause Cloudflare, no zone recreation on your side can fix it. This article shows the 5-step diagnostic that reveals the hidden layer and the exact ticket script to get your host to disable it.

Your Google Search Console starts reporting 403 errors on your WordPress site. You open Cloudflare. Your Skip Verified Bots WAF rule looks textbook perfect. Its hit counter reads zero. Your Bot Fight Mode is off. Your Security Events log is empty of anything relevant. You Pause Cloudflare on Site and the 403 persists. You delete your entire Cloudflare account, re-add the zone from scratch, and the 403 still persists. Every other domain on your account works perfectly — only this one is broken.

If any of that sounds familiar, you have almost certainly been bitten by a specific class of hosting problem that most site owners never hear about: a second Cloudflare instance you don’t own, sitting between your Cloudflare and your origin. It’s installed by your host as part of their shared-hosting stack. It runs on infrastructure you can’t configure. And its default protection profile treats Googlebot the same as any other automation.

The article below is what a full afternoon of debugging on a real production site produced. If your host is HostGator, Bluehost, iPage, HostMonster, FatCow, or Domain.com — all part of the Endurance International Group family — the diagnostic and fix here are aimed directly at you.

Why Every Documented Fix Does Nothing

If you’ve been in Cloudflare’s docs, community forums, or Reddit threads, you’ve almost certainly worked through the standard checklist for Googlebot 403s. Here’s what typically gets recommended, and why every single one of these leaves you exactly where you started when the problem is a stacked Cloudflare upstream:

• Add a WAF Custom Rule with expression (cf.client.bot) and action Skip all remaining rules. This is the accepted playbook for CF-initiated Googlebot challenges. On a stacked-CF site the rule shows zero hits, forever, because your host’s Cloudflare 403s the request before it ever reaches your zone’s WAF pipeline.
• Turn off Bot Fight Mode. Doesn’t matter. The challenge isn’t coming from your Bot Fight Mode — you don’t have any features toggled on your side that would produce it.
• Turn off Managed robots.txt in AI Audit. No effect. The upstream Cloudflare is doing its own thing.
• Set Security Level to Essentially Off. Only applies to your zone.
• Turn off JS Detections. Only applies to your zone.
• Pause Cloudflare on Site. Removes your Cloudflare from the request path. The upstream one is still there. The 403 remains.
• Delete your Cloudflare account and re-add the zone. Same DNS, same request path, same result.
• Grey-cloud your DNS records. Traffic now goes to what looks like your origin IP, but that IP resolves to a Cloudflare Anycast address you don’t control. Still 403.

Every single one of these fixes assumes that the Cloudflare in your dashboard is the only Cloudflare in the request path. On many shared-hosting plans, that assumption is wrong.

The Hidden Architecture

Under Cloudflare’s Cloudflare for Platforms product (also called SaaS Custom Hostnames or Cloudflare for SaaS), hosting companies can wrap their entire shared-hosting infrastructure in a Cloudflare instance. For the host, it’s attractive: free SSL certificates on every customer domain, edge DDoS protection, and a global CDN thrown in as part of the shared-hosting product without them having to build any of it.

For the customer, it’s invisible — unless something breaks. There is no toggle in cPanel to disable it. It doesn’t appear in any customer-facing dashboard. It doesn’t appear in Cloudflare’s own docs from your perspective, because it’s not your Cloudflare.

When you then set up your own Cloudflare zone on top — which almost every WordPress user does, because Cloudflare is the standard free CDN/SSL choice — here’s the actual request path:

Client (browser or Googlebot)
   |
   v
Your Cloudflare zone   (Anycast 104.21.x.x / 172.67.x.x)
   |  Your WAF rules run here. Your Skip rule works fine
   |  for anything that reaches this layer.
   v
Your host's Cloudflare partner instance   (Anycast 66.235.200.x)
   |  Managed Challenges get issued here.
   |  You have no dashboard access to this layer.
   |  Googlebot is challenged and returned a 403.
   v
Actual origin server   (Endurance shared-hosting node)
   |  Rarely reached by bots.
   v

The upstream Cloudflare instance sits on Cloudflare-owned IP ranges (AS 13335) that are not in the public Cloudflare shared-Anycast IP list. Specifically 66.235.200.0/24 at the time of writing. These ranges are announced by Cloudflare but assigned to hosting-partner customers rather than to the standard Cloudflare-for-websites product tier you signed up for.

One thing that trips up debugging: reverse-DNS on the partner-Anycast IPs often points at a host-owned hostname. As an example, 66.235.200.170 reverse-resolves to rs70.securehostserver.com. That’s a HostGator-owned domain, which makes the IP look like it belongs to your host’s datacenter. It doesn’t. An ASN lookup returns AS13335 / CLOUDFLARENET — the IP is Cloudflare Anycast at the network layer, even though the reverse DNS is misleading. When you’re confirming stacked Cloudflare, trust the ASN, not the reverse DNS.

Bot-shaped requests to the upstream layer get a Managed Challenge. Browser-shaped requests with realistic Accept and User-Agent headers often pass through. That’s why real users report the site works fine, while Google Search Console reports the site as inaccessible.

The 5-Step Diagnostic That Finds the Hidden Layer

Before you contact your host or make any changes, run this sequence. If all five signals match, you have a stacked-Cloudflare problem and no amount of tweaking your own zone will fix it. Total time: about three minutes plus DNS propagation.

Step 1: Baseline the current resolution

nslookup yourdomain.com 8.8.8.8

Expected result while your Cloudflare is active: an IP in the 104.21.x.x or 172.67.x.x range. That’s your own Cloudflare zone’s Anycast IP. Note it down for comparison.

Step 2: Pause Cloudflare on Site

In your Cloudflare dashboard, go to the zone Overview page. Scroll to the bottom-right column and click Pause Cloudflare on Site. This is a reversible operation that removes your Cloudflare proxy for three hours. Wait 60 to 120 seconds for DNS propagation.

Step 3: Re-resolve and identify the IP’s ASN

nslookup yourdomain.com 8.8.8.8
# Then look up the ASN owner of that IP:
curl -s "https://api.hackertarget.com/aslookup/?q=<the-ip-you-got>"

This is the moment of truth. Read the ASN, not the reverse DNS. There are two possible outcomes:

• If the ASN is AS13335 / CLOUDFLARENET — you have a stacked Cloudflare upstream. That IP is Cloudflare Anycast at the network layer, being run through your host’s partner integration with Cloudflare. Even if reverse-DNS points at a hostname like rs70.securehostserver.com, don’t be fooled — the ASN is authoritative.
• If the ASN is your host’s own (for Endurance brands like HostGator or Bluehost, this is AS46606 / UNIFIEDLAYER-AS-1 on ranges like 66.147.x.x or 108.167.x.x; other hosts vary) — you don’t have this specific problem. Your 403 is coming from somewhere else.

Step 4: Curl as Googlebot to the paused site

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
     https://yourdomain.com/

Read the response headers. If you see all of these together, stacked Cloudflare is confirmed:

• HTTP/1.1 403 Forbidden
• Server: cloudflare
• Cf-Mitigated: challenge
• CF-RAY: <some-ray-id>
• x-endurance-cache-level: 2 or similar origin-header fingerprint

The critical detail: your own Cloudflare is paused, but the response is still from Cloudflare. That’s only possible if a second Cloudflare exists in the path.

Step 5: Curl as a realistic browser

curl -sI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/131.0.0.0 Safari/537.36" \
     -H "Accept: text/html,application/xhtml+xml" \
     -H "Accept-Language: en-US,en;q=0.9" \
     https://yourdomain.com/

On a stacked-Cloudflare site, this often returns HTTP/1.1 200 OK — the upstream Cloudflare passes browser-shaped requests but challenges bot-shaped ones. That asymmetry is the final confirmation: same URL, same paused zone, one UA passes and the other 403s. The differentiator isn’t your Cloudflare. It’s the layer above it.

The Fix: Get Your Host to Disable Their Cloudflare

Because the offending layer isn’t yours, the fix isn’t in your dashboard. It’s a support ticket at your host. Expect Level 1 support to deny the issue exists — the pattern is real and repeated across multiple hosts. Insist on Level 2 escalation. Attach the curl evidence from Step 4 of the diagnostic. That evidence is what makes L2 acknowledge the layer.

Support Ticket Script

Copy, adapt with your details, and send:

Subject: Cloudflare-partner layer blocking Googlebot on my domain

Hi,

You have a Cloudflare partner instance (Cloudflare for SaaS)
in front of my origin for <yourdomain.com>. It is issuing
Managed Challenges to Googlebot, which is blocking Google
from indexing my site.

Proof: even with my own Cloudflare paused via
"Pause Cloudflare on Site", curl -A "Googlebot"
https://<yourdomain.com>/ returns HTTP 403 with the
following headers:

  Server: cloudflare
  Cf-Mitigated: challenge
  CF-RAY: <ray-id-here>

That combination proves the challenge is coming from a
Cloudflare instance upstream of my own zone. That is
your Cloudflare partner layer, not mine.

Please either:

  (1) Disable the Cloudflare-partner integration for this
      hostname, so my own Cloudflare zone is the only proxy
      in the path, or
  (2) Whitelist verified search bots (Googlebot, Bingbot,
      DuckDuckBot, YandexBot, Applebot) at your
      Cloudflare-partner layer.

This is causing measurable SEO indexing loss. Please
escalate to a technician who is familiar with the
Cloudflare-for-Platforms integration.

Thanks,
<your name>

Alternative Fixes

If your host refuses or drags their feet, you have two remaining options:

• Drop your own Cloudflare and use only the host’s. Point your nameservers back at your host. You lose control over WAF rules, cache purge, and page rules — but you eliminate the stacked-CF problem because there’s only one layer. Not ideal, but functional.
• Migrate to a host without stacked Cloudflare. Managed WordPress hosts like Kinsta, Rocket, WP Engine, Cloudways, GridPane, and RunCloud all provide clean-origin architectures where your Cloudflare is the only Cloudflare in the path. This is the long-term fix for any site where SEO indexing is critical to revenue.

Which Hosts Have This Pattern

The stacked-Cloudflare pattern is common across Endurance International Group brands. If your host is one of these, run the 5-step diagnostic before assuming your own Cloudflare configuration is at fault:

• HostGator — confirmed 2026
• Bluehost — same infrastructure family, same pattern reported repeatedly
• iPage — Endurance brand
• HostMonster — Endurance brand
• FatCow — Endurance brand
• Domain.com hosting — Endurance-related

Non-Endurance shared hosts sometimes ship similar setups on specific plan tiers. If you’re seeing the exact fingerprint from Step 4 of the diagnostic (paused Cloudflare + still receiving Server: cloudflare responses), the diagnosis is the same regardless of what host label is on your invoice.

Managed WordPress hosts and VPS providers generally don’t use this pattern. Confirmed clean-origin as of the time of writing: Kinsta, Rocket, WP Engine, Cloudways, GridPane, RunCloud, ServerPilot. Your own Cloudflare, if you add one, is the only Cloudflare in the path.

Why This Class of Bug Is Uniquely Painful

Debugging Cloudflare bot issues normally follows a well-worn playbook. The stacked-Cloudflare pattern defeats every step of that playbook by design, because it operates on infrastructure you have no visibility into. Specifically:

• It’s silent to humans. Real browsers pass through, so no user ever reports a bug. The only signal is Google Search Console coverage reports weeks later, by which point rankings have already dropped.
• It’s invisible to your WAF logs. Your Cloudflare never sees the challenged traffic because it’s already been intercepted upstream. Every log you have access to reports zero relevant events.
• It’s immune to every documented Cloudflare fix. Skip rules, disable Bot Fight Mode, disable Managed Rules, disable Managed robots.txt, disable JS Detections, disable Under Attack Mode, set Security Level to Off — none of it matters, because your zone isn’t the layer doing the challenging.
• It’s immune to Pause Cloudflare on Site. Which is one of the most defensible "prove Cloudflare is the problem" tests you have. Yet the challenge continues.
• It’s immune to zone recreation. Fresh Cloudflare zone, same problem. Delete the account entirely and start over — same problem. The root cause is upstream of anything you can control.
• It requires cross-vendor coordination to fix. Your host has to change something on their Cloudflare, which most L1 support doesn’t know exists. The fix hinges on getting to L2 with the right evidence.

The fingerprint is specific enough that once you know what to look for, the diagnostic takes minutes. Without that knowledge, it easily eats an afternoon or an entire day. Baking the pattern into your team’s troubleshooting checklist is worth doing before you’re in the middle of an incident.

What to Do Right Now

1. Run the 5-step diagnostic above. Confirm or rule out stacked Cloudflare in under 5 minutes.
2. If confirmed: open a support ticket at your host using the script above. Ask for L2 escalation. Attach the curl output showing CF-RAY with Pause Cloudflare active. Expect 6 to 8 hours propagation after the fix is applied.
3. Un-Pause Cloudflare on Site immediately after diagnosis. Running production on Pause is only for the diagnostic window.
4. Watch Google Search Console. Once the fix propagates, request re-crawling via URL Inspection → Test Live URL → Request Indexing on your key pages. Coverage should recover within a few days.
5. Add the diagnostic to your team runbook. Next time this happens on a client site — and if you work with WordPress sites on shared hosting, there will be a next time — you want the 5-step check ready to run without re-deriving it.

If SEO health monitoring is part of your workflow, SEObolt surfaces search-visibility drops on WordPress dashboards before they become weeks-old problems — useful for catching this specific class of issue early, since the earliest symptoms often show up in impression counts before they show up in coverage reports. For related Cloudflare-blocks-legitimate-traffic patterns, see also Cloudflare’s Block AI Bots Silently Breaks MCP Connections, which covers the same class of problem for MCP servers.