Redirects

A redirect is an HTTP response that tells a browser or crawler to fetch a different URL. Used correctly, redirects move users and crawlers cleanly from one URL to another while preserving SEO equity. Used badly, they are one of the most common causes of catastrophic ranking loss during site migrations.

What are the four redirect status codes?

301 Moved Permanently. The original URL has permanently moved to the new URL. Search engines transfer ranking signals to the new URL and update the index over time. Use for permanent migrations: URL structure changes, domain changes, page consolidations.

302 Found. The original URL has temporarily moved. Search engines retain the original URL in the index and treat the destination as temporary. Use for genuinely temporary redirects: A/B tests, geo-routing, maintenance pages.

307 Temporary Redirect. Functionally identical to 302 in modern usage, but enforces the request method. A POST request redirected with 307 stays a POST; redirected with 302, browsers historically converted to GET.

308 Permanent Redirect. The HTTP/1.1 equivalent of 307: permanent and method-preserving. Less commonly used but appropriate for permanent redirects of non-GET requests.

For SEO purposes, the practical distinction is between 301/308 (permanent) and 302/307 (temporary). All four pass ranking signals; the difference is how strongly each one argues that the destination should be the canonical URL. Google’s status-code documentation makes it a difference of degree rather than of kind: a 301 is used as a “strong signal that the redirect target should be canonical”, a 302 or 303 as a “weak” one, with 307 equivalent to 302 and 308 to 301.¹ So a temporary redirect does not pin indexing to the original URL; it argues less forcefully for the destination, and Google notes the target “might still be indexed if other canonicalization signals are present”.² The default for any URL change you intend to keep is 301.

When should you use 301 redirects?

• Page renamed or moved. /old-url/ to /new-url/.
• HTTP to HTTPS migration. All HTTP URLs redirect to HTTPS equivalents.
• WWW to non-WWW (or vice versa). Pick one canonical, redirect the other.
• Trailing slash standardisation. /page to /page/ (or vice versa, depending on convention).
• Site migration to new domain. Each old URL maps to its new equivalent.
• Page consolidation. Multiple thin pages redirected into a single comprehensive page.
• Removed content with a relevant alternative. Better than a 404 when a meaningful equivalent exists.
• A dead URL that still has inbound links. The highest-return case, because the link already exists and only the connection is broken. Broken link reclamation covers how to find these.

When NOT to redirect

To handle a typo where no real content exists. A 404 is more honest. Redirecting all 404s to the homepage gives a worse user experience than a proper 404 page.

To sweep a set of retired URLs into the homepage. Google’s site move guidance is explicit: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.”³ Redirecting several URLs into one page is fine when that page genuinely consolidates their content, which is the difference between consolidation and disposal.

To consolidate genuinely different content. Redirecting a product page to an unrelated category page, just to capture a 404, is a soft 404 in disguise. Google treats it as such.

For minor URL variations that should be canonicalised. Tracking parameters and similar variations are better handled with canonical tags than redirects.

Common redirect problems

Most redirect faults produce no error at deploy time. The rule saves, the build passes, and nothing tells you that the page is unreachable or that the old URL is still the one Google has indexed. These are the faults worth testing for by default.

Redirect chains

A redirect chain occurs when one redirect leads to another, which leads to another. Each hop adds latency and crawl overhead.

/old-url-1/ → 301 → /old-url-2/ → 301 → /current-url/

Individual 30x redirects do not lose PageRank, so a chain does not bleed a fixed percentage of equity per hop.⁴ The real risks are latency for users and crawlers, and Google’s hop limit: it follows only up to roughly 10 redirects in a chain before it stops.¹ Google’s own advice is stricter than its limit, recommending you redirect to the final destination directly and, where that is not possible, keep the chain to “ideally no more than 3 and fewer than 5”.³

Common sources of unintentional chains:

• HTTP→HTTPS redirect followed by trailing-slash redirect followed by content URL change
• Old redirects from previous migrations that were never consolidated
• CDN-level redirects layered on top of application-level redirects

