Redirects: 301 vs 302, Chains, and the Migration That Loses Your Rankings

Redirects are simple until a site migration, at which point they become the single largest determinant of whether you keep your organic traffic or start over.

The rules are short. The mistakes are expensive and mostly avoidable.

The status codes

301 — Moved Permanently. Search engines transfer ranking signals to the destination and eventually replace the old URL in their index. Browsers cache it aggressively, often indefinitely, which is why a mistakenly deployed 301 is genuinely painful to undo — returning visitors keep following it from cache long after you fix the server.

308 — Permanent Redirect. Identical to 301 except it preserves the HTTP method. A POST stays a POST instead of becoming a GET. Use it for API endpoints; for pages, 301 is fine and better understood by tooling.

302 — Found (temporary). Signals stay with the original URL and the destination is not indexed in its place. Correct for A/B tests, maintenance pages, and language redirection based on Accept-Language — anything where the destination genuinely depends on the request rather than being a permanent replacement.

307 — Temporary Redirect. The method-preserving version of 302.

The costly mistake is using 302 for a permanent move. Google will usually work it out eventually and treat it as a 301, but "eventually" can mean months of the old URL holding the ranking while the new page sits unindexed.

Chains

A chain is a redirect that leads to another redirect. They accumulate quietly:

http://example.com/old-page
  → 301 → https://example.com/old-page
  → 301 → https://www.example.com/old-page
  → 301 → https://www.example.com/new-page/
  → 200

Four requests before the browser sees any content. Each of those was probably a reasonable rule added at a different time by a different person: force HTTPS, canonicalise to www, migrate the path.

How much does this actually cost?

Not link equity. Google confirmed in 2016 that 301 redirects pass full PageRank, so the old "15% loss per hop" rule no longer applies. You will still find it repeated widely.

The real cost is speed. On a mobile connection each hop is a full round trip — DNS is already resolved, but the TCP and TLS handshakes may not be, and each redirect can add 200–400ms before anything renders. That lands directly on Largest Contentful Paint, which is a confirmed ranking signal and, more importantly, a confirmed bounce-rate driver.

Google follows up to about ten hops before giving up. Long before that, your visitors have.

The fix is to flatten: point the first URL directly at the final destination rather than at the next rule in the sequence. In practice that means your redirect rules should be written against the original URL, not chained onto each other.

The HSTS trick

If you redirect http:// to https://, every first-time visitor pays for that hop.

Adding HSTS removes it for everyone who has visited before:

Strict-Transport-Security: max-age=31536000; includeSubDomains

The browser now goes straight to HTTPS on every subsequent visit, without asking. That is a full round trip removed from every page load for returning visitors — one header, measurable gain.

Loops

A redirect loop makes a URL completely unreachable. The usual causes:

• A trailing-slash rule fighting a canonical rule
• An HTTPS redirect at the application layer fighting one at the CDN
• A language redirect that redirects the language page it just sent you to

Loops are invisible until someone hits the exact URL that triggers them, which is often a URL that only appears in search results or old links. Test the specific URLs, not just the homepage.

You can trace any URL hop by hop with our free redirect checker — it follows each redirect individually rather than summarising, so you see the whole chain and what each hop costs.

The migration mistake that loses rankings

Every old URL that had traffic or inbound links needs a direct 301 to its closest equivalent.

Not to the homepage.

Google treats a mass redirect of unrelated URLs to the homepage as a soft 404 and passes essentially nothing. This is the single most common way a site migration destroys organic traffic, and it happens because building a real URL map is tedious and redirecting everything to / takes one line.

The tedious version is the one that works:

1. Crawl the old site completely before you switch anything. Screaming Frog, Sitebulb, or your existing sitemap.
2. Export the URLs that matter — anything with organic traffic in Analytics, anything with inbound links in Search Console or Ahrefs.
3. Map each one to its closest equivalent on the new site. Not the category page if a specific page exists.
4. URLs with no equivalent should return 410 Gone, not 301 to something unrelated. 410 tells search engines to drop it cleanly; a bad 301 tells them you have a page about something you do not.
5. Deploy the redirects with the new site, not afterwards.
6. Monitor Search Console for four to six weeks. Crawl errors and index coverage will show you what you missed.

Step 4 is counter-intuitive and worth stating plainly: it is better to tell a search engine a page is gone than to send it somewhere irrelevant.

Trailing slashes

/page and /page/ are different URLs. Pick one convention, redirect the other to it, and make sure your internal links use the canonical form.

The cost of getting this wrong is not usually duplicate content — canonical tags handle that — it is an extra redirect on every internal navigation, because your own links point at the non-canonical form and every click pays for a hop.

Redirect versus canonical

Use a redirect when a page has genuinely moved and users should end up somewhere else.

Use a canonical when both URLs should remain accessible but only one should be indexed — a product reachable through two categories, a printable version, a URL with tracking parameters.

Redirecting when you should canonicalise breaks legitimate functionality. Canonicalising when you should redirect leaves duplicate pages accessible and lets search engines disagree with you.

Where to implement them

Server level — .htaccess on Apache and LiteSpeed, the server block on Nginx. Fastest, because it happens before your application starts.

Application level — a routing rule or a plugin. Slower, because the application boots first, but easier to manage when the rules depend on database state.

Never client-side. A JavaScript or meta-refresh redirect is slow, is treated inconsistently by crawlers, and passes signals unreliably. It is the wrong tool for a permanent move.

Quick checklist

• Permanent moves use 301, not 302
• No chain is longer than one hop
• HSTS is set so returning visitors skip the HTTPS redirect
• Every old URL with traffic or links maps to a specific equivalent
• Genuinely dead URLs return 410, not a redirect to the homepage
• Internal links point at the final URL, not at a redirect
• The specific URLs are tested, not just the homepage

The last one is where most problems hide.