In August 2014 Google officially announced to give sites which are running on an Secure Socket Layer (SSL) Certificate a ranking boost and make https a ranking signal.(Source).
ricardo.ch, the biggest Swiss online auction platform, was running on a Standard Transport Layer (HTTP), only Log-in areas were running on https.
In April 2015, we decided to redesign the whole platform in a responsive design. With this, we also decided to change the Log-In process and switched from a normal Log-In page a user was redirected to, to an overlay, which forced us to also switch from http to https.
New Log-In Process with Overlay instead of Landing Page
The special challenge was that we decided to not switch all at once, but do a step by step switch. Starting with our product detail pages, followed by homepage and the product listing page.
A switch to https is not as easy as it sounds and needs some thought in advance. With this post I’d like to point out the challenges and thoughts I had while realizing this project.
What is TLS/SSL & HTTPS?
SSL stands for Secure Socket Layer, which delivers an encrypted conversation between web browser and web server (Source). This means all data a user is typing into his browser, (address fields, credit card details, search phrases) will be not be visible for 3rd parties.
An encrypted, secured https domain looks like:
An unencrypted, unsecure domain looks like:
Advantages of a migration for the user
https and it’s lock symbol displayed in the browser’s address bar gives the user a safer feeling, which can have an impact on conversion rates. Users who feel secure on the web are more likely to give credit card credentials to a shop site.
The Lock Symbol in Chrome shows that the line is secured
Questions and challenges I faced before
As mentioned above, it wasn’t possible to migrate the whole site at once. A question which was raised quickly was:
Is it possible to migrate just partial to https?
This is no problem. However from a user perspective it is not really cool, as the user switches from unsecure parts to secure parts and vice versa, within the buyer flow (this is how we call the process from looking at a product to buying it). This can lead to browser notifications, which notify the user that he is on a unsecure site, ergo = bad user experience.
Different Browser Notifications for unsecure parts on an http domain
Do I need to set up a new Search Console account for my https version?
Yes. For Google http://www.ricardo.ch and https://www.ricardo.ch are two different domains.
Do I need to set up a new Disavow File for my https version?
I did not find any information about this particular question, but after I did set up a Search Console Account for the https version, my Disavow File was not migrated by Google. So yes, a new Disavow File needs to be added to the new Account.
The following posts helped a lot on the topic of migrating from http to https
What did I look at, when migrated?
When migrating from http to https, it is not just redirecting from one domain to another. All internal resources, like CSS files, CDN Paths, internal links and image paths need to be adapted too. External resources such as scripts from advertisers need to be adapted as well. If not, it can lead to blank spaces on the page and/or to those browser notifications as mentioned earlier.
Furthermore I did check the following facts before
- SSL Certificate is not terminated short to mid-term
- SSL Certificate is not running on the wrong host (www.ricardo.ch vs. ricardo.ch)
- https is not blocked in robots.txt
- https pages are not instructed to noindex
- https pages are responding a 200 status code
Adapting <head> elements
In <head> area rel=canonical or rel=alternate link elements are implemented, which are very important when migrating. These must be changed and it is important to mention that those should neither be protocol relative nor relative but absolute urls (Source)
A relative url is a url path without host and domain.
1. Adapting rel=canonical
At ricardo, we had a default canonical setting. Every URL referred to itself via rel=canonical. To tell Google that a migration from http to https has happened and that it can exchange them in their index, it is necessary to first change the link of rel=canonical. From what I learned it is super important to set them before you redirect everything ( I will point out at the reason why at the end of this post).
<link rel=“canonical“ href=“http://www.ricardo.ch/“ />
<link rel=“canonical“ href=“https://www.ricardo.ch/“ />
adapted rel=canonical from http to https
2. Adapting rel=alternate
Same needed to be done for rel=alternate, as ricardo has two different language versions, French and German, which will be referenced in rel=alternate.
<link rel=“alternate“ hreflang=“fr-CH“ href=“http://www.fr.ricardo.ch/“ />
<link rel=“alternate“ hreflang=“fr-CH“ href=“https://www.fr.ricardo.ch/“ />
adapted rel=alternate links from http to https
3. Adapting internal resources
All resources, which urls running on the same domain, have been changed to relative url paths. All resources on subdomains or other domains were adapted to protocol relative URLs (Source).
In the case of ricardo this looks like:
CSS Path adapted to relative URL Path
3. Adapting external resources
External resources are requests to external domains, which are necessary in order to display sites content or tracking properly. For ricardo, this was our Content Delivery Network, our Image Servers, Social Media Accounts, Adserver and our A/B testing tool Optimizely.
If you know by heart, that those resources are running on https, you can set absolute urls. If not it is recommended to set URLs as protocol relative.
If a browser then requests a page and finds the protocol-relative path, it tries to request first the https, before the http version. This avoids browser notification as mentioned earlier.
Links to a subdomain adapted in protocol relative urls
Server side redirects
To redirect user and user agents from http to https it is necessary to set a 301 permanent redirect. This redirect helps Google to understand that it has to exchange an already indexed http urls with new https urls. This can be done with a server side 301 redirect. You can do this in your htaccess file. At ricard0 we manage our redirects through an F5 load balancer. So all we needed to do is set up an iRule, which looks in our case exactly like:
IRule on a F5 who manage redirects from http to https
Browser redirects through HSTS
After we switched the entire site to https, we installed this http strict Transport Security Modul (HSTS) on our server. This modul forces a browser to load the page directly in https, without requesting a http version. Big advantage with this is that it makes the page load faster, because no redirect has taken place. You’ll notice a 307 Internal (browser cached) Redirect in your browser plug-in.(Source)
Browser Redirect with HSTS Modul
Switching http and https URLs in Google’s Index
After a migration from a technical point of view, the monitoring began. This can easily be done with:
- site search – for daily monitoring
- Search Console – for weekly monitoring
To keep in mind: The Numbers from Search Console and Site Search can have a massive difference. This is because Search Console shows also non html files a site search to 99% just html files.
To do a site search, I typed into google search bar site:www.ricardo.ch inurl:https and same for http site:www.ricardo.ch inurl:http.
In order to have a rather visible understanding I put this daily data into a Google Spreadsheet.
red line shows amount of https indexed, blue line amount http indexed urls
Indexing of https urls in search console
Indexing of http urls in search console
What I’ve learned after migration
As the deindexation has taken longer than I expected, I recommend to set the rel=canonical a month before redirecting the site from http to https
As you can see on the charts above, Google takes time to reindex, especially when you have (as we had at that time at ricardo) no sitemaps.