A site moves to new URLs, the redirects go in, and three weeks later organic traffic is down a third. Nobody in Search Console has written a letter. The question that arrives at that point is whether Google penalized the redirects, and the answer is almost always no, which turns out to be the less comfortable answer: a penalty would come with a report and a fix. What happened instead is that Google read the redirect’s claim, this page has permanently moved there, checked it, and where the claim didn’t hold, passed nothing through. The redirect wasn’t punished. It was ignored, and the signals the old URL carried went with it.
That is the whole of the “301 redirect SEO penalty” question. Google almost never penalizes a redirect; it evaluates one, and the evaluation can come back negative in five ways, four of which happen on ordinary migrations by people who were trying to do it right. One redirect practice still ends in a manual action, and it’s about deceiving users, not about status codes. Each of the five is diagnosable from the outside if you know which report to open, and the report is the last section.
How Google evaluates a 301 redirect
A 301 is an HTTP status: the resource at A is now permanently at B. Google’s documentation treats a permanent redirect as a canonicalization signal, meaning B should replace A in the index and the signals attached to A, links and ranking history, should consolidate onto B. In 2016 Gary Illyes and then John Mueller said on record that 3xx redirects lose no PageRank, and the industry has read that since as “a 301 transfers everything.” It transfers everything when the claim is true. Mueller’s 2017 line on redirecting 404s was that it makes sense when there’s a genuine replacement URL, and otherwise Google will likely treat the redirect as a soft 404. That sentence is the model: the redirect is evaluated against whether B answers what A answered.
The status code matters less than the volume of “301 vs 302” writing suggests. Google’s redirect documentation puts the types on a spectrum:
- 301 and 308: strong signals that the target is canonical.
- 302, 303 and 307: weak signals, though a temporary redirect left in place long enough gets treated as permanent.
- Meta refresh: a zero-second delay is read like a permanent redirect, a longer one like a temporary redirect.
- JavaScript redirect: read only after rendering, which is why Google’s own advice is to use it only where a server-side redirect is impossible.
After the type is read, every one of them is evaluated the same way, and none of it happens the day the redirect ships. Google reads a redirect by recrawling the source on the source’s own schedule: a URL Googlebot fetched daily gets its redirect read within days; a page it last visited in the spring gets read when it comes back. Consolidation follows that recrawl, and until then the old URL is still the one in the index. Google’s site-move guidance gives the other end of the window: keep the redirects in place for at least a year, because consolidation isn’t a single event, and a redirect that lapses at month six takes what it had passed with it. For a whole-domain move there’s a second signal on top of the 301s, the Change of Address tool in Search Console, which Google holds for 180 days.
ZERO VERSUS PENALTY
Google’s spam systems mostly don’t punish link and redirect manipulation. They neutralize it: the links or the redirected signals are treated as if they weren’t there. Google said so in December 2022, announcing that SpamBrain could detect sites buying links and sites that exist to pass links, and that such links would be neutralized. A neutralized signal produces no notification, no manual action and no drop. The lift doesn’t arrive. The one redirect practice that still draws a manual action is further down, and it’s about deceiving users.
Failure 1: soft 404, the target doesn’t replace the source
The most common zero, and it hits ordinary migrations as often as schemes. Redirect a product page to the homepage, a category to a loosely related category, a hundred retired blog posts to the blog index, and Google’s site-move documentation says what happens: redirects to pages that don’t replace the original are treated as soft 404s. A soft 404 is a page Google has decided is empty regardless of the status code, so the old URL drops out of the index the way a 404 would, and the links pointing at it pass nothing to the destination. In the SERP, nothing visible happens; the destination ranks as it did, and the rankings the old URL had are simply gone.
What passes the test is a redirect map, old URL to the one page that answers it, built before the migration and checked after. The matching is done on what the source ranked for, not on what its URL looked like: for each old URL, the top queries from Search Console’s sixteen-month window, then the new page that would satisfy them. The rule differs by page type. A discontinued product goes to its direct replacement, and to the parent category only when there is none; a store that lost its one-to-one mapping and sent every old product URL to the category root loses the long tail of product queries, which on most catalogues is most of the organic traffic. A blog post whose URL lost its date segment goes to itself at the new address; three thin articles merged into one go to the merged piece, provided the merged piece actually contains what each of them answered. Only a page with no successor gets a 410. The mass rule, everything to the homepage, everything to the parent, is a shortcut the check reads as a soft 404 a thousand times over, and it’s where most of the “301 penalties” I get asked about turn out to live.
How it surfaces: the source URLs show as Soft 404 rather than Page with redirect in Page indexing, if the property covers them, and the destination’s Links report never picks up the referring domains that pointed at the source.
Failure 2: the source is blocked from Googlebot
A redirect is read by fetching the source. If Googlebot can’t fetch it, there is no redirect as far as Google is concerned, only a URL it was told not to request. The usual cause is a robots.txt Disallow on the old domain, left from staging or added to keep the old site out of the SEO tools; a 301 behind a Disallow passes exactly as much as a 301 on a switched-off server. IP blocking does the same when a firewall rule covers Google’s ranges, which are published as JSON (googlebot.json on developers.google.com) and should be allowlisted from that file rather than from a reverse-DNS guess. Geo-blocking does it too: Google’s documentation says Googlebot crawls primarily from US addresses, so an old domain that only answers from one country is one Google never reads.
How it surfaces: Blocked by robots.txt on the source in Search Console, or in the logs, no Googlebot request to the source URL at all. Two checks resolve it in minutes: the source’s robots.txt fetched directly, and the source URL fetched with a Googlebot user agent from a US address.
Failure 3: redirect chains and loops
Google’s documentation says Search follows up to ten redirect hops; past that the URL shows as Redirect error and the destination is never reached. Ten is more generous than the three to five in older guides, and the 2016 statement holds at every hop: 3xx doesn’t leak PageRank. The cost of a chain is elsewhere. Every hop is a fetch, a chain of five means five requests before Google sees content, crawl spent on hops isn’t spent on pages, and a chain long enough to be accidental usually has a loop or a dead hop somewhere that nobody walked end to end.
Most chains aren’t deliberate. The one I find on nearly every migration is four hops before the redirect anyone actually wrote:
http → https → www → trailing slash → the intended target
Each rule was added at a different time and none of them knows about the others; on a domain move the source’s protocol and host rules stack on top of the destination’s, and a map that looked like one hop on paper runs six in production. Screaming Frog’s Reports → Redirects → Redirect Chains lists every chain with its hop count and final status, and that export is the first thing I open on a migration.
How it surfaces: Redirect error when the chain exceeds the limit or loops; otherwise Page with redirect with the final destination listed. If the final destination in Search Console isn’t the one you intended, the chain broke somewhere, and you’ve been redirecting into the break.
Failure 4: the migration around the redirect
The redirects are correct and the traffic still fell, and the reason is in the rest of the migration. These are the causes behind most post-migration drops that get reported as a penalty, and none of them is the 301.
- Internal links still point at the old URLs. Navigation, footers, the body of every article, the related-posts widget. Each one sends users and Googlebot through the redirect on every visit, and a crawl of the new site lists them in minutes. A 301 exists for the links you don’t control; your own links go straight to the destination.
- The sitemap lists the old URLs, or the new ones alongside the old. The sitemap should contain final, 200, canonical URLs and nothing else, regenerated on launch.
- The destination’s canonical points back at the source. A template that carries the old domain in its canonical field, or a CMS that kept the previous URL. Google is then told two contradictory things about the same page and picks one, and it isn’t always yours. URL Inspection on the destination shows which canonical Google selected.
- 302 where 301 was meant. A CDN default, a plugin setting, a framework that returns 302 for every redirect. Google eventually treats a long-lived 302 as permanent, but “eventually” is the weeks you’re reading as a penalty.
- Three redirect layers that disagree. The CDN redirects one way, the server config another, the CMS plugin a third, and the result depends on which layer answers first. One redirect layer owns the map; the others are empty.
- Redirects removed too early. A hosting change at month five takes the old domain offline, and everything consolidated so far reverts. A year is the floor Google gives; longer costs nothing.
- The page changed along with the URL. A redesign that moved the URL, rewrote the title, cut the text in half and dropped a block the page ranked for is four changes shipped as one, and the redirect gets blamed for the other three. Where the whole site fell on one date, with or without redirects, the diagnosis is the one in the website rankings loss audit, and the redirect map is only its fourth step.
Failure 5: the redirect was bought, not earned
Two schemes rely on a 301 to forward weight the destination didn’t earn, and both fail the same check as a product page redirected to the homepage.
The first is the expired domain. Since March 2024, Google’s spam policies name expired domain abuse as its own violation: buying a lapsed domain and repurposing it primarily to manipulate rankings on its old reputation. The documentation’s examples are blunt, casino content on a former school’s domain, affiliate pages on a domain that belonged to a government agency, and few people try those. The version that still gets tried is the “topical” one: a construction domain bought to redirect into a construction site. A matching category isn’t enough. A domain that spent eight years selling ready-mix concrete in one city carries anchors and linking neighbours about concrete; redirect it at a site that sells PVC windows in another city, and at the level of a category tree both are “construction,” while at the level of what the pages and the links are about they share almost nothing. The inbound links say concrete, the destination says windows, and the redirect is a soft 404 with a domain rating attached. The Wayback Machine’s per-year snapshot list is the cheap read of a donor’s history: what the site was about in each year, and the gaps, since a domain with snapshots through 2019, nothing until 2024 and then a fresh site was dropped and re-registered, and its links were earned by whatever was there before the gap. Rebuilding the old content before redirecting doesn’t change what the check reads; a concrete site restored from the archive is still about concrete.
The second is the redirect pipe for tiered links: thousands of forum-profile and comment links aimed at a layer of throwaway domains, each 301’d into the money site, chosen because a redirect was supposed to forward the weight while hiding the profile. It stops at two layers. Most of the bottom tier never enters the index, and a link that isn’t in the index isn’t in the link graph, so there’s nothing to forward however many hops it’s forwarded through. And a destination that suddenly inherits dozens of thin, new referring domains through 301s from domains with no history is the structure Google described in December 2022 when it said SpamBrain detects sites used to pass outgoing links. The forwarded signal is treated as if it weren’t there. The money site isn’t demoted for it; it doesn’t move, and with three spam updates so far in 2026 (March, June and August) and refreshes between them, a pipe that “works” is working in a gap measured in weeks.
The failures in one table
| What was done | What Google does | How it shows | Basis |
|---|---|---|---|
| 301 to an unrelated page or the homepage | Treats the source as soft 404; passes nothing | Soft 404 on the source; no new referring domains on the target | Google site-move docs; Mueller 2017 |
| Source blocked in robots.txt, by IP or by geo | Never reads the redirect | Blocked by robots.txt; no Googlebot hit in logs | Crawl mechanics; Googlebot US-origin docs |
| Chain past the hop limit, or a loop | Stops following; destination never reached | Redirect error; wrong final URL in Page with redirect | Google redirect docs (up to 10 hops) |
| Internal links, sitemap, canonical or 302 left pointing the old way | Reads conflicting signals; consolidates late or to the wrong URL | Old URLs still in results; Google-selected canonical ≠ destination | Canonicalization docs; site-move docs |
| Expired domain redirected at a site it isn’t about | Soft 404 at best; expired-domain-abuse enforcement at worst | Same as row one; occasionally a manual action | Spam policies, March 2024 |
| Tiered links forwarded through a redirect cascade | Bottom tiers never indexed; forwarded signals neutralized | Flat rankings; Links report unchanged | SpamBrain, December 2022 |
Does a penalty transfer through a 301?
The question runs both ways, and the answers differ.
From a penalized donor to a clean site. Mueller said in 2014 that he hadn’t seen a redirect from a penalized site hurt a clean one, and nothing since has changed that. Spam links on the donor are neutralized rather than transferred, which is the zero described above; the clean site gets nothing and loses nothing. If the donor’s link profile worries you, it can be disavowed in Search Console like any other, but the common outcome is that the redirect passes nothing and the question never arises.
From a penalized site to a new domain. This one transfers. A manual action attaches to the site, and a site that arrives on a new domain through redirects is still the same site to Google; Mueller has said on record that a manual action can follow a 301 to the new host. The “double 301” cleanse, redirecting through an intermediate domain to launder the history, doesn’t change what arrives. The only exit is the one printed in the Manual actions report: fix the cause, file the reconsideration request, wait for the review.
The one redirect that is a penalty. Sneaky redirects have been a named spam policy for as long as the policies have existed, and the definition says nothing about status codes. It’s about deception: showing Googlebot one page while sending users somewhere else, redirecting mobile users to an unrelated offer while desktop sees the original, JavaScript that lets the crawler read the content and then bounces the human to another domain. Hacked sites are the largest source, with an injected redirect to a pharmacy or a casino that fires only for certain user agents, and the manual action lands on the hacked site’s owner, who often learns of the injection from Search Console. The report lists Sneaky mobile redirects as its own line. The line between this and everything above is whether a user was misled. A 301 that passes nothing because the target doesn’t match is a bad decision Google ignores; a redirect that shows the crawler one thing and the visitor another is a lie Google punishes.
How to tell a 301 redirect penalty from a zero in Search Console
“Did we get penalized?” is the question asked after a redirect project and it’s usually the wrong one. The useful question is whether anything passed, and the penalty answer falls out of it.
A traffic drop after a migration isn’t evidence of a penalty, and a rise in a third-party authority score isn’t evidence that anything passed. Before reading either, exclude the boring causes in Failure 4; most “301 penalties” I’ve been asked to diagnose were one of those.
301 redirect penalty FAQ
Do 301 redirects lose link equity?
Not by being redirects. Google said in 2016 that 3xx redirects don’t lose PageRank, and that still holds. What loses equity is a redirect whose target doesn’t replace the source, which Google treats as a soft 404, or a source Google can’t fetch, or a chain it can’t finish. The percentage figures in older guides (85%, 90%, 99%) describe a mechanism Google retired that year.
How long should a 301 redirect stay in place?
At least a year, per Google’s site-move guidance, and there’s no cost to leaving it longer. Removing redirects when “the migration is done” is how a site loses in month seven what it kept in month three.
Can having thousands of 301 redirects hurt SEO?
Not as a number. Google has no limit on redirects per site. Thousands of redirects hurt when they’re chains, when internal links still enter them on every page, or when they all point at the homepage; thousands of clean one-hop redirects to matching pages are what a large migration looks like.
Can a 301 redirect transfer a penalty from an old domain?
From a penalized donor into a clean site, no: the donor’s bad links are neutralized, not passed on. From a penalized site onto a fresh domain, yes: a manual action follows the site through its redirects, and the reconsideration request is the only exit.
If a redirect project went flat and you want to know which of the five it was, that is what our SEO audit reads first.