Every redirect and error status code tells a crawler something specific about how to treat a URL long-term, not just where to send the current request. Getting the status code wrong doesn't break the user experience — a browser follows a 301 and a 302 identically — but it changes what happens to indexing and ranking signals behind the scenes, which is exactly the part that's invisible until traffic drops weeks later.

301 vs 302 vs 307: permanence is the whole distinction

A 301 (Moved Permanently) tells search engines the old URL is gone for good and ranking signals should transfer to the new target — this is the default choice for any intentional, lasting URL change. A 302 (Found / Temporary Redirect) signals the move is short-term, so engines keep the original URL as the canonical reference and generally hold off fully consolidating signals onto the destination — correct for things like a seasonal campaign redirect or an A/B test, wrong for a permanent platform migration. 307 (Temporary Redirect) is the HTTP/1.1-correct version of a temporary redirect that strictly preserves the request method (a POST stays a POST), used mostly by frameworks and APIs rather than hand-authored for SEO purposes — treat it the same as a 302 for indexing implications.

nginx-redirects.conf

text

# Permanent — old URL retired for good, consolidate signals
location = /old-product-page {
  return 301 /new-product-page;
}

# Temporary — seasonal campaign, keep old URL as canonical
location = /holiday-sale {
  return 302 /sale;
}

Using 302 for a permanent change is one of the most common redirect mistakes

Teams often default to 302 because it's the first option in a dropdown or because it feels 'safer.' For a genuinely permanent move, this slows down signal consolidation for weeks or longer, since search engines keep hedging on whether the old URL might come back. If the change is permanent, use 301 — there's no safety benefit to 302 here, only delay.

Redirect chains and loops

A redirect chain happens when URL A redirects to B, which redirects to C, instead of A pointing directly to C. Each hop adds latency, dilutes the signal transfer slightly, and — past a handful of hops — crawlers may simply stop following the chain and treat the original URL as a dead end. A redirect loop (A to B, B back to A) is worse: it never resolves, and both the crawler and the end user just get an infinite-redirect error. Chains accumulate naturally over multiple migrations layered on top of each other; the fix is to periodically audit and collapse them to single-hop redirects pointing straight at the current live destination.

chain-vs-collapsed.txt

text

# Redirect chain (bad) — accumulated across two migrations
/old-page -> /2022-page -> /current-page

# Collapsed (good) — single hop to the real destination
/old-page -> /current-page
/2022-page -> /current-page

Redirect types at a glance

Status code	Meaning	Signal consolidation	Use when
301	Moved Permanently	Transfers to new URL	Permanent URL/domain changes, migrations
302	Found (temporary)	Stays with original URL	Short-term campaigns, A/B tests
307	Temporary Redirect (method-preserving)	Stays with original URL	API/framework-level temporary redirects
308	Permanent Redirect (method-preserving)	Transfers to new URL	Permanent redirects where request method must be preserved

When a 404 is actually fine

Not every 404 is a problem to fix. A product that's permanently discontinued, with no reasonable replacement, genuinely should 404 (or better, 410 Gone, which signals intentional removal more strongly than a generic 404). Forcing a redirect for every retired URL — a practice sometimes called 'redirect hoarding' — creates a tangle of pointless redirects to irrelevant pages, which is its own form of crawl waste and user-experience confusion. A 404 is the right answer when there's genuinely nothing equivalent to send the visitor to.

When a 404 is lost equity

A 404 is a real problem when the URL still has inbound links (internal or external) or still receives organic traffic, and there's a clear replacement that should have been mapped. This is the output of a sloppy migration or an uncoordinated URL restructure — content moved, but nothing told search engines or incoming links where it went. The fix is always the same: find the current best-matching page and add a 301, closing the gap rather than letting the link equity evaporate.

Deciding whether a 404 needs a redirect

Situation	Has inbound links/traffic?	Has a real replacement?	Action
Discontinued product, nothing similar	Low	No	Leave as 404/410
Blog post moved to new URL structure	Yes	Yes	301 to new URL
Old category merged into a broader one	Yes	Yes (the broader category)	301 to merged category
Random typo URL that never existed	No	N/A	Leave as 404

Audit redirects on a schedule, not just during migrations

Redirect maps rot. A 301 that pointed to a valid page a year ago can now point to a page that's itself been redirected or removed. A periodic crawl specifically checking for chains, loops, and redirects-to-404s catches this decay before it compounds across multiple migrations.

What's next

Clean redirects matter partly because of how they interact with crawl budget — every chain or loop a crawler follows is a crawl spent on a non-answer instead of real content.

Next: Crawl Budget Optimization →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →