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.

[aakk9999]

4 - rel=canonical should declare https version of URL to be a canonical version

5 - For multilingual sites, rel=alternate hreflang references should be https version of URL

6 - For sites that have a separate desktop and mobile version, rel alternate media= should be https version of mobile URL (providing m. site is also https)

7 - If you are iframing or linking to external sources, make sure they are https

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

Yes, I have done so.

Regarding 301, some link juice will be lost because of 301 redirect.

[mihomes]

+ for the additions.

8 - TEST. While it should be a given, thoroughly test your implementation and be comfortable with the change before you make it. If at all possible test what you plan to do on a dummy domain before implementing. While this change seems simple enough if you miss something or do something wrong the consequences could be very bad ie. Google drops your ranking.

[raseone]

Im sure everyones experience is different but ever since the whole change-up at google years ago i loose 100% of the "link juice" every time i do a 301. Its so bad that i dont even bother anymore.

[mihomes]

@raseone - I've never had that problem in the past, but it definitely isn't the same 'value'... plus it takes awhile for them to pick up everything. With that said, I would still do the redirect because if you don't then any incoming links out there won't work whereas with the redirect they will. Even if you lose the 'link juice' don't throw away incoming links from other sites.

[raseone]

@mihomes

You're totally right. And for the benefit of anyone reading i should be more specific and concur with the point about incoming links. If there are any you would certainly not want to lose those.

As for the losing of 100% the value i can only assume thats its yet another symptom of the mysterious force that holds some sites down. 0 value transfer... 0. Unexpected and strange but for some reason verifiable and consistent.

[lucy24]

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

Another argument for using site-absolute* links if you don't already. If your internal links start in / then any change in protocol will take effect globally and you don't need to do anything.


* Or "site-relative" depending on your preferred terminology du jour.

[raseone]

So... Is the suggested solution a crop of 301s or a rewrite rule in the htaccess or both?

If an https page is new but indexed shouldn't we expect to see it on google by now? I still don't see any duplicates and the pages that show up in serps are all still http.

[raseone]

Subdomains for beta sites definitley coming in handy for experimentation. If this is the issue that finally drives you to set up a testing site you will want yo be sure its password protected and has no-index protection in htaccess. Dont want to get hit for duplicates... Or triplicates... Or quadruplets.

[mihomes]

Another argument for using site-absolute* links if you don't already. If your internal links start in / then any change in protocol will take effect globally and you don't need to do anything.

Exactly. I should have mentioned that in the post, but it is always a good idea to check anyways.

So... Is the suggested solution a crop of 301s or a rewrite rule in the htaccess or both?

I would do a rewrite in htaccess for everything. My personal preference is to list all my 301 redirects first in htacess, but these would be for pages that changed location, name, etc... below that is where I use sitewide non-www to www and http to https.

Lucy may be kind enough to give an example of non-www to www along with http to https... master of htaccess rules and more than helpful in the past :)

[raseone]

Right. This is my take also. That a single rewrite condition handles the basic issue.

It would seem silly to do 301s for all the individual pages if nothing but the https has changed. Just for notation I've run a bunch of sites with the www to non-www rewrite & a bunch without & seen no change in rankings in any case ever.

This https thing is a genuine security improvement though so it holds a bit more weight with me. There is a genuine, non-google reason to do this. I think I'll leave a site or 2 without the rewrite & see how Google reacts.

[lucy24]

a crop of 301s or a rewrite rule in the htaccess or both?

This isn't either-or. That is: it's not "apples and oranges" but "apples and red". A redirect can be expressed as a RewriteRule, or it can be expressed in some other way. The one thing you can't do is an internal rewrite, because your visitor (human or robot) has to "know" that it's asking for https.

Either way, it won't be "a crop of" anything ;) Just take your existing domain-name-canonicalization redirect (the one about with/without www) and add a line about https on/off.

[blend27]

9 -Before generating a CSR, if you are on a shared hosting plan, Make sure your website is assigned STATIC IP, if your host offers it.

Also, as far as 301s go, I wouldn't redirect anything but instead use as in #4 with canonical tag, which brings me to:

10 - Analyze your current website visitors traffic, see how many users are still using IE8 on XP and other older versions of browsers.

