301 Redirects: When to Use Them and SEO Pitfalls
You changed a URL. Maybe one blog post, maybe your whole site during a replatform. Somewhere out there, Google still has the old address in its index, other sites still link to it, and every visitor who follows one of those paths is about to hit either the right page or a dead end. Which of the two they hit depends on a single line of server configuration.
That line is a 301 redirect. Handled well, it quietly transfers years of accumulated rankings, backlinks, and traffic to a new address. Handled badly, it leaks that equity one hop at a time, or dumps it entirely by pointing everything at your homepage.
This guide covers what a 301 does, whether redirects can hurt your SEO, how link equity moves through them, when a canonical tag beats a redirect, a migration playbook, the mistakes we see in almost every audit, and how to check your own redirects with free tools.
What a 301 redirect is and when to use it
A 301 is an HTTP status code your server returns before any page content loads. It tells the requester, browser or Googlebot, that the URL moved permanently and gives the new address in a Location header. Browsers follow it instantly. Search engines do more: over the following weeks they replace the old URL in their index with the new one and consolidate its ranking signals onto the destination.
Permanence is the defining trait. That one word "permanently" is what authorizes Google to transfer everything the old page earned.
Use a 301 for SEO whenever a URL changes for good and a real replacement exists:
- Renamed or restructured URLs.
/services/ppc-management-2022becomes/services/ppc-management. One redirect, done. - HTTP to HTTPS. Every
http://address should 301 to itshttps://twin, handled once at server level rather than page by page. - www vs non-www. Pick one host and redirect the other, so Google indexes a single copy of each page.
- Merged content. Two overlapping posts become one deep guide; both old URLs 301 to it. This is a standard move when fixing keyword cannibalization.
- Domain changes. Rebrand, acquisition, or a country-code switch. Each old URL maps to its equivalent on the new domain, page to page.
- Retired pages with a clear successor. An old pricing page redirects to the current plans page because a visitor landing on either wants the same answer.
One condition ties all of these together: the destination has to serve the same intent as the source. When it does, signals flow. When the target is unrelated, Google often ignores the redirect and treats the old URL as a soft 404, which passes nothing.
Are 301 redirects bad for SEO?
No. Google applies no penalty of any kind to 301 redirects. A redirect is standard web plumbing that Google has processed for decades, and sites with thousands of clean 301s rank fine.
The penalty myth has two roots. First, an old rumor that each redirect lost around 15% of PageRank, similar to an outbound link. Google's Gary Illyes stated publicly in 2016 that 3xx redirects no longer lose PageRank, and Google has repeated the position since. Second, people see traffic drop after a migration and blame the redirects themselves, when the real culprits are almost always missing redirects, chains, changed content, or old URLs pointed at irrelevant targets. The tool was fine; the implementation was sloppy.
A correct 301 is neutral to positive for SEO. The risk lives entirely in execution, and the rest of this guide is about that execution. One caveat on timing: even a clean migration usually produces ranking turbulence for a few weeks while Google reprocesses the moved URLs. That wobble recovers. A drop that persists past two or three months signals a real problem worth auditing.
Do 301 redirects pass link juice? What happens to your backlinks
A page that spent three years earning links from industry blogs, directories, and press mentions holds equity you cannot rebuild on demand. When its URL changes, those links point at the old address, and the 301 is the mechanism that forwards their value.
Google's current position: a 301 passes PageRank roughly in full, with no damping factor for the hop itself. Treat that as the working assumption while respecting three conditions that decide whether the transfer actually happens:
- Relevance. The destination must answer the same query as the source. Redirect a guide about LinkedIn ads to a page about email tools and Google is likely to classify it as a soft 404 and pass little or nothing.
- Directness. Equity moves reliably through one hop. Stack redirects into chains and you add latency, crawl waste, and failure points (more on chains below).
- Stability. Signals consolidate over weeks, and old backlinks keep resolving through the redirect for years. Remove the 301 too early and every one of those links starts hitting a 404.
Two practical notes on backlinks. Where you have a relationship with a linking site, ask them to update the link to the new URL; a direct link always beats a redirected one. And after any migration, pull your top linked pages from Search Console's Links report and verify each one redirects correctly, because those pages carry a disproportionate share of your authority.
One warning: buying expired domains to 301 their backlinks at your money site is an old manipulation tactic. Google is good at ignoring these redirects, and at worst the pattern draws a manual action. Redirect domains you legitimately operated; skip the shortcuts.
Canonical vs 301 redirect: which one to use
Both tools tell Google "treat this other URL as the main one", which is why they get confused. The difference is what happens to the visitor.
A 301 redirect physically moves people. The old URL stops serving content; everyone lands on the new address. Use it when the old page should cease to exist.
A canonical tag (rel="canonical") leaves both pages live and readable. It is a hint in the HTML head that says "index that other URL instead of me". Users can still open either version. Use it when duplicates must keep working: URLs with tracking parameters, printer-friendly versions, a product reachable under two category paths, or syndicated content pointing back at your original.
The decision rule fits in one question: does anyone still need to load the old URL? If no, 301. If yes, canonical.
Two more differences worth knowing. A 301 is a directive that Google almost always obeys, while a canonical is a suggestion Google can override when other signals disagree (Search Console shows "Duplicate, Google chose different canonical" when that happens). And a canonical does nothing for a visitor holding an old bookmark, since it never redirects anyone.
Teams sometimes lean on canonicals during migrations because implementing 301s on their platform is awkward. Resist that. For a permanent move, the 301 is stronger, faster to consolidate, and unambiguous.
301 vs 302 vs 404 vs 410: choosing the right response
Every URL you retire needs one of a handful of responses. The quick comparison:
| Option | What it tells Google | Ranking signals | Use when |
|---|---|---|---|
| 301 redirect | Moved permanently, index the new URL | Transferred to the destination, roughly in full | URL changed for good and an equivalent page exists |
| 302 redirect | Moved temporarily, keep the old URL indexed | Stay with the original URL | Maintenance, A/B tests, seasonal swaps, geo routing |
| Canonical tag | Both URLs work; index the canonical one | Consolidated onto the canonical (a hint, can be ignored) | Duplicates that must stay accessible to users |
| 404 Not Found | Nothing here, might be an error | Dropped after repeated crawls | Page gone, no replacement, cause unknown or accidental |
| 410 Gone | Deliberately removed, will not return | Dropped, typically faster than a 404 | Page intentionally deleted with no equivalent |
301 vs 302. Google eventually treats a long-lived 302 like a 301, but "eventually" can mean months of the wrong URL sitting in the index. State your intent correctly from day one: 301 for permanent, 302 only when the original URL genuinely comes back.
301 vs 404. The choice hinges on one thing: does a real replacement exist? A 404 on a deleted page with no successor is healthy SEO; every site accumulates them and Google expects them. Forcing a redirect to a loosely related page just to dodge a 404 tends to earn a soft 404 classification anyway, so you gain nothing.
404 vs 410. A 410 is a more deliberate 404 and tends to clear URLs from the index a bit faster. Useful when pruning large batches of thin or expired pages on purpose. For the occasional dead page, a plain 404 is fine.
Avoid meta refresh and JavaScript redirects wherever SEO matters. They are slower, they depend on rendering, and search engines interpret them less reliably than a server-side 301.
Redirect chains and loops
A chain is URL A redirecting to B, B to C, C finally landing on D. Nobody builds one on purpose. They accrete: the 2019 restructure added a layer, the HTTPS move another, last year's rebrand a third, and no one ever flattened the stack.
Chains cost you three ways. Each hop adds latency for real users, which compounds on mobile and feeds the metrics covered in page speed and Core Web Vitals. Each hop burns crawl budget. And Googlebot follows a limited number of hops (Google documents up to 10, and fewer is safer), so a long chain can mean the destination never gets credited at all.
The fix is mechanical. Crawl your site, list every redirect pointing at another redirect, and update each rule to target the final destination directly. Repeat once or twice a year, because chains regrow.
Loops are the pathological cousin: A redirects to B and B back to A. Browsers give up and show an error, so a loop takes pages fully offline. Nearly every loop we see comes from two rule sets fighting, typically a www rule at the CDN arguing with an HTTPS rule in the application. After any config change, test a handful of URLs end to end.
301 redirects and SEO in a site migration: the playbook
Migrations are where redirect work concentrates, and where the stakes peak. New domain, new CMS, new URL structure, or all three at once: each replaces hundreds or thousands of indexed URLs, and every one needs a mapped destination. The sequence that protects rankings:
1. Crawl the old site before touching anything. Run Screaming Frog (or any crawler) across the live site and export every URL returning a 200. This list is your source of truth; you cannot redirect what you never recorded. Supplement it with URLs from Search Console, your XML sitemap, and analytics, because crawlers miss orphaned pages that still earn traffic.
2. Build the redirect map. A two-column spreadsheet: old URL, new URL. Map one to one wherever a true equivalent exists. Sort by organic traffic and referring domains so your highest-value pages get the most careful mapping. Pages with no successor get marked 410 rather than forced into a bad redirect.
3. Implement redirects server-side. Apply the map in .htaccess, Nginx config, your CDN's rules engine, or your platform's redirect manager. Use pattern rules for structural changes (a folder rename can be one regex instead of 500 rows) and explicit rules for everything irregular. Confirm every rule returns a 301, since several platforms default to 302.
4. Test on staging. Run your old URL list through a crawler in list mode against staging. You are checking four things: status is 301, destination matches the map, no chains, no loops. Spot-check each template type by hand.
5. Launch, then monitor for weeks. Keep the old XML sitemap available temporarily so Google recrawls old URLs and finds their redirects faster, and submit the new sitemap alongside it. Watch Search Console daily: page indexing for 404 and soft 404 spikes, performance for pages losing clicks. Fix misses as they surface, because there will be misses.
6. Update what you control. Point your own internal links, ads, email templates, and social profiles at new URLs directly instead of riding the redirects.
Redirect mapping is one slice of a migration; the broader checklist (content parity, tracking, performance, rendering) belongs to technical SEO as a discipline. But when migrations go wrong, the redirect layer is the most common failure point, so it earns disproportionate attention.
Common 301 redirect mistakes
The same handful of errors shows up in audit after audit.
Redirecting everything to the homepage. Faced with 800 old URLs and a deadline, someone points the entire list at the root domain. Google classifies those as soft 404s, passes no equity through them, and drops the old URLs from the index just as if they had 404ed. Map each URL to its closest equivalent, and let true orphans return a 410.
Chains from stacked rule sets. Hostname rules, protocol rules, trailing-slash rules, and page-level rules each add a hop. Order your rules so any URL resolves in a single redirect.
Conflicting http/https and www rules. The classic loop generator. When HTTPS enforcement lives at the CDN and www enforcement lives in the application, certain URL patterns bounce between the two forever. Consolidate protocol and hostname handling in one layer.
Internal links left pointing at redirected URLs. After a migration, your own menus, footers, and in-content links often still reference old addresses, so every click takes an extra hop and every crawl wastes budget. Update them at the source; this overlaps with routine internal linking hygiene and pays off in both crawl efficiency and speed.
Irrelevant targets. A deleted service page redirected to whatever seemed vaguely related fails Google's relevance check, gets treated as a soft 404, and the equity you were trying to save evaporates.
Removing redirects too early. Six months after a migration someone "cleans up" the redirect rules, and every backlink pointing at old URLs starts hitting 404s. Keep migration redirects for years. A redirect rule costs nothing to keep; severed backlinks cost real authority.
Case and parameter blind spots. /Blog/Post and /blog/post are different URLs to a crawler, and so are versions with and without query strings. If your old site mixed cases or served content on parameterized URLs, your rules need to catch those variants too. Easy to miss until you crawl your external backlink targets and find hundreds of 404s.
How to audit your redirects
You can verify most of this with free tools in an afternoon.
curl for single URLs. curl -I https://yoursite.com/old-url prints the response headers: the status code and the Location target. Follow the location manually, or use curl -IL to trace the whole path in one command and count hops. Two or more 301 lines in the output means you have a chain.
Screaming Frog for bulk checks. Paste your old URL list into list mode with "always follow redirects" enabled, and the redirect chains report shows every hop, final status, and loop. The same crawl in normal mode reveals internal links that point at redirecting URLs. The free tier covers 500 URLs.
Google Search Console for Google's own verdict. The URL Inspection tool shows how Google sees any specific address, including "Page with redirect" status, and the page indexing report surfaces soft 404s, redirect errors, and 404 spikes sitewide. One clarification for anyone searching "301 error in SEO": a crawl tool listing a URL as "301" is reporting a status, and a status by itself is healthy. It becomes a problem only when the redirect is unintentional, chained, looping, or pointing somewhere irrelevant.
Audit cadence: after every migration or config change, then once or twice a year as maintenance. Redirects rot quietly, and the decay never announces itself.
Frequently asked questions
Do 301 redirects hurt SEO?
No. Google applies no penalty to 301 redirects, and a correct one passes ranking signals to the destination roughly in full. Damage only comes from bad implementation: chains, loops, missing redirects, or irrelevant targets.
How long should I keep 301 redirects in place?
Treat migration redirects as effectively permanent. Google consolidates signals within weeks to months, but backlinks and bookmarks keep sending traffic through old URLs for years, and removing the redirect turns all of it into 404s. Keep rules live for a minimum of one year, and indefinitely for any URL with meaningful backlinks.
301 vs canonical: which one should I use?
Ask whether users still need to load the old URL. If the page should stop existing, use a 301: it moves visitors and transfers signals decisively. If both versions must stay accessible (parameter URLs, print versions, cross-listed products), use a canonical tag. For permanent moves the 301 always wins, because a canonical is a hint Google may ignore and it never helps a visitor with an old bookmark.
Do 301 redirects pass link juice from backlinks?
Yes. Google has confirmed that 301s pass PageRank without a damping loss, so backlinks pointing at a redirected URL keep benefiting the destination, provided the target is relevant and the path is a single hop. Where you can get a linking site to update the link directly, do it anyway.
What does a "301 error" in my SEO tool mean?
It usually means the tool found URLs responding with a 301 status, flagged for your review rather than as a fault. A redirect is normal behavior. Investigate only when the flagged redirects are unintentional, form chains or loops, or when internal links are the thing pointing at them.
Should I redirect deleted pages to my homepage?
No. Without a relevant equivalent, a homepage redirect gets classified as a soft 404, passes no equity, and frustrates visitors who expected something specific. Redirect to a true replacement when one exists; otherwise return a 410 and let the URL leave the index cleanly.
Before you flip the switch: a 301 checklist
Run through this before any URL change or migration:
- Every live old URL is captured (crawler, Search Console, sitemap, analytics).
- Each old URL maps to a genuinely equivalent new URL, or is deliberately marked 410.
- Redirects are server-side 301s, status code confirmed (some platforms default to 302).
- Every rule points at the final destination in one hop, with no chains.
- Protocol, hostname, and trailing-slash rules live in one layer and cannot loop.
- Internal links reference new URLs directly.
- A staging test covered every template type, and Search Console monitoring is planned for launch week.
- Redirect rules are documented somewhere the next developer will find them.
Redirects are unglamorous work, and they decide whether a site change keeps its rankings or donates them back to Google. If a migration is on your roadmap and you want an experienced set of eyes on the redirect map before launch, ask Lead The Way for a short technical review. Checking a spreadsheet takes an hour; rebuilding lost rankings takes months.