HTTPS best practices for SEO and usability

Question

Consider a page, http://example.com, which can be viewed both publicly and when a user authenticates. Now suppose you enable HTTPS for every page when a user logs into your website, but only when they are logged in. Your page, http://example.com now becomes https://example.com for all logged in users. If that logged in user likes your page and decides to link to it through a blog post or a social media website, there is a good chance that they will use the HTTPS version of the URL.

From an SEO perspective, what's your strategy for avoiding duplicate content issues between the two URLs?

What should happen if a user arrives at the HTTPS URL but has not logged in or does not have an account? Should there be a redirect to the HTTP version? If so, how would you handle it?

My instinct is that for all pages that can be viewed both publicly and while logged in, the page should first detect if the user is logged in. If logged in, it remains HTTPS or uses a 302 redirect from the HTTP version to HTTPS. If the user is not logged in and they arrive to the HTTPS version of the URL, it uses a 301 redirect to the HTTP version. However, I would welcome a more elegant or effective solution.

Edit: I was assuming that if a user is logged in, every URL should be HTTPS (or at least, that should be an option), but as I've done a little more research, perhaps that assumption was wrong. The way that I see people implementing it is that they only enable HTTPS for pages that send and receive sensitive data: login, shopping cart checkout, user profile management, etc. I'm trying to figure out which model is best.

Apparently, Google Mail gives users the option of whether or not to use HTTPS on every page through a setting in the user's profile. That's certainly an option, but I would still need to address the behavior of publicly available pages for all authentication states.

Because I'm building a content management system that will be used by other people, I need to make sure I get it right. What settings should be available to the site owner? At this point, I'm thinking granular control over each page (whether or not it's secured with SSL) and then for the whole site as well. However, giving that level of control might be a mistake if people don't understand all of the issues and could end up causing security issues. That, perhaps, is the first issue. What are appropriate levels of control and what are intelligent defaults? The second is how the pages should behave for the user. From an SEO perspective, I think that either the process I described above or using the rel="canonical" (like jmb suggested) would work, but nailing down the behavior of the page so that it is secure and seamless is essential as well.

Answer 1

You may want to look into <link rel="canonical" />. See http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html. Down in the comments someone from Google says that it can be used for http/https issues.

Caveat: I'm not sure if and to what extent <link rel="canonical" /> is supported by search engines other than Google, Yahoo and Bing. If other engines are important to your site you should check their FAQs.

From a user perspective: Redirecting a user who is logged in from http to https is insecure (if I understand correctly that you would like to create a seamless process). At the point where he arrives at the site (prior to the redirect) he would transfer his session cookie via http, making him vulnerable to session hijacking. Such a user needs to log in again from a https page.

In the case a user arrives via https and is not logged in: Depending on the circumstances (size of the site, expected traffic volume, expected number of times this will happen) you may be able to simply keep him on https. Also see HTTPS for entire site and https://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https for discussions on running a site on https (partly in your case).

Update:

What are appropriate levels of control and what are intelligent defaults?

Appropriate levels of control:

• Secure (https turned on, including the log in page and everything from there on)

and

• Insecure (no https).

There's no middle ground if you want to "get it right". Also see http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ and https://stackoverflow.com/questions/274274/is-it-secure-to-submit-from-a-http-form-to-https

Default: Depends on who your customers are.

Answer 2

There is no SEO strategy for SSL pages. Part of the definition of caching is this:

If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.

see: caching tutorial

So, in order to prevent overlap with non-SSL pages where this may hurt ranking, is to have your SSL-sensitive pages on completely different URLs.

Ironically, I have seen search engines actually store and keep links with the HTTPS url in them. This is contrary to what normally should happen, but does in cases where the page is a login area, is the home page, or otherwise has cache pragma re-written to allow caching. I would say avoid this if possible, as your page will drop in PageRank usually.

Answer 3

302 redirect do not transfer search ranking - so you may lose search ranking if you mass 302 your site.

301 can change bookmark definitions, I wouldn't want to constantly 301 my users around.

Also, make sure the http version includes a login form so the user can quickly return to the https version.

Now the big questions is - if the data is viewable over http why do you have an https version? what data are you hiding with the https encryption that is not already out there?

You can make a https member area, or post forms to https url from the http page or many other options that don't include having the entire site on both http and https.

Other than that, your idea looks workable - but I have no inside info has to how Google and the other web sites operate and you really can't be sure as to how this will affect your ranking (and its such an edge case it may well change drastically whenever Google update the algorithm).