301 vs 302 Redirects: Which to Use and How Google Treats Them

A redirect looks like a small server setting, but the status code you pick tells browsers and search engines two different things: whether the old URL is gone for good, and whether they should change how they repeat the request. Pick the wrong one and Google may keep showing a URL you retired, or treat a temporary detour as the page's new home.

The short version: 301 means moved permanently, 302 means moved temporarily. But there are five redirect codes in everyday use, plus meta refresh and JavaScript redirects, and each behaves a little differently in Google Search, in browsers and in HTTP caches.

This guide explains what each code means according to the HTTP specification, how Google documents its handling of them, why permanent redirects are hard to undo, and how to set up clean HTTP→HTTPS and www moves. It ends with a decision guide and a checklist you can use before any redirect goes live.

301, 302, 303, 307 and 308 at a glance

All five codes send the client to the URL in the Location header. They differ on two questions: is the move permanent, and may the client change the request method when it follows the redirect? The definitions come from RFC 9110, HTTP Semantics; Google's handling comes from its status code documentation.

Google adds a useful reminder: although it treats 301 and 308 the same, and 302 and 307 the same, the codes are semantically different, and you should use the one that fits so other clients, such as other search engines, can benefit.

How Google treats permanent and temporary redirects

Google's redirects documentation puts the difference in one line each: permanent redirects show the new redirect target in search results; temporary redirects show the source page. Behind that, Googlebot follows both kinds. What changes is the indexing pipeline: a permanent redirect is used as a signal that the target should become canonical, a temporary one is not.

Google also keeps track of both URLs. One becomes the canonical and the other an alternate name, and alternate names can still appear when a searcher's query suggests they trust the old URL more. After a domain move, Google says, seeing old URLs in results now and then is normal and fades over time.

Why 307 and 308 exist

RFC 9110 explains the history. Early browsers disagreed on whether to resend a POST as a POST or as a GET after a 301 or 302, and practice settled on GET. The specification now allows that for 301 and 302, and 307 and 308 were added to unambiguously preserve the method. MDN notes that browsers following the Fetch Standard change a POST to GET after a 301 or 302. For ordinary pages requested with GET, 301 and 308 behave the same; for forms and APIs, the method-preserving codes avoid lost request bodies.

One caution from the RFC itself: 308 is much younger (June 2014) than its siblings and "might not be recognized everywhere". For plain page moves, 301 is the conservative choice.

Meta refresh and JavaScript redirects

When you can't change the server, HTML and JavaScript offer fallbacks. Google documents how it reads them:

• Instant meta refresh (content="0; url=…") is interpreted as a permanent redirect. A delayed meta refresh is interpreted as temporary. The same applies to the HTTP Refresh header.
• JavaScript redirects are seen only after Google renders the page, and rendering can fail. Google says to use them only if you can't do server-side or meta refresh redirects.
• A "crypto redirect", a visible "We moved" link, is a last resort that not all search engines treat as a redirect.

<!-- Instant meta refresh: Google treats it as permanent -->
<meta http-equiv="refresh" content="0; url=https://www.example.com/new-page">

<!-- JavaScript: only if nothing else is possible -->
<script>
  window.location.href = "https://www.example.com/new-page";
</script>

Don't stack methods. MDN's guide to redirections notes that HTTP redirects run first, JavaScript next and meta refresh last, and that leaving an old HTML redirect behind after changing the server one can cause loops.

Chains, loops and the one-hop rule

Every hop costs a round trip. Google's crawlers follow up to 10 redirect hops, but its site move guide advises redirecting to the final destination directly and, if that isn't possible, keeping chains low, "ideally no more than 3 and fewer than 5", because chains add latency and not all browsers support long ones. When Google gives up, Search Console's Page indexing report shows a Redirect error: a chain that was too long, a redirect loop, a URL that grew past the maximum length, or a bad or empty URL in the chain.

For comparison, here is a real, clean setup. On 2026-10-31 we traced the four protocol and host variants of the W3C's home page with Backlnk's Redirect & HTTP Header Checker. http://w3.org/, https://w3.org/ and http://www.w3.org/ each answered with a single 301 straight to https://www.w3.org/, which returned 200. No variant needed a second hop.

1. http://w3.org/301, one hop
2. https://www.w3.org/200 OK, final URL for all four variants

Loops are the extreme case: A redirects to B, which redirects back to A. MDN notes that browsers detect them and show an error, so visitors can't reach the page at all. They typically appear right after a configuration change, for example when a CDN and the origin server each force a different host.