Audit chains regularly; tools like Screaming Frog report them clearly.

Redirect loops

A redirect loop is two or more URLs that redirect to each other:

/page-a/ → 301 → /page-b/ → 301 → /page-a/

Nothing loads. Browsers follow a fixed number of hops and then give up: the Fetch Standard specifies that if a request’s redirect count reaches 20, the browser returns a network error,⁵ which Chrome surfaces as ERR_TOO_MANY_REDIRECTS. Users see an error page rather than a slow one, so a loop on a template-wide rule is an outage, not a degradation. Googlebot stops in the same way, and a URL it cannot reach cannot stay indexed.

Loops come from rules that disagree with each other rather than from a single bad rule:

• Two layers fighting. A CDN rule and an application rule that redirect in opposite directions.
• Trailing slash rules in conflict. One rule appends a slash, another strips it.
• Case normalisation applied inconsistently. One rule lowercases the path, another sends the mixed-case version back.
• Flexible SSL behind a CDN. Cloudflare fetches your origin over HTTP, the origin redirects all HTTP to HTTPS, and Cloudflare requests over HTTP again. Cloudflare names this as the classic cause and the fix is to set the encryption mode to Full or higher, or drop the HTTPS redirect at the origin.⁶
• A rule matching its own destination. A pattern broad enough to catch the URL it redirects to.

Diagnose with curl -IL https://example.com/old-page/, which prints every hop and status code in order. Browsers cache 301s aggressively, so a browser tab is the least reliable way to test a redirect you have just changed.

Temporary redirects left in place for permanent moves

A 302 is the default in many CMS redirect managers, plugins and framework helpers, so permanent moves regularly ship as temporary ones without anyone choosing that. The cost is not lost equity, since 302s pass signals too. It is that Google keeps the original URL in the index and treats the destination as the temporary one, so the move never completes. Check the status code that comes back rather than assuming the tool used the one you intended.

Redirects pointing at dead or redirected destinations

A redirect is only as good as its destination. If the target has since been deleted, renamed or redirected itself, you have converted a clean 301 into a chain or a dead end, and users pay an extra hop to reach a 404. This usually happens when a mapping was written against a URL structure that changed afterwards. Re-test the full redirect list whenever URLs change again, not only at launch.

Internal links still pointing at redirected URLs

Redirects are a safety net for links you cannot edit, not a substitute for fixing the ones you can. Every internal link to a redirected URL puts an avoidable hop between your reader and the page, and does it on the routes you control most directly, such as navigation, hub pages and in-body links. After any URL change, crawl the site and update internal links to point at the final destination.

Redirect mapping for migrations

The single most consequential SEO activity in any site migration is redirect mapping. The discipline:

1. Inventory all live URLs. Crawl the existing site (Screaming Frog, Sitebulb) and export the full URL list. Cross-reference with Search Console’s top URLs by impressions and clicks; any URL that drives meaningful organic traffic must be mapped.
2. Map old URLs to new URLs. For each URL that will change, identify the new equivalent. Where pattern-based mapping works (e.g. /blog/(.*)/ → /articles/$1/), use regex. Where it doesn’t, use one-to-one mapping.
3. Identify URLs with no equivalent. Some content gets removed in a migration. These should typically 404 or 410, not redirect to unrelated pages. The site migration guide frames this as giving every URL a decision rather than a destination, which is the check that catches the ones nobody considered.
4. Implement and test. Deploy redirects to staging; spot-check critical URLs; verify each returns the correct status code (301, not 302) and lands on the right destination.
5. Monitor post-launch. Watch Search Console for crawl errors, indexing changes, and ranking shifts in the weeks after migration. Some volatility is normal; sustained loss indicates redirect or canonicalisation problems.

Server-level vs application-level redirects

Redirects can be implemented at multiple layers:

