301 vs 302 Redirects: Which One Should You Use?

A redirect sends visitors and crawlers from one URL to another. You'll need them whenever you rename a page, merge content, move to HTTPS, or change domains. The status code you choose tells browsers and search engines whether the move is permanent or temporary, and that affects which URL Google shows in its results.

This guide explains the five HTTP redirect codes, how Google treats each one, when to use which, and how to avoid the chains and loops that quietly slow sites down.

The five redirect status codes#

The HTTP redirect codes are defined in RFC 9110, the current HTTP semantics specification. Two questions separate them: is the move permanent or temporary, and may the browser change the request method, for example from POST to GET?

For ordinary pages that people and crawlers load with GET requests, the method question doesn't matter much. It matters for forms and APIs: if a form submits with POST to a URL that has moved, a 307 or 308 keeps it a POST, while a 301 or 302 may not.

RFC 9110 also notes that 301 and 308 responses are cacheable by default. Browsers can remember a permanent redirect and skip the original URL on later visits, which is one reason to be sure before you set one.

How Google treats redirects#

Google's documentation on redirects and Google Search groups redirects into two kinds.

Permanent redirects#

301 and 308 server-side redirects, instant meta refresh redirects, and JavaScript location redirects are treated as permanent. Google takes them as a strong signal that the redirect target should be the canonical URL, and it shows the new URL in search results.

Temporary redirects#

302, 303 and 307 server-side redirects, and meta refresh or HTTP refresh redirects with a delay, are treated as temporary. Google generally keeps showing the source URL in results, because you've said the move isn't lasting.

For search engines, 301 and 308 are equivalent, and 302 and 307 are equivalent. Choose between each pair based on whether you need the request method preserved.

Keep in mind that a redirect is a strong canonicalization signal, but not the only one. Internal links, sitemaps and canonical tags should all point to the same final URL so every signal agrees.

Which redirect should you use?#

The most common mistake is using a 302 for a move that's actually permanent, usually because it's a framework or plugin default. If the old URL is never coming back, use a permanent redirect.

A note on 307 you may see in browser developer tools: when a site uses HSTS, browsers upgrade http:// requests to https:// internally and label that as a 307 Internal Redirect. It's generated by the browser, not your server, so crawlers don't see it. Check your server's actual response with a tool instead.

Meta refresh and JavaScript redirects#

Server-side redirects are the most reliable, because every client sees the status code before any content loads. Sometimes you can't set them, for example on some hosted platforms. Google's guidance for the alternatives:

• Instant meta refresh (content="0") is treated as permanent.
• Delayed meta refresh is treated as temporary.
• JavaScript redirects should be a last resort, used only if you can't do server-side or meta refresh redirects, because they depend on the page being rendered.

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

Redirect chains and loops#

A chain is a series of redirects before the final page:

http://example.com/old-page
  -> 301 https://example.com/old-page
  -> 301 https://www.example.com/old-page
  -> 301 https://www.example.com/new-page/

Chains usually build up over the years: an HTTPS migration, then a www change, then a page rename. Google's documentation on HTTP status codes says its crawlers follow up to 10 redirect hops, so a short chain won't stop crawling. But every hop adds a round trip for every visitor, and long chains are fragile.

A loop is a chain that never ends:

/page-a -> 301 /page-b
/page-b -> 301 /page-a

Browsers show an error such as "too many redirects", and crawlers give up.

How to fix chains#

1. Find chains with our Redirect Checker, which shows every hop with its status code.
2. Update each old redirect to point directly at the final URL.
3. Update internal links so they point at the final URL and don't trigger redirects at all.

You can also check a single URL from the command line:

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

The -L flag follows redirects and -I requests headers only, so you'll see each status code and Location header in order.

Redirects during a site migration#

Redirects are the backbone of any migration. Google's guide to moving a site with URL changes recommends:

1. Map every old URL to its new URL. Use your sitemap, server logs and analytics to build the list, and prioritize pages with traffic and backlinks.
2. Use server-side permanent redirects from each old URL to its specific new equivalent.
3. Keep the redirects in place for as long as possible, generally at least a year.
4. Update internal links to the new URLs, then scan your key pages with our Broken Link Checker to catch any that now lead to errors.
5. Submit a new sitemap listing the new URLs.
6. Use the Change of Address tool in Search Console if you're moving to a new domain. It isn't needed for HTTP-to-HTTPS or www changes on the same domain.

A mapping spreadsheet can be as simple as this:

Implementation examples#

Apache (.htaccess)#

# Single page
Redirect 301 /old-page/ https://www.example.com/new-page/

# Whole folder, keeping the rest of the path
RedirectMatch 301 ^/blog/(.*)$ https://www.example.com/articles/$1

nginx#

location = /old-page/ {
    return 301 https://www.example.com/new-page/;
}

# Force HTTPS for all requests
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

On hosted platforms and CMSs, use the built-in redirect manager or a well-maintained plugin rather than editing server files.

Common redirect mistakes#

• Redirecting everything to the homepage. When old pages have no real equivalent, sending them all to the homepage confuses visitors, and Google may treat those redirects like soft 404s. Redirect to the closest relevant page, or let truly gone pages return 404 or 410.
• Using 302 for permanent moves. Check the defaults in your CMS or plugin.
• Leaving chains after migrations. Flatten them.
• Removing redirects too soon. Old URLs keep getting visits from bookmarks and backlinks long after a migration.
• Redirecting to pages that are blocked or noindexed. Every signal should point to the page you want indexed.

Quick answers#

Does a 301 pass link value? Yes. Links pointing to the old URL continue to benefit the new one. That's why reclaiming links to deleted pages with redirects works. See how to check backlinks.

Is 308 better than 301? For search engines they're treated the same. Use 308 when you need to preserve the request method.

Should I redirect my broken pages? Only when a relevant replacement exists. Our guide on how to fix broken links walks through the decision.

Choose the code that honestly describes the move, point every redirect straight at its final destination, and keep permanent redirects in place long after the change. That covers the vast majority of redirect problems.