Google https - what you need to know

[mihomes]

Regarding the recent announcement with Google and https (https://www.webmasterworld.com/google/4782828.htm) I thought it might be beneficial for us to collaborate on a list of do's and don'ts for those seeking to make the change. We can also discuss some related topics and questions (even I have some) that are popping into my head.

To get started :

1 - Much like setting up redirection for non-www -> www and vice versa you need to do the same for http -> https. You only want one listed.

2 - Go over your code and make sure any http links are changed to https if need be.

3 - Sitemaps should be your new https version.

Questions for discussion :

Do we need to add the https version(s) in Webmaster Tools (Search Console)?

Can we assume Google is not going to penalize us for the switch since they have this implemented now? While the pages themselves will be the same, historically, these are 'seen' as completely different pages much like the www version and non-www version - aka duplicate content. So, for those of us with old sites and plenty of incoming links to http will our 301 new 301 redirects pass less influence to ranking?

These are just a few things that popped in my head. Add on and discuss.

[lucy24]

Regarding the https to http redirect... wouldn't this require a ssl cert be installed for it to work?

Oops, right, yeah. If your site can't be reached by https a request will never reach the server and therefore will never see your redirects. That's exactly why we don't need a https-to-https redirect on a purely http site: unlike with/without www, there's no way a request can reach you by accident. (Or by malice, in the case of search engines trying every door.)

I don't think a response header can ever be absolutely binding on a browser, though. It's more of a "please try this first". (Analogously: If you tell it that suchandsuch type of content can be cached for a month, it doesn't mean you will refuse to grant any further requests for the material until the month is up. It's just for the browser's information.) After all, you need only empty your browser's cache, and then it will forget it ever saw the HSTS header. That's not a phenomenally high level of security.

[mihomes]

True, but relying on the customers to clear the cache is another thing :) I'm sure there is a decent amount out there that don't even know what a cache is nor know they would need to clear it if they had problems accessing a certain website. If they can't access the site then I doubt they are going to do a whois to try and contact you about it unless they already have your contact info.

I suppose they could force a refresh as well which would get the new hsts or find it no longer exists, but then again the customer needs to know to do that. If it works like normal caching, and assuming the cache isn't cleared on the browser, then it could indeed run until the age is invalid even though you removed the hsts or changed it.

The thing that got me was actually being on the 'browser list' of preloaded sites where it doesn't need the hsts header (or so it sounds like)... it is preloaded into the browser before ever visiting the site.

[lucy24]

I didn't mean that customers would have to empty their cache, only that the header can't be that overwhelming a mandate. It doesn't mean "for the rest of your existence, never try this hostname with anything but https".