301 vs 302 Redirects: Which to Use and When

A 301 or 308 signals a permanent move; a 302, 303, or 307 signals a temporary one. Google treats these signals as part of its canonicalization process, but the status code alone does not guarantee which URL appears in search. Use a permanent redirect when the move is lasting and a temporary redirect when the original URL is expected to return.

What is a redirect?

A redirect sends a browser or crawler from one URL to another, usually through a 3xx response with a Location header. For search engines, permanent and temporary redirects provide different signals about the move. Google’s redirect guidance explains how it handles common redirect types.

Google treats a permanent redirect as a strong canonical signal. It is generally appropriate when a page has moved for good, while a canonical tag is useful when both URLs should remain accessible. Redirect hygiene is one part of a technical SEO audit and deserves attention during a migration.

Quick facts

Why do redirects matter for SEO?

When a page moves, a relevant redirect helps visitors using old links reach the new page and gives search engines a signal about the URL change. If the old URL simply returns a 404, bookmarks and external links still point to the unavailable address. A redirect does not guarantee that rankings or every signal transfer unchanged, so map each old URL to its closest useful destination.

What redirects protect

• External link value. Links you spent months earning keep working. This is why redirects matter more the more backlinks a page has.
• Existing rankings and indexed positions during a migration.
• User experience. A visitor from an old link reaches content rather than an error.
• Crawl efficiency. Clean redirect maps stop crawlers looping through dead paths.

Expert note on link equity: Google treats permanent redirects as a strong signal that the target should be canonical. Its public guidance does not promise a fixed amount of PageRank transfer, so avoid guarantees or percentages. Google’s current redirect documentation does not discuss PageRank transfer at all. Treat “301s lose link juice” as an unverified legacy claim, and treat “redirects preserve signals” as the documented working principle. Either way the practical advice is identical: redirect to the closest relevant page, in one hop.

How do redirects work?

1. A client requests /old-page/.
2. The server responds with a 3xx status and Location: https://example.com/new-page/.
3. The client requests the new URL and receives the content with a 200.
4. Search engines process the redirect and use its permanence signal alongside other canonical signals.
5. After recrawling, Google may update the URL it shows for a permanent move.

This takes time. Google must recrawl the old URL to see the redirect, which on a low-traffic page can be weeks. Keep redirects in place for at least a year after a migration, and preferably permanently.

Redirect status codes compared

For ordinary content pages, 301 and 302 cover nearly every case. 307 and 308 matter where the HTTP method must survive the redirect, which is mostly APIs and form handlers rather than blog posts.

Non-HTTP redirect methods

Server-side HTTP redirects are the only reliable method. Everything else is a fallback for environments where you cannot touch the server configuration.

How to set up a redirect

Step 1: Map old URLs to the closest relevant destination

Build a two-column list before touching any configuration. Every redirect should land on the page most closely matching what the visitor expected. Redirecting everything to the homepage is treated as a soft 404, and Google may drop the old URLs rather than transfer their signals.

Step 2: Choose the status code

Permanent move, page will not return: 301. Temporary maintenance, A/B test, seasonal page, or geographic diversion: 302. If you cannot articulate when the original URL is coming back, the answer is 301.

Step 3: Implement it

Apache (.htaccess):

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

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Nginx:

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

WordPress: Rank Math and Redirection both provide a redirect manager in the dashboard. Plugin redirects are processed by PHP rather than the web server, which is slightly slower, but for a handful of rules the difference is negligible. For thousands of rules, or for site-wide protocol and host rules, do it at the server level.

Step 4: Eliminate chains

A chain is A to B to C. Each hop adds latency and gives Google another opportunity to stop following. Google will follow a small number of hops, but the correct target is always one hop. When you add a new redirect, update every existing rule that pointed at the old intermediate URL so it points directly at the final destination.

Step 5: Update internal links

Redirects are for external links and bookmarks you cannot control. Your own links should point at the final URL directly. Leaving internal links pointing at redirects slows every page load and muddies your internal linking structure. Search and replace them in the database.

Step 6: Update your sitemap and canonicals

Remove redirected URLs from your XML sitemap and make sure no canonical tag points at a redirected URL. Both are common leftovers after a migration.

Step 7: Verify

Check the response headers directly, not just what the browser shows:

curl -sIL https://example.com/old-page/ | grep -E "HTTP/|location"

