The Blog Migration Looked Successful. Six Weeks Later Traffic Was Down 35 Percent. The Redirects Were Wrong.
A developer migrated the company blog from one domain to a new one. She set up redirects, verified the homepage loaded correctly on the new domain, and marked the migration complete. Six weeks later, traffic to the blog had dropped 35 percent. An audit revealed that 40 percent of the internal links were pointing to pages that redirected through three hops before reaching their destination. The link equity that had accumulated over four years of backlinks was being diluted at every step.
The problem was not the redirects themselves. It was the type of redirect and the number of hops. HTTP status codes are not cosmetic labels on a response. They are instructions to browsers and search engine crawlers about how to interpret the relationship between the old URL and the new one, and a wrong code at a single important URL can quietly cost months of accumulated ranking work.
To understand what went wrong in that migration, it helps to understand where redirect status codes come from, how they were designed to behave, and why the gap between their designed behavior and real-world crawler behavior creates ongoing confusion.
The Origin of HTTP Status Codes
The Hypertext Transfer Protocol's status code system was designed by Tim Berners-Lee and formalized in early web standards. HTTP/1.0, published as RFC 1945 in 1996, included a 302 status code for redirects but specified only that the client should not change the request method when following the redirect. This specification was almost universally ignored. Browsers receiving a 302 response to a POST request would issue a GET to the new URL instead of repeating the POST, which was convenient for form handling but technically non-compliant.
HTTP/1.1, defined in RFC 2068 in 1997 and revised in RFC 2616 in 1999, added 303 and 307 to resolve the ambiguity. The 301 code, which had existed as a permanent redirect in HTTP/1.0, was clarified to indicate that all future requests should use the new URL. In April 2015, RFC 7538 added 308, a permanent redirect that explicitly preserves the request method. This gives four redirect codes that matter for web work: 301 (permanent, method may change), 302 (temporary, method may change), 307 (temporary, method preserved), and 308 (permanent, method preserved).
The SEO-relevant distinction is between permanent and temporary. A 301 or 308 tells a search engine crawler to treat the new URL as canonical and to transfer ranking signals there. A 302 or 307 tells the crawler the original URL is still the real one and will return later. Using a temporary redirect for a permanent URL change means the original URL remains the indexed version while the new URL receives no authority transfer.
301 vs 302: Why the Status Code Shapes Search Rankings
When search engines encounter a 301, they transfer the authority associated with the old URL to the new destination. The commonly cited estimate is 90 to 99 percent of ranking signals pass through. John Mueller of Google has stated that the signal transfer from a 301 is not instantaneous and may take months for the full effect to consolidate, but the transfer does occur.
A 302 transfers no authority by design. Search engines treating a 302 as temporary will keep the original URL in their index and will not pass its accumulated link signals to the destination. The destination URL builds authority only from its own inbound links. If those do not exist yet, it starts from zero.
For a permanent domain migration, using 302 instead of 301 means the new domain is invisible to the link equity the old domain earned. The old domain remains technically indexed, split traffic appears on analytics, and the new domain builds ranking from scratch. Developers who configure redirects on a staging environment, where temporary redirects are appropriate because the URLs will change again, and then copy that configuration to production without changing the status codes create exactly this failure mode.
The 302 mistake is also easy to introduce by accident through CMS misconfigurations. WordPress, for example, has historically issued 302s when permalink structures are changed without proper configuration of the rewrite rules. Some CDN and load balancer configurations default to 302 for HTTPS enforcement redirects, meaning HTTP-to-HTTPS redirects that should carry ranking authority do not.
What Redirect Chains Actually Cost
A redirect chain occurs when URL A redirects to URL B, which redirects to URL C, continuing until the final destination. Each hop in the chain adds latency. A page that loads in 200 milliseconds with no redirects takes approximately 400 milliseconds with one redirect hop and 600 milliseconds with two, assuming each hop adds a round-trip time of around 100 milliseconds on a typical network connection. Google has cited page speed as a ranking factor since 2010 for desktop and 2018 for mobile, making latency from redirect chains a compounding problem.
Search engine crawlers also have a crawl budget, the number of pages they will process in a given period for a site. Crawling a five-hop redirect chain consumes the budget of five page requests while delivering content for one. For large sites with thousands of URLs, this inefficiency can leave newer or less-linked pages uncrawled.
The authority dilution through chains is the most damaging effect. A single 301 preserves approximately 90 percent of link signals. Two consecutive 301s preserve roughly 81 percent. Three hops: about 73 percent. By five hops, roughly 59 percent of the original authority survives. A URL with substantial backlink value that sits at the start of a five-hop chain delivers only about three-fifths of that value to the final destination. Five-hop chains are not unusual after multiple migrations where each migration added a new set of redirects on top of the previous one without consolidating the chain.
Google stops following redirect chains at approximately five hops. A chain longer than five means the final destination may not be indexed at all, making all the upstream redirects invisible to search engines regardless of their status codes.
Redirect Loops and Other Common Failures
A redirect loop occurs when URL A redirects to URL B, which redirects back to URL A. Browsers detect loops and return an error, typically "ERR_TOO_MANY_REDIRECTS" in Chrome. Loops are common after misconfigured HTTPS rewrite rules, where the HTTPS version of a URL redirects to itself, and after CMS URL migrations where both the old and new URL patterns match the same rewrite rule.
Another common failure is the soft 404, where a redirect to a destination that no longer exists returns a 200 status code on a generic error page rather than a proper 404. Search engines index the generic page, creating duplicate content and consuming crawl budget without delivering useful pages.
Mixed redirect chains, where a 301 is followed by a 302, behave as the weakest link. A chain with any temporary redirect in it behaves as if the entire chain is temporary, meaning the final destination receives no authority transfer from any of the upstream links in the chain.
How to Audit Before and After a Migration
The developer's migration was recoverable. The first step was checking the status codes at each step of every redirect chain on the migrated URLs, confirming that the migration had used 302s throughout instead of 301s. The second step was correcting the redirect configuration to return 301s. The third step was updating all internal links to point directly to the final destination URLs, eliminating intermediate hops. The fourth step was submitting the updated sitemap to Google Search Console to accelerate re-crawling.
Conclusion
Traffic recovered over the following two months. The sequence illustrates the value of auditing redirects before and after any URL change, not just checking that the final destination loads. A redirect checker that shows the status code at every hop, the URL at every intermediate step, the final destination, and the total latency of the chain surfaces these failures before they compound into months of lost rankings.
Critical URLs to audit include the homepage, all URLs listed in the XML sitemap, all URLs with inbound backlinks from external domains, and any URL that appears frequently in internal linking. Auditing only the homepage and assuming the rest are correct is the mistake that went undetected for six weeks in the migration above.
Frequently Asked Questions
What is the difference between a 301 and 302 redirect for SEO?
A 301 permanently redirects a URL and transfers 90-99% of its link authority to the new location. A 302 is temporary and transfers no authority, so the original URL remains canonical in search indexes.
How many redirects in a chain are too many?
Google stops following redirect chains at approximately 5 hops. Practically, even 2-3 hops add latency and dilute authority. A single direct redirect is always preferable.
What is a redirect loop?
A redirect loop occurs when URL A redirects to URL B, which redirects back to URL A. Browsers stop and return an error. They are common after misconfigured HTTPS rewrites or CMS URL migrations.