Google has just announced that they are incorporating SSL/HTTPS into their algorithm.
At the moment the ranking factor is only a very “lightweight signal” and is “less weight” when compared to the Panda signals. I expect this will increase over time whilst they allow for webmasters with their fingers already on the pulse to implement these changes, so I plan to start incorporating this move wherever possible.
This change by Google has come from the desire for everything on the web to be secure, with Google wanting us to develop ‘secure by default’. If you think about it, this makes a lot of sense, however requires a little re-education when it comes to our expectations.
During the last year we have all heard about the risks of insecure data, hackers, Heartbleed etc. so we are aware of some of the risks. Users are starting to expect more secure elements within sites or secure sites for data that is deemed ‘private’, but not for ‘standard’ content or blogs etc. This is one of the key differences or game changes Google is promoting.
Whether your site is a blog, an e-commerce site or a bank, this move to secure by default looks to push ‘secure’ content across the board for all communication everywhere.
Google has understandably incorporated this because it protects both your visitors and your site, ultimately promoting a secure and trusted web.
So what is a secure site? A secure site isn’t just about encrypting data; for it to be ‘secure’ it should do three things:
- Authenticate the server – This checks the server so you know the site you are visiting is, in fact, the site it claims to be.
- Data integrity – Data is not modified in transit between client and server.
- Encryption – Stops people collecting your data or ‘eavesdropping’ on your journeys across the web.
All of the above, prevents the following attacks:
- Active attackers impersonating the site.
- Active attackers changing data.
- Passive & active attackers listening in and collecting information.
You can read more information on computer attacks in this article: http://en.wikipedia.org/wiki/Attack_(computing)
In short, a passive attacker listens in and gathers data, while an active attacker targets a site or a user. For example, by replicating a site hackers can trick visitors into using the ‘replica’ site and entering their personal information or credit card details etc. If everything is secure the passive attackers would not be able to understand the data as it would be encrypted, and an active attacker would not pass through the server authentication.
These three elements provide a secure site: authentication, data integrity and encryption.
This is some very top line information so that you can understand the process even if you are not the person in charge of deploying the change over from HTTP to HTTPS. However, understanding the process will enable you to more effectively manage the search implications:
A Bit of Background
TLS = Transport Layer Security
You’ve probably heard of Secure Sockets Layer (SSL) which is TLS’s predecessor. They are cryptographic protocols that provide secure communication over the Internet. In cryptography, the key to the code is also known as a cipher and it is measured in size. These keys have been upgraded from 1024 bit which became crackable sometime between 2006 and 2010, to the new 2048 bit size, which will be secure until 2030. This means that if you are currently on HTTPS but have a 1024 certificate you will need to upgrade to a 2048 bit TLS Certificate
Central Processing Unit (CPU)
Your Central Processing Unit is the hardware within your computer that carries out the instructions of a computer program. For a more in-depth definition of CPU visit this article: http://en.wikipedia.org/wiki/Central_processing_unit
Transmission Control Protocol TCP
Transmission Control Protocol is a core protocol of the Internet Protocol suite (IP). TCP provides delivery of data between programs running on computers and the Internet, for example. Find out more on TCPs here: http://en.wikipedia.org/wiki/Transmission_Control_Protocol
An HTTP ‘keep alive’ is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response. This reduces cost by reusing a TCP connection multiple times. Find out more here: en.wikipedia.org/wiki/HTTP_persistent_connection
How to Go Secure:
- You will need to get a 2048 bit TLS certificate
The cost for this can vary depending on whether you have a non-commercial or commercial site. There are also various options that are tailored to how you have developed your domain, although having a single domain is often the cheapest. A single domain means that you serve all content from your specified URL: www.example.com. However, you could have a multi-domain such as www.example.com, www.example.co.uk or resource.example.com and blog.example.com. Another option is to have a wildcard certificate, however this can be expensive but will help if you don’t know or cannot specify all of the subdomains you have.
- Configure TLS on your server
Most people are concerned that going ‘secure’ will have an increased cost implication by increasing the amount of CPUs. However, if you have modern CPUs set up with a couple of optimisations as in the example below, this isn’t the case:
Step 1. Asymmetric Encryption – Verifying the public script can increase costs so utilise Keep Alives (as above) to optimise this.
Step 2. Symmetric Encryption – Refer to Mozilla “server side TLS” Wiki for configuration best practices for Apache, HAProxy, AWS etc. https://wiki.mozilla.org/Security/Server_Side_TLS
- Check your site is secure with Qualys SSL Labs
You can scan and check your server to make sure that it is secure. You should do this any time you update your server and you will receive a report on any outstanding issues: https://www.ssllabs.com/.
You can also test other sites with this tool, so if you are ever unsure of a site’s security make sure you test before you buy!
How to Migrate to HTTPS and Protect Your SEO
Great resource: https://support.google.com/webmasters/topic/6029673
These tasks are a mix of the SEOs and Technical Developers’ jobs, but being aware of them will allow you to problem solve if any issues arise.
- Configure & verify HTTPS on your server
- Check correct hostname
- Check complete certificate chain
- Set a reminder for the expiry date and renew a week in advance.
- Check and set up HTTPS in Google Webmaster Tools (more on this later).
- Update site content to request HTTPS resources
- Use relative URLs. For example: src=”//example.com/
Protocol URLs will also work on development sites without the certificate installed on your server locally.
- Fix hardcoded HTTP URLs in your content (otherwise this creates a security hole)
- Redirect old HTTP links to HTTPS resources and set correct canonical tags.
- Use relative URLs. For example: src=”//example.com/
Mobile Optimisation: Make sure you are not going into a 301 redirect loop i.e. HTTP://example.com redirects to HTTP://www.example.com going to HTTPS://www.example.com and use HSTS as outlined below to improve performance.
- Update internal links to HTTPS
- Verify that robots.txt, rel=canonical and other signals are correct.
- Make sure you allow the Googlebot to crawl both HTTP and HTTPS URLs so that Google can find the redirect and index the HTTPS content. Test in Google Webmaster Tools with “Fetch as Google”.
- Make sure you allow Google to index the HTTPS content.
- Make sure canonical tags are updated from HTTP to HTTPS.
- Set up redirects correctly, add HSTS as well.
- HSTS – HTTP Strict Transport Security – Is a header the server can return when it returns the page. It sets a policy on the browser with a maximum age so that it remembers this for a defined time and includes subdomains. When a user requests the site, it will remember that you want it to view the HTTPS and will automatically skip the redirect and apply the rewrite so that it is quicker. It eliminates the HTTP to HTTPS redirects which is great for mobile users and increasing site speed.
- Verify HTTPS and HTTP profiles in Google Webmaster Tools, GWT
- Add all variants of your site into GWT even though you are redirecting all the URLs to one. This is because GWT sees them as separate sites as they can have different issues or technical problems which you can then identify in their separate GWT profiles. For example: https//example & https://www.example & http//example & http://www.example & https://m.example if you are not using responsive design
- Check GWT regularly
- Indexed pages – check that the HTTP indexing goes to zero pages indexed and the HTTPS site takes over the indexation increase.
- Check Google can crawl both sites.
So there you have it. Moving from HTTP to HTTPS needs to be a considered approach as with any site migration. Carrying it out correctly should have a positive impact on your site with a few added benefits for SEO and mobile along the way.