A redirect is a server's answer to "that address has moved". The browser asks for one URL, the server replies with a 3xx status and a Location header, and the browser asks again. Visitors rarely notice. Search engines notice everything about it.

Which status to use

  • 301 — moved permanently. The old URL is finished. Use it for site migrations, HTTPS moves, renamed pages and consolidations. Signals transfer to the new address and browsers cache it hard.
  • 302 — found, temporary. The old URL is coming back. Use it for genuinely temporary situations: maintenance, an A/B test, a seasonal takeover. The old URL keeps its indexing.
  • 307 and 308. The strict versions of 302 and 301. They guarantee the request method is preserved, so a POST stays a POST. Relevant for APIs and forms; for ordinary page moves 301 remains the conventional choice.
  • 303 — see other. Deliberately turns a POST into a GET. This is the redirect after a form submission that stops a refresh resubmitting it.

Google has said for years that it treats permanent and temporary redirects similarly for ranking purposes. That is true and it is still not a reason to be careless: the status is also read by browsers, caches and every other client, and a 302 that was meant to be permanent keeps the old URL alive in indexes far longer than necessary.

Chains: the cost nobody sees

A chain is a redirect that lands on another redirect. They accumulate quietly, one migration at a time:

http://example.com/old-page
  → https://example.com/old-page
  → https://www.example.com/old-page
  → https://www.example.com/new-page

Every visitor to that first address waits for four round trips before a single byte of the page arrives — on a slow mobile connection, comfortably a second of nothing. Crawlers typically follow a handful of hops and then give up and try again later, so a long chain delays the new URL being picked up. And each hop is a place where somebody later removes a rule and breaks the whole path.

The fix is always the same: point the first URL directly at the last one. Keep the intermediate rules in place for anything still linking to them, but do not make them serial. A loop — A to B, B back to A — is the same problem taken to its conclusion, and the browser gives up with an error.

Two mistakes that lose pages outright

Redirecting everything to the homepage

During a migration it is tempting to send every retired URL to /. To a search engine that is not a move, it is a soft 404: the destination has nothing to do with what was requested, so the old page's signals are discarded rather than transferred. Map each URL to its closest equivalent, and let genuinely gone pages return 410 or 404 honestly.

Redirects a crawler cannot see

A <meta http-equiv="refresh"> tag or a JavaScript window.location assignment moves a browser but is not an HTTP redirect. It is slower, it is treated as a weaker signal, and if it depends on JavaScript that fails to run the visitor stays on a blank page. If you control the server, redirect at the server.

The www and HTTPS pair

Most sites want one canonical host on one protocol, and this is where chains are born. Configure the server so that any combination of the wrong protocol and the wrong host arrives in a single hop:

http://example.com/x      → https://www.example.com/x
http://www.example.com/x  → https://www.example.com/x
https://example.com/x     → https://www.example.com/x

Note the path is preserved. A rule that redirects to the bare homepage instead of the matching path is the soft-404 mistake wearing a different hat.

Checking them

Test the URL a visitor actually types — with http://, without www, with the trailing slash — rather than the tidy final address, because the tidy one never shows the chain. What matters is the number of hops, the status at each one, and that the destination answers 200 rather than another redirect. It is worth re-checking after any infrastructure change: redirect rules are configuration, and configuration drifts.