Should you re-upload your disavow file after a domain migration?

Why doesn’t the disavow file automatically follow the domain?

The disavow file is a technical directive stored in the Search Console at the property level, not at the site level itself. When you migrate a domain, you create a new property in the Search Console.

Google treats this new property as a distinct site, even if you have set up perfect 301 redirects. The disavow file from the old property remains attached to the old domain and does not transfer automatically.

What actually happens if we forget this file?

Upon recrawling the new domain, Google rediscovers the backlinks pointing to your content. If some links had been disavowed on the old domain, they will this time be reintegrated into the link graph and potentially considered for ranking.

If these links had been disavowed for good reasons (spam, toxic PBNs, over-optimized anchor text), their reintegration can degrade the perceived quality of the link profile. In some cases, this may trigger a drop in rankings or a manual action if the profile becomes suspicious again.

Does the disavow file still have real usefulness today?

For years, Google has claimed that its algorithm better handles toxic links and that disavowing is only necessary in exceptional cases. The reality on the ground is more nuanced: some highly polluted link profiles (due to negative SEO or outdated practices) still benefit from disavowals.

During a migration, if you had an active disavow file, it's likely that your link profile needed this filter. Not reapplying it means resetting this protection.

• The disavow file is linked to the Search Console property, not to the domain itself.
• A migration creates a new property, so the file does not automatically follow.
• Disavowed links can be recrawled and reintegrated into the link graph on the new domain.
• Reapplying the disavow file is a critical post-migration step to maintain the quality of the link profile.
• Timing matters: ideally, re-upload the file right after validating the new property in the Search Console.

Is this statement consistent with observed practices in the field?

Yes, and it’s a classic pitfall. Many migrations focus on redirects, crawl budget, sitemaps, and completely overlook the disavow file. Most migration checklists don't even mention this point.

In practice, I have seen sites lose 20 to 30% of traffic post-migration for no apparent reason, only to discover that thousands of spam links had become active again. The worst part: Google doesn't notify you that disavowals have disappeared. You find out when rankings drop.

What nuances should we bring to this recommendation?

First nuance: if your disavow file primarily contained links that no longer exist (expired domains, 404 pages), re-uploading the file will have no impact. Do a quick audit before copy-pasting a three-year-old disavow file.

Second nuance: Google has improved its handling of toxic links. If you had disavowed links out of excessive caution (low authority domains but not toxic), now is the time to clean up the file. Do not automatically reapply all disavows without consideration.

Third point: this statement comes from an era when disavowals were more crucial. Today, [To be verified] if disavowed links actually have a measurable negative impact on all types of sites. Recent tests show that the algorithm ignores spam links much better than before.

In what cases does this rule not strictly apply?

If you have never used a disavow file on the old domain, of course, there’s no need to create one on the new domain. But still check: some SEOs forget that they uploaded a file five years ago.

If you are using the migration to completely clean up your link profile (disallowing toxic backlinks at the source, contacting webmasters), you can start fresh without disavowals. But let’s be honest: how many migrations have the budget and time for this large-scale manual cleanup?

What should you do practically during a domain migration?

First instinct: retrieve the disavow file from the old property before migrating. Download it from the Search Console (Search Traffic > Disavow Links > Download). Keep this file in a safe place, with a timestamp.

Second step: as soon as the new property is validated in the Search Console and the redirects are active, re-upload the disavow file to the new property. Don’t waste time: every day that passes allows the crawler to reintegrate toxic links.

What critical errors must you absolutely avoid?

Error #1: assuming that 301 redirects also transfer disavows. False. Redirects transfer link equity, not disavow instructions.

Error #2: waiting several weeks after migration to re-upload the file. The longer you wait, the more time Google has to recrawl and reintegrate toxic links. Act within 48 hours post-migration.

Error #3: copy-pasting an old file without auditing it. Some links disavowed three years ago no longer exist or have been cleaned up. Others, new ones, may need to be added. Take advantage of the migration to update the file.

How can you check everything is in order after migration?

Use the Search Console to confirm that the disavow file has been successfully uploaded to the new property. Check the last updated date.

Monitor the backlinks detected by the Search Console in the weeks that follow. If you see previously disavowed domains reappear, it’s a sign that the file has not been applied or that the format is incorrect. Compare the link lists before/after migration.

• Download the disavow file from the old Search Console property before the migration
• Create and validate the new Search Console property for the target domain
• Re-upload the disavow file to the new property within 48 hours post-migration
• Audit the disavow file: remove outdated links, add newly identified toxic links
• Verify in the Search Console that the file has been accounted for (last updated date)
• Monitor the evolution of detected backlinks for 30 days to spot any reintegrated toxic links