---
title: "Redirect errors"
slug: "redirect-errors"
category: "seo"
tags: ["seo", "redirects", "redirect-chains", "soft-404", "migration", "crawling"]
status: "stable"
last_updated: 2026-09-27
summary: "The redirect failures that cost traffic after a URL change (chains, loops, redirects to noindex or 404 targets, soft 404s, homepage dumps) and how to audit for them with curl."
related: ["[[seo/redirects]]", "[[howto/seo-migration-playbook]]", "[[cheatsheets/http-status-codes]]", "[[seo/crawl-budget]]", "[[seo/technical]]", "[[seo/audit-checklist]]"]
---

## Overview

Most traffic lost in a URL change comes from a handful of redirect mistakes, not from the status code choice. A chain left over from an earlier migration, a loop, or a blanket redirect to the homepage can each undo an otherwise clean move. This page lists those failures and the checks that catch them. For which status code to use in the first place, see [[seo/redirects|Redirects for SEO]].

## Keep redirect chains to fewer than three hops

Each hop in a redirect chain costs latency for users and crawl resources for bots. Googlebot follows up to 10 hops and then gives up, and other crawlers may stop sooner. The three-hop limit below is a house rule, not a Google threshold.

- 1 hop: ideal. `/old` 301 to `/new`.
- 2 hops: tolerable during a migration window; flatten within a sprint.
- 3+ hops: slower for users, more wasted crawl; long chains risk crawlers giving up before the final URL.
- Loops: any chain that returns to a URL already seen. Crawlers drop the URL; users see a browser error.

The fix on every migration is the same: rewrite the redirect map so every old URL points directly at the current final URL, not at an intermediate.

```bash
# Audit chains with curl
curl -sIL https://example.com/old-url | grep -E "^(HTTP|Location)"
# Each HTTP line is a hop. More than three is a bug.
```

## Check for these failure modes before every deploy

- Chain depth. The most common migration bug; old URL A 301s to B, which a previous migration 301s to C. Flatten so A 301s straight to C.
- Redirect loop. A 301 to B, B 301 back to A. Crawler stops; user gets a browser error. Run the curl audit before deploy.
- Redirect to a noindex page. Destination is excluded; source is replaced by the noindex destination and drops out of the index too.
- Redirect to a 404. The redirect resolves to a missing page; the URL disappears from the index. Validate every destination returns 200 before adding to the map.
- Soft 404: a URL returns 200 OK but the page is empty or a "this page does not exist" template. Google classifies as 404 and drops it. Return real 404 status for missing pages, or 301 to the closest equivalent.
- Meta-refresh and JS redirects as a substitute for 301. Google can process both (an instant meta refresh reads as permanent; a JS redirect only works after rendering), but server-side redirects are the most reliable signal. Use a server-side 301 unless the server cannot issue redirects.
- 302 used for a permanent move. Google may eventually treat it as permanent, but until then the old URL stays canonical. Use 301 from the start.
- Redirecting the entire old site to the homepage. Every URL becomes a soft 404 at scale and the new homepage absorbs no signal from the old deep pages. Map old URLs to the closest new equivalent; only redirect to the homepage as a last resort.

## Related

- [[seo/redirects]]; choosing between 301, 302, 307, 308, and canonical
- [[howto/seo-migration-playbook]]; the migration sequence and redirect map workflow
- [[cheatsheets/http-status-codes]]; status code reference
- [[seo/crawl-budget]]; why wasted hops matter on large sites
- [[seo/technical]]; canonical and indexability rules
- [[seo/audit-checklist]]; where the redirect checks sit in an audit