What Are the Advantages and Disadvantages of Converting a Website to a Secure HTTPS?

What Are the Advantages and Disadvantages of Converting a Website to a Secure HTTPS?

Do you also wonder whether it makes sense to move your website from the so far used HTTP protocol to a secure HTTPS? Would you like to learn beforehand what is ahead of you if you do so?

Switching to HTTPS is definitely not a simple thing. That’s why you should weigh all the pros and cons beforehand. This article summarizes of all possible pitfalls a transition to HTTPS can cause, along with a list of the main reasons why (not) to go for the implementation of HTTPS on your site.

To start with, let’s sum up what HTTPS is.


HTTPS (Hypertext Transfer Protocol Secure) is a superstructure above HTTP (Hypertext Transfer Protocol), Internet communication protocol, which is used to transfer data on the Internet.

You have probably already came across HTTPS. Yet, you may simply not be aware of it. The easiest way to identify if a site is using an HTTPS protocol is to check the link bar, where would be a picture of a green locked padlock.

Sample link bar with an HTTPS protocol


HTTPS differs only by the data being encrypted during the transfer between the server (the website you want to view) and the client (your browser).

This substantially reduces the possibility to tap, monitor or modify the information. HTTPS also verifies the counterparty (to see who actually sends the data). This enables the users to know who they communicate with, and that no one is trying to deceive them.

However, even the use of HTTPS does not mean that communication cannot be tapped or modified in some manner. But it is significantly more difficult to do so when MITM method is employed,

Note MITM (man-in-the-middle) is a method of attack on security. Such an attack is usually caused by an attacker who is an intermediary between two communicating users. S/he taps all the communication, and sends its encryption keys to both parties, which help gain access to the contents of encrypted messages, and subsequently change them. Either of the users may not be aware of the existence of such an intermediary. Having said that MITM implementation requires additional action taken in the network infrastructure, through which the user connects to the server (usually to manipulate the routing tables of IP or DNS, i.e. so-called DNS spoofing).


Securing a system with HTTPS is done through a TLS protocol, which is based on certificates and trusted certificate authorities. These certificate authorities are institutions from whom are obtained trusted SSL certificates.

Anyone using a secure protocol needs to have “installed” a list of trusted authorities or certificates of their counterparties in their system. These are the parties they trust and are willing to communicate with (i.e. trust them).

By default, an operating system of any ordinary user contains some trusted root certificate authority (such as VeriSign and Comodo). Web servers you communicate with have certificates signed by such trusted certificate authorities.

So much about it in a nutshell.


“Certificate authorities are credible institutions that issue certificates. The price of such a commercial certificate depends on the level at which the company is in the whole food chain”.

This is owing to the fact that the company needs to spend appropriate funds to acquire its own certification. Following this is also specified the company’s margin from certificate issuance.

Certification companies can grant permission to other companies to issue certificates, and thus make them certificate authorities that sell certificates (usually at lower prices). These can then spread such an authorization further and resell.

The C price, therefore, varies depending on the entity from which you are buying the certificate. Generally, the longer the authority exists the more expensive the certificate.

Note: Your certificate can be trusted even if it is not directly signed by a trusted certificate authority. This can be achieved through an intermediary – another certificate authority. For example, if there is a generally recognized certificate authority A, which signs a trusted root certificate of a certificate authority B, then you can consider the certificate from authority B a trusted one.

Broadly speaking, this “trust-path” can unlimitedly chain. This way you can easily get 3 more certificates, along with your original certificate, preparing a credibility path for your certificate.

This can cause problems when intermediated certificates, which are required to verify your certificate, are not listed in the correct order, or when any of these certificates are invalidated throughout the chaining.

Certificate chaining:

Therefore it is good to aim to have as short as possible trust-path – this usually also affects the cost of the certificate.

Here you can check the correct deployment of an SSL certificate:


Imagine that you are logging on to an unsafe site and your password is somehow snatched on the way. Now someone will have your account login details. Everyone can probably imagine what a spectre such a situation may be for banks and for its users logging in their electronic banking.

But this is not the only risky situation you might face. Imagine that you send to your users some data and the attacker alters it on the way.

