What a redirect is and why you need one

A redirect is a server response telling the browser and the search crawler: the content you asked for is not here, it lives at another address. Technically it is a 3xx response code plus a Location header with the target URL.

GET /catalog/old-category/  HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/catalog/new-category/

For the user the difference between the codes is invisible — either way they land on the final page. The difference exists only for the search engine, and it is what decides the fate of the old URL in the index. That makes a redirect one of the rare cases where a technically “working” setting can quietly destroy indexation for months without producing any visible symptom on the site.

Redirect codes and how they are read

Method Code How the search engine reads it When to use it
301 Moved Permanently 301 Moved for good: the old URL merges with the new one, signals pass across, the old address leaves the index URL changes, merging mirrors, a removed product with a direct equivalent
302 Found 302 Temporary forwarding: the old URL stays in the index A temporary placeholder, an A/B experiment, a product temporarily off sale
307 Temporary Redirect 307 The same as 302, but the request method is guaranteed to be preserved (POST stays POST) Temporary redirects for forms and API requests
308 Permanent Redirect 308 The same as 301, with the request method preserved A permanent move where the method matters; support in older clients is weaker than for 301
meta refresh 200 Recognised, but processed more slowly and less reliably; with any delay above zero it is read as temporary Do not use it for SEO work; acceptable for utility pages
JS redirect 200 Fires only after the page renders, postponing the recrawl indefinitely Do not use it for URL changes; acceptable for user logic after sign-in
💡

The choice in one line: if you are not planning to bring the old URL back, use 301; if you are, use 302. Everything else (meta refresh, JS redirects) is a poor fit for search work: they give no server-level signal that anything has moved.

Standard jobs in e-commerce

A removed or sold-out product. The most frequent situation, and the most expensive in its consequences — in a large catalogue the assortment changes constantly. The options, in descending order of preference:

Situation The correct answer
A direct equivalent exists (a new model, the same product under another SKU) 301 to the equivalent product page
No equivalent, the product may return A page with a 200 code, an out-of-stock status and a block of similar products
No equivalent, the product will not return, the page has no traffic or links 404 or 410
A whole product line removed 301 to the relevant category, not to the homepage

An out-of-stock page with the content preserved and a set of alternatives is usually better than a redirect: it holds search traffic on the model name and gives the shopper a choice instead of a dead end.

A category URL change. When the structure moves, it is not enough to set the 301s from the old addresses — you also have to rewrite every internal link to the new URLs, update the sitemap and check that the filter and pagination URLs inside the category have moved too.

Merging mirrors. Four classic pairs that must be reduced to one canonical version in a single hop:

http://example.com/      ->  https://example.com/     (protocol)
https://www.example.com  ->  https://example.com/     (www)
/catalog/shoes           ->  /catalog/shoes/          (trailing slash)
/Catalog/Shoes/          ->  /catalog/shoes/          (letter case)

The rules have to be coordinated: if the protocol and the www are handled by separate rules that fire in turn, you end up with a three-hop chain instead of one.

Mistakes that cost real money

Mistake What happens
A redirect chain Every hop is an extra request and extra latency; it burns crawl budget and some signals are lost on long chains
A redirect loop The page is unreachable for both user and crawler — an ERR_TOO_MANY_REDIRECTS error and a guaranteed exit from the index
Mass redirection to the homepage The search engine sees that the content does not match the query and treats those URLs as soft 404s — no signals pass and the pages simply drop out
302 instead of 301 for a permanent move The old URL stays in the index for months, the new one does not gain positions, and traffic is split between two addresses
Geo and language redirects by IP A crawler arriving from one region physically cannot see the other versions of the site, so they never reach the index. It breaks hreflang and in bad cases makes the sitemap unreachable
A redirect where a canonical belongs A redirect removes the page for the user; where you only need to name the primary version (sort orders, UTM parameters) a canonical URL is the right tool
The old URL blocked in robots.txt The crawler cannot fetch the URL and therefore never learns about the redirect — no merge happens
Internal links still pointing at old addresses The site itself pushes the crawler through redirects on every crawl, even though the rule is set correctly
⚠

Redirecting all traffic from non-existent addresses to the homepage looks like a tidy way to avoid 404s, but for search it is the worst option available. The search engine compares the content of the final page with the original request, finds no match and marks those hops as soft 404s — no signals pass, and the homepage collects a stream of irrelevant visits that bounce straight back to the results page.

How to check

  1. The response code, not the view in the browser. The browser shows the final page and hides the intermediate hops. You need a tool that prints the whole trace with codes: curl -I -L or any server-response checker.
  2. A crawl of the whole site. A full crawl shows what you cannot see one URL at a time: how many internal links point at redirects, where chains have formed, whether there are loops.
  3. Webmaster console reports. In Google Search Console, the indexing report with the “Page with redirect” status; in Yandex Webmaster — Yandex being the dominant search engine in Russia and several CIS markets — the section listing pages excluded from search. This is where mass problems surface that spot checks never reveal.
  4. Check as the crawler, not only as your own browser. If the site has geo or language logic, check the response for a request with no cookies and from a different region — that is exactly how a crawler arrives.
  5. Verify after release. Any URL move is a reason to recheck the sitemap, the internal links and the robots.txt file the same day, not a month later once organic traffic has fallen.

Checklist before a URL move:

  • a mapping of old URL to new URL is in place, one to one, with no bundles of addresses pointing at a single page;
  • 301 everywhere, not 302;
  • not a single chain: the old address leads straight to the final one;
  • internal links, menus and breadcrumbs rewritten to the new addresses;
  • the sitemap contains only final URLs that return 200;
  • the old URLs are not blocked in robots.txt — otherwise the crawler never sees the redirect;
  • canonical tags on the new pages point at themselves.