toolkit

Scenario · Before you touch a site

The edge is changing what the page serves

“I fixed it, but the live page hasn't changed.” Or an audit finding nobody can reproduce in a browser.

A page that was fixed but still looks unchanged, or an audit finding that nobody can reproduce in a browser, is very often not a mystery — it's Cloudflare sitting between the visitor and the actual site, quietly rewriting the page on the way through. This reads exactly which of those settings are turned on, confirms which version of the site is actually being served, and snapshots the live page so "it hasn't changed" and "it changed and you're looking at a cached copy" stop being the same sentence. Every actual fix still happens by hand in the Cloudflare dashboard — this only tells you where to look.

What to ask for

Cloudflare zone clientOptional integration — reads a domain's Cloudflare zone: DNS records, the deploy surface (with --pages-project), and the zone settings that rewrite delivered HTML (Rocket Loader, Auto Minify, Email Obfuscation, Auto HTTPS Rewrites) — settings every HTML-reading skill in the tree is otherwise blind to.Cloudflare deploy surface checkVerifies a live Cloudflare Pages deploy for the six traps invisible to every check that only reads HTML: a Content-Security-Policy header silently dropped because its _headers line ran over Cloudflare's length limit; a served asset over 25 MiB, which hard-rejects the whole deploy; the deployed HTML rewritten by Auto-Minify so a byte-parity comparison drifts against a transform nobody made; a stale edge-cached alias serving the previous bundle for up to 24h after a redeploy; declared _headers/_redirects rules that were written but never confirmed live; and an Access-gated preview reachable on its unprotected deployment alias even though the project alias is gated.Hosting & DNSHosting & DNS infra fingerprint — reads a domain's DNS, TLS, headers and RDAP and reports the backend stack: web host, nameservers, CDN/edge, email provider, SSL issuer, CMS, registrar and last-changed date.Before/after checkBefore/after verification for a change to a live page — the safety net for the small edit that doesn't justify a staging round-trip.

See it work

A real run of Cloudflare zone client:

INFO  example.com · 2 DNS record(s)
  [info] Auto Minify setting not present on this zone — Cloudflare deprecated the classic feature on newer zones; not the same as "off"

  report: ./out/cloudflare-zone-client-cloudflare-zone-client.html

The captured report, exactly as a run hands it to a client —open the full report ↗

Cloudflare sits between the origin and every visitor, and several of its settings rewrite the delivered HTML. That makes it the invisible cause of two recurring puzzles: a fix that does not appear, and an audit finding that does not reproduce.

  1. Establish what the visitor actually gets. Before theorising, snapshot the live page. “It hasn’t changed” and “it changed and I am looking at a cached copy” are different problems.
  2. Read the zone settings that rewrite HTML. The zone client reports the ones that matter: Rocket Loader, Auto Minify, Email Obfuscation, Automatic HTTPS Rewrites. Every HTML-reading check in the toolkit sees the output of these, so a finding about an inline script or an obfuscated mailto may be Cloudflare’s work rather than the site’s.
  3. Confirm which deployment is serving. For a Pages-hosted site, the deploy surface check reports what is actually live versus what was last built. A deploy that failed silently is the most common form of “I published and nothing happened”.
  4. Check the DNS and the proxy state. The hosting fingerprint reports whether records are proxied, and whether the origin is hidden behind the client’s own Cloudflare account rather than ours — which changes who can purge and who can see the origin at all.
  5. [manual] Purge, and purge the right thing. A targeted purge of the changed URLs, then a hard reload. If the content still does not change, the cache in front of Cloudflare is not the cache holding it — look at the origin’s own page cache.
  6. Re-snapshot and compare. The before/after diff is what proves the change reached a visitor, which is the only claim that matters.
  7. Re-run whatever check produced the unreproducible finding, now that the edge behaviour is known. Several findings dissolve once Rocket Loader or Auto Minify is accounted for.

The edge explains findings, not just staleness

The caching half of this is well known. The half that wastes real time is an audit result nobody can reproduce — a script attribute that is not in the source, an obfuscated email, a rewritten URL. Step 2 is worth running before debugging any HTML-level finding on a proxied site.

What this does not cover

Changing any of it. Every client here is read-only: they report the zone's settings, its DNS, and which deployment is actually serving, and every fix is made in the Cloudflare dashboard by hand. Origin-side caching — a page cache plugin, a host's own layer — is also outside them, and on a WordPress site that is at least as often the culprit.

← All scenarios