Changed a 301 redirect, but the browser stubbornly keeps sending visitors to the old URL? A familiar headache for anyone who has configured site migrations or restructured links.

The issue is neither the server nor WordPress. The browser permanently remembers a permanent redirect and does not query the server again; that is how the HTTP specification works. Until the cache expires or the user clears it manually, the old rule remains in effect.

Below is a clear strategy: how to test redirects without consequences, why 302 saves your nerves during debugging, and what to do if the cache is already stuck for real visitors.

💡 Quick overview:

• Always start with 302 (temporary), test, and only then switch to 301 (permanent)
• Clear your browser cache every time you change redirect rules
• For Chrome: DevTools → Network → Disable cache, or Application tab → Clear site data
• If a 301 is already cached by users, you can only wait or change the destination URL

How the browser caches a 301 redirect

When the server responds with a 301 Moved Permanently status, the browser interprets it literally: "this URL has moved forever." It stores the pair "old URL → new URL" in its own redirect cache, separate from the page and image cache.

The next time the user (or you, the developer) opens the same address, the browser does not send a request to the server at all. It immediately substitutes the saved destination URL from the cache. The server sees no request, and you do not see the current behavior.

The HTTP specification does not define a strict retention period for such a cache. In practice, Chrome, Firefox, and Safari keep 301 in the cache until explicitly cleared. The server's Cache-Control header may be ignored by the browser specifically for 301, because "permanently" means permanently.

This behavior is a feature, not a bug. It saves a round-trip for legitimate permanent moves (for example, a domain change). However, during development, it becomes a trap.

Why this causes problems during configuration

Imagine a scenario. You are setting up a redirect from the old URL /old-page to /new-page. You configure a 301, test it in the browser, and it works. An hour later, you realize you made a mistake: the correct URL is /new-page/v2.

You change the rule on the server and hit "refresh" in the browser. You land on /new-page. Again. Because the browser already remembered the first pair and does not give the server a chance to show the new rule.

You think the redirect is not working. In reality, it is working, just not the one you just configured.

On a test site, we once spent half an hour cycling through .htaccess rules before realizing the browser was showing the cache. Cleared the cache, and everything immediately worked as intended.

The situation is worse with visitors. If you activated an incorrect 301 on a production site, everyone who visited during those minutes received the wrong rule in their browser's cache. You fixed the error on the server in 10 minutes, but their browsers will continue sending them to the old URL for days or weeks, until the cache is cleared.

Note: you cannot clear the redirect cache on the user's side. No server trick can reach someone else's browser.

The 302 → 301 strategy: test without consequences

A rule that saves hours of debugging and protects against mistakes on a live site:

Always start with a 302 (temporary) redirect. Switch to 301 only after you are confident the rule is correct.

The browser does not cache 302 aggressively; it queries the server anew with each request. Change the rule on the server, and the browser immediately picks up the new behavior. No cache clearing needed.

Step-by-step approach for any URL change:

• Set up a 302 redirect in .htaccess, Nginx configuration, or via a WordPress plugin (for example, Redirection).
• Open the old URL in incognito mode or with the "Disable cache" option enabled in DevTools.
• Confirm you land on the correct destination page.
• Check 2-3 additional URLs from the same group.
• Only when everything is tested, replace 302 with 301 in the rules.
• Do a final check in normal browser mode.

In practice, this approach takes exactly two extra minutes per redirect group and completely eliminates the risk of a "cached error" for visitors.

If you use the Redirection plugin for WordPress, it creates 301 by default. Manually switch to 302 in the dropdown when creating a rule, and do not forget to switch back to 301 after testing.

How to clear the redirect cache locally

When the browser has already remembered an incorrect 301 and you cannot see the current behavior, here is what helps:

Chrome. Open DevTools (F12), go to the Network tab, and check Disable cache. Or do a full reset: Application → Clear storage → Clear site data. The most reliable method for a specific site is chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. For a complete clear: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (the Develop menu is enabled in Settings → Advanced).

Incognito mode is a quick way to check fresh behavior without clearing the main cache. The browser uses a clean session with no saved redirects.

Important nuance: closing the browser does NOT clear the 301 redirect cache. Unlike session storage, the redirect cache survives browser restarts. Only explicit clearing or incognito mode works.

What to do if the cache is stuck for users

This is the most unpleasant scenario: an incorrect 301 was active on the production site for some time, and part of your audience now carries it in their browser caches. You fixed the server rule, but these users keep landing in the wrong place.

Here is what you can do:

• Change the destination URL to a new one. If the old location pointed to /page-v1 and you need /page-v2, simply replace the address in the same rule. Browsers with the old destination URL cached will continue going there (the problem). However, new visitors will go to the right place. This does not solve the problem for those already "infected," but it stops the spread.

