Redirects Done Right: 301s, 302s, Chains

Nobody plans to accumulate redirects. They accumulate the way cables accumulate in a drawer: one site migration here, a renamed product page there, an HTTPS switch years ago, a trailing-slash change nobody remembers making. Five years later a single old backlink to your site triggers four hops before a visitor sees a page — and every hop costs you speed, crawl budget, and a little bit of the link equity you worked to earn.

The good news is that redirects are one of the most fixable problems in technical SEO. The rules are simple, the tools are free, and an afternoon of cleanup usually holds for years. This post covers the rules, the cleanup, and the habits that stop the drawer from filling back up.

The two redirects that matter (and the ones that mostly don't)

A redirect is just an HTTP status code plus a destination. The server says "not here — go there," and the browser (or Googlebot) follows. For day-to-day WordPress work, two codes cover nearly everything:

• 301 — Moved Permanently. The page has a new home and it's not coming back. Browsers cache this aggressively, and search engines transfer the old URL's ranking signals to the new one. This is your default for renamed pages, deleted-and-replaced content, domain changes, and HTTP-to-HTTPS.
• 302 — Found (temporarily moved). The page is elsewhere for now. Search engines keep the original URL in the index and don't consolidate signals to the destination. Use it for genuinely temporary situations: a product out of stock pointing to its category, an A/B test, a seasonal landing page swap.

You'll also meet a few relatives:

• 307/308 are the strict-method versions of 302/301. They matter for form submissions and APIs (they guarantee a POST stays a POST). For ordinary content pages, 301 and 302 are fine.
• Meta refresh and JavaScript redirects are the redirects of last resort. Search engines can follow them, but slowly and unreliably, and users see a flash of the old page. If you control the server — and on WordPress you do — use a proper HTTP redirect instead.

The decision rule: will the old URL ever come back?

Every redirect decision reduces to one question: is the original URL coming back?

• If no → 301. Renames, restructures, consolidations, migrations.
• If yes, on a known timeline → 302. Stock-outs, maintenance detours, campaign pages.
• If you're not sure → treat it as permanent and use a 301. A wrong 302 that lives for years is worse than a 301 you later reverse, because search engines eventually treat long-lived 302s as 301s anyway — but on their timeline, not yours, and with a period of confusion in between.

The most common real-world mistake isn't choosing the wrong code — it's a plugin or theme silently issuing 302s for everything. WordPress's wp_redirect() function defaults to 302 unless the developer specifies otherwise. If you've ever added a redirect in custom code and skipped the second argument, you've shipped a 302 you meant as a 301. Check with curl: curl -I https://yoursite.com/old-page/ and read the status line. Thirty seconds, no guessing.

Why chains are worse than they look

A redirect chain is any sequence of two or more hops: A → B → C. A redirect loop is the pathological cousin: A → B → A, which ends in a browser error. Chains happen through completely reasonable individual decisions:

1. Year one: you move to HTTPS. http://site.com/services → https://site.com/services.
2. Year three: you restructure. /services → /what-we-do.
3. Year five: you rebrand that page. /what-we-do → /solutions.

Now an old backlink to the HTTP URL triggers three hops. Each hop is a full round trip — on a mobile connection, budget 100–300ms per hop, so a three-hop chain can add close to a second before the destination even starts loading. Google has said it follows up to ten hops, but crawl efficiency drops with each one, and anything past three or four is asking for trouble. Link equity also degrades in practice across long chains, whatever the official position on single 301s being lossless.

The fix is always the same: point every old URL directly at the final destination. Don't delete the intermediate redirects — update them. A → C, B → C. One hop each, no matter how old the inbound link is.

How to audit your redirects in an afternoon

You don't need enterprise tooling. Here's a workable sequence:

1. Crawl your own site

Run a crawler (Screaming Frog's free tier handles 500 URLs, which covers most small-business sites) against your homepage. Filter for 3xx responses. Every internal link that returns a redirect is a link you should update to point at the final URL directly — internal links should never rely on redirects, because you control both ends.

2. Check your known legacy URLs

Pull your top historical URLs from Google Search Console (Performance → Pages, set the date range as far back as it goes) and from your redirect plugin's own list. Test the ones that matter with curl or a bulk HTTP status checker. You're looking for chains, loops, 302s that should be 301s, and redirects landing on 404s — the saddest outcome, where you paid the redirect cost and delivered nothing.

3. Test the four homepage variants

Check all of these resolve in one hop to your canonical version: http://site.com, http://www.site.com, https://site.com, https://www.site.com. A surprisingly common pattern is http-www → https-www → https-non-www: two hops on every legacy link, fixable with one server rule.

4. Fix in the right layer

Order of preference:

• Server or edge level (nginx config, .htaccess, Cloudflare rules, or your host's redirect manager) for site-wide patterns: HTTP→HTTPS, www normalization, trailing slashes, old-domain-to-new-domain. These execute before WordPress even loads — fastest possible.
• A redirect plugin (Redirection is the standard choice) for individual page moves. It logs hits and 404s, which makes future audits easier.
• Not your theme's functions.php. Redirects buried in theme code disappear when you switch themes and are invisible to whoever maintains the site next.

Migration day: the redirect map

If you're restructuring a site or changing domains, redirects stop being cleanup and become the main event. The discipline that saves you:

1. Export every indexed URL before you touch anything. Crawl the live site, pull Search Console data, and export the WordPress URL list. This is your "before" column.
2. Build a one-to-one map in a spreadsheet: old URL → new URL. Resist the lazy pattern of redirecting everything to the homepage — Google treats mass homepage redirects as soft 404s, and users hate them. Every old URL should land on its closest equivalent; genuinely retired content can honestly 410 (Gone) or redirect to a relevant category page.
3. Implement as 301s, then crawl the old URL list and verify every row returns exactly one 301 to the mapped destination.
4. Keep migration redirects for at least a year — realistically, forever, since they cost nothing to keep. Backlinks from years ago still send visitors.

A quick reference table

Habits that keep the drawer tidy

• Every rename gets a redirect the same day. Make it part of the publish checklist, not a quarterly cleanup.
• Every redirect points at the final URL. When you move a page that already had redirects pointing to it, update those old redirects to the new destination in the same session.
• Review your 404 log monthly. The Redirection plugin logs 404s; five minutes of scanning it catches broken inbound links while they're still sending traffic worth catching.
• Re-run the homepage-variant test after any hosting, CDN, or SSL change. These are exactly the moments chains get introduced.

The honest summary

Redirects are not a ranking strategy; they're loss prevention. A 301 doesn't earn you anything — it just stops you from throwing away authority you already have. Pick 301 for permanent, 302 for genuinely temporary, keep every path to one hop, and audit twice a year. It's unglamorous work, which is exactly why the sites that do it have a quiet edge over the ones that don't.

Photo: AS Photography on Pexels