Most host changes are planned around databases, files, and DNS—but the quiet breakage usually comes from undocumented CDN and cache rules that nobody remembered to copy over.
Before changing hosts, document your CDN provider, DNS and proxy status, all cache and bypass rules, purge workflows, WAF/firewall policies, and who owns each change.
If no one on your team can explain how your CDN, cache plugin, and firewall interact today, you are not ready for a safe host migration.
This article treats CDN and caching as their own mini-migration. You’ll walk away with a concrete documentation template, the hidden failure modes to expect, and a clear sense of who needs to own which rules.
For broader context on everything a team should capture before a host or vendor change, this is a focused companion to What Website Teams Should Document Before Changing Hosts or Infrastructure Vendors (prerequisite background on the wider checklist of systems and owners your team needs to map before you touch infrastructure).
As a prerequisite to this decision, What Website Teams Should Document Before Changing Hosts or Infrastructure Vendors explains the adjacent issue in more detail.
Why CDN and Cache Rules Deserve Their Own Migration Checklist
On most serious WordPress and business sites, performance and protection are not handled in a single place:
- DNS may live with the domain registrar.
- A CDN or reverse proxy may handle edge caching and a web application firewall.
- The host or application layer may add its own cache, plus a WordPress cache plugin.
Individually, each decision made sense. Together, they create a pile of rules that only exist in scattered dashboards and half-remembered Slack threads.
During audits and migration planning, we often see three patterns repeat:
- Login and checkout issues after a move. A forgotten rule that bypassed cache for login or checkout pages disappears, so authenticated traffic gets cached and users can’t log in or complete orders reliably.
- SEO and analytics blind spots. A WAF rule written during an incident starts blocking crawlers or stripping query parameters used by analytics, and nobody notices until traffic or reporting looks wrong weeks later.
- Blame ping-pong between vendors. The host says “it’s the CDN,” the CDN says “it’s your origin cache,” and internal teams have no documentation to referee the conversation.
The common root cause is not the tools; it is the lack of an owned rulebook.
Treat your CDN and cache configuration as a product spec you need to recreate, not a lucky accident you hope survives a host change.
Checkpoint: if you announced a host move today, could someone show a single document that describes every place caching and firewall logic lives and what it’s supposed to do?
Map the Current Delivery Chain: DNS, CDN, and Origin Relationships
Before you document individual rules, you need a simple diagram of the delivery chain. Without it, you won’t know which system is responsible for which behavior.
Think in three layers:
- DNS and routing – where your domain points.
- Edge and proxy – any CDN, reverse proxy, or WAF that sits between users and your origin.
- Origin and application – your hosting provider, PHP stack, and WordPress-level caching.
For broader background on this decision, the WordPress Hosting articles hub collects related context.
Create a table or diagram with at least these fields:
- Hostname / zone: e.g.,
www.example.com,api.example.com,assets.example.com. - DNS provider and record type: where DNS is hosted; A, CNAME, or other.
- Proxy status: whether traffic flows directly to the origin or through a CDN / proxy.
- Edge cache / WAF presence: yes/no flags with the relevant product.
- Origin host: current hosting provider and environment (production, staging, development).
- Application cache: whether you use a WordPress cache plugin, object cache, or host-provided cache.
To operationalize this decision, how our WordPress Hosting (Fully Managed) work supports this decision explains the adjacent issue in more detail.
The point is not to create an artful network diagram. The point is to answer, for each hostname: “Where could cache or firewall decisions be happening?”
A hidden failure mode at this stage is the forgotten subdomain—for example, a legacy checkout.example.com or portal.example.com that still routes through the old host or a different CDN profile and will quietly break if its special treatment isn’t carried forward.
Checkpoint: can you list every public hostname that matters to customers or crawlers, and for each one, state confidently whether it passes through a CDN/WAF and which origin host it hits?
Document Cache Rules and Bypass Logic That Affect Real Users
Once you know the chain, document how caching actually behaves for humans and crawlers.
Instead of copying a config export, focus on the functional behaviors a new host or CDN setup must reproduce. Capture these fields in a spreadsheet or doc:
- Path or pattern: URLs, path prefixes, or route patterns affected (e.g.,
/blog/*,/checkout/*,/wp-admin/*). - Rule location: which layer owns the rule (CDN page rule, origin cache, plugin rule, server config).
- Cache behavior: cache everything, cache static only, cache by device, or do not cache.
- TTL (time-to-live): how long responses are cached at the edge or origin.
- Bypass rules: paths or query parameters that must never be cached (logins, carts, account pages, form handlers).
- Logged-in behavior: how you avoid caching personalized content—cookie-based bypass, headers, or separate paths.
- Admin and API exceptions: rules that protect
/wp-admin/, AJAX endpoints, and APIs from caching.
In support work, we have noticed a recurring scenario: someone added a rule years ago to bypass cache for login and checkout paths, then changed plugins or URL patterns later. The host migration “works,” but the new stack doesn’t have that historical patch, so user sessions start acting erratically.
Another subtle failure mode here is dueling caches—for example, a WordPress plugin sending no-cache headers while the CDN is configured to ignore origin cache headers and still cache everything. During a migration, one vendor simplifies their side, assuming the other will handle it, and behavior changes without anyone realizing.
To make this documentation actionable, add two more fields:
- Why the rule exists: performance, stability, incident from the past, or a third-party integration.
- Must-keep vs. revisit: whether the rule must be preserved exactly, or can be simplified during the move.
Checkpoint: could a new engineer, with no history on your project, read this section of the document and accurately answer, “What gets cached, what never does, and why?”
Capture Purge, Warmup, and Deployment-Related Cache Workflows
Caching rules are only half the story. The other half is how content actually becomes visible when your team changes something.
You need to capture the workflows around cache control:
- Who can clear cache where: list roles or teams and which systems they can purge (CDN, origin cache, plugin, host panel).
- Purge entry points: buttons in dashboards, CLI scripts, or deployment hooks that clear cache.
- Scope of purges: full-zone purges vs. URL-based vs. tag-based purges.
- Deployment behavior: what your team does when pushing code, updating plugins, or changing themes:
- Do you clear all caches every time?
- Does CI/CD call any cache APIs automatically?
- Are there environment-specific behaviors (production vs. staging)?
- Editorial workflows: what marketing or content teams do after publishing a high-stakes page:
- Do they manually purge a URL?
- How do they validate the live version?
A hidden failure mode here is the phantom cache: during a migration, your new host introduces an additional cache layer with its own purge button. The team keeps clearing the CDN, but the origin cache still serves old content, so everyone spends hours insisting they “already cleared cache” while pointing at the wrong system.
To prevent that, your documentation should include a “how to see real origin content” note:
- Which query parameter, header, or cookie bypasses cache for debugging.
- Which IP or VPN path the team can use to hit the origin directly (if allowed).
In many migrations, the time-consuming incidents are not caused by broken code; they are caused by nobody knowing which cache needs to be cleared, in which order, or how to confidently validate that a change is live.
Checkpoint: if a critical security fix had to go live in 10 minutes, does your documentation explain exactly which caches to purge, who does it, and how you would confirm success?
Record WAF, Bot, and Firewall Rules That Protect (or Break) Traffic
Your web application firewall (WAF), rate limiting, and bot controls are safety nets that can also become tripwires during a host change.
You don’t need to document every low-level rule or vendor preset. Instead, capture the rules and patterns that have behavioral impact:
- Custom WAF rules: anything written by your team or vendor, especially those matching specific paths, IP ranges, or query strings.
- Bot and crawler settings: how you treat “bad” bots vs. search engines and monitoring tools.
- Rate limiting policies: thresholds for requests per IP or per path, and what happens when limits are exceeded.
- Geo or IP blocking: countries, regions, or networks that are blocked or challenged.
- Known problem solves: rules added because of past incidents—scraping, attacks, form spam, or abusive integrations.
- Exceptions and allowlists: IPs or user-agents that must never be blocked (payment gateways, monitoring, marketing tools, corporate VPN ranges).
A frequent hidden failure mode is recreating only half the exceptions. The team remembers to open things up for search engines but forgets the marketing automation scanner or a payment provider’s IP range, leading to intermittent checkout errors or reporting gaps.
To make this documentation functionally useful, add these fields:
- Impact type: what happens if the rule is missing or changed (checkout failures, login blocks, spam surge, analytics skew).
- Owner and review cadence: who is allowed to edit WAF rules and how often they’re reviewed.
That review cadence links directly to Maintenance Maturity: mature teams treat WAF and firewall rules as part of their recurring governance, not just something changed in a panic during an attack and never revisited.
Checkpoint: if your CDN or WAF vendor changed tomorrow, could you re-implement the handful of rules that really matter, along with their exceptions, without waiting for someone to “remember what we did last time”?
Assign Ownership and Verification Steps for the New Host
Documentation without ownership is just a nicer-looking risk.
For each section of your CDN/cache rulebook, make explicit who owns it now and who will own it after the move. A simple matrix works:
- Area: DNS, CDN cache rules, origin cache, WAF, deployment purge hooks, monitoring.
- Current owner: internal role or external vendor primarily responsible today.
- Future owner: who will be responsible after the host change.
- Approval model: who can request changes, who can approve them, and who actually implements them.
Ownership clarity is where Maintenance Maturity becomes real. High-maturity teams:
- Know where caching and firewall decisions are made.
- Have defined review points (e.g., quarterly checks on WAF exceptions and cache TTLs).
- Bake rule verification into every infrastructure change, not just “big migrations.”
On top of ownership, you need a verification plan for the new environment. Define specific tests:
- Public pages: confirm expected caching and TTL behaviors with and without query strings.
- Logins and accounts: test multiple login/logout cycles, password resets, account updates, and profile changes under load.
- Checkout and forms: simulate full purchase flows and key forms, verifying no cached steps, tokens, or confirmation pages.
- Admin and editorial: ensure editors see their own drafts correctly and that admin screens are never cached.
- Crawlers and integrations: confirm that search engines, uptime monitors, and integrations can access what they need without being blocked or challenged.
For each test, decide ahead of time:
- Who runs it.
- What tools they use.
- What “good” looks like.
A hidden failure mode here is assuming the host’s go-live checklist covers your edge rules. Most hosting checklists focus on origin performance and uptime; they don’t know your historical WAF exceptions or the bespoke caching rules you created to keep marketing and engineering happy.
Checkpoint: do you have named individuals—or vendors—assigned to recreate and verify each group of rules, with a documented test they must pass before you sign off on the migration?
Using Managed WordPress Hosting When the Picture Is Fuzzy
Sometimes you walk through this exercise and realize there is no single person who can explain how your CDN, cache plugin, and firewall rules came to be. That’s a Maintenance Maturity signal: you’re running a critical website on habits and folklore instead of an owned configuration.
That’s the point where a managed hosting partner stops being a nice-to-have and becomes risk reduction.
A competent WordPress hosting team can help you:
- Untangle overlapping CDN and origin caches and recommend a simpler model.
- Translate tribal knowledge into a documented rulebook.
- Design a migration plan that includes explicit verification steps for cache behavior and WAF policies.
- Decide which legacy rules must be preserved and which should be retired.
If this article surfaced more unknowns than answers, treat that as useful data. You’ve found the risk before it turned into a broken checkout at 10 p.m. on a campaign launch day.
You can explore how a dedicated team would handle this by reviewing Best Website’s WordPress Hosting (Fully Managed) service, which is designed to own the operational side of caching, CDN rules, and firewall behavior as part of your broader hosting and support model (operationalization of the governance work described above).
For a site that already has a complicated mix of vendors and historical rule tweaks, it can be faster to talk through your specific stack than to map it alone; if you’d like help turning your current CDN and cache situation into a clear migration-ready plan, get in touch and share what you know so far through the contact form so we can assess how much work is required before you change hosts.
Decision: before approving any host change, insist on a single, owner-backed document that describes your delivery chain, cache rules, purge workflows, and WAF behavior—and either assign internal owners to keep it accurate or engage a managed WordPress host to own that layer with you, so migrations stop being roll-the-dice events and start being repeatable, low-drama operations.
If you want more depth on how hosting and support decisions fit into a broader infrastructure picture, the collection of Wordpress Hosting articles includes additional guidance on migrations, reliability, and long-term governance for serious business sites.
Leaving that decision unresolved creates avoidable delay, rework, and production risk.