Guide · redirects · 1 Oct 2026

Why a moved URL can keep its old redirect target

A redirect is a response to one requested URI. Each redirect in a chain is a separate response with its own Location and cache rules.

Documentation summary · sources retrieved 1 Oct 2026 at 06:17 UTC · no route, browser, provider, or cache was tested.

Short answer

A cache can reuse a matching stored redirect response while it is fresh, when stale reuse is allowed, or after validation. The response carries the Location used for the next request. The cache does not thereby cache the later target page as the same response. A fresh redirect response at one hop can coexist with an older redirect response at another hop.

A new route policy does not erase a response already stored elsewhere. The final URL alone cannot show which redirect response supplied the old target.

Inspect the response at each requested URI. A current first hop does not prove that a later hop has a current Location.

Redirect status and cacheability

This table describes baseline HTTP semantics, not a promise that a particular client or cache stores or follows the response.

Status	Follow-up method	Heuristic freshness
301 Permanent	A user agent may change POST to GET.	Yes; lifetime is cache-dependent unless explicit freshness is set.
308 Permanent	Must preserve the method.	Yes; lifetime is cache-dependent unless explicit freshness is set.
302 Temporary	A user agent may change POST to GET.	No by default; explicit cacheability can allow storage.
303 See Other	Follow with a retrieval (GET or HEAD); not the same action.	No by default; explicit cacheability can allow storage.
307 Temporary	Must preserve the method.	No by default; explicit cacheability can allow storage.

All storage and reuse still depend on the request method, directives, matching conditions, and implementation. Use an explicit max-age or Expires when a bounded lifetime matters; set s-maxage when shared caches need a separate lifetime. no-cache allows storage but requires validation. no-store prohibits storage of the new exchange; it does not delete an older redirect.

Checklist: locate the old target

Record the exact starting URI, method, time, browser/profile, and whether navigation was typed, clicked, reloaded, or restored with Back/Forward.
For every hop, record request URI and method, status, raw and resolved Location, and the next request.
Capture cache metadata for each redirect response: Cache-Control, Expires, Date, Age, validators, Vary, Cache-Status, and documented hop fields when present.
Keep 304 responses with the matching stored response and validator. A 304 reuses a stored response; it is not a new redirect carrying a changed target.
If no network request occurred, check history or application/service-worker state before calling it an HTTP redirect-cache hit.
Use positive named-hop evidence. Age is not cache identity, and a missing header does not prove a miss.

Stop at the evidence boundary: if only the final URL is known, the source hop is unknown. If an old Location is visible but no cache evidence identifies its supplier, report the hop but leave the cache layer unknown.

Choose policy for the route

Route need	Starting choice	Limit
Stable permanent move	Use 301 if its method behavior is acceptable; use 308 when the method must be preserved. Set an explicit lifetime if stale-target duration must be bounded.	A route rollback can remain hidden while a prior redirect is fresh. No universal cache eviction time exists.
Temporary or changeable target	Use 302 or 307 as method requirements allow. Set short explicit freshness or require validation with `no-cache`.	Short freshness narrows future reuse; it does not remove older copies. Consider `s-maxage` for a separate shared-cache limit.

See the dated research report for the full expected/unexecuted scenario matrix and source ledger. For layer attribution beyond redirects, use Serving-layer diagnosis.