301 vs 302: which redirect and when
One question decides it, and it is not a technical one. Everything else on this page is the consequence of getting that answer right or wrong.
A 301 is permanent and a 302 is temporary. Use 301 when the old URL is never coming back, because search engines treat it as a signal to show the new URL in results and to consolidate signals onto it. Use 302 when the original will return, because the source URL stays the one that is indexed.
- 301
- Moved permanently. Cached hard by browsers. The target becomes the indexed URL.
- 302
- Found, meaning temporary. The source stays the indexed URL.
- 307 and 308
- The same two intentions, with the request method guaranteed not to change.
- The deciding question
- Is the old URL ever coming back? That is the whole decision.
What a redirect is, precisely
A redirect is a response the server sends instead of a page: a status code in the 3xx range and a Location header naming where to go instead. The browser follows it without asking. That is the difference between a redirect and every other instruction in this area, and it is worth holding onto, because it is why a redirect cannot be outvoted the way a canonical tag can.
The status code carries the intent. 301 says this URL has permanently moved. 302 says it is temporarily elsewhere and this address is still the right one. Both send the visitor to the same place and they say opposite things to everything that keeps a record.
Google is explicit about the consequence: permanent redirects show the redirect target in search results, and temporary redirects show the source page. That single sentence is the whole reason the choice matters, because it decides which of the two URLs is the one people find.
The question that decides it
Is the old URL ever coming back? If no, 301. If yes, 302. Everything below is the consequence of that answer, and almost every wrong redirect on the web is somebody having never asked it.
Cases that are permanent, and should be 301: a page that moved, a domain migration, http to https, apex to www or the other way, a merged pair of pages, a retired product pointing at its replacement, a URL structure change. If you are confident the redirect will not be reverted, it is permanent.
Cases that are temporary, and should be 302: A/B testing where the original must keep its position, a page down for maintenance, geolocation or language routing at the front door, a seasonal campaign taking over a URL for a month, a product briefly out of stock and pointing at its category.
The one that catches people out is the last of those. A 301 from a product to its category, applied while the item is out of stock, tells search engines to replace the product URL with the category one. When the stock returns, the product page has to be rediscovered and re-earned. A 302 would have held its place.
Where 307 and 308 come in, and why they exist
Both are stricter versions of the two above, and the difference is about the request method rather than about permanence.
In practice, browsers implementing 301 and 302 have historically rewritten a POST into a GET when following the redirect. That behaviour was widespread enough to become expected, and it is technically a violation of what those codes are supposed to mean. 307 and 308 were defined to close that gap: 307 is a temporary redirect and 308 a permanent one, and both guarantee the method and the body are preserved.
For ordinary page redirects on a website, this rarely matters, and 301 and 302 remain the codes everybody reads and expects. Where it does matter is APIs and form submissions, where turning a POST into a GET loses the request body and produces a bug that only appears behind a redirect somebody added for an unrelated reason.
Search engines treat 308 like 301 and 307 like 302. Google lists all four in the same table, split by permanence rather than by method.
Chains, loops and the things that go wrong after the redirect is correct
The choice of code is the easy half. The failures that survive in production are structural.
Chains
A redirects to B redirects to C. Every hop is a round trip for the visitor and a cost for the crawler, and each one is a place for a later change to break the chain in the middle. Redirect to the final destination, and update the old rules rather than adding new ones in front of them.
Loops
A sends to B and B sends back to A, and the browser gives up with an error. Usually two rules written months apart by people solving different problems, and usually invisible until one specific entry path hits it.
Redirecting everything to the homepage
The lazy fix for a migration, and it is treated as a soft 404: the target does not answer the question the old URL did. Map old URLs to their real equivalents, and let the ones with no equivalent return 410 or 404 honestly.
Redirecting to a URL that is then canonicalised elsewhere
A redirect pointing at a page whose canonical names a third URL is two instructions in different directions. Land redirects on pages that canonicalise to themselves.
Leaving redirects in the sitemap
A sitemap listing URLs that redirect asks a crawler to spend its budget rediscovering what you already told it. The sitemap should list destinations only.
The practical reason to be careful with 301
A 301 is cached hard. Browsers remember it aggressively and will stop asking your server about that URL at all, sometimes long after you have changed your mind. This is the reason to be certain before using one, and it is a stronger reason than anything about rankings.
The failure looks like this: a 301 is deployed by mistake, someone notices within the hour and reverts it, and the people who visited in that hour keep landing on the wrong page for days with no way to explain it. Their browser is not asking. A hard refresh clears it for one person who knows to try.
If there is any doubt, ship a 302, confirm the behaviour is what you wanted, and promote it to a 301 afterwards. Going from temporary to permanent is a routine change. Going the other way is a change your visitors' browsers may not hear about.
Every redirect method, side by side
Six ways to send somebody somewhere else. The first four are status codes and are the only ones worth reaching for by default.
| Method | Means | What search engines do with it | Use when |
|---|---|---|---|
| <b>301</b> | Moved permanently | Show the target in results and consolidate onto it. | The old URL is not coming back. |
| <b>302</b> | Found, temporarily elsewhere | Keep showing the source in results. | The original will return. |
| <b>308</b> | Moved permanently, method preserved | Treated as a permanent redirect, like 301. | A permanent move on a POST endpoint. |
| <b>307</b> | Temporary, method preserved | Treated as a temporary redirect, like 302. | A temporary move on a POST endpoint. |
| meta refresh | Redirect written into the HTML | Zero seconds reads as permanent; longer reads as temporary. | You cannot configure the server. Rarely otherwise. |
| JavaScript | Redirect performed after the page loads | Only seen by something that executes scripts, which is not everything. | Last resort, when nothing else is available. |
Prefer a status code every time you can. A meta refresh or a script redirect asks the client to do work before the redirect exists, which means a fetcher that does not render never learns about it at all. The render gap checker shows you which half of your page survives that distinction.
Implementing one without creating three problems
Redirects accumulate. A rule added today outlives the person who added it, so the discipline is in the audit trail as much as in the code.
- 01
Answer the permanence question first, in writing
Is the old URL ever coming back? Note the answer next to the rule. Six months later, nobody remembers whether a redirect was meant to be temporary, and the default assumption is always wrong in at least one direction.
- 02
Redirect to the specific equivalent, not to the homepage
A URL with no real equivalent should return 404 or 410 rather than being swept into the homepage. An honest 404 is a clean signal; a redirect to something unrelated is a soft 404 that wastes a crawl and confuses a visitor.
- 03
Collapse chains as you add rules
When B starts redirecting to C, update the rule that sends A to B so it sends A to C. Adding rules in front of rules is how a site ends up with five hop chains that nobody dares touch.
- 04
Do it at the edge where you can
A redirect in a CDN or web server config is faster than one in application code and it works even when the application is down. It is also the layer most likely to be forgotten during a migration, so it belongs in the migration checklist rather than in somebody's memory.
- 05
Update the sitemap, the internal links and the canonical
A redirect is not finished while your own site still links to the old URL. Internal links should point at destinations directly, so no visitor and no crawler pays for a hop that exists for external links.
- 06
Keep them, and review them
Redirects from a migration are load bearing for years, because external links do not update. Removing them to tidy up is how a site loses the value of a migration it already paid for.
How to check what a URL actually returns
One command answers most of this. curl -sIL https://example.com/old-page prints every hop with its status code, so a chain, a loop and a wrong status code are all visible in the output rather than inferred from behaviour. A browser hides all of it: it follows the chain and shows you the destination, which is exactly the information you do not need.
The three things to look for. The status code on the first hop, which is the intent you actually shipped. The number of hops, because more than one means a chain to collapse. And the final URL, which should be the page you meant and should canonicalise to itself.
That last check is the one people skip, and it links the two halves of this subject. A redirect landing on a page whose canonical tag names a third URL is two instructions pointing in different directions, and the resolution is not yours to make. Our canonical checker reads the destination's tag and resolves it.
At scale, this is a crawl rather than a check. Redirect faults are properties of rule sets, so they cluster: one bad rule affects a whole section, and finding it means comparing what a site links to against what those URLs return. That is what the full audit does across a site rather than one URL at a time.
The neighbouring checks worth running
A redirect question is almost never alone. These are the four that decide whether the redirect you just fixed is doing what you think.
Related reading: what a canonical tag is, the technical SEO checklist, the robots.txt generator, what an SEO audit actually checks.
Questions people ask about redirects
What is the difference between a 301 and a 302 redirect?
A 301 says the move is permanent and a 302 says it is temporary. Both send a visitor to the same place. They differ in what is recorded: a permanent redirect makes the target the URL shown in search results, while a temporary one keeps showing the source. Browsers also cache a 301 far more aggressively.
Which redirect is better for SEO?
Neither is better. They express different intentions, and the correct one is whichever is true. A 301 where the page will return costs you the original URL. A 302 on a permanent move leaves search engines showing an address you have abandoned. The question to answer is whether the old URL is ever coming back.
Do 301 redirects pass link equity?
Google describes a permanent redirect as a strong signal that the target should be the canonical URL, and the signals associated with the old URL consolidate onto the new one. The practical version: a correctly implemented permanent redirect keeps the value of the links pointing at the old address, and a chain of several hops is worth avoiding regardless.
What is a 307 redirect?
A temporary redirect that guarantees the request method is preserved. Browsers following a 301 or 302 have historically turned a POST into a GET, which loses the request body. 307 and its permanent counterpart 308 were defined to remove that ambiguity, and they matter most on APIs and form endpoints rather than on ordinary pages.
How long should I keep a redirect in place?
Indefinitely, in practice. External links to the old URL never update, so a redirect from a migration keeps earning for years, and removing it to tidy up throws away value the migration already paid for. Review them to collapse chains, not to delete them.
Are redirect chains a problem?
Yes, in two ways. Every hop is a round trip for a visitor and a cost for a crawler working to a budget, and each additional link is somewhere a future change can break the chain in the middle. Point the first URL at the final destination and update the old rule rather than stacking a new one in front of it.
Should I redirect old pages to my homepage?
No. A redirect to a page that does not answer the same question is treated as a soft 404, and it is a worse experience than an honest error page for somebody who followed a specific link. Map old URLs to their genuine equivalents and let the rest return 404 or 410.
Is a meta refresh redirect bad?
It works and it is a fallback rather than a choice. A zero second meta refresh is read as a permanent redirect and a delayed one as temporary, but it requires the HTML to be fetched and parsed before the redirect exists, which is slower and less reliable than a status code. Use it when you genuinely cannot configure the server.
How do I check what a URL redirects to?
Run curl with the head and location flags, which prints every hop and its status code. That shows you the first status code, the number of hops and the final destination, all three of which a browser hides by silently following the chain and showing you only where it ended up.
Check where your URLs actually end up
The audit follows what your pages link to, reports the status each URL returns, and reads the canonical on the destination so you can see whether the redirect and the tag agree. Free, no card, and it takes about a minute.