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.

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, transfers signals) and 302/307 (temporary, doesn’t transfer signals). The default for any URL change you intend to keep is 301.

When to 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.

When NOT to redirect

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

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 and 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.

Redirect chains

A redirect chain occurs when one redirect leads to another, which leads to another. Each hop adds latency and reduces the equity transferred.

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

Google has stated it follows up to roughly 10 hops in a chain, but signal transfer degrades sharply after the first one. The best practice is to update all redirects to point directly to the final destination, eliminating chains entirely.

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/

Browsers detect loops and refuse to follow them. Crawlers do the same. Pages in a loop are effectively inaccessible. Loops typically arise from configuration errors (conflicting redirect rules, application-level vs server-level conflicts).

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.
  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.

Frequently asked questions

Do redirects pass full PageRank? 301 redirects pass the great majority of ranking signal. There was a period where Google described loss as “very minor”; current guidance suggests the loss is negligible in practice. Don’t avoid 301s for fear of equity loss.

How long should redirects stay in place? Permanently. There is no SEO benefit to ever removing a 301 redirect; 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.