By Greg Nowak. Last updated 2026-06-23.
Cloudflare often starts as a sensible layer in front of a business website: DNS, SSL, CDN, a few redirects, and maybe a cache rule for static assets. The debt arrives later. A campaign needs old URLs redirected. A developer bypasses cache for an admin path. An agency adds staging exceptions. Someone begins moving from Page Rules to modern Rules products. After enough launches, nobody is fully sure which layer owns the behavior of a given URL.
That is why this failure mode is easy to miss. The site may not go down. Instead, a lead form behaves differently for returning visitors, a campaign URL lands after three hops, a preview path is cached, or Google sees a status code that the browser team never noticed. For business owners, operations leads, and agencies, this is not Cloudflare housekeeping. It is revenue-path risk.
Why old Page Rules become operational risk
Cloudflare now recommends modern Rules features for new implementations, and the execution model is not the same as the older Page Rules mental model. Page Rules use a first-match approach. Modern rules can stack, run in a fixed product sequence, and newer Rules products take precedence over Page Rules when both match. That means a rule created during a recent migration can quietly override behavior that a previous agency or developer assumed was still active.
Caching is the area to treat with particular care. Under Cloudflare default cache behavior, HTML and JSON are not cached by default, and Cloudflare does not cache when a response has headers such as Set-Cookie, a private or no-store cache directive, or a request method other than GET. But cache rules can change eligibility, and Cloudflare's Page Rules migration guidance warns that choosing Eligible for cache in a Cache Rule enables cache-everything behavior by default. On a brochure site that may be fine. On a WordPress, Drupal, commerce, account, quote, or preview workflow, it needs deliberate testing.
Redirects have a similar business effect. Google treats permanent redirects such as 301 and 308 as strong canonical signals, while temporary redirects such as 302 and 307 send a different message. Google also documents that 4xx URLs are not indexed and are removed over time, while persistent 5xx and 429 responses can slow crawling and eventually remove indexed URLs. If Cloudflare changes status codes or redirect targets, it changes how buyers and crawlers reach your important pages.
| Audit area | Business risk | What to verify |
|---|---|---|
| Redirects | Campaign loss, SEO confusion, broken handovers | One final URL, correct 301/302 choice, no avoidable chains |
| Cache rules | Wrong content shown, stale forms, private paths exposed | Expected Cache-Control, Set-Cookie, and CF-Cache-Status by path type |
| Admin and preview paths | Editors and agencies see inconsistent behavior | Explicit bypasses for logged-in, preview, cart, checkout, quote, and account routes |
| SEO files | Crawl and indexation signals drift | robots.txt, XML sitemaps, canonical pages, and removed URLs return expected status codes |
| Origin and hostname rules | Staging or legacy hosts leak into production | Production, staging, legacy domains, and origin overrides are documented |
A practical audit process
Start with a request-path inventory. List every place that can affect a request before it reaches the CMS or application: Cloudflare Page Rules, Redirect Rules, Cache Rules, Origin Rules, Transform Rules, Workers, Snippets, web-server rewrites, application middleware, and CMS redirect or cache plugins. The question is not only what exists. It is which layer is meant to own each decision.
- Build a URL test set around commercial importance. Include the homepage on each hostname, key service pages, old campaign URLs, form thank-you pages, admin and preview paths,
robots.txt, XML sitemaps, media URLs, and any checkout, quote, or account flow. - Check headers and hops with repeatable commands, not only browser clicks. Browsers hide too much and cached sessions can mislead you.
curl -I https://www.example.com/old-url
curl -I -L https://www.example.com/old-url
curl -I -H 'Cookie: wordpress_logged_in=1' https://www.example.com/
curl -I https://www.example.com/robots.txt- Record the expected and actual
Status,Location,Cache-Control,Set-Cookie, canonical URL, andCF-Cache-Statusfor each test URL. - Use Cloudflare Trace when a simulated request needs explanation. It is useful for seeing rule evaluation and testing different request conditions. Use production logs or Log Explorer when you need evidence of what real visitors experienced.
- Retest after every cleanup change. Treat edge configuration like production code: small changes, known expected output, and a rollback note.
What cleanup should produce
A healthy Cloudflare setup is not the one with the most clever rules. It is the one a new operator can explain without guessing. After cleanup, there should be one clear owner for permanent redirects, explicit cache bypasses for sensitive paths, and a short response map for the URLs that matter to sales, SEO, and support.
- Put simple hostname and domain redirects at the edge when that is the cleanest owner.
- Keep editorial or content-managed redirects in the CMS only when non-technical users genuinely need to manage them.
- Avoid solving the same redirect in Cloudflare, the web server, and a CMS plugin at the same time.
- Document cache rules by intent: static assets, public HTML, authenticated paths, preview paths, and transactional flows.
- Keep a launch checklist that includes headers, redirect hops, canonical output, forms, and crawl-critical files.
For WordPress and Drupal sites, this matters because the application is only one layer in the chain. A plugin, theme, reverse proxy, web server, and Cloudflare rule can each be locally reasonable while producing confusing behavior together. The work is to reduce the number of places where the same request can be changed.
When to bring in help
Cloudflare rules debt tends to sit between infrastructure, SEO, CMS delivery, and agency handover, so it often has no obvious owner. That makes it good consulting work: map the real request path, remove overlap, protect the commercial URLs, and leave documentation that the next team can actually use.
If your site has years of Cloudflare exceptions, legacy Page Rules, unexplained cache behavior, or redirects nobody wants to touch before launch, Greg can audit the setup and turn it into a clearer operating model. See how Greg works as a digital project manager.
Related on GrN.dk
- When URL Parameters Become an Operations Problem: Fix Crawl Waste, Cache Fragmentation, and Duplicate URLs
- Form Spam Is a Lead-Quality Problem: A Practical Hardening Playbook for Business Websites
- AI Crawler Control for Business Websites: Protect Content Without Sacrificing Search Visibility
Need help with this kind of work?
Ask Greg to audit your Cloudflare setup Get in touch with Greg.