HTTPS vs HTTP

Can the Switch Hurt SEO?

[ablu272]

If a site changes its SSL certificate so that it moves from an https:// to an http:// what are the SEO issues to look out for, and how can we prevent possible negative affects?

[ablu272]

We have two sites and we are trying to decide if we should add the HTTPS to one and remove it from the other.

[phranque]

i would treat this as similar to a hostname change.

make sure you have the proper 301 redirects in place to serve content only for the canonical scheme, hostname and an unspecified (default) port number for the specified protocol.
there should be no chained redirects - do all the scheme/hostname/port/path/parameter canonicalization in one step.

all your internal links should specify the proper secure scheme and hostname (assuming they aren't relative urls).
whenever possible try to get any inbound links changed to avoid the redirect.

also make sure that your ssl certificate is valid for your hostname so that you don't get a high bounce rate from any ssl-related browser warning popup messages.


what is your reason for each of the changes?

[ablu272]

I don't know why they want to take the HTTPS off of the subdomain, but adding it onto the main site is probably because customers are asking why we don't have HTTPS there when our competitors do. The main site has a lot of links to the login, but the login page itself has HTTPS.

Okay. So, we should place 301 redirects and canonical tags on the pages. The pages are http://www.example.com/keyword or [subdomain.example.com...] so I don't think they are relative.

Since the old pages will only change their HTTP designation, there wont be an archived version of the old URL. Do we place the canonical tag with the old URL on the URL's page?

Example:
<...rel="http://old-site.com/keyword"> on the new page

?

[phranque]

I did not mean to imply a link rel canonical tag.
I am suggesting a 301 redirect to the canonical url.

[ablu272]

Oh, Thanks for that clarification.

So, the 301 redirects will take care of the canonicalization, right?

[phranque]

if you can always redirect every non-canonical request to the canonical url then that takes care of canonicalization.

in the cases where this isn't possible, then you will need the link rel canonical element.

a 301 is part of the HTTP protocol specification created by IETF and W3C and is incontrovertible.
a link rel canonical element is a non-standard implementation created by search engines, may be handled inconsistently by various search engines, and may in fact be treated as a suggestion rather than a directive.

[Robert Charlton]

If I understand your question correctly... I'm going to take a sloppily worded stab at part of your question....

I don't know why they want to take the HTTPS off of the subdomain, but adding it onto the main site is probably because customers are asking why we don't have HTTPS there when our competitors do. The main site has a lot of links to the login, but the login page itself has HTTPS.

While you definitely would want to have log-ins, etc, on https, making the entire site https, IMO, is not a good approach.

The reason for keeping one subdomain as a secure subdomain is that it's practical to set up a secure subdomain with 301 redirects. It's not really possible to set up individual secure pages... and on some sites, it can get tricky to have the entire site seen as secure under one certificate.

That's because Security Certificates are issued per hostname, not per domain. You could buy a certificate for a secure subdomain... but for an entire domain, each hostname would have to be secure. If you tried to get an SSL certificate for the entire domain, you'd have to buy additional certificates for each subdomain, alias, etc. Otherwise, you'd risk running into SSL error messages all the time.

The security certificate warning message is browser related, so I can't imagine that the link rel canonical element would do what's needed to eliminate certificate problems. My interpretation of the link rel canonical element is that it's purely to tell search engines what your indexing preferences are. I doubt that the element would suffice to work with the certificates.

If your site is getting SSL error messages, it's likely that your certificate isn't set up correctly. Shared servers, as I remember, often have a shared certificate, which can lead to problems. Having an individual certificate and using it with a secure subdomain is really the best way to set things up.

While the above wording should be fairly close to correct, more server-literate hands than I will have to step in and clean up or enhance the technicalities of what I'm saying.

[phranque]

a wildcard subdomain SSL certificate is typically significantly more expensive, so it might be cheaper to get a number of single-hostname certificates.
also, if you prefer or require extended validation for your application i don't know of any certificate authorities that will supply that for a wildcard subdomain certificate.

making the entire site https, IMO, is not a good approach

with the recent moves by google to increase the number of secure searches and therefore the precipitous increase in "not provided" keywords in analytics for those referrals, i'm starting to change my philosophy regarding all-https implementations for sites.
any secure search referred to a secure url should maintain the referrer dataand therefore keywords that are made available to analytics.

the only downside i can see for using SSL site-wide is the cost of encryption.

see this for some discussion on this - Google To Change SSL Search Referrer Data:
http://www.webmasterworld.com/google/4431397.htm [webmasterworld.com]

[ablu272]

Robert,
I'm not exactly server-literate either. I just have to figure out how to communicate what we need to the geniuses and they make it happen.

The site isn't getting SSL errors; the certificate is expiring; so the decision makers want to know if they should change the HTTPS set-up while the opportunity is in place.

[Robert Charlton]

The site isn't getting SSL errors; the certificate is expiring; so the decision makers want to know if they should change the HTTPS set-up while the opportunity is in place.

I wouldn't say that it's really an opportunity, as you're redirecting essentially every page on your site, so you are going to lose an estimated 15% of inbound link juice, and probably drop in traffic for a while until your redirects are processed throughout Google's system etc etc.

My thought is that if it's not broke, don't fix it... particularly if you don't know how.

The discussion phranque cited above doesn't suggest to me that referrer data is preserved, so I see no benefits in that regard. I think the discussion suggests that there was hope that it might, but no one was sure.

I would get extremely precise clarification from the geniuses what they have in mind, and get illustrations of what's happening where. I'm sure they're not thinking about referrer data.

customers are asking why we don't have HTTPS there when our competitors do.

Unless there's a security certificate warning popping up somewhere, or a sign-in on a non-secure page that should be secure, I'm not sure what the issue is.