CDN Cache Invalidation Checklist for Site Migrations and URL Changes

Overview

A migration rarely fails because of one obvious error. More often, it is a stack of small issues: an old redirect cached at the edge, an HTML page still serving a retired canonical, a CSS or JS file with a long TTL and no version bump, or a bot getting a different response from a user because one layer has updated and another has not.

That is why a cache invalidation checklist matters. During a site migration, you are not only changing URLs. You are changing assumptions that upstream systems have stored about your site. Browsers cache assets. CDNs cache HTML, images, redirects, and headers. Reverse proxies may cache responses differently than your origin expects. Search engines may revisit old URLs while your users are already hitting the new ones. If those layers are not aligned, migrations look unstable even when the origin server is configured correctly.

This article focuses on a repeatable SEO migration checklist for CDN planning and invalidation. It is written to be reused before:

• domain changes
• protocol changes such as HTTP to HTTPS cleanup
• URL structure rewrites
• CMS rebuilds and redesigns
• large redirect deployments
• asset path changes
• rollback scenarios after a problematic launch

The goal is simple: make sure the content, headers, redirects, and assets that users and crawlers receive are the responses you intend to serve now, not what your cache layer remembers from last week.

If you are also tightening your broader technical stack, it helps to pair this work with a deeper page-quality review such as Page Authority Is a Symptom: A Technical Playbook to Build Pages That Actually Rank.

Checklist by scenario

Use the scenario that matches your change set. In practice, many launches combine more than one of these, so it is normal to merge checklists.

1. Full domain migration

This is the highest-risk scenario because nearly every cacheable layer is affected.

• Inventory cacheable responses before launch. Include HTML, redirects, images, CSS, JS, API responses used by rendered pages, XML sitemaps, robots.txt, and feeds.
• Document current CDN rules. Confirm which paths cache HTML, which bypass cache, and whether redirects are cached at the edge.
• Lower TTLs in advance where possible. If your CDN or reverse proxy currently caches HTML or redirect responses aggressively, reduce TTLs before launch rather than only after.
• Stage redirects at the origin and the edge carefully. Avoid split logic where one layer redirects and another serves old content for the same path.
• Prepare a purge list for old and new hostnames. A domain move may require invalidation on both the retiring and destination hostnames.
• Purge HTML, redirect responses, and metadata-bearing files immediately after cutover. Prioritize pages that expose canonicals, hreflang, structured data, and internal navigation.
• Check header consistency. Verify Cache-Control, Surrogate-Control, Vary, canonical signals, and redirect status codes across representative URLs.
• Refresh XML sitemaps and robots.txt. If these are cached, bots may receive stale crawl instructions.
• Validate key templates from multiple locations. Edge nodes can update unevenly, so sample from more than one region if your tooling allows.
• Monitor old URLs directly. Confirm they return the intended redirect and do not intermittently serve cached 200 pages.

2. URL structure rewrite without changing domain

This is common during CMS consolidation or taxonomy cleanup. It often looks simpler than it is because the hostname stays the same, but cache conflicts are still common.

• Map old URLs to new URLs one to one wherever practical. This reduces ambiguity and helps with validation.
• Purge cached HTML for high-value old URLs. If old pages remain cached as 200 responses, crawlers may keep seeing the old version instead of the redirect.
• Invalidate redirect rules if your CDN caches 301 or 302 responses. Redirect cache issues often persist because teams update the origin but forget the edge is still serving an earlier rule.
• Purge category, tag, and hub pages. These often contain stale internal links even after page templates update.
• Regenerate breadcrumbs, canonicals, and pagination links. Then purge the templates or paths where those elements are cached.
• Check trailing slash, case, and parameter handling. Cache keys can treat close variants differently, which leads to duplicated or conflicting responses.

3. Redesign with the same URLs

Even when slugs remain stable, a redesign can still create cache invalidation problems that affect indexation and performance.

• Version static assets. If CSS or JS filenames remain unchanged, old edge and browser caches may continue to serve outdated files.
• Purge HTML templates after deployment. New markup may not be visible if the CDN is still serving old document responses.
• Review image paths and responsive image markup. If the HTML changes but image assets are still cached under old assumptions, layout and crawlability can suffer.
• Confirm canonical, meta robots, and structured data output on key templates. These are common casualties of partial rollout.
• Test hydration-dependent content. A cached shell paired with new API responses can produce inconsistent page states for users and bots.

4. Redirect rule changes or cleanup

Sometimes you are not migrating the whole site. You are simply fixing redirect chains, replacing temporary redirects, or consolidating legacy routes. This still deserves a cache invalidation checklist.

• Identify whether redirects are cached by the browser, CDN, reverse proxy, or all three. A correct rule at the origin does not guarantee an immediate correction everywhere else.
• Purge the source URLs, not just the target URLs. The cached redirect lives on the old route.
• Test with and without cache bypass headers where available. Compare origin behavior with edge behavior.
• Check for chained redirects introduced by partial updates. One stale edge rule can turn a clean 301 into a multi-hop chain.
• Confirm status code intent. If a redirect should now be permanent, make sure no layer is still serving an old temporary response.

5. Asset path or media CDN changes

Asset migrations are often treated as front-end housekeeping, but they can affect crawl efficiency, rendering, and perceived stability.

• Fingerprint or rename assets when possible. Versioned filenames are usually safer than relying on global purges alone.
• Purge critical render assets first. CSS, JS, fonts, and hero images deserve priority because they shape both user experience and rendered output.
• Check CORS, cache headers, and compression settings on the new asset host. Migrations sometimes break because the files exist but are not served with compatible headers.
• Verify old asset URLs either continue to work temporarily or fail in a controlled way. Hard breaks can leave cached HTML calling missing resources.

