Which 3xx Redirect Should You Use for SEO?

When people ask which redirect is best for SEO, they are usually asking the wrong question slightly.

The right question is not "which redirect does Google like best?" The right question is:

What are you trying to tell browsers, search engines and other clients about the old URL?

If the old URL is permanently gone and the new URL should replace it, use a permanent redirect. In most website and SEO work, that means a 301. A 308 can also be correct, especially in modern infrastructure, but 301 is still the safest default for normal page migrations.

If the move is temporary and the old URL should remain the main URL, use a temporary redirect. In most normal web page cases, that means a 302. A 307 can also be correct when preserving the original request method matters.

If you are redirecting after a form submission, payment flow or API action, the SEO answer may not be the right answer. You may need 303, 307 or 308 depending on how the request method should be handled.

This article is written from the practical SEO and migration point of view. It covers what each 3xx redirect means, which one to choose during a site migration, where teams get it wrong, and how to test redirect behaviour before and after launch.

The short answer

For normal SEO and website migration work:

For SEO migrations, the boring answer is usually the correct one:

Use 301 redirects for permanent URL moves. Map old URLs to the most relevant new URLs. Avoid chains. Avoid loops. Do not redirect everything to the homepage.

What a 3xx redirect actually tells a client

A 3xx response tells the client that more action is needed. For redirects, the server usually sends a Location header pointing to another URL.

A simplified response looks like this:

The client then decides whether to request the new location.

That matters because a redirect is not magic. It is an instruction. Browsers, crawlers, monitoring tools, APIs and URL checkers all interpret that instruction according to the status code and their own behaviour.

For SEO, the status code communicates intent:

• Permanent redirects say the new URL should replace the old one.

• Temporary redirects say the old URL should remain valid.

• Method-preserving redirects say the client should not change the request method when following the redirect.

Google's own redirect guidance separates permanent redirects from temporary redirects and describes permanent redirects as a stronger signal that the target should be shown in Search, while temporary redirects are weaker signals and may keep the source URL in results.

That is why choosing the right redirect code is less about superstition and more about making your intent clear.

301 Moved Permanently

A 301 means the resource has moved permanently.

This is the main redirect for SEO migrations. Use it when the old URL should no longer be used and the new URL should become the preferred address.

Use 301 for:

• Old page to new equivalent page.

• Old domain to new domain.

• HTTP to HTTPS migrations.

• Changing URL structures.

• Consolidating duplicate pages.

• Moving from /old-product/ to /new-product/.

• Removing file extensions such as .html when the page still exists.

• Standardising www or non-www.

• Standardising trailing slash behaviour.

A clean 301 helps users, search engines and other clients understand that the move is final. During a migration, this is exactly the signal you usually want.

301 migration example

Old URL:

https://www.example.com/services/seo-consulting.html

New URL:

https://www.example.com/seo-consulting/

Best redirect:

301 old URL to new URL

Not:

301 old URL to homepage

Not:

302 old URL to new URL

Not:

301 old URL to intermediate URL to final URL

The goal is a direct, permanent, page-level redirect to the closest matching new page.

308 Permanent Redirect

A 308 also means the resource has moved permanently. The key difference is that 308 preserves the original request method. If the original request was POST, the redirected request should also be POST.

For normal SEO page redirects, most requests are GET requests, so the practical SEO difference between 301 and 308 is usually small. For APIs and application routes, the difference can matter a lot.

Use 308 when:

• The move is permanent.

• You want method preservation.

• You are redirecting API endpoints.

• Your framework or platform uses 308 for permanent HTTPS or canonical redirects.

• You are confident your clients handle 308 correctly.

Many modern platforms use 308 for permanent redirects because it is more precise than 301 for method handling. In SEO terms, Google documents 308 as a permanent redirect type. The main reason many SEO teams still default to 301 is compatibility, habit and broad familiarity across tools, clients and non-technical stakeholders.

301 or 308 for a normal website?

If you are migrating a normal marketing, ecommerce, blog or service website, I would usually choose 301.

Not because 308 is bad, but because 301 is universally understood in SEO, developer handovers, client reports, CMS plugins, redirect maps and legacy tooling.

If your platform already emits 308 for a clean permanent HTTPS or canonical redirect, that is not automatically a problem. Test it. Confirm it ends correctly. Avoid chains. Make sure the final URL returns 200.

302 Found

A 302 means the resource is temporarily available somewhere else.

Use 302 when the move is temporary and the old URL should remain the main URL.

Good 302 use cases include:

• Temporary campaign routing.

• Short-term landing page swaps.

• A/B tests.

• Temporary product availability pages.

• Temporary maintenance pages.

• Geo or language routing where the original URL remains valid.

• Login or authentication flows where the destination depends on session state.

In SEO migrations, unexpected 302 redirects should be reviewed. If you have permanently moved a page and you use 302, you are sending mixed signals. You are telling clients the move is temporary while expecting search engines to treat the new page as the replacement.

