Choosing between the types of redirects is a five-second decision that determines whether a URL keeps its rankings or throws them away. There are only a handful worth knowing, they behave differently in browsers and in Google’s index, and the difference between a 301 and a 302 has cost more sites more traffic than almost any other technical mistake.
Here is the short version before the detail: use a 301 when the change is permanent, a 302 or 307 when it genuinely is not, and avoid meta refresh and JavaScript redirects unless you have no server access at all. Everything below explains why.
Server-side redirects: the 3xx status codes
A server-side redirect is an HTTP response with a 3xx status and a Location header pointing at the new address. No page content is sent. The browser follows the header, and so does every crawler. These are the redirects that matter for SEO because they are fast, unambiguous, and visible to a crawler without rendering anything.
They are also cheap. A 3xx response is a few hundred bytes and no database work, so a well-built redirect map costs users almost nothing in load time. Compare that to a client-side redirect, which requires downloading and parsing a full HTML document before the browser learns it is going somewhere else.
You can see one on the command line in a second:
curl -sIL https://example.com/old-page | grep -E "HTTP/|location"301 Moved Permanently
The workhorse. A 301 says the resource has moved for good and the new URL should replace the old one everywhere — in bookmarks, in link equity, in the index. Google treats it as a strong canonicalization signal and consolidates ranking signals onto the destination.
Use it for domain changes, HTTP to HTTPS, www standardization, permanent URL restructures, retiring duplicate pages, and merging thin content into a stronger page. Two cautions. Browsers cache 301s aggressively, sometimes indefinitely, so a mistaken one is painful to unwind for real users even after you fix the server. And a 301 to an irrelevant destination — every retired product dumped on the homepage — is treated as a soft 404 and passes nothing. Redirect to the closest genuine equivalent or let it 410.
How long should you keep a 301 in place? Indefinitely, if you can. Google generally stops checking the old URL after a while, but external links and old bookmarks keep sending real people for years. Removing redirect rules is a cleanup task with no upside and a clear downside.
302 Found and 307 Temporary Redirect
Both signal a temporary move. The original URL stays canonical, and Google keeps indexing it rather than the destination. Use them for A/B tests, short promotional takeovers, a page down for maintenance, and geo or device routing where the source URL remains the real address.
The technical difference is method handling. A 302 historically allowed browsers to convert a POST into a GET when following it; 307 forbids that and preserves the original method and body. For a plain GET page redirect they behave identically, but 307 is the strictly correct choice for anything involving form submissions or APIs.
Worth knowing: Google has said that if a 302 stays in place long enough, it will eventually be treated much like a 301 and the destination becomes canonical. Do not rely on that. Leaving a permanent move on a 302 for months means you spend that time with signals split and rankings soft.
308 Permanent Redirect and 303 See Other
A 308 is to 301 what 307 is to 302: permanent, but guaranteed to preserve the HTTP method. Google treats 308 the same as 301 for indexing. It is the right choice for permanent API endpoint moves and anywhere POST integrity matters. For ordinary page moves, 301 remains the safer default simply because every intermediary on the internet has handled it for thirty years.
A 303 See Other explicitly converts the follow-up request to a GET. Its real home is the post-form-submission pattern that stops a refresh from resubmitting an order. It has essentially no SEO application, and you should not see it on content URLs.
Client-side redirects: meta refresh and JavaScript
These happen after the page loads rather than before, which is exactly why they are second-class.
A meta refresh sits in the HTML head:
<meta http-equiv="refresh" content="0;url=https://example.com/new-page/">Google can follow an instant meta refresh and generally treats it like a permanent redirect, but it is slower for users, it is not a real HTTP signal, and any delay above zero seconds is treated as a temporary redirect at best. A delayed refresh with an interstitial is also an accessibility problem.
JavaScript redirects — window.location.href = "..." — are followed by Google only after the page renders, which is a separate and slower pass than crawling. They work, but they add latency, they fail entirely if the script errors, and they are invisible to any tool that does not execute JavaScript. Use them only when you control nothing but the page body, and replace them with a server redirect the moment you can.
Choosing quickly: a decision list
- Is the move permanent and the content equivalent? 301.
- Permanent, but the request method must survive? 308.
- Genuinely temporary, source URL stays canonical? 307 (302 is acceptable).
- Content is gone with no equivalent? Do not redirect. Return 410 Gone, or 404, and update internal links.
- Duplicate content that must stay reachable by users? Not a redirect at all — use a canonical tag.
- No server access whatsoever? Instant meta refresh, as a temporary measure.
Redirect hygiene that actually costs rankings
Choosing the right status code is half the job. The other half is what happens after months of accumulated changes.
Chains are the biggest offender: A redirects to B, B to C, C to D. Every hop is an extra request, extra latency for users, and extra crawl cost. Google will follow a reasonable number of hops but stops well before ten. Flatten chains by pointing every legacy URL directly at the current final destination.
Loops are worse and fully break the page — that is the “too many redirects” error users hit in the browser. They usually come from two rules fighting each other, typically an HTTPS rule and a www rule applied in the wrong order.
Internal links pointing at redirects are pure waste. If your own navigation links to a URL that 301s, fix the link. External links you cannot control; your own you can.
Auditing this at scale needs a crawler that follows and reports every hop, because chains are invisible one URL at a time. SEO Rocket’s technical audit crawls full sites — verified past 900 pages — and reports evidence per issue: the actual redirecting URLs, their targets, and the titles and tags on both ends, so you can hand a developer a precise list instead of a summary. It does not deploy redirects or edit your server config; the rules stay in your .htaccess, nginx config, or CDN. It also reports PageSpeed and Core Web Vitals with real-user field data, which is where redirect latency shows up as a measurable LCP cost.
One last expectation to set. After a large redirect project, rankings on the new URLs typically settle over several weeks, with daily movement of two or three positions along the way that means nothing. Judge the migration on indexation and traffic trends after a month, not on what you see the following morning.