6. Rollback after a failed launch

Rollback is where cache complexity becomes most visible. You are not just restoring code. You are undoing expectations already distributed across the edge.

• Keep a rollback purge plan ready before launch. Waiting to design one during an incident wastes recovery time.
• Purge both failed-launch paths and restored legacy paths. Stale content can remain on either side.
• Revalidate redirects, canonical tags, and robots directives immediately after rollback. These often remain mixed.
• Spot-check pages that changed status codes during launch. A formerly live URL that briefly returned 404, 302, or 503 may still be cached incorrectly.
• Annotate the timeline in analytics and monitoring tools. This helps separate cache lag from true post-launch demand changes.

What to double-check

The checklist above covers scenarios. This section covers the details that are easy to miss even when the migration plan looks solid.

HTML is often the most important purge target

Teams are usually good at purging assets and less consistent about purging HTML. For SEO, stale HTML is often the bigger problem because it contains canonical tags, meta robots directives, internal links, hreflang references, pagination signals, structured data, and links to assets. If one old HTML document remains cached at the edge, it can keep broadcasting old signals long after the origin is corrected.

Redirect responses may be cached longer than expected

Redirects can persist in browsers, CDNs, and intermediary layers. If you change a redirect rule after launch, test whether you are seeing the updated response or a cached one. This is one of the most common causes of redirect cache issues during cleanup work.

Cache keys can create duplicate realities

Query strings, cookies, device headers, and protocol variations can produce multiple cached versions of what appears to be the same page. During migration, confirm which request attributes are part of the cache key. Otherwise, one version may serve new content while another continues serving old markup.

Status code consistency matters more than isolated passes

A single successful test is not enough. Check whether the same URL consistently returns the same status code, headers, and body across repeated requests and representative regions. Inconsistent behavior confuses both debugging and crawling.

Sitemaps, feeds, and utility files deserve priority

XML sitemaps, robots.txt, and feeds can be cached and forgotten. Since these files influence crawl behavior directly, purge and validate them alongside your main templates.

Analytics and tag management should be verified after cache changes

A migration that looks healthy in crawl tests can still break measurement if stale tag containers or scripts remain cached. Confirm analytics tags, consent scripts, and event definitions on the pages you purged. If your team depends on clean measurement, formalize launch annotations and validation as part of the same runbook.

For related workflow thinking, A Content Ops Workflow That Optimizes for Both Google and Generative AI is useful when technical and editorial changes ship together.

Common mistakes

The safest way to use this article is to treat these as anti-patterns. If any one of them appears in your launch plan, fix it before go-live.

• Assuming a code deploy automatically invalidates the CDN. Many platforms separate deploy success from cache refresh success.
• Purging everything without a plan. Full purges can be necessary, but they can also increase load, reduce performance, and make troubleshooting harder. Prefer targeted invalidation when you can explain the affected paths clearly.
• Changing redirects after launch without clearing cached source URLs. This leaves old routing logic active even when the origin is correct.
• Keeping long HTML TTLs during migration week. Aggressive caching may be desirable during stable periods and unhelpful during transition periods.
• Forgetting that browser caches exist too. You may confirm a fix in one environment and still have users seeing old assets because filenames did not change.
• Testing only the homepage. Migration issues often appear first on templates with parameters, pagination, faceted navigation, or legacy deep links.
• Ignoring stale internal links in cached navigation components. Header, footer, breadcrumb, and mega-menu fragments can keep old URLs alive.
• Not documenting which layer owns which cache decision. When no one knows whether the CDN, reverse proxy, application, or browser controls freshness, debugging slows down quickly.
• Skipping rollback rehearsals. If recovery depends on ad hoc cache decisions made under stress, traffic recovery will usually take longer.

Technical SEO work tends to overlap with governance. If your stack also needs clearer rules for crawler handling and infrastructure-level bot behavior, see Robots, LLMs.txt and Bot Governance: A DevOps Playbook for 2026.

When to revisit

This checklist works best as a living document, not a one-time migration note. Revisit it whenever one of the underlying inputs changes.

• Before any redesign or replatforming project. Add cache steps at the planning stage, not the launch stage.
• Before seasonal planning cycles. High-traffic periods are a poor time to discover stale redirect behavior or mixed template caches.
• When CDN rules, reverse proxy rules, or hosting architecture change. Even small infrastructure adjustments can change cache behavior in ways your old runbook no longer reflects.
• When workflows or tools change. New deployment methods, headless rendering patterns, or multi-CDN setups deserve a fresh review.
• After any migration incident or rollback. Capture what was unexpectedly cached and update the checklist with those lessons.

To make this practical, keep a reusable launch note with these fields:

1. scope of URLs and assets affected
2. current TTLs by response type
3. which layers cache redirects
4. purge method and owner
5. paths to invalidate immediately after launch
6. post-launch validation URLs
7. rollback purge paths
8. monitoring window and success criteria

If you maintain this as part of your deployment process, you reduce the odds that site migration cache invalidation becomes an afterthought. That is the real win. Good migrations are not just about redirect maps and content parity. They are about serving the intended response consistently, quickly, and predictably to both users and crawlers.

Bookmark this checklist, adapt it to your CDN and deployment model, and review it before every structural site change. The details may differ by stack, but the discipline is the same: know what is cached, know what changed, and invalidate with intent.