What happens if I change a 301 to a 302?

Every client that has not seen the redirect before receives the 302 and treats the move as temporary.

Search engines re-evaluate on their next crawl of that URL and begin indexing the source again rather than the target, on their own schedule.

Shared caches and CDNs holding the 301 continue to serve it until their entry expires or is purged, which is one purge away from being fixed.

Monitoring and link checkers report the new code immediately, because they do not keep a redirect cache between runs.

Anything that stored the target rather than the redirect — a bookmark updated by the browser, a link someone copied from the address bar — keeps pointing at the destination regardless of the code.

Browsers that cached the 301. The whole point of a permanent redirect is that the client stops asking, so it never learns you changed your mind.

How long that lasts depends on the cache lifetime that was in force when the 301 was served, and on the browser's own policy. It can be months.

You cannot invalidate it remotely. There is no header that reaches a client which is not making the request.

The documented way to unwind it is to serve a 200 at the old URL and wait for each cached entry to expire — which means the old URL has to have content again.

Search engines that already consolidated the old URL into the target do not instantly reverse either; they re-evaluate, which is a process rather than a switch.

A permanent redirect is a promise that the old address is finished. Clients are entitled to act on it by not asking again, and that is what makes it efficient.

A temporary redirect makes no such promise, so clients re-check every time. That is why it is safe and why it costs a request per visit.

The efficiency and the irreversibility are the same property viewed from two sides.

This is the practical argument for using 302 while a decision is still open: promoting it to 301 later is free, and demoting a 301 is not.

A migration that is being rolled back, where the old URLs are becoming real again.

A redirect published in error, where the sooner the signal is corrected the less of the index is affected.

A seasonal or campaign destination that was marked permanent by accident.

In each case, accept that the correction lands unevenly: crawlers and new visitors get it now, and a share of returning visitors will not for a while.

A staged rollout where the permanent form was applied before the destination was final, which is the situation this whole asymmetry exists to warn about.

Purge the CDN, which is the one cached layer you control.

Make the old URL serve real content again if it is meant to be a destination, rather than leaving it as a redirect nobody can escape.

Update internal links, the sitemap and the canonical tags to name the URL you now want indexed. The redirect alone is a weak signal when everything else disagrees.

Expect search results to lag by weeks rather than days, and avoid changing the signals again in the middle — that restarts the process.

Communicate it to anyone watching analytics: traffic will appear to move between two URLs for a period, and that is the correction working rather than a fault.

`curl -sIL https://example.com/old | grep -iE '^(HTTP|location)'` shows the code you are actually sending, which is not always the code the configuration implies.

Check from a client that never visited the site, and from a private browser window, to separate your own cached copy from the server's behaviour.

VeriFixScan reports `transport.redirect_chain` with the status of every hop it followed, so a mixed chain of 301 into 302 is visible as such.

No external check can report what is sitting in a visitor's browser cache. That population is only visible as traffic that keeps arriving at the old destination.