Your origin now redirects to the correct destination, yet some visitors still land on the old page. Before changing the rule again, find the first hop that supplies the outdated Location. A browser or CDN may be reusing a permanent redirect without contacting the updated origin.
This guide covers stale redirects after a migration, path change, or CDN rule update—not repeated redirect loops. Commands are diagnostic examples for public pages that are safe to request with GET. Replace the sample hostname and IP address; these examples have not been tested against your production environment.
Capture the original URL and inspect the first hop
Record the exact URL the visitor entered, including its scheme, hostname, path, and query string. Start with a GET request that does not follow redirects:
curl -sS -D - -o /dev/null https://www.example.com/old-path
Check the status code, Location, Cache-Control, Expires, Age, and any provider-specific cache-status headers. Then capture the full HTTP redirect chain:
curl -sS -L --max-redirs 10 -D redirect-chain.txt -o /dev/null \ https://www.example.com/old-path
The header file can contain several responses. Find the first destination that differs from the expected route. A redirect to a canonical hostname followed by a path redirect involves separate rules; a final 200 response does not prove that the preceding hops are correct.
curl does not execute JavaScript or HTML meta refresh. If the HTTP chain is correct but the browser still navigates elsewhere, inspect page code and Service Workers too.
Do not replay payment, deletion, or other state-changing requests simply to reproduce a redirect. Keep cookies, authorization headers, and complete signed URLs out of public support tickets. On Windows, use curl.exe if your shell maps curl to another command, and replace /dev/null with NUL where appropriate.
Understand what permanent redirects can retain
Both 301 and 308 responses are heuristically cacheable. Their actual lifetime depends on cache directives, implementation behavior, and CDN rules; there is no universal one-day lifetime or rule that they can never be cleared. A 308 preserves the request method and body. With a 301, historical client behavior may change POST to GET, so API semantics and client compatibility matter when choosing a status code.[1][2]
A temporary redirect is not automatically uncacheable either. Inspect explicit cache directives and edge policies for 302 and 307 responses. A 307 preserves the method for a temporary redirect. Do not change redirect codes across every API merely to repair one public page.
While validating a new route, consider a temporary redirect with a deliberately short cache lifetime or an appropriate no-storage policy. Move to a permanent migration only after checking the destination, application compatibility, and SEO implications. Treat the redirect code, cache policy, and search-engine migration plan as separate decisions.
Compare the CDN response with the origin
If the CDN returns the old destination, compare it with the origin from an authorized diagnostic environment:
curl -sS --resolve www.example.com:443:203.0.113.10 \ -D - -o /dev/null https://www.example.com/old-path
The IP address is reserved for documentation. --resolve changes the connection destination while keeping the URL hostname for the Host header, TLS SNI, and certificate verification. If the origin accepts traffic only from the CDN, use an approved diagnostic route. Do not open it to the internet or add -k to bypass certificate verification.
When the origin returns the new destination but the edge returns the old one, distinguish two causes:
A cached response still contains the previous
Location.An active CDN redirect rule still produces the old destination.
Purging an object will not repair an incorrect edge rule. Updating a rule may not invalidate responses already stored in cache. Check rule priority, deployment scope, hostname and path matching, and any redirects generated by load balancers, web servers, application frameworks, or plugins. Multiple origin instances may also have inconsistent configurations.
Age and cache-hit headers are useful clues, not proof that a response is correct or that caching is absent. Consult your provider's documentation for their meaning. A request with Cache-Control: no-cache can help compare revalidation behavior, but it is not a global purge command; edge behavior still depends on the configuration.[3]
Purge the redirecting entry, not just its destination
The browser requests /old-path before it knows where to go next. Purging only the landing page can leave the cached redirect at the original entry untouched.
Check the actual cache key: scheme, hostname, trailing slash, and query-string handling can affect which object is stored. Some configurations ignore query parameters; others create separate variants. Adding a random parameter may not bypass caching and can create additional objects, so it is not a reliable permanent fix.
Start with a targeted purge of the confirmed stale entry. Verify the first hop and full chain before expanding the scope. A site-wide purge can increase origin traffic: assess capacity, avoid peak periods, and have a way to stop further changes. Keep the purge receipt, but judge success by the responses visitors actually receive.
Check whether the affected browser requests the entry at all
If curl and a clean browser profile follow the new route while an existing profile does not, preserve the browser's Network log and inspect navigation. Disabling cache with developer tools open is a diagnostic aid, not proof that every permanent redirect has been removed. Its scope varies by browser.
Compare with a clean browser profile or another device and check whether the server receives a request for the original entry. A private window is useful for comparison, but should not be treated as perfectly isolated from every network-related state.
New response headers affect clients that receive those responses. They cannot recall an old redirect that a browser still reuses without requesting the original URL. Adding no-store now therefore cannot, by itself, fix every previously stored redirect.[3]
If necessary, ask the visitor to clear the relevant site's cache with informed consent. Clearing site data can remove login state, offline content, and unsynchronized drafts; do not default to deleting all browser data. If you still control the old destination, consider a safe migration notice or a controlled forwarding route. Check carefully that it cannot redirect back into a loop.
Keeping the old domain, certificate, and necessary compatibility paths available is often safer than immediately shutting them down. A directly accessible new entry can help affected users temporarily, but assess canonical URLs and SEO before introducing long-lived duplicate pages.
Separate HTTP redirects from browser and application navigation
An HTTP-to-HTTPS upgrade does not necessarily come from a current server-issued 301. HSTS, local policies, or browser behavior can affect navigation. Cross-check actual responses, browser diagnostics, and server logs. Do not weaken or remove HSTS to solve an unrelated path problem.
When the address changes after a page loads, inspect JavaScript navigation, meta refresh, front-end routing, and Service Workers. A CDN purge cannot remove every client-side state. Old search results and address-bar suggestions also do not prove that the server currently returns an incorrect Location.
Validate a scoped change and plan for cached rollback effects
Before changing anything, back up the origin and CDN rules, destination URLs, status codes, and cache settings. Test a low-risk path or staging hostname first, and identify which clients may still retain previous responses.
Acceptance checks should cover:
The original entry returns the intended status and
Location, and later hops contain no unnecessary redirects or loops.CDN and origin behavior agree, with no stale rule on another origin instance.
Clean sessions, existing browsers, and relevant regions have been checked.
For forms and APIs, method, body, and authentication behavior remain correct.
To roll back, restore the last verified configuration and deal with affected cached objects again. Permanent redirects already delivered to clients may remain there; reverting the server does not instantly restore every user's earlier behavior. Maintain compatibility entries and support instructions rather than repeatedly switching permanent routes back and forth.
Record the original URL, the first incorrect hop, the layer that produced it, and the corrected full chain in the incident ticket. That evidence tells the next operator whether to change a rule, purge an entry, or address retained browser state.
References
Sources checked for the paired article on October 26, 2026. Adapt the examples to your CDN and browser behavior.
