Do 301 redirects really transfer ALL SEO signals to the new URL?

What does Google say a 301 redirect actually transfers?

Google promises that 301 redirects transfer the majority of SEO signals from the old URL to the new one. Specifically, this includes PageRank, backlinks, domain trust, and even the disavow files you submitted.

The phrase 'as much as possible' remains deliberately vague. Google does not guarantee a 100% transfer, and some signals may dilute during the process. Crawl histories, some user behavior data, or temporal signals may not be fully preserved.

Why specify that disavowal is transferred?

This mention of the disavow file is not trivial. Before this clarification, many SEO professionals were unsure whether they needed to resubmit a disavow file after an HTTPS migration or a domain change.

Google confirms that you do not start from scratch: if you cleaned up your link profile before the migration, that work remains valid. The engine associates disavowals with the site entity, not just the original URL.

In what contexts does this rule apply?

Mueller explicitly mentions two use cases: site changes and moving to HTTPS. The first pertains to domain migrations or URL structure redesigns. The second has become nearly universal since Google has pushed for secure protocols.

However, the rule also applies to internal redirects, product URL changes, or content consolidations. Any properly configured 301 redirect triggers this transfer, as long as the signal is clear and the URLs are genuinely equivalent.

• PageRank and backlinks are transferred during a properly set up 301 redirect.
• Disavow files follow the URL and do not require resubmission.
• The transfer is never 100%: some temporal or behavioral signals may get lost.
• The quality of the migration (redirect chains, 404 errors, semantic consistency) affects the effectiveness of the transfer.
• Two main use cases: domain migration and moving to HTTPS, but applicable to any strategic redirect.

Is this statement consistent with what we see in practice?

Overall yes. Well-executed migrations show nearly complete authority transfer, often within a few weeks. Rankings stabilize quickly, backlinks continue to provide juice, and positions do not collapse.

But the devil is in the details. Poorly executed migrations lose traffic, and this is not due to the 301 redirect itself. Redirect chains, degraded response times, loss of semantic relevance between the old and new URLs: all of this sabotages the transfer. [To be verified] whether Google applies a gradual degradation factor on overly long redirect chains.

Which signals are NOT transferred after all?

Google talks about 'as many signals as possible', not all. Fresh behavioral data disappears: historical click-through rates on the old URL in the SERPs, accumulated visit times, or navigation patterns specific to that URL.

Temporal signals may also partially reset: a page published three years ago undergoing migration may lose its historical anchoring. Google might treat it as a 'new' URL for a while, even if the content is identical. [To be verified] whether the first indexing date strictly follows the URL or if it can be inherited.

Should we still worry during an HTTPS migration?

No, it's become a non-issue. The transition to HTTPS is considered a minor technical change by Google for years. The transfer is nearly instantaneous, and measurable losses are negligible if the configuration is clean.

The real danger does not come from the redirect itself, but from ancillary configuration errors: poorly installed SSL certificate, mixed content, canonical settings incorrectly pointed to the HTTP version. An HTTPS migration should today be seamless if you follow the basics. If you lose traffic after moving to HTTPS, it's not the fault of the 301, but of your technical implementation.

What should you check before launching a migration with 301 redirects?

Start by mapping all high-value SEO URLs: pages generating organic traffic, URLs with strong backlinks, content ranking for strategic queries. Ensure that each old URL points to a semantically equivalent new URL.

Test the redirects in a pre-production environment. Use a crawler like Screaming Frog to detect redirect chains (A → B → C), infinite loops, or hidden 404 errors. Ensure that the HTTP status codes are indeed 301, not 302 or 307 which do not offer the same transfer guarantees.

What mistakes should absolutely be avoided during a migration?

Never redirect en masse to the homepage. This is the worst mistake: Google detects that the semantic match is broken and may ignore these redirects. Each old URL should point to its logical equivalent, even if it requires manual mapping.

Avoid redirect chains that slow down crawling and dilute the transfer of signals. If URL A redirects to B which redirects to C, configure A to point directly to C. Google follows chains, but it's inefficient and potentially penalizing.

How to verify that the transfer is working correctly after migration?

Monitor Google Search Console: impressions and clicks should gradually transfer to the new URLs. If the old URLs continue to generate traffic several weeks later, it's a sign that Google isn’t following the redirects or is still hesitating.

Use a ranking tracking tool to compare rankings before and after migration. A slight volatility is normal in the first weeks, but a sustained drop indicates a problem. Also, check that external backlinks point to the new URLs in tools like Ahrefs or Majestic.

• Map each old URL to a new equivalent URL, never to the homepage by default.
• Eliminate all redirect chains before going live.
• Check HTTP codes: 301 only, never 302 or 307 for a permanent migration.
• Test crawling in pre-production with a tool like Screaming Frog or Botify.
• Monitor Search Console to detect 404 errors and track traffic transfer.
• Monitor rankings for at least 6 weeks post-migration to identify any anomalies.