For example, after a customer fills in the order details, the attacker slips another payment gate link under the original one and the unsuspecting customer sends money to someone else. There are a number of such risk scenarios during unsecured transfers.

Users who connect to an unsecured site may be viewing modified transmitted data and see any “harmful” content (viruses, banners etc.). Hypothetically, every time a user will want to view your site, your competition could display pornographic material, or harm you in any other way they may please.


Strictly speaking, it should be used on any sites where data theft or alteration could cause irrecoverable damage, i.e. virtually on all websites :-).

Yet, those who should pay to data protection due attention are especially:

  • E-shops where you fill out online order forms and pay by credit cards: Avoiding misuse or theft of important personal data and payment information is crucial here.
  • Banks and financial institutions, working with payment data and personal details of customers.
  • Civil service and state administration, since these institutions often work with sensitive information (dates of birth, addresses, social security numbers, etc.) as well as all other institutions they must protect your data properly
  • All other websites that process customer data online, (emails, addresses, phone numbers, payment details).

These segments should consider data protection their priority.


Almost two years ago Google released a statement, in which it warned that from the perspective of SEO sites using HTTPS (SSL = certificates) would be slightly favoured, and will probably appear higher in search results. Which, naturally, caught attention of marketers thinking that such a switch to HTTPS will help them gain competitive advantage.

For the record – Google supported the switch to HTTPS already in 2012, i.e. two years before the term HTTPS started being widely used, mainly thanks to SEO.

To set the record straight – although Google announced that it would prefer HTTPS, at the same time Google itself also argues that HTTPS has very little importance and affects about one percentage of queries. Therefore, switching to HTTPS “only” because of search engines does not make any sense.

There are hundreds of similar signals a search engine evaluates. And if the use of HTTPS is only 1% in the resulting evaluation ranking on Google it may simply not be worth it. Another point is that it means a huge amount of work. I will give you a closer idea below of what for ordeal you have to deal with if you switch to HTTPS.

You don’t really have to worry that your site would drop a dozen ranks down. Neither you get penalized if your site is still running on an unsecured HTTP. It’s just something you can do to get a little advantage. But if you don’t, no disaster will happen. Actually, almost nothing will happen, as the results show, of most users who got convinced to switch to HTTPS “because of SEO.”

You should switch to HTTPS because of your users, to protect their privacy. Nothing looks worse than when some security problem leaks, and users‘ data then inexorably run on the Internet, and everyone knows it may have been YOUR fault! The problem can be even worse if you are a company that provides hosting, makes websites, or if you run an Internet wallet…


The price of the certificate – when switching to HTTPS you need to purchase willy-nilly an SSL certificate that you have to update regularly (and pay for it, or get a certificate from an entity that will provide it for free).

You can also purchase an SSL certificate even for several years ahead. Then it is not necessary to manually update it every year, unless you want to. This entire process can be automated, but it will cost you some extra time to figure out how.

Unless you need to secure hundreds of websites, you don’t have to worry that you would be paying a staggering amount. Also, there are several companies offering trusted certificates for free. So you don‘t always have to pay for it.

And if by chance you are an owner of a large number of domains that you want to secure through HTTPS, then a few thousands are probably not a big issue, as you are at least a medium-sized company, for which such amounts are a drop in the ocean.

Certificate Prices Vary Depending On the Type

Automated trusted SSL certificate from Let’s Encrypt – the cheapest (free) version, which cannot do Wildcard.

It is worth mentioning that some Czech hosting providers already offer auto-SSL. I.e. all hosted sites can make use of an SSL certificate (Let’s Encrypt) of their hosters, which is either free or for a symbolic fee. Dušan Janovský from Seznam has made the following list.

Basic Commercial SSL – The certificate can be purchased at about CZK 150 per year, which applies mostly to a single domain.

SAN / UC (Subject Alternative Name / Unified Communications)) – These certificates enable securing multiple domains with a single SSL certificate.

