For a number of years Google has strongly advocated moving sites to HTTPS as a form of basic security, and with Chrome 70 rolling out later this year (which will mark HTTP sites as not secure), the search engine is forcing the hands of Webmasters even further.

HTTPS doesn’t necessarily mean that you have a secure website however, but what is clear, is that Google (and other search engines), see it as a security feature, and it’s in their interest to only send users to secure websites. In time, their definition of what is secure probably will change, but for now, it’s HTTPS.


Google has confirmed that HTTPS can offer a slight ranking signal, but in a market where a high per cent of sites are served on HTTPS, the benefit is minimal. However, SEO is not all about rankings and in Chrome 70, Google will highlight websites served over HTTP as not secure, so this will definitely impact your site’s conversion rates.

Not migrating to HTTPS correctly can also have disastrous consequences for your organic search traffic, so while moving to HTTPS is now cheaper than ever (in terms of the cost of SSL certificates), it’s still important that the process is managed correctly.

What is HTTPS

HTTPS is effectively a standard HTTP protocol with an added layer of SSL (secure socket layer), or TLS (transport layer security) encryption. This encryption adds security to data in transit (the requests being sent between your computer and the server), but it does not secure your data at rest, either on your computer or in the database. It is commonly known as SSL. Browsers and servers still communicate through HTTP, but with the SSL layer of encryption.

It prevents packet sniffers and passive attackers, such as Eve, from viewing or modifying packet requests, while keeping passwords, credit card details, and other information you’re sending safe — at least while it’s in transit.

Alice, Bob, and Eve are fictional characters used to explain Crypto technologies (amongst others).

Packets can still be intercepted by passive attackers while you’re exchanging them with a server, but they cannot be read unless the hacker has the encryption key, so the data packet can be decrypted.

How a secure connection is established

A secure (SSL) connection is set up between the user’s browser (the client), and the server by means of a handshake. A successful handshake consists of:

  • Confirming that the user browser is communicating with the right sever, and vice versa.
  • Both the client and the server agreeing on a cipher suite (for example TLS_RSA_WITH_3DES_EDE_CBC_SHA), including the encryption algorithm used to exchange data.
  • The encryption keys being agreed by both parties.

If the handshake fails and a secure connection can’t be established, the user typically gets an error screen:

Aforementioned error screen.

Once that a secure connection has been established, both the client and the server can use the algorithm and keys (agreed upon during the handshake) to securely transmit packets between each other.

The handshake

The handshake consists of three stages, and all play a role in securing the connection between the client and the server, these are the Hello, the SSL certification exchange, and the key exchange.


The handshake is initiated by the client sending a ClientHello message to the server, containing all the necessary information for the server to connect to the client via SSL (cipher suites, maximum SSL version etc). If successful, the server responds with a ServerHello, which contains similar information.

SSL Certification Exchange

Now that a secure connection has been established, the server is required to declare its identity to the client, and this is achieved by the SSL certificate.

The SSL certificate contains the server’s public key, owner, and the domain (property) it’s attached to, along with certificate expiry dates and a digital signature.

The client then checks that it trusts the certificate, or that it has been verified and trusted by an authoritative CA (certificate authority).

Key exchange

During the Hello phase, the symmetric algorithm used to encrypt the data packets is agreed, and this uses both a single key for encryption and decryption. The single key is agreed upon using asymmetric encryption, as well as the server’s public and private keys.

Once both parties are sufficiently happy that they are communicating with the “right” person, HTTP requests can be sent in plaintext, as only the other party in the handshake knows how to decrypt the message, preventing MITM (man in the middle) and passive attackers from being able to read your messages (even if they capture them).


In 2014 Google announced via the Webmaster Central Blog that HTTPS was a ranking signal, but this was only half of the message. The first sentence of the blog post read:

Security is a top priority for Google.

Given that a part of Google’s algorithm is founded on user-based metrics, Google’s preference for trusted and more secure websites isn’t surprising. The search engine has made all the signals that if equal, HTTPS will rank higher than HTTP.

What about a ranking boost?

From experience, the ranking boost is minimal, but if you’re purely basing HTTPS on rankings, then you’re judging a fish by it’s ability to climb a tree.

As part of an overall SEO strategy, moving to HTTPS should always be a priority to protect users and the business.