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, transfers signals) and 302/307 (temporary, doesn’t transfer signals). 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.

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

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.

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.

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

Footnotes

1. HTTP status codes — Google Crawling documentation ↩

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