I previously moved `site.com/page` from a Next.js site to WordPress and configured a permanent redirect to `page.site.com`. We now want to restore the original URL. The redirect has been removed, but Chrome still sends me to the subdomain with a `308 Permanent Redirect (from disk cache)` more than a week later. I realize a normal redirect back could create a loop because the browser is replaying the cached redirect. Is there a reliable way to recover the original URL without renaming it?
3 Answers
There is no universal way to force every browser to forget a permanent redirect. Existing visitors may need to clear their cache, wait for the cached entry to expire, or use a different URL. Since you control the subdomain, a temporary redirect from it back to the original page with a harmless query parameter is usually the safest recovery path.
A cached 301 or 308 cannot reliably be removed from someone else’s browser just by deleting the server-side redirect. For users who already cached it, the practical workaround is to redirect `page.site.com` back to a slightly different URL, such as `https://site.com/page?from=subdomain`, using a temporary redirect and `Cache-Control: no-store`. The query string gives the browser a different cache key, so it can load the page instead of replaying the old redirect. Keep the clean URL as the canonical URL, and leave the workaround in place while old caches expire.
For future redirects, use a 302 or 307 while the change is still reversible. Once you are certain, you can replace it with a 301 or 308. If you do use a permanent redirect, set an appropriate cache policy such as a limited `max-age`; `no-store` is useful for temporary recovery redirects. Also update the restored page’s canonical tag to `https://site.com/page` so search engines do not treat the query-string version as a separate canonical URL.
This is mainly a returning-browser problem. Search engines will eventually recrawl and update their redirect information, but that does not clear a 308 already stored in a user’s browser.
Keep testing with a browser profile that already has the old redirect cached, as well as with a clean browser or `curl`. A redirect loop workaround is unpredictable and shouldn’t be relied on in production.