And finally before pushing SSL site wide try displaying a message to users that the site will be ported over to SSL and their browser will not work any more. I'd do it for a few weeks.

Some of the older versions of Android stock Browser(not everybody has S6), cant connect to all HTTPS sites.

[raseone]

On further inspection of sites that have had https for about a year i see no sign of https urls indexed by google. Perhaps i will try to force the issue.

There are definitely weird and undesirable results when a page is coming from https but includes resources from http. My Use of subdomains for some things will need adjustment. Some sites might require more than one certificate.

Any thoughts on how a single certificate can cover all subdomains?

[mihomes]

@raseone - none of the content you serve should be coming from http as that kind of defeats the purpose. As for your certificate question it sounds like you need a wildcard certificate which will cover the domain and all possible subdomains of it.

[mihomes]

Example redirect for non-www to www and also forcing https. Only one of the two will ever be met so there will only ever be a single redirect :

#non-www to https www
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule (.*) https://www.example.com/$1 [R=301,L]

#if www met above, but not https then force it
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://www.example.com/$1 [R=301,L]

[mihomes]

9 -Before generating a CSR, if you are on a shared hosting plan, Make sure your website is assigned STATIC IP, if your host offers it.

Also, as far as 301s go, I wouldn't redirect anything but instead use as in #4 with canonical tag, which brings me to:

10 - Analyze your current website visitors traffic, see how many users are still using IE8 on XP and other older versions of browsers.

And finally before pushing SSL site wide try displaying a message to users that the site will be ported over to SSL and their browser will not work any more. I'd do it for a few weeks.

Some of the older versions of Android stock Browser(not everybody has S6), cant connect to all HTTPS sites.

One thing to note about this is SNI which allows multiple certs on a shared IP address. There are some things to understand when using this though so anyone interested in it should do their research prior.

[lucy24]

Only one of the two will ever be met

But the server still has to evaluate conditions twice on every request. The two rules can be collapsed into one by using [OR], since the targets are identical.

:: idly wondering if there currently exists any legitimate user-agent that is capable of processing https requests but that does not send the "Host" header ::

I wouldn't redirect anything but instead use as in #4 with canonical tag

I don't understand the advantage. Surely serving up a page is more work for your server than sending back a 301 response?

[Dymero]

I'm also confused about not using redirects. If you don't redirect your pages, the benefit to using HTTPS becomes less, at least in the short-term, as everyone can still access the non-HTTPS site.

11 - If you have anything else in your htaccess file, especially anything to do with caching, the redirects must go first. I initially put mine beneath the caching instructions and then wondered why redirects wouldn't work.

[mihomes]

Regarding what Lucy comments on I believe this is what was meant :

RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$ [OR]
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://www.example.com/$1 [R=301,L]

[lucy24]

If you have anything else in your htaccess file, especially anything to do with caching, the redirects must go first.

That can't possibly be right; there has to be something else going on. Caching/expiration and redirecting are handled by different modules, and each module is an island. So the only ordering that matters is within any one mod.

I believe this is what was meant

RIght.

[raseone]

@Dymero

The rewrite will direct all traffic as you specify. I think the talk of 301s is for the sake of search indexes.

[lucy24]

The rewrite will direct all traffic as you specify. I think the talk of 301s is for the sake of search indexes.

?
RewriteRule != rewrite (lower case) * Or did you just mean 301 as opposed to 302?


* g1smd used to lay great stress on distinguishing between capitalized Redirect/Rewrite and lower-case redirect/rewrite to point up the difference between some specific rule and a functional result.

[mboydnv]

I did this in September. Our site was a wordpress site. Make sure you go through Db and change all links to https://

Here's the code in our root htaccess for rewdirecting to 301. Be sure to add new site in Google Webmaster tools and update any analytics code in your template too.

This is the code from the top down to the wordpress code. Be sure to change the IP to your server's Ip.

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} libwww-perl.* 
RewriteRule .* ? [F,L]

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

RewriteCond %{HTTP_HOST} ^00\.28\.106\.21 [OR]
RewriteCond %{HTTP_HOST} ^www\.yourdomain\.com
RewriteRule (.*) https://yourdomain.com/$1 [R=301,L]

RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://yourdomain.com/$1 [R=301,L]

[raseone]