Search engines can sometimes figure things out over time, especially if a temporary redirect stays in place for a long time, but that is not a good migration strategy. Make the intent clear from day one.

302 migration mistake

Old URL:

https://www.example.com/old-category/

New URL:

https://www.example.com/new-category/

If this is a permanent restructure, do not use:

302 old category to new category

Use:

301 old category to new category

A 302 is for "not yet, maybe later". A migration usually says "this is the new address".

307 Temporary Redirect

A 307 is a temporary redirect that preserves the original request method.

For example, if a client sends a POST request, a 307 tells the client to repeat the POST request at the new location. That is different from older 302 behaviour, where clients often convert the follow-up request to GET.

Use 307 when:

• The move is temporary.

• Method preservation matters.

• You are handling application routes or API endpoints.

• You do not want POST to become GET.

For normal SEO page checks, 307 is not usually the first choice. Most public page redirects are GET requests, and most SEO teams are trying to distinguish permanent from temporary moves. In that context, 301 or 302 is usually the more familiar decision.

However, if a platform returns 307 for temporary HTTPS enforcement, maintenance routing or application behaviour, inspect the chain rather than panicking. The main audit questions are:

• Is this temporary behaviour expected?

• Does the final URL return the correct status?

• Is the redirect part of a login, geo, bot protection or app flow?

• Is the redirect appearing on pages that should have a permanent migration redirect?

303 See Other

A 303 tells the client to retrieve another URI using GET. It is commonly used after form submissions or actions where the server wants to redirect the client to a confirmation or result page.

This is not a normal SEO migration redirect.

Use 303 for:

• POST form submission to confirmation page.

• Payment flow to receipt page.

• Application action to status page.

• API patterns where the result should be fetched with GET.

Do not use 303 as your main page migration redirect. If a content URL moved permanently, use 301 or possibly 308.

300, 304, 305 and 306 are not your SEO migration choices

Not every 3xx code is a redirect choice for SEO.

300 Multiple Choices is rarely used for modern SEO migration work.

304 Not Modified is a caching response, not a redirect. It tells the client that the cached representation is still valid.

305 Use Proxy is obsolete in practice and not relevant for normal website migration decisions.

306 is unused and reserved.

When someone asks "which 3xx redirect should I choose for SEO?", they usually mean 301, 302, 307 or 308. In most migration work, the real decision is 301 vs 302, with 308 and 307 appearing because of modern frameworks and method-preserving behaviour.

The migration rule: permanent means permanent

During a website migration, use permanent redirects when the old URL should be replaced.

That includes:

• New domain.

• New CMS.

• New URL structure.

• New page slugs.

• Merged pages.

• Removed old sections with relevant replacements.

• HTTP to HTTPS.

• www to non-www, or the reverse.

The redirect map should be built before launch. Each old URL should be mapped to the most relevant new destination. Do not rely only on broad rules if important pages need page-level decisions.

A good migration redirect is:

old relevant URL > new relevant URL > 200

A weak migration redirect is:

old product URL > homepage > 200

A messy migration redirect is:

old URL > old HTTPS URL > old www URL > new category > new page > 200

A broken migration redirect is:

old URL > new URL > 404

The status code matters, but relevance and final destination matter just as much.

Avoid redirecting everything to the homepage

Homepage redirects are one of the most common migration mistakes.

They are easy to implement. They are also often poor SEO and poor user experience.

If an old page has a clear replacement, redirect it to that replacement. If a product was replaced, redirect to the replacement product. If a service page changed URL, redirect to the new service page. If a blog post has a new equivalent, redirect to it.

If there is no relevant replacement, sometimes a 404 or 410 is cleaner than pretending the homepage is the answer.

A homepage redirect may be acceptable for a small number of truly unmatched URLs, but it should not be the default migration strategy.

Avoid redirect chains

A redirect chain is not automatically fatal, but it is usually a sign that old rules are stacking up.

Example:

Each hop may have made sense at the time, but the better migration rule is usually:

Chains create extra requests, add latency, make debugging harder and increase the chance of failure. They also make reporting messier because teams have to understand the journey, not just the destination.

During a migration, always test redirect count and redirect chain, not just status code.

Be careful with temporary redirects that become permanent by accident

Many teams use 302 during development or staging because they are still testing. That is fine if it stays in staging.

The problem happens when temporary redirects reach production and remain there for months.

A temporary redirect that never changes is a confusing signal. It tells clients that the old URL is still the source of truth, while the site behaves as if the new URL is the source of truth.

If the move is permanent, make it permanent.

Query strings need a decision

Migration redirect maps often forget query strings.

Examples:

Some query strings are important. Some are tracking noise. Some control product or filter behaviour. Some create duplicate content.

Before launch, decide how query strings should behave:

• Preserve them.

• Drop them.

