Skip to main content
GrN.dk

Main navigation

  • Articles
  • Contact
  • Your Digital Project Manager
  • About Greg Nowak
  • Services
  • Portfolio
  • Container
    • Excel Freelancer
    • Kubuntu - tips and tricks
    • Linux Apache MySQL and PHP
    • News
    • Image Gallery
User account menu
  • Log in

Breadcrumb

  1. Home

Cloudflare Page Rules Debt: The Quiet Way Business Websites Break

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 useful Cloudflare audit starts with business-critical request paths, not with the dashboard order alone.

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.

  1. 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.
  2. 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
  1. Record the expected and actual Status, Location, Cache-Control, Set-Cookie, canonical URL, and CF-Cache-Status for each test URL.
  2. 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.
  3. 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.

Sources

  • Cloudflare Rules: Page Rules migration guide
  • Cloudflare Cache Rules: Order and priority
  • Cloudflare Cache: Default cache behavior
  • Google Search Central: Redirects and Google Search
  • Google Crawling Infrastructure: HTTP status codes
Last modified
2026-06-23

Tags

  • Cloudflare
  • Website Operations
  • Technical SEO
  • wordpress
  • Drupal

Review Greg on Google

Greg Nowak Google Reviews

 

  • Drupal CMS 2.0: quick starts, harder rebuild choices
  • CMS Upgrades in 2026: A PHP Roadmap for WordPress and Drupal Sites
  • Essential Drupal 8 Modules: What Still Matters on an Older Site
  • Cloudflare Page Rules Debt: The Quiet Way Business Websites Break
  • Model Retirements Are Quietly Breaking AI Integrations
RSS feed

GrN.dk web platforms, web optimization, data analysis, data handling and logistics.