Redirects for SEO are how you move a URL without losing its rankings, but done wrong, they leak the link equity you spent years building. Chains, loops, wrong status codes, and redirects to dead pages all cost you. Here's how to get them right.
Redirects accumulate. Every site migration, URL rename, and HTTPS move adds rules, and over time they tangle into chains and loops that quietly drain authority and crawl budget.
A redirect is a promise: this URL now lives somewhere else. Search engines honour that promise and transfer the old page's ranking signals to the new one, but only if the redirect is clean, permanent where it should be, and lands on a live page. Redirects are how you move or restructure URLs without losing years of accumulated authority, which makes them one of the highest-stakes parts of technical SEO. A botched redirect during a migration can erase rankings that took years to earn.
The trouble is that redirects pile up silently over a site's life. Each one looks harmless on its own, but together they tangle into the three failure modes below.
A redirects to B redirects to C. Each hop adds latency for users, wastes crawl budget, and risks leaking equity. There's no upside to a chain, only a hop to remove. Chains & loops →
A temporary 302 used for a permanent move keeps the old URL indexed and stalls the transfer of authority to the new page. 301 vs 302 →
A redirect that lands on a 404 or 5XX sends users and crawlers to a dead end, and any equity it carried evaporates. Always redirect to a live, relevant page, not a guess.
The redirect mistakes that cost the most ranking authority.
Why A to B to C leaks equity and wastes crawl budget, how loops break a page entirely, and how to collapse chains and update internal links to point at the final URL.
Permanent vs temporary, why using a 302 for a permanent move stalls the transfer of authority, and how to choose the right status code for migrations and campaigns.
Grounded in the real checks the crawler runs.
A redirect issue is often the visible symptom of an internal-linking problem too.
A 301 is a permanent redirect: it tells a search engine that a URL has moved for good and that the destination should take its place in the index. That single instruction is what makes it the default choice for almost every real move.
A permanent redirect consolidates the old URL onto the new one. The destination replaces the source in the index, and the ranking signals the old URL had accumulated, principally its inbound links, are attributed to the destination instead. This is why redirecting a retired page to a relevant replacement preserves value that deleting it would simply discard.
The transfer is not instant. A search engine has to re-crawl the old URL to see the redirect, then process the consolidation, and for a large site that plays out over weeks. Judging a migration on the first few days after launch is the most common way teams talk themselves into reverting a change that was working.
A 301 preserves value only when the destination is a genuine equivalent. Redirecting a specific product page to the homepage is technically a valid redirect and practically a deletion: the searcher wanted one thing and got the front door, and the specific relevance that made the old page rank has nowhere to land. Search engines increasingly treat these as soft 404s rather than honouring them as moves.
Chains leak in a different way. Every hop adds latency for the user and a request for the crawler, and long chains risk being abandoned before they resolve. Chains rarely get built deliberately; they accumulate, one migration at a time, until a URL from three site versions ago passes through four hops to reach a live page. Auditing for them periodically is what keeps a decade of moves from compounding.
Use a 301 when the move is permanent, which covers URL restructures, domain changes, http to https, consolidating duplicates, and retiring a page in favour of a successor. Use a 302 only when the original URL will genuinely return, such as a page temporarily replaced during maintenance, because a 302 asks search engines to keep the original indexed.
The failure mode here is a 302 left in place after a permanent move, which keeps signals attached to a URL you no longer serve. The detail is covered in the 301 versus 302 guide, and chain-specific problems in the redirect chains guide.
Redirect maps live in server configuration, a CDN, or a plugin table, and they are rarely reviewed after the migration that created them. Rules outlive the people who wrote them, patterns start matching URLs nobody anticipated, and a regex written for one directory quietly captures another added years later.
Treating the redirect map as something to audit rather than something to write once is what prevents the slow accumulation of chains, loops and rules pointing at destinations that no longer exist. A crawl that follows every redirect to its final destination is the practical way to see the map as it actually behaves rather than as it was intended.
A single, correct 301 is fine and passes nearly all link equity to the new URL. Redirects are not inherently harmful, and avoiding them is not the goal.
They start costing you when they pile into chains, form loops, land on 404s, or use the wrong type, such as a 302 for a permanent move. The fix in every case is the same shape: redirect directly to the final destination, and update internal links to point there too, so that no crawl and no click wastes a hop.
Use a 301 for permanent moves. It transfers ranking signals to the new URL and replaces the old one in the index, which is what you want any time the old address is gone for good.
Use a 302 only when the change is genuinely temporary and the original URL will return. Using a 302 for a permanent move is a common mistake that leaves the old URL indexed and slows the transfer of authority to the new page. See 301 vs 302 for how each status code is interpreted and where the wrong choice hurts most.
A redirect chain is a URL that redirects to another URL which itself redirects, for example A to B to C. They accumulate naturally: each individual rule was reasonable when it was added, and nobody revisits the earlier ones.
Each hop adds latency for the user, consumes crawl budget, and can dilute equity, and search engines may stop following long chains altogether. Collapse the chain so the first URL goes straight to the final destination, and update internal links to point at that final URL rather than relying on the redirect to carry them there.
Avoid redirecting deleted pages to the homepage. Mass-redirecting dead URLs to the root is frequently treated by Google as a soft 404, in which case the equity doesn't transfer and you have gained nothing over letting the URL 404.
Redirect each removed page to the most relevant live page instead, matching topic to topic. Only when there is truly no relevant target should you let the URL return a clean 404, which is a legitimate outcome rather than a failure.
Free to start. Find chains, loops and broken redirects across your whole site.
Start my free audit