Implications of putting the whole site behind SSL

[adder]

Hi,

I've got a very complex site with various sections. It's not a pure ecommerce site, I've got lots of content, tools and stuff.

Some of the stuff requires login to be accessed.

I wanted to put the whole site behind SSL because many parts of it do require SSL.

What are the implications of putting the whole site behind SSL? Could there be any issues with search engines, crawl rate, content or anything else?

thanks.

[toplisek]

SSL should be used for secured pages. It secures transaction not search engines.

[brotherhood of LAN]

> issues with search engines

You're more likely to see which search terms people are arriving at your site with.

[phranque]

You're more likely to see which search terms people are arriving at your site with.

that's what i thought until i read the announcement quoted in this Google SEO News and Discussion forum thread - Google To Change SSL Search Referrer Data:
http://www.webmasterworld.com/google/4431397.htm [webmasterworld.com]

[phranque]

all requests and responses on SSL connections get encrypted and decrypted so that has some cost depending on the specifics.


are the various sections in various subdomains or is the content all on one hostname?

[adder]

I wouldn't mind seeing more search terms :) unlikely to happen, though!

are the various sections in various subdomains or is the content all on one hostname?

It's still work in progress. I was going to put some stuff on subdomains but I was just advised by my cloud admin that I don't get the wildcard SSL, so I will have to settle for www.example.com as my hostname.

[phranque]

you will have to implement redirects so that any requests for a non-secure port and/or protocol get redirected to the canonical protocol and hostname.

if you are internally linking with fully qualified absolute urls make sure to use the https: protocol for those urls.

[incrediBILL]

OK, old wives tales told by old wives again...

Running YOUR site under SSL hasn't got anything to do with GOOGLE returning referral data because THEY run things under SLL. Apples, oranges, blah.

The implications are the HTTP and HTTPS server on your site are treated as two completely different domains in Google, just like www and non-www. Therefore, running a site with half the content in HTTP and half in HTTPS will probably dilute your site ranking and most likely anything in the HTTPS side will have a touch time ranking being that far down the PR chain of your site in the first place.

Not to mention if these products are behind a login then you need to allow crawlers to get past the login in order to crawl.

Your SSL pages will load slower by definition because SSL adds time, therefore Google will probably rate them as slow loading pages unless they give you an adjustment for being on SSL which I doubt.

The customer experience will be excrutiatingly slow, like it is with a bank's website, and shoppers may bail because of the slow experience.

If the only reason you're putting it in SSL is because of the login, that's silly. Make the login SSL and once secured redirect back to those pages. Having pages only available to people that have a login doesn't mean they have to be displayed in SSL to be secure. Your server is tracking a session that knows the person has logged in and the pages, unless containing secure data, can be run though the HTTP server just fine until checkout.


Any questions?

[brotherhood of LAN]

>Running YOUR site under SSL hasn't got anything to do with GOOGLE returning referral data because THEY run things under SLL. Apples, oranges, blah.

If a website is accessed from a HTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referer field is not sent.[10]

10. ^ "Hypertext Transfer Protocol -- HTTP/1.1: Encoding Sensitive Information in URI's (RFC 2616 § 15.1.3)". IETF. June 1999. Retrieved 2013-03-20. "Clients SHOULD NOT include a Referer[sic] header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol"

[en.wikipedia.org...]

I think phranque's post already put that angle to bed.

[incrediBILL]

Phranque's point is about how it SHOULD work per spec.

Google didn't implement it according to spec.

My point was Google doesn't claim to send the keywords even if you click through to a secure connection which would be value for running the entire site in SSL and I haven't tested it nor can I find anywhere Google claims to send anything from their secure search other than the AdWords gclid.

Per SearchEngineLand:

To solve this, Google changed from the standard way that referrers are supposed to be passed to its own unique system, which works like this:

Secure /// does NOT pass referrer to /// Unsecure unless…
Secure >>> passes referrer if ADVERTISER to >>> Unsecure

[searchengineland.com...]


Basically, you don't get referrer data on non-SSL or SSL links from Google unless you're an advertiser and even then it's only AdWords data, not regular organic search results.

Hope that clears up my point that there is no SE value for adding SSL. Period.

[brotherhood of LAN]

Google's change in behaviour happened well afer serving results via HTTPS, phranque's post clarified that Google's behaviour has changed, so in regards to SE's (mainly Google), there's no gain in referrer data.

Not sure why there's any need to repeat that.

[incrediBILL]

I don't know, we just said the same thing.

I think it's shared annoyance at Google screwing things up that bears repeating. :)

What's a more important topic is actually stopping SEs from crawling the site via HTTPS which is easily solved by blocking all crawlers from accessing VIEW CART and beyond. All checkout pages should be physically blocked which stops the crawlers from finding the HTTPS server in the first place.

What typically happens with sites that mix HTTP/HTTPS is that they have to make links back to the HTTP server and typically do silly things like using the same site template on both servers and then the whole site gets indexed in HTTPS.

Heck, it even happened to one of my sites by accident and that can make a big old mess.

HTTPS servers need to be handled with care as they can cause a lot of trouble once the SE gets access if the HTTP/HTTPS area overlaps and aren't completely different pages/content.

Had to help more than a few unravel a cross-crawled HTTP/HTTPS site. Yuk.

[toplisek]

There are some notices from internet sources:
''There are at least two reasons search engines may penalise https URLs: (a) they may consider it more likely to be a private URL and/or a misconfiguration by a hapless webmaster just asking to be taken down a notch; (b) if it's a migration from http to https, http forwarding is necessary and there might be a duplicate link penalty.''

[phranque]

''There are at least two reasons search engines may penalise https URLs: (a) they may consider it more likely to be a private URL and/or a misconfiguration by a hapless webmaster just asking to be taken down a notch; (b) if it's a migration from http to https, http forwarding is necessary and there might be a duplicate link penalty.''

the quoted statement is basically useless speculation and the author follows it up with this statement:

Whether (a), (b), neither, or both apply to Google or any other search engine is hard to say, because secrecy. It's a risk of unknown unknowns.

however, his post does get this relatively authoritative answer.

http://plus.google.com/106413090159067280619/posts/ZZVAS65mmw4 [plus.google.com]:

HTTPS-only sites are fine, there's absolutely no need to shy away from that if you implement it properly. There's certainly no penalty involved with running your site on HTTPS-only when done right. A few of the things that come to mind are (definitely incomplete, just from the top of my head):
- don't forget the http->https redirect & other canonicalization things
- look into HSTS
- list the https site separately in webmaster tools (it's a different site)
- make sure the infrastructure can handle the higher load (SSL, caching, etc)
- check out the differences wrt. caching

- John Mueller