HTTP to HTTPS and www moves, done in one hop

Any site can be requested in four variants: http:// and https://, each with and without www. Google's advice is to pick one as the canonical and redirect the others to it. The goal is that every variant reaches the canonical host in a single permanent redirect, keeping the path and query string.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # plus your ssl_certificate and ssl_certificate_key lines
    return 301 https://www.example.com$request_uri;
}

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com
    # plus your SSLEngine and certificate lines
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

NGINX's return directive accepts a redirect URL for codes 301, 302, 303, 307 and 308 (ngx_http_rewrite_module). Apache's Redirect directive appends the rest of the requested path to the target, so /old-page lands on https://www.example.com/old-page; the Apache documentation recommends this virtual host approach for canonical hostnames over mod_rewrite.

Two more points for these moves. Google says a Change of Address in Search Console isn't needed for HTTP→HTTPS or www/non-www switches, only for moves between domains or subdomains. And once a browser has received a Strict-Transport-Security header over HTTPS, MDN explains that it upgrades later http:// requests for that host to HTTPS itself, before contacting the server. Your HTTP redirect still matters for first visits and for every client that hasn't stored the policy.

Permanent means cached: undoing a wrong 301

RFC 9110 says a 301 and a 308 are "heuristically cacheable": unless explicit cache controls say otherwise, a browser or proxy may store the redirect and reuse it without asking your server again. MDN's own example 301 response carries cache-control: max-age=2592000,public, which is 30 days. If you publish a permanent redirect by mistake and then remove it, returning visitors can keep landing on the wrong URL for as long as their copy stays fresh.

Backlnk's practice for risky changes, such as a new domain or a restructured URL scheme:

• Be sure before you go permanent; if the old URL may come back, use 302 or 307.
• During rollout, send an explicit, short lifetime on the redirect response, then lengthen it once the mapping is confirmed.
• Test with a client that doesn't reuse your browser's cache, such as a private window or curl.

$ curl -sI http://example.com/old-page
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/old-page
Cache-Control: max-age=3600

Choosing the right code

Work through these questions in order; the first one that applies decides.

1. Is the page gone with no equivalent replacement? Don't redirect it. Return 404 or 410. Google's site move guide warns that redirecting many old URLs to one irrelevant page, such as the home page, can confuse users and may be treated as a soft 404.

2. Is this a test? If an A/B test sends users from the original URL to a variant, Google's testing guidance says to use a 302, not a 301, so the original stays in the index.

3. Is the old URL coming back? Maintenance, a seasonal page, a temporarily unavailable service: use 302, or 307 if forms or API calls must keep their method.

4. Are you redirecting after a form submission? Use 303 so the follow-up request is a GET and reloading the result page doesn't resubmit the form.

5. Has it moved for good? Use 301, or 308 when clients send POST or PUT to the URL. Google's site move guide says to keep these redirects for as long as possible, generally at least one year.

Redirect checklist

• Every old URL reaches its final URL in one hop, with the path and query string preserved where they matter.
• The status code matches the intent: 301 or 308 for permanent, 302 or 307 for temporary.
• All protocol and host variants end at the same canonical URL.
• The destination returns 200, is indexable and declares itself as canonical.
• Internal links, canonical tags and sitemap entries point to final URLs, not to redirects.
• No old HTML or JavaScript redirect conflicts with the server redirect.
• Important URLs are checked with URL Inspection after launch.

Trace your redirects with Backlnk

Backlnk's free Redirect & HTTP Header Checker does the tracing for you. Enter a URL and it follows the full chain hop by hop, with the status code and timing of each hop, and it also tests the http:// and www or non-www variants of the host (up to six traces in all). The report checks for loops, HTTPS→HTTP downgrades, temporary codes and whether all variants end at the same URL; it compares the final URL with the canonical, and reviews X-Robots-Tag, caching, compression and security headers such as HSTS and Content-Security-Policy.

Chains with more than one hop are flagged as a Backlnk heuristic, not because Google rejects them. The headers are observed from Backlnk's crawler; a CDN can answer differently by region or user agent, so confirm important results with URL Inspection in Search Console.

Next step

Run your home page and your most-linked old URLs through the Redirect & HTTP Header Checker and fix any chain longer than one hop or any temporary code on a permanent move. If Search Console lists URLs as Page with redirect or Redirect error, our guide to finding why a page is not indexed explains what those statuses mean and how to confirm the fix.