I have a client which disavowed a few thousand dirty links from his site profile back in February 2015. Recently the site was switch from HTTP to HTTPS (SSL enforced).

Google recommends that you add all variations to the Google Console (Webmaster Tools).

The site has a total of 4 variations, eg:

  • http://www.example.com (Previously Preferred)
  • http://example.com
  • https://www.example.com (Now Preferred)
  • https://example.com


Since technically this is a new property in Google Webmaster Tools, do you need to submit the same disavow file added previously back in 2015?

  • I would believe so. Since these are properties that have to be set individually, programmatically, I would assume that the schema ties any activity within a property only to that property. Otherwise, what other options are there? On the flip-side, if the links go only to HTTP and not to HTTPS, then you may not have to submit a disavow list (yet) and any list may be confusing. Heaven forbid! Let us not confuse Google. Cheers!!
    – closetnoc
    Apr 26, 2016 at 16:42

5 Answers 5


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.

HTTP://example.com      <-- HTTP://example.com/seo-guide
HTTP://www.example.com  <-- HTTP://www.example.com/seo-guide
HTTP://example.com      <-- HTTPS://example.com/seo-guide
HTTP://www.example.com  <-- HTTPS://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.

HTTP://www.spamdomain.com --> HTTP://www.example.com

Within the index, the target is HTTP://www.example.com.

Stopping there for a moment, let's look at Google's Search Console and see what Google has to say.

In: https://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: https://support.google.com/webmasters/answer/34592?hl=en

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

When you visit: https://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.

HTTP://www.spamdomain.com --> HTTP://www.example.com --> HTTPS://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?

HTTP://www.spamdomain.com --> HTTPS://www.example.com

In: https://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:


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:


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.


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.

  • Sorry but you misunderstood the question or didn't read it fully. The site has already had a disavow using HTTP:// when all URLs were indexed under site:http://www.example.com back in last year. The site is now operating under SSL, under a new property, does this mean the same disavow must be added to this property, if so please cite reputable references. Apr 30, 2016 at 21:23
  • Am I to understand (from another comment) you're attempting to disavow your own domain?!!? Disavow is for removing references from threats to your backlink profile. Robots.txt is for controlling how your own domain is indexed. Why are you looking to target specific urls?
    – L Martin
    May 1, 2016 at 23:44
  • We have disavowed other domains and URLS in the disavow file in 2015... in 2016 the website is now HTTPS, not HTTP. The question is not about the contents of the disavow file, it is about the change of property in Google webmaster tools (console). May 2, 2016 at 9:03
  • Then target what's been indexed in your backlink profile in the Search Console. Just like the answer says - Google tells you verbatim where it found the link.
    – L Martin
    May 2, 2016 at 21:22
  • "which one is Google indexing?" - I think this is pretty much it. Although I wouldn't necessarily use the term "indexing". You apply the disavow file to whichever property is reporting the backlinks you want to disavow. Which is how the disavow file should be created in the first place - by downloading the list of backlinks from the property in Google Search Console. If the backlinks are in the list then disavow, otherwise, disavowing links which don't appear in the backlink report just won't do anything. That being said, there would be no harm in disavowing on both properties.
    – MrWhite
    May 7, 2016 at 8:32

In the disavow file, domain:example.com covers all cases of www cname(s) and all subdomains, under http:// and https://. So no matter what their domain runs as, or what subs are running, it'll be disavowed

https://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?

  • Hi Dhaupin, you don't use domain:example.com in the disavow on your own domain, that's target domains. The question is not about the contents of a disavow file. It is about the property in Webmaster Tool. May 1, 2016 at 8:00

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.


Maybe I'm a little late to the party but a colleague of mine just found this useful piece of information:


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.