Salesforce connection failure
Some of the features of the website may not work. Please try again later.

Search Engine Friendly URLs and Shared SSL

A short blog post to draw attention to what I believe may be a little known issue. It’s one we came across recently when designing an online shop.

Essentially the client wished to experiment with an online shop in order to sell cookies and preserves to a wider customer base than they now have. As the online shop is exploratory it was essential to keep costs down, so we went with a standard hosting package and a shared SSL certificate, as these certificates are substantially cheaper than their full SSL cousins.

The set-up was therefore as follows:

  • Standard URL http://www.mysite.com
  • Secure URL https://secureserver.hostingcompany.net/

The site was designed and built in a CMS, products added, payment gateways set up and everything functioning happily, ready for a public launch until I thought “hmm we should turn on SEF URLs so we can track more easily what people are browsing in the Analytics search results, and also because having search engine friendly URLs is good SEO practice” (see previous blog post on SEO).

So, I did.

I checked the site and everything looked as normal – home page working fine, contact us, about us, delivery policy etc. all displaying the required format of http://www.mysite.com/page_name.html So far so good until I tried to place a final test order through the shopping cart. I loaded up my cart, and clicked to begin the checkout process. In doing so I moved from the standard site in to the secure environment of the SSL and the urls changed to the non-SEF https://secureserver.hostingcompany.net/index.php?page=checkout.index&option=com_shoppingcart&Itemid=18&cartReset=N&redirected=1&Itemid=18.

This highlighted the first of the issues – As soon as you move to the secure server, urls are no longer search engine friendly, which although it wouldn’t affect sales too badly as the user had already entered the purchase area, it would make it harder to track in Analytics.

Then in the interests of thorough testing I tried to go back to the shop to add another product to my basket, only to be presented with a 404 error… not good! In fact any link I clicked on resulted in a 404 error even clicking the ‘home’ button. I quickly determined that this was because the url rewrite function was seeking to access an SEF URL on the secure section of the site, which of course because it was set up on different a shared access server, didn’t make sense and generated an error.

What to do?

Well I scoured the forums and it turns out that some people have come across this before, but no real solution exists to the problem. I contacted the hosting company and asked if they knew a way around it only to be told that they are not aware of any rewrite scripts that would be able to work across a shared SLL.

Essentially that leaves three options:

  1. Pay for a full SSL and a dedicated IP – not an option favoured by my client at the present time.
  2. Ignore security, leaving the checkout process insecure, until such time as the user gets to PayPal in order to make a payment – risks losing sales when people realise they are not in a secure environment
  3. Ignore SEF URLs and just let the CMS generate its standard URLs – not great for SEO

So I’m left in a quandary between options 2 and 3 until the shop proves itself worth a dedicated IP and a full SSL.

I’m erring towards security without SEF URLs as I think a security breach is potentially more damaging to sales. We can try and improve their search engine rankings in other ways.

What would you do?
Have you come across this issue?
Do you know of anyone who has managed to resolve this?

To be updated if I find a satisfactory solution.

Click here to read the full post

Comments are closed.