If Operating in a vacuum with nothing else to interfere I've tested 2 approaches that work to redirect both www to non-www and http to https (one of which is Lucy24s approach)


My version of Lucy24s code

# redirect www to non-www & http to https
RewriteEngine On
RewriteCond %{HTTP_HOST} !^(example\.com)?$ [OR]
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://example.com/$1 [R=301,L]

A different approach that uses 2 separate rules

#force https
RewriteEngine On 
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://example.com/$1 [R,L]

#redirect www to non-www
RewriteEngine On 
RewriteCond %{HTTP_HOST} !^(example\.com)?$
RewriteRule (.*) http://example.com/$1 [R=301,L]

I'm interested in any feedback on these 2 options. Does the second option with 2 rules also create 2 redirects? if so should I add a 301 to the first rule?

What is the best way to actually watch the response from the server? Having trouble trying to use the console in chrome. Maybe firebug?

[lucy24]

Does the second option with 2 rules also create 2 redirects? if so should I add a 301 to the first rule?

Still just one redirect. The difference is whether the server evaluates two conditions on two separate passes, or one-and-a-half conditions on a single pass. (One and a half because, if the first line of an [OR] is matched, it doesn't bother to check the second line.)

I think I said something about nanoseconds earlier-- if not here, then in a parallel thread. That's what we're talking about at this point: shaving nanoseconds off the server's response time, and micro-whatevers off its processing load.

The [R] flag creates a redirect. So does any RewriteRule whose target includes the full protocol-plus-domain.* But the default redirect is a 302, not a 301. That's the only reason you need to specify R=301. For human users of course it makes no difference-- though it might conceivably affect the way the browser caches the response. But this is the Google SEO subforum. Search engines may or may not distinguish between 301 and 302. In theory, a 302 response is indexed at the old URL while a 301 is indexed at the new one. In practice, nothing is ever straightforward. Especially when talking about The World's Leading Search Engine.


* A while back, penders or someone like him found some blahblah in the Apache docs that makes it sound as if this is not really the case: no [R] flag, no redirect. But nobody has ever figured out how to make this happen in real life.

[raseone]

Excellent Lucy! Thank you for clearing that up. I understand it much better now.

The way I set it up initially I thought it would create a chain of 2 redirects. In any case the shorter option is better. Thanks for that.

As for Google... #*$! Google.

[mihomes]

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Word of warning here. Only use this if you are positive you will not be going back to http. This is essentially the same as any cache rules you might have in place so if for some reason you need to go back to http then you might have some visitors who won't be able to access your site (in this example for up to a year). This tells the browser to redirect any http links to https... on the client side... without your own redirect rules being hit (this does not mean remove your redirect rules). Also, it will only take affect after the initial request because it needs to be set first for it to take affect.

There is also a preload and includesubdomains option which can be set as well. The preload allows you to be on a 'list' so this is basically already set for a visitor even without ever visiting the page before (comes bundled somehow with the browser). This might be better suited for another topic, but when I read about this a lot of questions and possible problems came to mind. Namely, say you buy a domain and the previous owner had this enabled and is on the list, but you don't want to use https? How do you get 'off' the list and how long would that take? I think you can figure out where I am going though.

I just read up on this the other night, but this was the gist I got from it. If anything is in error please comment.

Anyways... remember to do your research prior to implementing.

[lucy24]

if for some reason you need to go back to http then you might have some visitors who won't be able to access your site (in this example for up to a year). This tells the browser to redirect any http links to https

Seems as if you could override this by coding an explicit https-to-http redirect-- which you would then need anyway, replacing http-to-https-- because that would override anything the browser had in its cache from earlier.

Can't experiment because my test site is strictly http, but maybe someone else can investigate. Nothing beats hands-on trial and error.

[mihomes]

Regarding the https to http redirect... wouldn't this require a ssl cert be installed for it to work? I actually tried this the other night on a test domain of mine... I do not have an ssl cert installed for it, but went ahead and did an https to http redirect in htaccess. Upon trying a page with https there was no redirect, the untrusted warning showed, and continuing anyways brought up the 'cgi-sys/defaultwebpage.cgi' error page.

Also, I'm not exactly sure if even then it would work. You might end up in an endless loop since the hsts forces https on the client side of things.

If anyone has experience with this I would really like to know what exactly happens here.