301 vs 302 Redirects: Which One and When to Use It

Most redirect advice stops at 'use a 301, not a 302' and calls it a day. That is the easy half. The hard half is the ledger every service business builds over a decade: the service line you dropped, the three city pages that say the same thing, the holiday promo that ends every January, and the pile of redirect rules three different WordPress plugins left behind.

This post is the decision table for those. Which status code, why, and exactly what breaks when you pick wrong.

What is the actual difference between a 301 and a 302?

A 301 tells Google the move is permanent and the destination should become the canonical URL; a 302 tells Google the move is temporary and the original URL should stay in the index. Google's own redirects documentation is unambiguous: with a permanent redirect, 'the indexing pipeline uses the redirect as a signal that the redirect target should be canonical,' while with a temporary redirect, 'the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical.'

Read the consequence carefully. A 302 on a permanently moved page means Google keeps showing the old URL in search results. It is not that a 302 'leaks link equity' — that is folklore. It is that Google does exactly what you told it: keep the source page.

There are more codes than two. Google groups 301 and 308 as permanent, and 302, 303, and 307 as temporary. The split that matters technically comes from RFC 9110, which says a 307 means 'the user agent MUST NOT change the request method' — a POST stays a POST. For a 301 or 302 the spec instead adds a note: 'For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead.' That is why your quote form breaks when someone drops a naive 301 in front of the form handler URL.

Verdict: for a service business, 301 wins by default. Reach for a 302 only when you can name the date the original page comes back. If you cannot name that date, it is a 301.

Which status code does each real service-business scenario need?

Nine scenarios cover roughly everything a service business will hit in five years. Here is the ledger — scenario, code, why, and the failure mode when you get it wrong.

Print that. It answers the redirect question faster than any audit tool will, and it is the same table we work from when we take over a legacy site as part of technical SEO.

You dropped a service line — do you redirect it, 410 it, or leave it?

Redirect it only if a genuinely equivalent page exists; otherwise 410 it. Google's HTTP status code documentation states that all 4xx errors except 429 are treated the same — 'Google crawlers inform the next processing system that the content doesn't exist' — so a 404 and a 410 have the same end state for Google. The difference is speed and intent, not outcome.

The test is one question: would the person who landed on the old page be served by the new one? A plumber who kills a 'sewer line replacement' page but still does sewer work should 301 it to the parent sewer service page. A plumber who genuinely stopped doing sewer work should 410 it and delete the internal links pointing to it.

What you must not do is 301 every dead service page to the homepage. Google can treat an irrelevant redirect as a soft 404 — it looks at the destination, decides it does not answer the original page's purpose, and drops it from the index anyway. You get the worst of both: no ranking and a confused visitor who bounces off your homepage hero.

When is a 302 genuinely the right call?

A 302 is right when the source URL is coming back and you know roughly when. In practice that is three cases for a service business, and most owners never use any of them.

• Seasonal landing pages. A furnace tune-up promo runs October to February. Point it at the general HVAC maintenance page for the eight dead months with a 302, then remove the redirect when the promo returns. The promo URL keeps its index position and its accumulated links year over year.
• A page temporarily down for a rebuild. You are rewriting the /roof-replacement page and it will be live in ten days. 302 to the parent roofing page while it is down.
• A/B or geo-splitting live traffic. If you are routing a share of visitors to a variant URL, that is temporary by definition. A 301 here would permanently swap the URL Google indexes.

The seasonal case is the one people get backwards. They 301 the promo page in February, then in October they build a brand-new URL because they forgot the redirect existed — and now the old, still-ranking URL bounces visitors to a page with no promo on it. Use a 302, put a calendar reminder on the date you remove it, and the page comes back with its history intact.

Should you redirect duplicate city pages or canonical them?

Redirect them if you are killing them; canonical them only if users still need to reach them. Google lists both redirects and rel=canonical annotations as 'strong' canonicalization signals in its duplicate URL guidance, but they do very different things to the visitor: a redirect makes the URL unreachable, and a canonical leaves it fully browsable.

For a service-area business with three thin, near-identical city pages, the honest answer is usually neither-then-both: rewrite one page properly, 301 the other two into it. Canonicalizing three thin duplicates just makes Google ignore two thin pages instead of indexing them — the thinness is still the problem. See our guide to location pages that avoid doorway penalties for what a page has to contain to justify existing at all.

If the pages have to stay live — a franchise requires them, or paid ads send traffic there — use rel=canonical and accept that only one will rank. And if the duplicates are competing for the same term rather than duplicating each other, that is a different problem: keyword cannibalization, not a redirect problem.

What is a redirect chain and how much is it costing you?

A redirect chain is a URL that redirects to a URL that redirects again, and Google's crawlers follow only up to 10 hops by default before giving up. Google's status-code documentation says it plainly: 'By default, Google's crawlers follow up to 10 redirect hops.' Hit that ceiling and the destination is never crawled at all.

You will almost never build a ten-hop chain on purpose. You build it in layers, over years, and every layer is invisible:

• The 2018 HTTP-to-HTTPS redirect (hop 1)
• The 2020 www-to-apex redirect (hop 2)
• The 2022 trailing-slash normalization your host added (hop 3)
• The redirect plugin rule from the 2023 URL rename (hop 4)
• A second plugin, installed by a different agency, redirecting the renamed URL again after the 2025 redesign (hop 5)

That is a real five-hop chain assembled from five reasonable decisions. Each hop is a full round trip on the user's connection before a single byte of your page renders — on mobile that is real latency against Google's Core Web Vitals threshold of an LCP under 2.5 seconds, measured at the 75th percentile of real page loads (Google, web.dev). A redirect chain does not just cost crawl budget. It costs your slowest users the most, and they are the ones on a phone in a driveway looking for an emergency plumber.

The other failure mode is the loop: page A redirects to B, B redirects back to A. Nobody ever sees the page again — not Google, not a customer. Loops are usually born when two plugins each own a rule for the same URL.

How do you find and flatten the chains your plugins built?

Flattening a chain means one rule: every old URL points directly at the final destination in a single 301. No intermediate hops. Here is the sequence we'd run on a service-business site that has been through two redesigns.

• Crawl the site with redirects followed. Screaming Frog's 'Redirect Chains' report (free up to 500 URLs) lists every chain, its hop count, and the final status. Sitebulb and Ahrefs Site Audit produce the same report.
• Export the chain report and keep two columns: the original URL and the final 200-status destination. Everything in between is noise you are about to delete.
• Rewrite each rule to point source directly at final destination. Delete the intermediate rules. Where two plugins both own rules, consolidate into one — server-level rules in .htaccess or your host's redirect manager beat a PHP plugin, because they resolve before WordPress boots.
• Re-crawl and confirm every source URL now returns a single 301 to a 200. If you still see a 301 → 301, you missed a rule.
• Check Search Console's Pages report for 'Page with redirect' and 'Not found (404)' counts before and after. The numbers should move within a few weeks.

One caution: never delete redirect rules you have not replaced. An old URL still holding backlinks is an asset. Flatten the chain, do not cut the rope. If your redirect file is a decade of accumulated guesswork and you are not sure what is load-bearing, that is exactly what a technical SEO audit is for.

Redirects are the least glamorous work in SEO and one of the few places where a single wrong character costs you rankings you already earned. If you want someone to open your redirect file, crawl the chains, and tell you exactly which rules are bleeding you, that is what our technical SEO service does. Get my free audit and we will start with the chains.