: Do you need to disavow on [HTTPS SSL] after performing a disavow on [HTTP] I have a client which disavowed a few thousand dirty links from his site profile back in February 2015. Recently

@Sue5673885

Maybe I'm a little late to the party but a colleague of mine just found this useful piece of information:
twitter.com/methode/status/653980343658151936
Here is a transcript of the tweet from Gary Illyes (emphasis added by me):


okay, checked with the team: yes, you need to reupload the disavow file to the https site profile in SC.

Vote Up Vote Down

@Samaraweera270

No, there's no need to re-submit for the SSL domain. You've already disavowed links for the HTTP version; in other words they're no longer taken "into account when [Google] assesses your site".

Consequently, the negative effect can't be passed to the the new site (HTTPS): it's already been dealt with.

The fact that subdomains and protocols are added separately in Search Console doesn't seem to have a bearing on the issue.

Vote Up Vote Down

@Sherry384

This is a difficult question to answer simply because there is no direct answer to this question. So let's see if we can work through the process.

Let's assume a few things. The first of which is a blanket 301 redirect from one site, HTTP, to another, HTTPS. The second is that there are links to the HTTP site and not to the HTTPS site.

What we know.

The Google index keys off of two primary data elements, the domain name URL, and the URL of any page or resource.

For any site, the domain name is the full URL for the site including the protocol. If a site can be found with HTTP and HTTPS, these will be different sites as will www or non-www. Since the full URL is the key, any variation in the URL will appear in the index and Google will key any resource it finds as a result of that URL.
example.com <-- example.com/seo-guide HTTP://www.example.com <-- www.example.com/seo-guide HTTP://example.com <-- example.com/seo-guide www.example.com <-- www.example.com/seo-guide

For any link to exist within the index, it has a source and target URL. If a link or page exists, Google will not remove that URL from the index.
www.spamdomain.com --> www.example.com

Within the index, the target is www.example.com.
Stopping there for a moment, let's look at Google's Search Console and see what Google has to say.

In: support.google.com/webmasters/answer/2648487?hl=en

Note: When looking at the links to your site in Search Console, you
may want to verify both the www and the non-www version of your domain
in your Search Console account. To Google, these are entirely
different sites.


In: support.google.com/webmasters/answer/34592?hl=en

If your site supports multiple protocols (http:// and ), you
must add each as a separate site.


When you visit: www.google.com/webmasters/tools/disavow-links-main
...assuming that you are logged on, you will see all of your Search Console properties. You will see if you added them, properties for HTTP, HTTPS, www, and non-www sites. Google recommends that you add all the variations of the site. If you select the Disavow Links button, you can easily see that the key used is the domain name URL.

What we do not know.

We know that the page that existed prior to adding the 301 redirect is removed from the index and the target of the 301 redirect is added using the new location. This is true if the 301 remains on-site or to a new domain entirely. We know that both the old URL and new URL exists and are keyed to the domain name. We also know that link value is passed from the spam site through the redirect to the target page. This we know.

What is not known is whether a disavow created for one Search Console property will, in effect, act as a firewall.
www.spamdomain.com --> www.example.com --> www.example.com

Let's remember a few things about programmers and database engineers. They are simple by nature and sometimes lazy. Sorry folks. I am talking about myself. Often code and data are stove-piped. As well, if code or data elements can be reused, they will be.

For example, if I were a programmer and/or a DBA, would I retain the relationship above or simply add a new link to the index? Which is easiest to create and maintain?
www.spamdomain.com --> www.example.com

In: support.google.com/webmasters/answer/93633?hl=en
Matt Cutts warns that creating 301 redirects in chains may not be followed if the chain has too many links. The regular googlebot may not follow them. (Oh God! Did I just quote Cutts? Love ya Matt!)

This gives us a clue, perhaps, that Google is not interested in the path of any 301 redirect as much as the result. In otherwords, it is likely that there is no database relationship between URLs indicating a 301 redirect within the Google index. Purely speculation of course. But let us look at it this way. From a programmers perspective, keeping track of 301 redirects are not necessary if I simply put a new link as a result of the 301 redirect in the index as suggested above.

As long as the 301 redirect remains, both links have a source and target and remain valid. In otherwords, they both remain in the index. However, as soon as the 301 redirect is removed, the link added as a result of the 301 redirect instantly becomes invalid and is removed. Am I starting to make sense?

For the record, I am sure there is much more to the schema than what I have described, however, keeping it simple, I rather suspect my logic follows reality enough for an illustration.

There is only one way to (maybe) know if you are Google Search Console user. (That's a big maybe.)

So what is the answer?

If, in the scenario you describe, you add the HTTPS property, and still assuming that you 301 redirect the entire site from HTTP to HTTPS, you see the links appear for the HTTPS property, then I would say the answer is:

YES.

If, in the scenario you describe, you add the HTTPS property, and NOT assuming that you 301 redirect the entire site from HTTP to HTTPS, you will not see the links appear for the HTTPS property based upon what we know about how the Google index is keyed. In this case, the answer is:

NO.

Without digging deeper into any old patents and so forth, we may never know the answer fully even if we did. There is only one way to know and it is not recommended.

If you are worried about bad links to your HTTP site, it would not hurt and certainly could be wise to disavow the links for the HTTPS property. Your call.

Vote Up Vote Down

@Correia994

In the disavow file, domain:example.com covers all cases of www cname(s) and all subdomains, under and . So no matter what their domain runs as, or what subs are running, it'll be disavowed
support.google.com/webmasters/answer/2648487?hl=en says:


If you want Google to ignore all links from an entire domain (like
example.com), add the line domain:example.com.


Example, domain:blogger.com would prevent blogger itself, and all peoples blogs on all the subdomains, https or not, from backlinking.

As far as the trigger mechanism in Google backend, I can only assume that a new https domain verify/property would still be disavowed when using domain:example.com wildcard style. Wouldn't hurt to re-upload it though if in doubt, ya know?

Vote Up Vote Down

@Kimberly868

The answer is - which one is Google indexing?

It will only index one version. That's the one you disavow.

Do it with the root domain (domain:example.com) and you don't even need to specify a protocol.

Vote Up Vote Down