Ultimate guide to HTTPs for SEO

Why should you move to HTTPS

Google have made no secret that they are pushing for everyone to move, all sites to HTTPS. They have carried out research and discovered that boosting HTTPS improved ranking results and in August 2014 Google confirmed that HTTPS is a ranking signal although weak in 2014 it is potentially stronger now.

There are many acronyms used to describe essentially the same thing, however when talking in a technical capacity, it is best to use the correct language , “HTTPS”, “HTTP over TLS” and “TLS” are all terms for the same thing. “SSL” is the older standard and the current recommendation is to use TLS, however many people still refer to HTTPS as being SSL.

Googles recommendations

It is generally best to start with Googles own recommendations when planning to implement changes based on their SEO benefit. The short list is below:

  • Decide the kind of certificate you need: single, multi-domain, or wildcard certificate
  • Use 2048-bit key certificates
  • Use relative URLs for resources that reside on the same secure domain
  • Use protocol relative URLs for all other domains
  • Don’t block your HTTPS site from crawling using robots.txt
  • Allow indexing of your pages by search engines where possible. Avoid the noindex robots meta tag.
  • Use HTTP Strict Transport Security
  • Use SPDY (deprecated) 

What kind of certificate do you need: single, multi-domain, or wildcard certificate

Majority of sites now span multiple subdomains,   If you host blogs, forums or anything similar on a separate sub domain then  I would recommend you use an appropriate wildcard. In the past I would always recommend using a subdomain to load assets, particularly if mobile speed is important.

Most browsers limit the amount of files they can retrieve from a single host at once, so where files can’t be combined they should be split over multiple hosts. This solution is referred to “Parallelism”, you can also ensure that a subdomain is optimised for static assets (using cookieless and a 304 status header).

Recently however HTTP2 is changing the recommendations here.

Use a 2048-bit key certificates

For the required organic boost get the best certificate you can, as a minimum I would recommend that the cert has the following criteria;

  • provided by a trusted organisation
  • 2048-bit key
  • TLS

Relative URLs or ‘protocoless’ urls

It is critical when loading assets you use https, otherwise they will not appear in some browsers or where they do appear they will be not show the green padlock. Personally if you are confident about going to HTTPS I would now try and load all assets via HTTPS explicitly and not use protocoless urls any more.

There are a number of digital assets tend to present the most issues –

  • Images, particularly where the image was loaded using a page editor such as in WordPress posts.
  • JavaScript libraries hosted on CDNs (like jQuery),
  • CSS (including images or fonts loaded in using CSS),
  • Form end points (the target of a form)
  • Embeds such as Facebook, YouTube or other JS embeds

Later I will talk through some tools to find these.

Don’t block your HTTPS site from crawling using robots.txt / robots metatag

Sometimes to ensure that there is no duplicate content web managers would block the HTTPS version of the site. This is less common when it is a single site available on both http and https. If you block anything that stops Google from being able to tell you are on HTTPS, you won’t see any benefit and increasingly this will negatively impact your organic performance.

Use HTTP Strict Transport Security (HSTS)

“…This mechanism tells the browser to automatically request pages using HTTPS even when the user enters http in the browser location bar. It also tells Google to serve secure URLs in the search results. All this minimizes the risk of serving unsecured content to your users…”
https://support.google.com/webmasters/answer/6073543?hl=en

This is a change to your Content Security Policy (CSP) however this should be the very last step as it can create functional problems if something critical becomes blocked, however for the maximum organic boost, this step is required.

About SPDY

“ SPDY is a protocol that incorporate TLS, which attempts to reduce latency when loading pages. It is currently not an HTTP standard (albeit it is being drafted for HTTP 2.0), but is widely supported.”
https://wiki.mozilla.org/Security/Server_Side_TLS#SPDY

SPDY was created by Google and can significantly improve HTTPS page speed, as this is a bit more technical, the best thing would be for you to read the details at – https://www.chromium.org/spdy/
Recently however Google have deprecated support for SPDY – this looks like it will be discontinued as HTTP/2 becomes a standard.

“..Throughout the process, the core developers of SPDY have been involved in the development of HTTP/2, including both Mike Belshe and Roberto Peon. As of February 2015, Google has announced that following the recent final ratification of the HTTP/2 standard, support for SPDY would be deprecated, and that support for SPDY would be withdrawn completely in 2016…”
https://support.google.com/webmasters/answer/6073543

 

As such HTTP/2 is strongly recommended to gain the performance boost that comes if you are on HTTPS.

Moving to HTTPS

Ideally moving to HTTPS gradually allows you to test along the way, avoiding any issues as you go. This approach minimises any potential for users (or search engines) to experience issues.

At this point we will assume you don’t have a separate server for HTTPS and in fact you will be running the main server with a https cert installed, if this isn’t the case you will need to adapt these recommendations accordingly, in fact it massively complicates the whole process.

