If your site works for you but not visitors, you’re dealing with one of the most frustrating WordPress problems: everything looks perfect from your seat, yet real humans (customers, readers, clients) see errors, endless loading, blank pages, login loops, or a completely different version of the site.

The reason this happens so often is simple: modern websites aren’t “one server, one page.” They’re a stack of layers—CDN edge caching, browser caching, server caching, WAF rules, bot protection, geo restrictions, ISP quirks, DNS propagation, and even cookie-based “special treatment” for you as an admin. One tiny mismatch can make the site appear healthy for you while failing for everyone else.

This guide walks you through the most common CDN/cache/geo/WAF “gotchas,” how to prove which layer is at fault, and how to fix it without guesswork.

If you’d rather skip the detective work, jump to emergency WordPress support or browse the complete range of WordPress services.

The “Works for Me” Website Problem: What It Usually Means

When site works for you but not visitors, it’s rarely random. It’s usually one of these patterns:

  1. You’re seeing an uncached “origin” version (because you’re logged in, whitelisted, or bypassing cache), while visitors see a cached/broken version.
  2. Visitors are being blocked (GeoIP rule, WAF rule, bot protection, rate limiting, firewall, or hosting security layer).
  3. Visitors are routed differently (CDN edge node issues, DNS differences, IPv6 vs IPv4, split tunneling, or ISP-level weirdness).
  4. Only some pages fail (checkout, login, account, contact forms)—often due to caching rules that should never apply to dynamic or personalized pages.

Your job is to identify which layer is lying to you.

Step 1: Confirm It’s Real (and Not Just One Person)

Before you change anything, confirm the symptom from multiple places:

  • Test on mobile data (turn Wi-Fi off).
  • Test from a different browser you don’t normally use.
  • Test using a private/incognito window.
  • Ask a friend in another city/country to test.
  • Use an external checker (basic ones are fine, but don’t stop there).

Why: you might be “special” because:

  • You’re logged into WordPress (cookies).
  • You’re in the hosting provider’s safe list.
  • Your IP is allowlisted in a WAF rule.
  • Your browser has a clean cached version.

Step 2: Identify the Failure Mode (This Tells You Where to Look)

When site works for you but not visitors, the exact visitor experience is a clue. Common failure modes:

A) 403 Forbidden (Often WAF/Geo/Origin Permissions)

  • Geo-blocking rules
  • WAF custom rules
  • Hotlink protection / firewall
  • Origin server denies requests from CDN IPs
  • CloudFront/edge permission issues (see AWS guidance on 403 causes) (AWS Documentation)

B) 503 Service Unavailable (Often Origin Overload or Edge Error-Caching)

  • Origin server is overloaded/down
  • CDN is caching the error response
  • Health checks failing
  • CloudFront notes 503 is typically origin performance-related, sometimes edge constraints (AWS Documentation)

C) Infinite Redirect / Too Many Redirects

  • HTTP→HTTPS loops
  • Mixed rules between WordPress, CDN, and host
  • Incorrect “Flexible SSL” type setups (common with CDNs)

D) Visitors See Old Content / Broken Layout

  • Stale CDN cache
  • Browser cache holding old CSS/JS
  • Minification conflicts cached at the edge
  • Wrong cache key (cookies/query strings not handled)

E) Only Logged-Out Users Have the Problem (Classic Caching Misfire)

  • You’re logged in, so you bypass cache and see the correct site
  • Visitors get cached HTML that includes something broken, or is missing something required

Step 3: Understand the 3 Cache Layers That Commonly Trick You

Most “site works for you but not visitors” issues are cache-layer disagreements.

1) Browser Cache (Visitor-side)

A visitor might be holding:

  • old CSS/JS files
  • cached redirects
  • cached HTML in some cases (service workers can do this too)

Fix: hard refresh, clear cache, or bump asset versions. But if many visitors complain at once, it’s usually not just browser cache.

2) WordPress/Server Cache (Origin-side)

This includes:

  • full-page caching plugins
  • host-level caching (NGINX FastCGI, LiteSpeed, Varnish)
  • object cache (Redis/Memcached—usually not the direct cause of “only visitors fail,” but can contribute)

If your cache plugin is configured wrong, it might:

  • cache pages that should be dynamic
  • cache pages with personalized output
  • serve the wrong cached variant

WordPress discussions regularly warn against caching logged-in experiences because it can leak or mix personalized content (WordPress.org).

3) CDN/Edge Cache (The Biggest Culprit)

CDNs (Cloudflare, CloudFront, Fastly, etc.) can:

  • cache HTML pages aggressively
  • cache error responses (yes, really)
  • cache redirects
  • ignore important cookies or headers unless configured