SSL Wildcard Certificates (also known as Star certificates) – Are a universal type of SSL certificate that allows securing all subdomains under one primary domain. Wildcard certificate contains an asterisk before the name of the main domain (e.g. * Its use saves costs for purchasing additional SSL certificates; and at the same time, it saves the time required for their installation and management.

SSL IDN (Internationalized Domain Names) – Are certificates used to secure domains that use characters that are not in the standard Latin alphabet (A-Z). IDN SSL certificate can secure, for example sites, which have in their names Russian or Chinese characters.

The certificates then differ not only in the price and amount of domains, which can be secured by one certificate, but also in the type of authentication:

DV SSL (Domain Validation)– The most affordable SSL certificates that use for their verification only basic authentication at the domain level, which is sent in verification e-mail. A huge advantage of DV certificates is quick issuance, which can be done in minutes.

OV SSL (Organization Validation) – SSL Certificates offer a higher degree of credibility compared to DV certificates thanks to complete identification of the company for which the SSL certificate is issued. Verification of the company stresses credibility of the web site owner. The visitor has the option to verify the site operator at any time.

EV SSL (Extended Validation certificates) – This certificate switches the browser bar of EV SSL certificate to green. In addition, the company name appears next to the www link.

Note: Someone else can deal with your SSL worries, if you opt for intermediary services (i.e. Offload SSL). Encryption is done before the server. This communication can be enabled / disabled through firewall used only by the intermediary, thus minimize the risk that someone will be able to tap or change your data.


And now – what you should really expect if you decide to switch to HTTPS. And what advantages and disadvantages does it bring?


Perhaps the biggest hurdle that may discourage you from switching to HTTPS is time.

When switching to HTTPS you have to take into account that the actual processing of the information will take some time (figuring out what certificates are out there, which one to choose and where to buy it). You also need to consider the time spent on the actual implementation (you simply have to know where to put what, how to check it, and ensure smooth operation of your HTTPS). Finally you will also spend time fixing bugs, which you cannot avoid.

The following section is going to give you a bit of a picture of what is ahead of you if you decide to switch to HTTPS. Of course this is usual routine for an experienced web hosting company or a web integrator. However, if you do not have anyone of that sort to hand you may be in a bit of trouble.


You will need to redirect your whole web to the new URL, which will be used now by the new HTTPS instead of HTTP.

And why do we have to redirect? Websites running on HTTPS constitute a separate web system, different to the one that previously ran on HTTP. You actually have two identical websites from the perspective of search engines.

If you want to avoid duplicating your site (which is not a desirable state from SEO perspective), you have to redirect the old HTTP web to the new HTTPS version.

You need to redirect all the unsecured URLs to secured ones through status code 301 (Moved Permanently – which means that it is permanent, not just temporary).

Now imagine that this whole process has to be done, say, for a website that is used by thousands of people every day; and everything must be done smoothly, ideally without your end user being aware of it.

Again, of course, if your site uses a platform that is ready for changes of this sort (such as our CMS), the whole process is much easier and less time-consuming.


Subsequently, you have to verify that the redirection works on all subdomains of the site.

Furthermore, it is necessary to reset all the URL export links (e.g. Feeds for or zboží.cz where you have to change the URLs of https feeds).

The same goes for images, JavaScript, CSS, multimedia, PDF files, etc. You should also ensure that HTTPS is working on subdomains and external sources from which you link files – CSS, JS, images, CDN, etc.

You will need to modify all URLs on the web so that they lead to your HTTPS site (either use an absolute URL with HTTPS, a relative URL, or protocol relative URL „://“).

The redirection settings need to be done so that looping doesn’t occur (the user might be redirected to another URL and back again, and so forth, and instead of viewing the site he would see a constantly changing URL).

Additionally, you if there are hard links on your web, you need to adjust the so-called hardcoded URLs (hard links registered with http: //, for example, in articles, javascript, CSS files, etc., which means some more work.

You should adjust hreflang URL, if applicable.

You should modify URL of RSS, if you use RSS feed for e-books.

You need to modify URL to Facebook, Twitter and other interactive buttons, the same applies to meta tags OG: URL.

You should create new robots.txt.

You need to switch the location of sitemap.xml files to https: // and edit the sitemap link in robots.txt.

You should change URL in sitemap.xml file to https: //.

For large sites you need to, for smaller sites (up to a few dozen pages) you should keep the original redirect chain.

You have to redirect URL with_escaped_fragment_ = to their alternatives 1: 1 (i.e. from -> 301 -> ) to preserve information about the real source of visits.

You should test the previous points prior to deployment (e.g. using tools Screaming Frog, or Xenu´s Link Sleuth)

Changes in Google Analytics, Google Webmaster Tools, Adwords, Sklik and other tools – the next necessary step after transition to HTTPS is to reset the URLs in Google Analytics. If not, Google Analytics will not be measuring.

Google Analytics Settings

You should add the HTTPS version of the site in Google Webmaster Tools (because of HTTPS statistics).

You should change the URL of the web wherever you have been using it, e.g .: PPC campaigns (Sklik, Adwords, Facebook etc.), banner and other campaigns, affiliate links, opensearch.xml.

Then you should probably change the URL in your email signatures, automatic emails, etc. These URLs may be redirected on the server side.


To make matters worse, until recently, Seznam, in particular, had problem with indexing the transferred websites, which resulted in noticeable drop in their traffic (this situation lasted nearly a year). Seznam allegedly resolved the situation in April.

Although Seznam says that everything is alright now, it should still be borne in mind that Seznam does not guarantee smooth transition to HTTPS: “Sadly, in individual cases short drops may still occur (the bigger the site, the more prone to the problem).”

This, however, is true for any massive changes in links. In short, you never know how it can shake up your web.


As an HTTPS operator you have to keep in mind when the certificate expires, and thus in time generate and deploy a new certificate.

Otherwise, your visitors may end up viewing an ugly red warning message saying that the site does not have a valid certificate. Of course, SSL certificate renewal can be automated, but again – it will cost you extra time to figure how to do it. And time is money…

And then you want to keep in mind there is a need for testing during migration to HTTPS and fixing bugs that always occur during transition to HTTPS. You will definitely forget about something or set up something wrong.

Finally, also note that search engines can take a while processing that some change associated with the transfer to HTTPS took place, which can result in temporary (or steady decline) in your ranking (especially on Seznam) and therefore lower traffic.


Now we get to the main arguments for switching to HTTPS. Although, there are not so many, but after all they are not the reason why you are doing it.


In essence, this should be the main reason to switch to HTTPS. Transmitted data is not so easy to capture; therefore we significantly eliminate the risk of the possible data leakage problem.


Using HTTPS is considerably more complicated than using HTTP, using SPDY protocol can noticeably increase the speed of web loading. Thanks to linking of requests for individual files.

If the page loads a large number of objects (typically images that cannot be combined into one) HTTP takes considerable time to process the request creation. SPDY can group requests for files, and thus achieve a significant increase in acceleration in loading sites.

This will save you time in the future – so you will not have to make the change later. As sooner or later HTTPS protocol will probably be a standard. As a result you will be slightly ahead, and can make this change now.

As the expert on security, Michal Špaček says:

“The next version of HTTP counts only with encrypted traffic, simply put, HTTP 2.0, will be only HTTPS. While one day you will get that one extra point in SEO already now, while Google still officially favours sites that have switched to HTTPS :-). As was stated above – you shouldn’t be switching to HTTPS just for this one point.”


If you manage transactions or users’ sensitive data, and want to increase the credibility of your website and data security.

If you are launching a new Web / e-shop (so in essence you are creating everything from scratch and don’t need to do any migration from HTTP to HTTPS)

If you don’t want to be dealing with the transition HTTPS later, when you have to (as HTTPS will be a standard on the majority of sites).

Migration to HTTPS only because of SEO makes no sense, which is also confirmed directly by Seznam and Dušan Janovský:

“We get many questions asking if it is a good idea to move sites to https: protocol. Apparently, Google said they want it. I say that changing your URL for no reason is stupid. ”


Was this article helpful?

Support us to keep up the good work and to provide you even better content. Your donations will be used to help students get access to quality content for free and pay our contributors’ salaries, who work hard to create this website content! Thank you for all your support!

Reaction to comment: Cancel reply

What do you think about this article?

Your email address will not be published. Required fields are marked.