Introduction

A migration can look broken even after the server-side redirect has already been fixed. That happens when browsers or intermediate caches keep honoring an older 301 Moved Permanently response they stored earlier. The result is that some users continue getting sent to the wrong domain, scheme, or path while fresh sessions behave normally. The fix is to prove whether the redirect is still live at the server or only cached on the client side, then clear the right layer.

Symptoms

  • Some users still get redirected to an old domain after a migration
  • Incognito mode or a different browser behaves correctly while the normal browser does not
  • Direct server checks show the redirect was already removed or updated
  • Only one device or network keeps following the old redirect path
  • The problem started after a hostname, HTTPS, or canonical redirect change

Common Causes

  • The old redirect was sent as a 301 and cached aggressively by browsers
  • A CDN or intermediary proxy cached the previous permanent redirect
  • Multiple redirect layers were changed, but one cache still serves stale responses
  • HSTS or canonical host policies make the redirect appear harder to remove
  • Teams assume DNS is wrong when the real issue is cached redirect history

Step-by-Step Fix

  1. Reproduce the issue in a normal browser session and compare it with an incognito or new-device test.
  2. Inspect the current live response with redirect tracing tools so you can see whether the origin or CDN still returns a 301 now.
  3. If the live response is already corrected, treat the issue as a caching problem rather than making more redirect changes.
  4. Clear or bypass CDN and proxy caches that may still be serving the old permanent redirect.
  5. Ask affected users to test in a clean browser session or after clearing site data if only their local browser still follows the stale route.
  6. Review the migration history for overlapping redirect rules at the CDN, load balancer, application, and web server layers.
  7. Avoid flipping the redirect repeatedly, because each permanent change increases confusion about which layer owns the final behavior.
  8. If the redirect must remain temporary during rollout, use a temporary status where appropriate until the migration path is stable.
  9. Document the canonical redirect owner for future migrations so old 301 rules do not linger in browsers and caches longer than expected.