• CDN level (Cloudflare Page Rules, Vercel redirects, Netlify _redirects). Fast; runs before application logic; appropriate for bulk pattern-based rules and static URL changes.
• Web server level (nginx, Apache .htaccess). Fast; runs before application logic; appropriate for infrastructure-level redirects (HTTPS, www).
• Application level (framework routing). Slower (request reaches the application); appropriate for dynamic redirects that depend on application state.

Prefer CDN or server-level for static redirect rules. Reserve application-level for cases where dynamic logic is required.

Meta refresh redirects

A meta refresh is an HTML instruction that redirects a browser after a specified delay. It lives in the <head> element:

<meta http-equiv="refresh" content="0; url=https://example.com/new-page/">

The content value is a delay in seconds before the redirect fires. Zero means immediate; higher values produce a countdown the user sits through before being moved.

Meta refreshes are not server-side redirects. The original URL returns a 200 status code. The redirect fires only after the browser parses the HTML. Googlebot does follow meta refreshes, but processing is slower and equity transfer is less efficient than a proper 301. Other crawlers may ignore them entirely.

For SEO purposes, meta refreshes are a last resort for environments where server-side redirects are not possible: hosted CMS platforms with no redirect configuration, third-party tools, or pages where you have no control over response headers. In those cases, a meta refresh is better than no redirect at all, but should be replaced with a 301 at the earliest opportunity.

Avoid delays above zero. A five-second countdown before redirect provides no SEO or user benefit.

JavaScript redirects

A JavaScript redirect changes the browser’s location once the page has loaded:

<script>window.location.replace("https://example.com/new-page/");</script>

Google recognises the method, and ranks it last of the three it supports: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.”² The reason is that the instruction does not exist until the page has been fetched, parsed and the script executed. Google renders on a deferred pass, so as its documentation puts it, “Google might never see it if rendering of the content failed.”

The gap is wider outside Google. Most crawlers that build AI retrieval indexes do not execute JavaScript, so a JavaScript redirect is not a slower redirect to them, it is no redirect: they see a page that returns 200 with the old content still in the HTML. Gemini is the exception that proves the point, since it draws on Google’s infrastructure and therefore its rendering. The same limitation applies to most third-party crawlers and link tools.

Treat JavaScript redirects as a stopgap for cases where you control the page’s markup but not its response headers, and replace them with a 301 when you can. If you need one to persist, pair it with a canonical tag pointing at the destination so there is a signal in the raw HTML.

Frequently asked questions

Do redirects pass full PageRank?

Yes. Google’s crawling FAQ states: “Ranking signals (such as PageRank or incoming links) will be passed appropriately across 301 redirects.”⁷ Don’t avoid 301s for fear of equity loss.

How long should redirects stay in place?

Permanently. Google’s floor is “at least 1 year”, long enough for it to transfer all signals to the new URLs,³ but there is no SEO benefit to ever removing a 301 after that. The cost of removal is potential 404s for users and lost equity from any remaining external links. Treat redirects as permanent infrastructure.

Can I 301 to a page that is itself 301-redirected?

You can, but you create a chain. Update both redirects to point to the final destination instead.

Why is my redirect not working?

Check three things in order. Whether a page still exists at the source URL, because some hosts serve the file instead of applying the rule. Whether another rule at a different layer is matching first. Whether you are looking at a cached 301 in your browser. curl -IL on the source URL answers all three faster than a browser tab will.

Footnotes

1. HTTP status codes — Google Crawling documentation ↩ ↩²

2. Redirects and Google Search — Google Search Central ↩ ↩²

3. Site moves with URL changes — Google Search Central ↩ ↩² ↩³

4. A search-engine guide to 301, 302, 307 — John Mueller ↩

5. Fetch Standard, HTTP-redirect fetch — WHATWG ↩

6. ERR_TOO_MANY_REDIRECTS — Cloudflare SSL/TLS documentation ↩

7. FAQ: Google Search Crawling and Indexing — Google Search Central ↩