• Map specific parameters.

• Redirect parameterised URLs to clean canonical URLs.

• Return 404 or 410 for obsolete parameter patterns.

Do not let the server make accidental decisions through generic rewrite rules.

Internal links and sitemaps should point to final URLs

Redirects are safety nets, not a substitute for updating the site.

After a migration, update:

• Internal links.

• XML sitemaps.

• Canonical tags.

• Hreflang alternates.

• Navigation.

• Footer links.

• Structured data URLs.

• Open Graph URLs.

• Paid campaign URLs where possible.

• Email templates where possible.

A sitemap full of redirecting URLs tells search engines that your published URL inventory is behind the actual site structure. Internal links that point through redirects waste crawl time and make QA harder.

Use redirects to catch old traffic. Use updated links to show the new structure clearly.

How to choose during common scenarios

Use the intent of the URL change first, then choose the redirect code. Permanent moves usually need 301; temporary routing usually needs 302 or 307; form-style flows may need 303.

New website, same domain, new URL structure

Use 301 redirects from old URLs to the most relevant new URLs.

Test old URLs before launch in staging if possible, then test again immediately after launch.

New domain

Use 301 redirects from old domain URLs to new domain equivalents. Use Google Search Console's site move guidance where applicable. Keep redirects in place long-term.

HTTP to HTTPS

Use a permanent redirect. 301 is the common SEO default. 308 is also a permanent redirect, but confirm your infrastructure and reporting tools handle it cleanly.

Product temporarily out of stock

Usually do not redirect the product page if it is coming back. Keep the page live if possible and communicate availability. If you must redirect temporarily, use 302, not 301.

Product permanently discontinued

If there is a direct replacement, use 301 to the replacement. If there is a close category, decide whether that is genuinely useful. If there is no useful replacement, a 404 or 410 may be more honest.

A/B testing landing pages

Use 302 or another temporary mechanism. Do not use 301 unless the old page has permanently moved.

Form submission to thank-you page

Use 303 where appropriate. This is application behaviour, not an SEO migration redirect.

API endpoint moved

Use 308 if the move is permanent and method preservation matters. Use 307 if the move is temporary and method preservation matters.

A migration QA checklist

Before launch

1. Export current URLs from sitemaps, analytics, backlinks, CMS and crawl data.

2. Build a redirect map.

3. Map old URLs to the closest relevant new URLs.

4. Avoid one-size-fits-all homepage redirects.

5. Decide query-string handling.

6. Test redirect rules in staging where possible.

7. Check for chains and loops.

8. Confirm new URLs return 200.

9. Check canonicals on final URLs.

10. Prepare a post-launch scan list.

After launch

1. Scan old URLs.

2. Filter 3xx, 4xx, 5xx, Failed and loop rows.

3. Review final URLs and redirect chains.

4. Confirm old URLs do not redirect through unnecessary hops.

5. Confirm sitemap URLs are final canonical URLs.

6. Confirm important pages do not return temporary redirects by mistake.

7. Tag issues by type and owner.

8. Export developer and SEO reports.

9. Rescan fixed URLs.

10. Keep monitoring Search Console, logs and analytics.

Decision table

That table is not theoretical. It is how I would approach a real migration redirect plan.

Testing matters more than arguing about 301 vs 308

In SEO discussions, teams can spend too long debating whether 301 or 308 is "better" while ignoring the problems that actually hurt migrations:

• Wrong final URLs.

• Redirects to the homepage.

• Chains.

• Loops.

• Temporary redirects left in production.

• Old URLs in sitemaps.

• Canonicals pointing to redirected URLs.

• Important pages returning 404.

• Blocked URLs.

• Noindex on final pages.

• Query strings handled badly.

A clean 301 to the wrong destination is still wrong. A 308 to the right destination may be perfectly fine. A 302 used permanently is unclear. A long chain that eventually ends in 200 still needs cleanup.

Redirect quality is not just the status code. It is intent, relevance, directness and final state.

Use URL Verifier Pro to test the redirect plan

URL Verifier Pro is built for this kind of redirect QA. Import your old URL list, run the scan, then review status codes, final URLs, redirect counts and redirect chains in one table. Filter the problem rows, tag issues such as wrong destination, temporary redirect, chain or loop, add notes for developers and export a focused CSV report.

For a migration, the most useful workflow is simple:

1. Scan the old URLs.

2. Review the final destinations.

3. Fix the redirect rules.

4. Rescan only the affected rows.

5. Export the remaining issues.

If you are choosing redirects for a new site launch, the code choice is only step one. The real work is proving that every important old URL lands on the right new URL with the fewest possible hops.

References

• Google Search Central: Redirects and Google Search

• Google Search Central: Site moves with URL changes

• RFC 9110: HTTP Semantics

• RFC 7538: HTTP Status Code 308 Permanent Redirect

• IANA HTTP Status Code Registry