What the check looks at
C3 requests up to four public addresses exactly as a visitor would, with no query string and no cookies: the home page, the newest post, the shop page and the newest product, when they exist. In the HTML it looks for two things WordPress prints only for a signed in user: the admin bar (wpadminbar) and a logout link with its nonce, with its parameters in any order.
A request without cookies is never signed in, so if either appears, the answer is a stored copy of a page built for someone who was. The cf-cache-status header then tells where the copy came from: HIT means the Cloudflare cache, anything else a cache on your server or the server itself.
Like every request Edge Doctor sends, these go only to the hosts of your Site Address and WordPress Address (home_url() and site_url()). An address WordPress gives on another host, such as a single sign on page, is never requested.
Results and what they mean
| Result | What it means |
|---|---|
| FailedConfidence: High | A signed in page is being served to everybody The answer carried the admin bar or a logout link. The result names the address, the marker and the layer that served it. |
| PassedConfidence: Medium | Anonymous visitors see anonymous pages None of the pages came back with signed in content. The evidence names the data center the server’s requests went through. |
| Could not checkConfidence: Medium | This check could not be completed Every address answered with the WooCommerce Coming soon page ( maintenance). |
| Could not checkConfidence: Low | This check could not be completed No address returned HTML. See the reasons below. |
| Not applicable | Cloudflare is not in front of this site Check A1 did not detect Cloudflare, so this check sent no request. Reason not_behind_cloudflare. |
When the result names a reason
maintenance: The site is in maintenance mode or behind a coming soon page, so the pages read were not the real ones. Addresses that showed the Coming soon page are listed as not seen and never count as passed.loopback_failed: Your server could not reach its own site, so this check had nothing to read. The plugin links this result to its own guide: Your server could not reach its own site.blocked_by_config: WordPress itself refused the requests from your site to itself, so none was sent. WP_HTTP_BLOCK_EXTERNAL is on, and your own address is not let through. The plugin links this result to its own guide: WordPress blocks requests to your own site.not_behind_cloudflare: This site is not behind Cloudflare.
Symptoms you may notice
- Visitors report seeing your admin bar, your name, or Edit and Log out links.
- A member area, or a page that greets a user by name, shows the same person to everyone.
- After you log out, the site still looks logged in, or the reverse.
Why it happens
A page built for a signed in user was stored and handed out again. At Cloudflare that happens when a Cache Rule makes HTML eligible for the cache, ignores the headers WordPress sends to signed in users and does not step aside for the login cookie. On a test site on 2026-10-25, under a rule with Ignore cache-control header and use this TTL, a page loaded by a signed in administrator came back as HIT on a later request.
When the answer was not a HIT, the copy came from a page cache on your server, which some cache plugins and hosts run in front of WordPress.
Confirm it by hand
Open the page in a private window, where you are not logged in, and look for the admin bar. From a terminal:
curl -s "https://example.com/" | grep -c "wpadminbar"
curl -sI "https://example.com/" | grep -iE "cf-cache-status|age"A count above 0 is a leak. HIT with a growing age says the copy comes from Cloudflare. To see which data center answered you, open /cdn-cgi/trace on your site and read the colo line.
How to fix it
1. Remove the stored copy now. Purge the affected addresses, or everything.
2. Stop it from being stored again. Edit the Cache Rule that covers your HTML so that it bypasses the cache when the WordPress login cookie is present, and consider letting it follow the origin headers (Use cache control-header if present, bypass cache if not):
http.cookie contains "wordpress_logged_in_"3. If the copy did not come from Cloudflare, look at the page cache plugin or the server cache first: it must not store pages for logged in users.
Check C5 tests the rule itself and tells you which part of it lets this happen.
Limitations
This is the most important limitation in the plugin. Cloudflare keeps a separate cache in each data center, and the plugin sees only the one its own server’s requests pass through, named in the evidence. A signed in page stored in the data center your visitors use is out of its reach: on 2026-10-25 a test site showed exactly that, a stored page in one data center while the server read another. That is why a pass has Medium confidence and is never proof that nothing leaks.
Check C5 does not depend on a stored copy. It tests whether the rule would store such a page at all, so it is the more reliable of the two.
Only up to four public addresses are read, and only for the two markers above. Signed in content without the admin bar or a logout link, such as a custom greeting, is not detected.
Related checks
- C5 Login cookies and private responses: whether the cache rule could store a signed in page at all.
- C6 Cached pages older than their nonces: stored pages whose nonces expire before the cache does.
- C1 wp-admin and the login page in the cache: wp-admin and the login page in the cache.
- C7 Cached HTML without a purge: whether anything clears the cache when you publish.
Sources
- Cloudflare: cache responses
- Cloudflare: create a Cache Rule
- Cloudflare: Cache Rules settings
- Cloudflare: purge everything
Run this check on your own site with Edge Doctor for Cloudflare®, free on WordPress.org.
Edge Doctor for Cloudflare® is not affiliated with or endorsed by Cloudflare, Inc. Cloudflare is a registered trademark of Cloudflare, Inc.