With CloudFront, error caching is explicitly configurable—and if it’s set to cache errors for minutes, visitors may keep seeing failures after you’ve already “fixed” the origin (AWS Documentation).

The Most Common CDN “Gotchas” (and How to Fix Them)

Gotcha #1: “Cache Everything” Rules (Especially for WordPress)

A “Cache Everything” rule can be catastrophic if it applies to:

  • /wp-admin/
  • /wp-login.php
  • WooCommerce cart/checkout/account
  • membership pages
  • pages with nonce tokens

Cloudflare community threads frequently warn that caching “everything” breaks logged-in behavior and dynamic pages (Cloudflare Community).

Fix approach (safe default):

  • Cache HTML only for logged-out users.
  • Bypass cache on:
    • /wp-admin/*
    • /wp-login.php
    • /cart/, /checkout/, /my-account/ (WooCommerce)
    • any membership/account/dashboard paths
  • Respect cookies like wordpress_logged_in_ and woocommerce_items_in_cart.

If you’re unsure, simplify: temporarily disable the “Cache Everything” rule and purge.

Gotcha #2: CDN Caches an Error (503/520/522) and Keeps Serving It

You fixed the server, but visitors still see the error.

This happens when:

  • CDN cached the error response
  • browser cached an error page
  • edge node had a temporary problem

CloudFront documents how 503 responses can appear due to origin issues, and troubleshooting focuses on origin health/performance (AWS Documentation).

Fix:

  • Purge CDN cache (and any “cache by status code” settings).
  • Lower or disable error caching TTL while debugging.
  • Confirm origin is healthy directly (bypass CDN if possible).

Gotcha #3: Wrong Cache Key (Cookies / Query Strings / Headers Not Considered)

Your CDN might treat two different experiences as the same cached page.

Examples:

  • Cookie determines currency/language, but CDN ignores it
  • Logged-in cookie isn’t respected and the edge caches personalized HTML
  • Query strings are ignored, but your theme uses them for variation

Fix:

  • Ensure your CDN cache rules include the correct cache key logic.
  • Bypass cache for logged-in users.
  • Add clear cache-control headers where needed.

Gotcha #4: “It Works on My IP” Because You’re Allowlisted

Many site owners unknowingly allowlist:

  • their office IP
  • their VPN IP
  • their own country/ASN
  • Googlebot (and accidentally themselves)

So the WAF blocks everyone else.

Geo Blocking & WAF Rules: The Silent Visitor-Killers

If site works for you but not visitors and the complaints cluster by country/region, suspect GeoIP or WAF.

Cloudflare’s docs show common ways to block/allow by geography using custom rules (country, continent, ASN, region) (Cloudflare Docs).

Symptoms that scream “Geo/WAF”

  • Visitors in certain countries can’t load the site
  • Traffic drops suddenly from a region
  • People see 403 pages or CAPTCHA loops
  • API calls (REST/AJAX) fail but homepage loads

Common Geo/WAF mistakes

  1. Blocking entire continents “to stop spam”
  2. Blocking data centers/ASNs that include legitimate mobile carriers or corporate networks
  3. “Bot Fight Mode” / aggressive bot settings that block real users
  4. WAF rule matches a URL pattern too broadly (e.g., blocks /wp-json/ or admin-ajax.php)

How to fix Geo/WAF issues quickly

  • Temporarily put WAF in “log” mode (not block) for the suspicious rule.
  • Check WAF event logs for blocked requests.
  • Whitelist known-good traffic if needed—but don’t overdo it.
  • Narrow the rule to actual bad paths (e.g., block XML-RPC brute force, not your whole site).

WordPress-Specific Cache Traps (Why You See “Normal”)

Trap #1: You’re Logged In, So You Bypass Cache Automatically

Many setups don’t cache for logged-in users (for good reason). WordPress community guidance frequently repeats that caching logged-in pages can cause content mixing or privacy issues (WordPress.org).

So you see a fresh page every time… while visitors see a cached mess.

How to test: open an incognito window. If the incognito view matches visitors’ complaints, it’s cache.

Trap #2: Admin Toolbar / Nonces / Personalized Blocks

Some themes or plugins embed:

  • nonces
  • personalized greetings
  • A/B testing scripts
  • location-based banners

If cached at the edge, visitors might receive broken tokens or mismatched scripts.

Fix: exclude those pages/blocks from page cache, or refactor them to load via AJAX with appropriate caching rules.

Trap #3: WooCommerce & Membership Pages Cached Like Blog Pages

WooCommerce pages must be handled carefully:

  • Cart/checkout must not be served from stale HTML cache.
  • “Fragments” and dynamic endpoints must be reachable (WAF can break them).

If you’re dealing with speed improvements too, consider a dedicated performance pass like WordPress speed and performance—but only after the caching rules are correct.

A Practical Debug Checklist (Use This in Order)

When site works for you but not visitors, do this sequence to avoid thrashing:

1) Reproduce as a visitor

  • Incognito window
  • Different device
  • Mobile data
  • Different network

2) Identify whether the CDN is involved

Look for signs like:

  • response headers (e.g., cf-cache-status, age, x-cache)
  • “Server” headers that indicate a proxy

3) Purge all caches (in the right order)

Do it like this:

  1. Purge WordPress cache plugin cache
  2. Purge host/server cache
  3. Purge CDN cache
  4. Ask a visitor to hard refresh (or test via fresh device)

4) Temporarily bypass the CDN

  • Point hosts file (advanced) or use an origin URL if available
  • If origin works and CDN doesn’t: your problem is CDN/WAF/caching rules
  • If origin also fails: it’s the server/app

5) Inspect WAF / firewall logs

  • Find blocks by country, ASN, user-agent, path, query string
  • Confirm whether the visitor requests are being challenged or blocked

6) Check DNS differences

  • Are some users hitting old IPs?
  • Are AAAA (IPv6) records present and correct?
  • Did you recently migrate?

CDN + WordPress: Safer Default Rules (Most Sites Should Start Here)

If you want the “boring but reliable” baseline:

  • Cache static assets aggressively:
    • images, CSS, JS, fonts (long TTLs)
  • Cache HTML only for logged-out users
  • Never cache:
    • /wp-admin/*
    • /wp-login.php
    • any checkout/cart/account paths
    • pages that set sensitive cookies
  • Don’t block by geography unless you have a business reason
  • Prefer “log” over “block” when deploying new WAF rules

Cloudflare’s geo-rule examples show how easy it is to block entire regions accidentally—so implement with care (Cloudflare Docs).

Real-World Scenarios (and What Usually Fixes Them)

Scenario 1: “Visitors see the old site, I see the new one”

Usually: stale CDN cache or browser cache
Fix: purge CDN + set proper cache headers + ensure assets are versioned.

Scenario 2: “Visitors get 403, I’m fine”

Usually: Geo/WAF rule, origin firewall, hotlink protection
Fix: check WAF logs, relax rules, confirm origin allows CDN IP ranges.

Scenario 3: “Only some countries can’t access”

Usually: Geo block, ASN block, regional edge issue
Fix: review geo rules; ensure no blanket blocks; test from those regions.

Scenario 4: “Checkout breaks for visitors”

Usually: cache rules applied to dynamic pages or WAF blocks AJAX endpoints
Fix: bypass cache for checkout/cart/account; allow needed endpoints.

Scenario 5: “It failed earlier today, now it’s fixed—but visitors still see errors”

Usually: cached error responses at the edge
CloudFront explicitly supports error caching and custom error pages, which can prolong the appearance of downtime (AWS Documentation).
Fix: purge, reduce error caching TTL, verify origin health.

When This Is Actually Malware (Yes, Sometimes)

Occasionally, site works for you but not visitors because malicious code is being served conditionally:

  • only to logged-out users
  • only to specific countries
  • only to certain user agents
  • only when coming from search/social referrers

That’s a classic pattern for SEO spam or redirect malware.

If you suspect this (visitors see weird redirects, pharma spam, or different content), go straight to WordPress malware removal or remove WordPress malware and infections.

External References (Helpful, Non-Service Documentation)

If you’re adjusting these systems, these official docs are worth keeping open:

(These are informational resources and don’t sell WordPress services.)

The Fastest “Fix Path” If You Don’t Want to Spend Your Day on This

If your site works for you but not visitors and it’s impacting revenue, leads, or SEO, the fastest route is:

  1. Stabilize uptime and visitor access
  2. Audit cache layers and CDN rules
  3. Fix WAF/Geo blocks without weakening security
  4. Lock in performance after correctness

You can go straight to:

Quick Summary: Why This Happens (and the 80/20 Fix)

When site works for you but not visitors, the 80/20 is:

  • Reproduce logged-out (incognito).
  • Purge all caches (plugin → host → CDN).
  • Disable “Cache Everything” for HTML unless you’re intentionally engineering it.
  • Check Geo/WAF logs for blocked visitors and overbroad rules.
  • Ensure dynamic pages are excluded (login/checkout/account/admin).