301 vs 302 vs 307 vs 308 Redirects: Which One to Use and When

Use a 301 or 308 when a URL has moved for good, and a 302 or 307 when the move is temporary and the original URL will come back. The difference inside each pair is the request method: 307 and 308 guarantee the browser repeats the same method (a POST stays a POST), while 301 and 302 allow clients to switch to GET. For ordinary page moves on a website, a 301 is still the safe default.

Key takeaways

• Permanent move: 301 (or 308). Temporary move: 302 (or 307).
• Google treats 301 and 308 as permanent and 302 and 307 as temporary for indexing purposes.
• 307 and 308 matter mainly for forms and APIs, where the request method must not change.
• Avoid redirect chains and loops; point every old URL straight at its final destination.
• Keep redirects in place for a long time after a migration, ideally at least a year.

The four redirect codes at a glance

All four send a Location header telling the client where to go next. The status code tells the client (and search engines) how to treat that new location.

What "permanent" and "temporary" mean for SEO

When Google sees a permanent redirect, it takes that as a strong signal that the target URL should become the canonical one shown in search results. Over time, the old URL drops out of the index and the new one replaces it. A temporary redirect is a weaker signal: Google is more likely to keep the original URL indexed because you have told it the original will return.

That said, Google has said it looks at the overall picture. If a "temporary" 302 stays in place for a long time and everything else points at the new URL, Google may eventually treat the target as canonical anyway. Do not rely on that. Pick the code that describes what you actually mean.

Google documents its handling of each redirect type in its redirects and Google Search guide.

When to use a 301

A 301 fits nearly every permanent change on a normal website:

• You renamed a page: /services-old to /services.
• You moved from HTTP to HTTPS.
• You picked one hostname, such as example.com instead of www.example.com.
• You merged two thin articles into one stronger article.
• You moved the whole site to a new domain.

Browsers cache 301s aggressively, sometimes indefinitely until the cache is cleared. That is good for speed but painful if you made a mistake, so test before you deploy a permanent redirect on an important URL.

When to use a 302

Use a 302 when the original URL is coming back:

• A product is out of stock and you send visitors to a category page for a few days.
• You are running a short campaign and want /offer to point at this month's landing page.
• You send logged-out users from /account to /login.
• You are redirecting based on language or location and want the original URL to stay indexed.

A common mistake is using a 302 for a permanent move simply because it is the default in a framework or plugin. Many server-side frameworks issue a 302 unless you ask otherwise. Check what your CMS or code actually sends.

When 307 and 308 are the right choice

The original HTTP specification for 301 and 302 did not let clients change the method, but browsers did it anyway, turning POST requests into GET requests after a redirect. The 307 and 308 codes were added to remove that ambiguity: the client must repeat the same method and body.

This matters when:

• A form posts to /contact/submit and you move that handler. With a 301, the browser may follow with a GET and the form data is lost. A 308 keeps the POST.
• An API client sends PUT or DELETE requests to an endpoint you are relocating.

For ordinary page-to-page redirects that only receive GET requests, 301 and 308 behave the same in practice, as do 302 and 307. Either is fine; 301 and 302 have the broadest support across older tools and crawlers.

The 307 you did not configure

If you check your site in browser developer tools and see a "307 Internal Redirect" from HTTP to HTTPS, that is usually the browser applying HSTS (HTTP Strict Transport Security) on its own, not your server. To see what your server actually returns, test with a tool that does not use your browser cache, such as the Server Status Checker, or with curl -I.

How to set up redirects

Apache (.htaccess)

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

# Force HTTPS and non-www in one hop
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

nginx

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

location = /old-page/ {
    return 301 /new-page/;
}

location = /api/v1/orders {
    return 308 /api/v2/orders;
}

If you are writing rewrite rules for dynamic URLs, the URL Rewriting Tool can generate the .htaccess pattern for turning query-string URLs into clean ones.

What a redirect response looks like

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/
Cache-Control: max-age=3600

Redirects to avoid

Chains

A chain is when URL A redirects to B, which redirects to C. Every hop adds a round trip for users and another request for crawlers. Google follows a limited number of hops (its documentation mentions up to 10) before giving up, but you should aim for one. After a migration, update old rules so they point straight at the final URL.

Bad:  http://www.example.com/page -> https://www.example.com/page -> https://example.com/page
Good: http://www.example.com/page -> https://example.com/page

Loops

A loop is when A redirects to B and B redirects back to A. Browsers stop and show a "too many redirects" error. Loops often appear when a CMS setting and a server rule disagree about www versus non-www, or HTTP versus HTTPS behind a proxy or CDN.

Redirecting everything to the home page

When you delete a lot of pages, it is tempting to send all of them to the home page. Google may treat redirects to an unrelated page as soft 404s, so you gain little. Redirect to the closest relevant page, and let truly gone pages return a 404 or 410.

Meta refresh and JavaScript redirects

Google can follow both, but server-side redirects are clearer for every client and are processed faster. Use meta refresh or JavaScript only when you have no access to server configuration.

How to check your redirects

1. Check the hostname variants. Test http://example.com, http://www.example.com, https://www.example.com and https://example.com. Three should redirect, in one hop, to the fourth. The www Redirect Checker does this quickly.
2. Check the status code of key old URLs. Confirm each returns 301 (or 308) for permanent moves, not 302.
3. Check the destination. The final URL should return 200, not another redirect or a 404.
4. Update internal links. Redirects are a safety net; your own navigation and content should link straight to the new URLs.
5. Update your XML sitemap so it lists only final, 200-status URLs.

How long to keep redirects

Keep permanent redirects for as long as you reasonably can. Google's site-move guidance suggests keeping them for at least a year, and external backlinks and bookmarks can keep sending people to old URLs for many years after that. A redirect rule costs almost nothing to maintain, so there is rarely a good reason to remove it.

Quick checklist

• Moved for good? 301 (or 308 for non-GET requests).
• Coming back? 302 (or 307 for non-GET requests).
• One hop from any old URL to its final destination.
• No loops, and no blanket redirects to the home page.
• Internal links and sitemap updated to the new URLs.
• Redirect rules kept for at least a year, ideally longer.