Observations on the application of Disavow
Here at LinkRisk we spend a huge amount of time working with the disavow files of customers and watching their impact. We take the responsibility of holding and creating those little text files massively seriously.
Recently there has been an increase in debate with some customers on how Disavow should be handled and how we see it being applied at Google. I thought I would share some of that debate here and talk through some of the technicalities of handling risk within that process.
Some basics: –
We suggest that in almost ALL cases customers disavow at domain level.
This should be done as domain:example.com (Google also seem to accept domain: example.com nowadays – note the space)
The debate on where to host the disavow.
Our standing advice is that the disavow should be uploaded to all domains affected by issues. I would extend that to say: –
Upload the disavow to every domain potentially touched by the risk.
Now to be even more prescriptive on how we suggest this is approached: –
Upload the disavow to every domain that could be regarded by Google as potentially in benefit from the links applied. This means upload to the www and non-www versions of the domain and to the http and https versions if claimed in WMT.
Also upload it to any domain that is the beneficiary of a redirection.
This would also include any domain that is redirected using softer or less frequently used methods, by this I mean if you 301 OR 302 to a new domain you should include the disavow from the old on the new and if you target a new domain using canonical you should do the same.
If there is potential for the target to benefit from the source then the disavow needs to be on both.
This DOES NOT mean we believe that Google applies the negative impact of links pointed at source onto the target but it does mean that the potential exists for them to do so or that they have every right to, under manual review, consider the redirection in any form to be an avoidance of the true risk or a manipulation of their link value.
The debate on how Google applies disavow internally
We still see numerous instances where people try to save themselves the bother of auditing correctly and just add things like: –
Its our view that this isn’t something that Google would take and negate the risk of everything under those properties. Our parsing rules internally at LinkRisk wont allow you to disavow massive scale blogging platforms in that way.
We therefore suggest you deal with the subdomains as unique sites as you would elsewhere.
The Majestic issue
We are huge supporters of Majestic, we believe that ‘Real SEO’s use Majestic’. Their data does tend to need more work to clean than most though as they take the view that you should be given all the urls that they see rather than them pre-processing that data before export. That means that in your average Majestic export you will find a larger percentage of links from places like: –
In reality, to Google this is probably all viewed as one page. Our suggestion is to make your decision at root and deal with this as
The debate on removing from the disavow
- Can you do it? Yes
- Should you do it? ONLY if the entry was a mistake in the first place
- Will the value come back if its removed from the file? Yes but not as quickly as you’d like or expect it seems.
The debate on adding notation to the disavow
You upload a .txt file to Google, when you download the file again its a .csv and its lost the notation. Does that mean that you’re wasting your time in adding notation?
In our view no, its still best practice to add notation on why something was disavowed in the first place. Notation isn’t a method by which you communicate your methods to Google’s team, its a tool to make sure you understand why the entry is there and to use as evidence if you ever have to justify that both internally, externally and to Google in reconsideration request.
Be super careful with the disavow, its a powerful tool in your armoury as an SEO and if you don’t feel confident then ask.