Redirect management

A redirect is an instruction from a server to a browser saying: "the page you asked for has moved or been deleted — go here instead." It's how websites preserve user experience and SEO equity when URLs change.

When done correctly, redirects are effectively invisible to users. They will simply arrive at the new URL without any interruption. If redirects for deleted content are not done, or are done incorrectly, they can break websites and damage rankings.

Common redirect types

301 — Moved Permanently

The standard for permanent URL changes. A 301 tells search engines that the old URL is gone for good and the new URL has taken its place. Search engines transfer ranking signals (link equity, indexing) to the new URL.

Use for: - URL structure changes. - Content consolidation (multiple old pages → one new page). - HTTPS migrations, www/non-www canonicalisation. - Directing users to suitable replacements for deleted content. - Domain migrations.

302 — Moved Temporarily

A 302 tells search engines the move is temporary; the original URL is expected to return. Search engines treat 302s differently — they typically don't transfer ranking signals to the destination.

Use for: - Temporary maintenance redirects. - A/B testing variants. - Geolocation-based redirects to country-specific pages. - Anything genuinely temporary.

Common mistake: using 302 instead of 301 for permanent moves. Search engines may eventually treat persistent 302s as 301s, but it's slower and unreliable. Always use 301 for permanent changes.

307 — Temporary Redirect

HTTP/1.1 version of 302. Identical in effect but preserves the request method (GET stays GET, POST stays POST). 302 sometimes converts POST to GET, which can break form submissions.

308 — Permanent Redirect

HTTP/1.1 version of 301. Same purpose, but preserves the request method. Less commonly used in practice; 301 remains the dominant choice.

Meta refresh and JavaScript redirects

Both work in browsers but are weaker SEO signals than server-side redirects. Search engines do follow them, but with delay and less reliable signal transfer.

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

window.location.href = "https://new-url";

A Meta refresh or JavaScript redirect should never be used when access is available to use server-side redirects (301/302).

How redirects are configured

Note: The following are examples only, this is not an extensive or complete list, and other methods may be required depending on the website and server setup.

Apache (.htaccess)

Redirect 301 /old-page /new-page
RedirectMatch 301 ^/blog/(.*)$ /articles/$1
RewriteEngine On
RewriteRule ^old-product/(.*)$ /products/$1 [R=301,L]

Nginx

rewrite ^/old-page$ /new-page permanent;
location = /old-page { return 301 /new-page; }

CMSs

• WordPress: plugins like Redirection or Rank Math; large-scale via direct database edits.
• Shopify: Online Store → Navigation → URL Redirects.
• Webflow, Squarespace, Wix: built-in redirect managers.

CDN-level

• Cloudflare Workers, Cloudflare Rules — edge-level redirects, faster than origin redirects.
• Fastly, Akamai — similar capabilities for enterprise-scale sites.

When to use a redirect

• URL has changed but content still exists — 301 to the new URL.
• Old page has been deleted — 301 to the closest relevant live page.
• Multiple versions of a URL exist (HTTP/HTTPS, www/non-www, trailing slash) — 301 to the canonical version.
• Domain has migrated — site-wide 301s mapping every old URL to its new equivalent.
• Two pieces of content have been merged — 301 the deprecated URL(s) to the combined content URL.
• Multilingual content — 302 (not 301) for geolocation routing, since the same user might be redirected to different versions.

When NOT to use a redirect

• Pointing every 404 to the homepage. Google treats this as a soft 404 and ignores the redirect. Only redirect when there's topical relevance between source and destination.
• As a substitute for fixing internal links. If you control the source page, update the link directly. Redirects work, but every redirect adds latency and one more thing to maintain.

Redirect chains and loops

Chains

A → B → C → D. Each hop adds latency, dilutes signals, and risks crawler abandonment. Google specifies it follows up to 10 hops; in practice, performance degrades before that.

Fix: collapse chains. If A → B → C → D is the current state, update the redirect rules so A → D, B → D, and C → D directly.

Loops

A → B → A. The browser bounces back and forth until it gives up. Causes a "too many redirects" error and an unreachable page.

Fix: trace every redirect rule that touches the involved URLs. Loops usually come from conflicting rules (e.g., a rule that adds trailing slashes and another that removes them). Audit .htaccess, server config, and CMS-level redirects together.

Redirect SEO impact

Link equity transfer

301s pass ranking signals. Equity transfer is the primary reason to use 301 over 302 for permanent moves.

Crawl budget

Each redirect counts as a fetched URL during crawling. Excessive redirects (especially chains) waste crawl budget on large sites.

Indexing delay

After a redirect is implemented, search engines take time to re-crawl the source URL, follow the redirect, and update its index. For prominent URLs this can be days or weeks. For low prominence pages, it can be multiple weeks.

Auditing redirects

Server logs

Logs show every redirect actually being requested, which reveals: - Old URLs still receiving traffic (so the redirects are valuable). - Unexpected redirect patterns from CMS bugs or rule conflicts. - 404s where redirects should exist.

Google Search Console

The Pages report flags URLs Google has identified as redirects, and the URL Inspection tool shows the exact final destination Google sees.

Migration redirect plans

For any URL structure change or domain migration, build a redirect map:

Old URL	New URL	Status
/old-blog/post-name	/articles/post-name	301
/products?id=1234	/shop/product-slug	301
/old-section/*	/new-section/*	301 (pattern-based)

Test the map in staging: 1. Verify every entry redirects to the right destination. 2. Verify no chains exist (each old URL → final URL in one hop). 3. Verify no loops (no URL redirects to itself, directly or transitively). 4. Verify the destinations all return 200.

After launch, monitor: - 404s in Search Console (anything that should have been redirected). - Server logs for 5xx errors triggered by malformed rules.

Maintenance

Redirects are append-only. Once a redirect is in place, removing it breaks links from external sites, old bookmarks, and printed materials. Best practice:

• Keep all redirects indefinitely.
• When new redirects are added, check whether they create chains with existing ones.
• Document the rules. Large .htaccess files become unmaintainable without comments.

Common mistakes to avoid

• 302 instead of 301 for permanent moves.
• Redirecting all 404s to the homepage.
• Long redirect chains building up over years.
• Conflicting rules producing loops.
• Updating CMS-level redirects without removing the corresponding .htaccess rules (or vice versa) leaves orphaned rules.
• Not updating internal links after a redirect — every internal redirect is an unnecessary hop.
• Removing old redirects because "the URL hasn't been live for years" — backlinks and bookmarks live longer than that.
• Case-sensitivity issues — /About and /about redirect rules treated differently on case-sensitive servers.
• Trailing slash inconsistency — /about and /about/ redirecting to each other in a loop.

Web hosting/servers

Disclaimer: All information contained herein is for informational purposes only. It is not advice or instructional.