• Use a different redirect method. If 301 is cached, the browser does not query the server, but server logic still works for new visitors. Add a JavaScript redirect on the destination page as an additional layer on top of the HTTP redirect for those who still land on the old page.

• Honestly acknowledge: there is no direct cure. You cannot reach the user's browser. If the cache is already loaded, the only way to reset it is if the user clears the cache or visits via an incognito link. Fortunately, the redirect cache does not live forever: browser reinstallation, device changes, and OS updates eventually reset it.

In our experience, an incorrect 301 becomes critical only in two cases: a mass migration (hundreds of URLs) with an error in the rules, or a redirect of the homepage. In both cases, the damage from a cached error outweighs any time saved by skipping testing.

301, 302, 307, 308: when to use what

To avoid confusion, keep this quick redirect code table handy:

For a WordPress site, knowing the difference between 301 and 302 is sufficient in the vast majority of cases. Codes 307 and 308 are niche tools for situations where preserving the HTTP method is critical (for example, a form must remain a POST request and not turn into GET during a redirect).

In short: 302 is your working tool during development. 301 is the final "done" stamp.

One more trap: WordPress and caching plugins

On WordPress, the 301 caching problem stacks on top of server and plugin caching. A typical situation:

You edit a redirect in the Redirection plugin, click "save," and it does not work. You clear the browser cache, and still the old page appears. What is happening? A caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) served a cached version of the page; the server never even executed the redirect rule.

Steps for debugging redirects on WordPress:

• Clear the caching plugin cache (each plugin has its own "Purge All Cache" button).
• Disable caching during testing (in WP Rocket, this is Development Mode).
• Clear the browser cache (as described above).
• Only then test the redirect.

On a test site, we keep the caching plugin disabled until all redirects are fully ready and enable it only after the final switch from 302 to 301.

This short English video visually demonstrates the difference between 301 and 302 in practice and explains why the redirect code choice affects SEO:

⁉️🤔 Frequently asked questions

Why does the browser cache 301 instead of querying the server each time?

The HTTP specification defines 301 as "the resource has moved permanently." Querying the server every time the URL is opened would contradict the meaning of "permanently" and create unnecessary load. Caching the redirect saves one HTTP request per visitor. At a scale of tens of thousands of visits, this noticeably speeds up navigation. The browser caches the redirect fact itself (the "from → to" pair), not the page content. This is a separate type of cache called redirect cache. Chrome stores it in the user profile; Firefox stores it in the places.sqlite file along with navigation history. That is why clearing the image and script cache does not always reset redirects; you need a full clear or clearing site data.

Can you prevent the browser from caching 301 on the server side?

Formally, no. Browsers may ignore the Cache-Control: no-store header for permanent redirects. The specification does not require browsers to honor Cache-Control for 301/308, since a permanent redirect implies the rule will not change. Some versions of Chrome and Firefox respect Cache-Control for 301, but you cannot rely on this in production; the behavior is not guaranteed and varies between versions. The only reliable way to "undo" browser caching of a 301 is to initially use 302 during testing. If a 301 is already cached by the user, the server is powerless.

How does 302 differ from 307 in practice?

Both are temporary redirects, and neither is cached by the browser. The difference lies in HTTP method handling. With 302, the browser may change a POST request to GET during the redirect (this happened historically, and many browsers still do it). With 307, the method is guaranteed to be preserved: POST stays POST, PUT stays PUT. For WordPress and virtually any site, the difference is negligible since redirects almost always involve GET requests (page opening). 307 is needed only if forms, APIs, or file uploads go through a URL you are temporarily redirecting.

How can I check which redirect is cached in my browser?

Open DevTools (F12) → Network tab, and check "Disable cache" (this is MANDATORY, otherwise the browser will not make a request to the server and you will not see the current response). Then open the old URL. In the Status column, you will see the actual response code from the server (301, 302, etc.) and the Location header with the destination URL. Without "Disable cache," DevTools will show a 200 status or (disk cache), meaning the browser served from cache and the server was not queried.

Do you need to keep a 301 redirect forever?

Google recommends keeping permanent redirects for at least a year after a move. In practice, if the old URL is no longer promoted, has no external links, and is not indexed, the redirect can be removed after 6-12 months. However, if other sites linked to the old URL or it is present in search engine indexes, you should keep the redirect permanently. Removing a 301 with a rule cached by users will not solve the problem; their browsers will continue using the cached pair until they clear the cache.

Should you be afraid of 301 redirects?

No, if you follow the "302 first" rule. A permanent redirect is a reliable tool for moving content, changing domains, and cleaning up duplicates. Problems only arise when 301 is set up without testing.

Remember the key point: 301 is a promise to the browser that "I will not change my mind." Do not make that promise until you are certain. Ten minutes testing a 302 redirect in incognito will save days of cleaning up cached errors for your live audience.