301 vs 302 and the Status Codes That Decide Whether Your Pages Rank
A status code is a two-part instruction: it tells a browser what happened and tells a search engine what to do about the URL long-term. Choosing the wrong one rarely breaks anything visibly, which is why the damage is usually discovered months later in a traffic report.
301 and 302 answer different questions
A 301 says this URL has permanently moved; consolidate everything you know about it onto the new address. A 302 says the content is temporarily somewhere else; keep the original URL indexed.
Using a 302 for a permanent move is the costly version of this mistake. Search engines keep the old URL in the index, ranking signals do not consolidate, and the new address never fully inherits the authority of the old one. The reason it persists is that many frameworks and hosting panels issue 302 by default — a redirect configured without specifying the type is frequently temporary without anyone intending it.
Two related codes exist for a narrower purpose: 307 and 308 preserve the HTTP method and body across the redirect, which matters for POST requests where 301 and 302 historically allowed the method to change. For ordinary page moves, 301 remains the correct choice.
404 and 410 are not interchangeable
A 404 means not found, possibly temporarily — a typo, a broken link, or something that may return. A 410 means deliberately and permanently gone. Search engines typically drop a 410 from the index faster, which is what you want after removing expired listings or discontinued products.
Neither is inherently bad for a site. A URL that genuinely does not exist should return one of them. What causes problems is the soft 404: a page that tells the user "not found" while returning HTTP 200. The crawler sees a successful response and indexes an error page as real content.
Single-page applications produce these very easily, because the server returns 200 for every route and the "not found" state is rendered by JavaScript afterwards. If your site is a SPA, that is worth testing explicitly rather than assuming. The HTTP status code reference covers each code's practical implications, including which ones affect indexing.
Redirect chains and loops
Each hop in a chain adds latency and dilutes the signal being passed. A chain of four redirects to reach a final destination is a common artefact of several site migrations layered over each other — http to https, then www to non-www, then an old slug to a new one.
The fix is to collapse chains so every old URL points directly at the final destination in one hop. Redirect loops, where two URLs point at each other, make a page completely unreachable and are usually the result of two rules written at different times by different people.
This is also the argument for treating slugs as permanent. Changing one without a redirect discards every link and ranking signal accumulated at the old address. If you must generate new URLs, the URL slug generator produces a clean lowercase form with accents transliterated, so the address is right the first time.
Codes that quietly shape crawling
A 503 is the correct response during planned maintenance, ideally with a Retry-After header. It tells crawlers to come back rather than to interpret the outage as a permanent removal — returning 404 or 200 with an error page during downtime is what turns a maintenance window into an indexing problem.
A 429 signals rate limiting and should also carry Retry-After. Aggressive rate limiting applied indiscriminately can throttle legitimate crawlers and slow the discovery of new content.
And a reminder that catches people out repeatedly: blocking a URL in robots.txt prevents crawling, not indexing. A blocked URL with inbound links can still appear in results without a snippet, and because the crawler cannot fetch the page, it never sees a noindex tag placed there. To remove a page from the index, allow it to be crawled and serve a noindex directive. The robots.txt generator builds the file with that distinction made explicit, and the meta tag generator handles the canonical and indexing directives that belong in the page head.
What to audit first
- Every 302 that has been in place longer than a few weeks.
- Redirect chains longer than one hop.
- "Not found" pages returning 200.
- Any Disallow rule inherited from a staging configuration.
- Canonical tags pointing at a different protocol or hostname than the one actually served.