What each redirect actually means
HTTP status codes are the three-digit numbers servers send back to browsers explaining what happened with a request. HTTP status codes in the 200 family mean success. Codes in the 300 family mean redirect: the requested URL has moved, here is where to find it.
A 301 Moved Permanently says: this URL is gone for good. Send everyone to the new URL instead. Search engines should transfer indexing, links, authority and rankings to the destination. Browsers can cache the redirect aggressively because it is not coming back.
A 302 Found (originally "Moved Temporarily") says: this URL is just away for now. Send users to the new URL but remember the original. Search engines should keep the old URL in the index, not transfer rankings, and continue checking the original. Browsers do not cache aggressively because the situation may change.
Two more codes worth knowing exist but matter less in practice. A 307 Temporary Redirect is the modern, stricter cousin of the 302. A 308 Permanent Redirect is the modern, stricter cousin of the 301. For SEO purposes, Google treats 308s like 301s and 307s like 302s. Use the older codes unless you have a specific reason not to.
Why the choice matters
The choice between 301 and 302 controls how Google moves your rankings.
When you 301 from A to B, Google eventually drops A from the index, treats B as the canonical, and transfers all the link signals A had earned over the years. Within four to six weeks, B is ranking where A used to. The transition is clean.
When you 302 from A to B, Google keeps A in the index, keeps the rankings on A, and treats B as a transient destination that does not need its own index entry. If the move was actually permanent, this is a disaster. You have a URL that loads B's content but Google still indexes A, and B never inherits anything. Six months later you wonder why the migration "did not work".
One historical caveat that still trips people up. Google used to publicly say a small amount of authority leaked through a 301. The current public position from Google is that 301s pass 100 percent of signals. We have run enough migrations to back that up: clean 301s recover rankings to within a hair of the original, often inside a fortnight. The "lossy 301" rumour is folklore now.
When to use a 301
Almost every redirect on a normal website should be a 301. The list of common cases:
- URL changes during a site redesign or replatform. Old slugs to new slugs, every single one.
- HTTP to HTTPS migration. Each old
http://URL 301s to the matchinghttps://URL. - www to non-www (or vice versa). Pick one canonical version. 301 the other.
- Trailing slash normalisation. Pick one pattern. 301 the other.
- Domain change. Old domain 301s to new domain at the URL level (not just the homepage).
- Page deletions where there is a closest-relevant replacement. Old product page 301s to the new product page or the parent category.
- Product consolidation. Three near-duplicate product pages merged into one. The two retiring URLs 301 to the survivor.
- Internationalisation cleanup. Stale country variants 301 to the surviving regional URL.
For migrations specifically, every single old URL needs its own line in the redirect map. Mapping every old URL to the homepage is the lazy version and bleeds rankings everywhere. The full process is in the site migration checklist.
When to use a 302
The honest list of when a 302 is the right call:
- A/B testing two URL variants. You want both URLs to keep ranking individually until the test concludes.
- Maintenance pages. The real URL is down for an hour or a day. The maintenance page is the temporary target.
- Holiday or campaign landing pages. The brand's
/promotionsURL points at the Christmas page in December and the Easter page in March. - Geo-targeting routes. The homepage 302s users to the closest regional variant based on their location. The original URL is canonical; the geo-destination is transient.
- Logged-in vs logged-out variants of the same URL. Where a logged-out user is sent to a different URL than a logged-in user.
- Out-of-stock product pages that you plan to bring back. 302 to the parent category while the page is paused.
For most Perth small businesses, the only 302s you ever ship are maintenance redirects and the occasional A/B test. Everything else is a 301.
Redirect chains and loops
A chain is when one redirect leads to another redirect. A loops back to B which redirects to C which redirects to D. Each extra hop costs you.
The user pays in time: each hop is another DNS lookup, another TCP handshake, another HTTP request. Two-hop chains add 200 to 500ms on a mobile connection. Three-hop chains add 500ms to a full second. That extra latency feeds into your Core Web Vitals and your bounce rate.
Google pays in crawl budget. Each hop in the chain is a separate fetch. A site with 4,000 internal links going through two-hop chains is asking Googlebot to do 12,000 fetches to crawl 4,000 pages. The chapter on crawl budget covers why this matters for larger sites.
Your rankings pay through small but consistent signal leakage. Google honours redirects up to about 10 hops and gives up beyond that, but well before 10 it starts treating long chains as low-quality. The rule we use: zero chains where possible, one extra hop tolerated, two extra hops needs a justification.
The fix is to update the original redirect to point directly at the final destination. If A 301s to B and B 301s to C, change A to 301 directly to C. Run a Screaming Frog crawl, filter by status code 301, and look at the "Redirect Chains" report. Update one chain at a time.
Redirect loops are the worst case. A redirects to B. B redirects to A. The user sees a "too many redirects" error and the page never loads. Loops happen most often when conflicting redirect rules are added by different developers over time. The fix is to find both rules, decide which one is correct, and delete the other.
Common mistakes
- Use a 301 by default unless you can name a specific reason for a 302.
- Maintain a redirect map spreadsheet that lists every redirect on the site.
- Update internal links to skip the redirect hop.
- Audit redirects every quarter with Screaming Frog. Look for chains over two hops.
- Map every old URL to a specific replacement during migrations. Never map everything to the homepage.
- Use 302s for permanent moves. The signals stay stuck on the old URL.
- Chain redirects through three or more hops. Each hop hurts.
- Forget to redirect old URLs after deletion. The 404 wastes any backlinks pointing at them.
- Redirect everything to the homepage during a migration. It is the laziest possible answer.
- Implement redirects in JavaScript instead of via HTTP server config. Googlebot may not follow them reliably.
Tools and checklists
- Screaming Frog. Free up to 500 URLs. The "Response Codes" report and the "Redirect Chains" tab are the workhorse. Identify every chain in a single crawl.
- Browser dev tools. Network tab, preserve log enabled. Visit a URL and watch the redirect chain in real time. Useful for spot checks.
- HTTP status code checkers. Free online tools that report the status chain for any URL.
- Search Console URL Inspection. Shows the canonical URL Google chose and any redirect chain it encountered.
- Our free SEO audit tool. Flags redirect issues alongside the broader audit. Run a free audit.
Perth and WA context
The three redirect patterns we see most often on Australian sites.
The HTTPS migration leftover. A Perth business migrated from HTTP to HTTPS five years ago. The 301 redirect rule was set up correctly at the time. But every internal link inside content was still pointing at the old http:// URL. Every click on an internal link goes through the 301 hop. Multiply by 800 internal links and your crawl budget and Core Web Vitals both quietly suffer. The fix is a find-and-replace in the database to update internal links to use the canonical https:// URL.
The "everything goes to the homepage" migration. A Mandurah business migrated from an old domain to a new one. The developer set up a single redirect rule that sent every old URL to the new homepage. Result, 200 backlinks pointing at old service pages all hit the homepage instead of the new service pages. Authority for the service pages started from zero. Six months later they were still rebuilding rankings they would have inherited automatically with a real redirect map. We have inherited this exact pattern at least five times.
The accumulated redirect chain. A Joondalup e-commerce site that has been through three platform migrations in eight years. The 2017 redirect chains to the 2020 redirect chains to the 2024 redirect. Three hops on every URL the customer typed in. The site is slow, the crawl budget is wasted, and authority is leaking. The fix is to consolidate every chain to a single hop pointing at the current destination. A day's work for a developer with the redirect map spreadsheet handy.
One pattern across all three. The redirects worked when set up. Nobody re-audited after later changes. Layers accumulated. The audit is the first time anyone has looked at the full redirect map in years. The findings are not exotic; the fixes are not glamorous; the recovery in crawl efficiency and page speed is consistently real.
Related guides
- Back to the Technical SEO pillar for the 12-chapter index.
- The technical SEO audit. Stage five is redirects.
- Site migration checklist. The big one for redirects.
- Canonical tags explained. The other canonical signal.
- HTTPS and SSL for SEO. HTTPS migration is the most common redirect scenario.
- Crawl budget explained. Redirect chains burn crawl budget.
- Internal linking strategy. Internal links should skip redirects entirely.
- URL structure best practice. Good URL choices reduce future redirects.
