| 12:05 pm on Jun 27, 2013 (gmt 0)|
SSL should be used for secured pages. It secures transaction not search engines.
|brotherhood of LAN|
| 12:08 pm on Jun 27, 2013 (gmt 0)|
> issues with search engines
You're more likely to see which search terms people are arriving at your site with.
| 12:51 pm on Jun 27, 2013 (gmt 0)|
|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:
| 12:56 pm on Jun 27, 2013 (gmt 0)|
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?
| 1:23 pm on Jun 27, 2013 (gmt 0)|
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.
| 6:57 pm on Jun 27, 2013 (gmt 0)|
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.
| 7:11 pm on Jun 27, 2013 (gmt 0)|
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.
|brotherhood of LAN|
| 8:47 pm on Jun 27, 2013 (gmt 0)|
>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. ^ "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"
I think phranque's post already put that angle to bed.
| 12:20 am on Jun 28, 2013 (gmt 0)|
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.
|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
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|
| 12:50 am on Jun 28, 2013 (gmt 0)|
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.
| 12:54 am on Jun 28, 2013 (gmt 0)|
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.
| 8:19 am on Jun 28, 2013 (gmt 0)|
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.''
| 9:26 am on Jun 28, 2013 (gmt 0)|
|''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.
- John Mueller
|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