You want to see one 3xx followed by one 200. Then watch the Pages report in Search Console for “Page with redirect” counts and any rise in soft 404s.

Redirects in a site migration

Migrations are where redirect discipline pays for itself. A practical sequence:

1. Crawl the live site and export every indexable URL before making changes.
2. Export the top landing pages by clicks from Search Console; these matter most.
3. Export the pages with the most referring domains; these carry the most external value.
4. Map every one of them to a destination, individually where traffic justifies it and by pattern rule elsewhere.
5. Deploy the redirects at the same moment as the new site, not afterwards.
6. Recrawl the old URL list on launch day and fix any that return 404 or land on a chain.
7. Submit the new sitemap and keep the old one available briefly so Google recrawls the old URLs and discovers the redirects.
8. Monitor Search Console weekly for eight weeks.

Common redirect mistakes

301 vs 302 vs canonical vs 410

Decision guide

• URL changed permanently: 301.
• Site moving to https or to a new domain: 301, applied as a site-wide rule.
• Product temporarily out of stock: keep the page live with stock status; do not redirect at all.
• Seasonal page returning next year: 302, or better, keep the page live and update it.
• A/B test on two URLs: 302.
• Two similar pages both needed: canonical tag, not a redirect.
• Page deleted with no equivalent: 410 Gone, or a 404. Do not force a redirect to an unrelated page.

Redirect audit checklist

• All permanent moves return 301 or 308, verified in response headers
• No redirect chains longer than one hop
• No redirect loops
• Every redirect destination returns 200 and is indexable
• No mass redirects to the homepage
• Internal links updated to final destinations
• Redirected URLs removed from the sitemap
• No canonical tags pointing at redirected URLs
• Old URLs not blocked in robots.txt
• http to https and www consolidation handled at server level
• Migration redirects retained for at least twelve months
• Search Console soft 404 count stable after deployment

Frequently asked questions

Does a 301 redirect pass full link value?

Google’s redirect documentation does not quantify PageRank transfer, and Google describes redirects as signals that help consolidate signals to a target; it does not specify a fixed transfer amount. The widely repeated 15 percent loss figure is not documented guidance. Treat signal preservation as the working assumption, and prioritise relevance of the destination over arithmetic.

How long should I keep redirects in place?

Minimum one year after a migration; permanently if the rules cost nothing to maintain. External links to old URLs can persist for a decade.

Is a 302 ever the right choice?

Yes, when the original URL is genuinely coming back: maintenance windows, A/B tests, short-term geographic routing. If you cannot name a return date, use a 301.

Do redirects slow down my site?

Each hop adds a round trip. A single redirect is negligible; chains are measurable and can affect Core Web Vitals on entry pages. Keep internal links pointing at final URLs.

Should I redirect a deleted page or let it 404?

Redirect only if a closely equivalent page exists. Otherwise return 404 or 410. Irrelevant redirects are treated as soft 404s and gain you nothing.

What is the difference between 301 and 308?

Both are permanent and both are treated the same by Google for canonicalisation. 308 preserves the HTTP method, which matters for POST requests. For content pages, 301 remains the conventional choice.

Can I redirect http to https and www to non-www in one rule?

Yes, and you should. A single combined rule avoids the classic two-hop chain of http to https then www to non-www.

How fast does Google process a redirect?

It must recrawl the old URL first. High-traffic pages may update within days; rarely crawled pages can take weeks or months.

Key takeaways

• 301 and 308 are permanent; Google indexes the destination.
• 302, 303, and 307 are temporary; Google keeps indexing the source.
• Redirects are the strongest canonicalisation signal Google recognises.
• Always redirect in one hop to the closest relevant page.
• Never mass-redirect to the homepage; Google reads it as a soft 404.
• Update internal links, sitemaps, and canonicals after redirecting.
• Use server-side redirects; JavaScript and meta refresh are unreliable fallbacks.
• Keep migration redirects for at least a year.

Conclusion

When a URL changes, choose a redirect that matches the move, map it to the closest useful destination, and avoid chains. Then verify the response headers and update your internal links, sitemap, and canonical tags. Google may take time to recrawl the old URL and process the change.

Related articles

• Technical SEO guide
• Canonical tags and duplicate content
• Noindex vs nofollow vs disallow
• Robots.txt explained
• XML sitemaps explained

External references

• Google Search Central: Redirects and Google Search
• Google Search Central: Consolidate duplicate URLs