Redirects for SEO: 301, 302 and the Ones That Cost You Traffic

By Faaiz Mahmood · Updated 11 September 2026 · 9 min read

Redirects are the plumbing of a website. Nobody notices them when they work, and a surprising amount of lost search traffic traces back to a migration where they were done carelessly. The rules are not complicated, but the details matter more than most people expect.

1. The codes, and what each one signals

For ordinary page moves, the choice is 301 or 302 and almost always 301.

2. 301 versus 302, in practice

The old advice was that 301 passes ranking value and 302 does not. That is out of date. Google has said for years that it passes signals through both, and that it works out intent from behaviour: leave a 302 in place for months and Google will eventually treat it as permanent anyway.

So why still care? Because the codes control which URL Google keeps.

With a 301, Google drops the old URL and indexes the new one. With a 302, Google understands the old URL is the real one and keeps it in the index, since you said the move was temporary. If you permanently moved a page and used a 302, the old address stays in results, and any new content at the destination struggles to rank on its own.

Use 302 for the narrow cases it was designed for: a page temporarily diverted during maintenance, a geo or language redirect where the original must stay addressable, an A/B test. Everything else is a 301.

3. Redirect to the closest equivalent

When a page goes away, the redirect should go to whatever most closely replaces it. A discontinued blue running shoe should redirect to the running shoe category, or to the replacement model. Not to the home page.

Mass-redirecting removed pages to the home page is the classic migration shortcut, and Google treats those as soft 404s. It can tell the destination has nothing to do with the request, so it declines to pass the signal and often drops the URL anyway. You get all the cost of the redirect and none of the benefit, plus visitors who arrive at a home page with no idea why.

If nothing equivalent exists, do not redirect. Return 410 Gone and let it drop cleanly. That is the honest answer and Google handles it well. See HTTP status codes.

4. Chains and loops

A chain is a redirect pointing at another redirect:

/old-page  ->  /newer-page  ->  /newest-page  ->  /final-page

Each hop is a separate request. Visitors wait longer, and every hop spends a slice of crawl budget on delivering nothing. Google follows a limited number of hops before giving up; treat anything past two as a bug.

Chains accumulate naturally. A site moves to https, then restructures its URLs, then drops a category, each change adding a layer. The fix is to flatten them: make every old URL point straight at the final destination in one hop, and delete the intermediate rules.

A loop, where A points to B and B points back to A, takes the page down entirely. Browsers show a redirect error and crawlers give up. The usual cause is two rules written months apart by different people, or a trailing-slash rule fighting a canonical host rule.

5. Site migrations, in order

Most catastrophic traffic drops come from migrations. The sequence that works:

1. Export every indexed URL first. Search Console, your sitemap, analytics, and a full crawl. You cannot map what you have not listed.
2. Map old to new, one by one. A spreadsheet with two columns. Every old URL gets a specific destination, or an explicit decision to let it 410.
3. Use 301s, one hop each. No chains from day one.
4. Update internal links to the new URLs. Do not rely on redirects for your own navigation. Internal links are a signal, and pointing them at redirected URLs weakens it.
5. Update canonicals and the sitemap to the new addresses. An old sitemap full of redirecting URLs undoes a lot of careful work.
6. Keep the redirects for at least a year. Google needs repeated crawls to transfer signals, and old inbound links live a long time. Removing redirects after a month is a self-inflicted wound.

6. Writing them

In Apache, with mod_rewrite in .htaccess. A single page:

Redirect 301 /old-page/ https://example.com/new-page/

Forcing https and a canonical host, which is the pair almost every site needs:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Writing those as one rule matters. Chaining a separate http-to-https rule and a separate www rule produces two hops for a visitor who arrives at http://www., which is the most common chain on the web.

In Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

In PHP, when the logic has to live in the application:

header('Location: https://example.com/new-page/', true, 301);
exit;

The exit is not optional. Without it the script keeps running and may emit output after the header.

7. What to avoid

• Meta refresh. <meta http-equiv="refresh"> is slow, poor for accessibility, and a weaker signal. There is no situation where a server redirect is not better.
• JavaScript redirects. Google can process them, but only after rendering, which delays everything. Avoid for anything permanent.
• Redirecting in robots.txt. Not a thing. Robots.txt cannot redirect.
• Redirecting a 404 template. If the page is gone, return 404 or 410. Redirecting every miss to a search page creates soft 404s at scale.

8. Checking your redirects

The quickest check is one command. -I fetches headers only, -L follows the whole chain, so you see every hop:

curl -sIL https://example.com/old-page/ | grep -i "^HTTP\|^location"

You want exactly one HTTP/… 301 followed by one HTTP/… 200. More than two status lines means a chain to flatten.

Across a site, a crawler will list redirect chains and loops as a report. And after any migration, watch the Pages report in Search Console: a rise in Page with redirect is expected, while a rise in Not found or Soft 404 means URLs slipped through your map.