301 vs 302 Redirects — Getting This Wrong Costs You Rankings
Redirects seem trivial. A status code, a Location header, done. But the difference between a 301 and a 302 isn't semantic — it has real effects on how search engines transfer link equity, how browsers cache responses, and how your analytics attributes traffic.
Get it wrong on a site migration and you can tank months of SEO in a weekend. Get it right and the transition is invisible. To quickly confirm whether a URL returns the expected redirect response, you can use our URL Redirect Checker.
The Redirect Status Codes and When to Use Them
301 Moved Permanently — The resource has permanently moved. Browsers cache this response indefinitely. Search engines transfer link equity to the destination URL. Use for: permanent URL changes, domain migrations, HTTP to HTTPS, www to non-www consolidation.
302 Found (Temporary Redirect) — The resource is temporarily at another location. Browsers don't cache this. Search engines continue indexing the original URL. Use for: A/B testing, maintenance pages, temporary campaign redirects, geo-based routing where you want the canonical URL preserved.
307 Temporary Redirect — Like 302 but explicitly preserves the HTTP method. A POST to a 307-redirected URL will POST to the destination, not convert to GET.
308 Permanent Redirect — Like 301 but preserves HTTP method. The semantically precise alternative to 301 for cases where you're permanently redirecting non-GET requests.
303 See Other — POST-to-GET redirect. After a form submission, redirect to a confirmation page using 303 to prevent duplicate form submissions on browser back/refresh.
The SEO Consequences of Using the Wrong One
From Google's perspective:
A 301 tells Googlebot the old URL is permanently gone. Eventually it stops crawling the old URL and updates its index to point to the destination. Link equity from inbound links pointing to the old URL transfers to the new one over time.
A 302 tells Googlebot the original URL is still canonical. It keeps indexing the source URL. Link equity stays at the source. The destination doesn't benefit from it.
If you use a 302 when you mean a 301 on a permanent migration, your old URLs stay indexed and your new ones inherit no authority. This can take months to recover from.
One common trap: "I'll use 302 for now and switch to 301 later." The problem is that 301 responses get cached by browsers indefinitely. Users who visited before won't re-request the redirect — they'll go straight to the cached destination. This makes 301s harder to change than 302s. If you're not sure, decide before you deploy.
Redirect Chains — A Silent Performance Problem
A redirect chain is A → B → C when it should be A → C. Each hop adds latency and slightly dilutes link equity passing through.
Common causes: • Old 301s pointing to URLs that were later redirected again • Adding an HTTPS redirect on top of an existing www redirect, creating HTTP → HTTPS → www chains • CMS migrations that stack redirect layers without cleaning up old ones
Each redirect in the chain is a full HTTP round trip — typically 100–300ms depending on server location. A 3-hop chain adds up to 900ms of pure latency before the browser sees a single byte of content.
Check your chains from the terminal: curl -IL https://old-url.com 2>&1 | grep -E "HTTP|Location"
Trace full redirect chains and see every hop instantly
Try URL Redirect Checker Free →Implementation Examples
NGINX
# Permanent redirect return 301 https://new-domain.com$request_uri;# HTTP to HTTPS server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; }
Apache .htaccess
Redirect 301 /old-page /new-pageRewriteEngine On RewriteCond %{HTTP_HOST} ^www\.example\.com [NC] RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
Next.js
// next.config.js redirects: async () => [{ source: '/old-path', destination: '/new-path', permanent: true, }]