Now you have a acquired and installed a certificate the next steps are as follow; –

  1. Test the certificate
    A quick test of the certificate is available online at SSLLabs.com/ssltest This free online service performs a deep analysis of the configuration of any https web server on the public Internet. This free service gives you a grading, aiming for an A is preferable, but many large companies only attain a C, it does tell you the steps required to improve.
  2. Setup Google Search Console (GSC) access for HTTPS
    Formerly called Google Webmaster Tools (GWT), Google sees https and http as separate websites so within GSC both need to be authorised to see the complete picture.
    Depending on the authentication method you are using, simply adding the new site will ‘just work’. If you access has been given to you from another account, unfortunately you would need to ask them to do this.
  3. Dual run both http and https
    Running the site on both HTTP and HTTPS allows you to scan for any issues   therefore giving you the opportunity to resolve any issues before pushing users and search engines to HTTPS. 

Google Analytics Tracking
You can track who is on HTTP and HTTPS very easily if you are using Google Tag Manager as a built in URL Variable – (see image). This allows you to see the proportion of traffic not on HTTPS at a later date.

Configuring a Protocol variable in GTM

This can either be setup as a content group or a custom dimension by editing the main tracking, if you need help with this tweet @OfflineTake

Fetch and Render
Use Googles Fetch and Render within webmasters tools to ensure there are no issues with Google crawling the content – google.com/webmasters/tools/googlebot-fetch

Monitor for exceptions using a CSP Violations Report
Chrome and Mozilla support the ability to push mixed content reports out to a 3rd party reporting tool. An excellent  tool was developed by Scott Helme (which at time of  publish is free). Scott has written an excellent post on “how to” ScottHelme.co.uk/fixing-mixed-content-with-csp/  

Moving to HTTPS

When your site is  fully tested and you are confident that everything is in place then push organic value to HTTPS rather than HTTP

  • Change the canonical tags across the site to ensure they are pointing to HTTPS
  • Change the XML Sitemap
  • Make sure that traffic on HTTPS stays on HTTPs by crawling it with Screaming Frog

This pushes the organic traffic rankings to HTTPS consolidating the link equity and allows for further testing it also gives further time to update any inbound marketing.

Within Screaming Frog there is an export called “insecure content” that is invaluable to tracking down where links to http are within your site.

At this point I would recommend waiting approximately one week – before finally moving permanently over.

301 Redirection 

Redirect all traffic using a 301 (Google have said that a 302 will carry 100% of the ‘PageRank’ but I would absolutely go with a 301 otherwise you are neglecting Bing & other search engines).

  1. HSTS

To improve security, something Google recommend “enable HTTP Strict Transport Security”, this significantly improves security.

“HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.”

This is another change to your Content Security Policy (see above) and will enforce HTTPS for all content, protecting your content from injection and cookie hijacking which is one of the main reasons for this push from Google. When you are completely confident you are going to be able to maintain HSTS a final step is to get onto the chrome preload list – https://hstspreload.appspot.com/

Further information on HSTS can be found here – https://varvy.com/pagespeed/hsts.html

Additional notes

  • Add the renewal of the certificate to a calendar and make sure you renew it ahead of time (it might be worth making sure there are multiple people who are responsible for this) if you are on the HSTS list and the certificate expires, you can loose all traffic.
  • Any site migrations become more complex with additional certificates required, if a domain name change is done then it is critical that the old site certificate is maintained.
  • When moving to HTTPS you do not need to use the change of address feature in Google Search Console.
  • Migrating in stages is ok! As mentioned above, blogs are sometimes more challenging so migrate the main site first.

Hire a consultant

If you don’t have an SEO consultant or an agency in place it is well worth hiring a consultant, the steps above are relatively simple however having someone in place to ensure they are followed and performance impact is monitored is well worth it considering the impact it could have.

 

SEMrush Webinar

The three of us here at TakeItOffline will be running a webinar on HTTPS Migration on April 25th at 2pm BST. If you’d like to watch, please follow this link and register your details, otherwise the video should be available to watch afterwards. We will also be posting the slides after the talk.

 

Leave a Reply

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

  • SomeGeeza says:

    What are your thoughts on using the “Upgrade-Insecure-Requests” HTTP Header to ensure users only see secure versions of pages?

    Is this fine to use in the case of a CDN where the assets haven’t been redirected to https versions, but users are only (theoretically at least) being served the secure versions?

    • Gerry White says:

      your CDN would still need to support https but, yeah I think this is a great step – part of me does feel that you should try and complete this yourself rather than relying on a CSP and quite honestly, it is something I haven’t implemented (I have blocked mixed content). If you do it and see good results from it, can you reply to your comment with how it went ?