What Is HTTPS and How Is It Different From HTTP
Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The ‘S’ at the end of HTTPS stands for ‘Secure’. It means all communications between your browser and the website are encrypted. HTTPS is often used to protect highly confidential online transactions like online banking and online shopping order forms.
Web browsers such as Internet Explorer, Firefox and Chrome also display a padlock icon in the address bar to visually indicate that a HTTPS connection is in effect.
How Does HTTPS Work?
HTTPS pages typically use one of two secure protocols to encrypt communications – SSL (Secure Sockets Layer) or TLS (Transport Layer Security). Both the TLS and SSL protocols use what is known as an ‘asymmetric’ Public Key Infrastructure (PKI) system. An asymmetric system uses two ‘keys’ to encrypt communications, a ‘public’ key and a ‘private’ key. Anything encrypted with the public key can only be decrypted by the private key and vice-versa.
As the names suggest, the ‘private’ key should be kept strictly protected and should only be accessible the owner of the private key. In the case of a website, the private key remains securely ensconced on the web server. Conversely, the public key is intended to be distributed to anybody and everybody that needs to be able to decrypt information that was encrypted with the private key.
What is a HTTPS certificate?
When you request a HTTPS connection to a webpage, the website will initially send its SSL certificate to your browser. This certificate contains the public key needed to begin the secure session. Based on this initial exchange, your browser and the website then initiate the ‘SSL handshake’. The SSL handshake involves the generation of shared secrets to establish a uniquely secure connection between yourself and the website.
When a trusted SSL Digital Certificate is used during a HTTPS connection, users will see a padlock icon in the browser address bar. When an Extended Validation Certificate is installed on a web site, the address bar will turn green.
Why Should I Care?
Google have made this clear since 2014 that https is a ranking factor, but they are making bigger changes this year (2017). Google has stated “Starting January 2017, Chrome 56 [version] will label HTTP pages with password or credit card form fields as “not secure,” given their particularly sensitive nature.”. This means that sites that are not using https could be losing traffic as people cannot access the site. Google will also use https as a ranking factor and indirectly use user experience factors to down rank sites not using https. I wrote about this in Chase Reiner’s Top Strategies For SEO in 2017.
There is proof of this as I received a notification from Google Search Console with one of my sites I manage, triggering a warning.
It says in the message below that the page contains credit card or password input fields. The weird thing is that it contains neither.
The affect of this will be that this page will:
- Display a warning when people visit the page
- Affect search rankings on this page.
So even if you do not collect passwords or credit card information it is a good idea to get https on your site. This will stop Google mistakenly marking your pages as insecure.
How To Get HTTPS On Your Site
Get An SSL Certificate
The first step is to buy an SSL certificate for your site, you can get these from somewhere like SSLs.com.
There are number of different types, but get one that best fits your needs. For example if you want to have both www and non-www versions of your site secure get a wildcard SSL.
They also differ by level of assurance, type of encryption they use and type of validation. Essentially the more you pay the more secure your connection is. SSL certificates range from $30-$100 USD per year.
Making the switch from HTTP to HTTPS
- Start with a test server. This is important because it lets you get everything right and test without screwing it up in real time. Even if you are doing the switch without a test server, there’s almost nothing you can do that you can’t recover from, but it’s still best practice to have a plan and have everything tested ahead of time.
- Crawl the current website so that you know the current state of the website and for comparison purposes.
- Read any documentation regarding your server or CDN for HTTPS.
- Get a security certificate and install on the server.
- Update references in content. This can usually be done with a search-and-replace in the database. You’ll want to update all references to internal links to use HTTPS or relative paths.
- Update references in templates. Again, depending on how you deploy, but you’ll want to make sure references to scripts, images, links and so on are either using HTTPS or relative paths.
- Update canonical tags. Most CMS systems will take care of this for you when you make the switch, but double-check, because that’s not always the case.
- Update hreflang tags if your website uses them, or any other tags such as OG tags for that matter. Again, most CMS systems will take care of this, but it’s best to QA it just in case.
- Update any plugins/modules/add-ons to make sure nothing breaks and that nothing contains insecure content. I commonly see internal site search and forms missed.
- CMS-specific settings may need to be changed. For major CMS systems, these are usually well-documented in migration guides.
- Crawl the site to make sure you didn’t miss any links and nothing is broken.
- Make sure any external scripts that are called support HTTPS.
- Force HTTPS with redirects. This will depend on your server and configuration but is well-documented for Apache, Nginx and IIS.
- Update old redirects currently in place (and while you’re at it, take back your lost links from redirects that haven’t been done over the years).
- Crawl the old URLs for any broken redirects or any redirect chains.
- Update sitemaps to use HTTPS versions of the URLs.
- Update your robots.txt file to include your new sitemap.
- Add the HTTPS version of your site to all the search engine versions of search console that you use and load the new sitemap with HTTPS to them. This is important, as I’ve seen traffic drops misdiagnosed because they saw the traffic in the HTTP profile drop, when the traffic in reality moved to the HTTPS profile. Another note for this is that you do not need to use the Change of Address Tool when switching from HTTP to HTTPS.
- Update your disavow file if you had one for the HTTPS version.
- Update your URL parameter settings if you had these configured.
- Go live!
- In your analytics platform, make sure you update the default URL if one is required to ensure that you are tracking HTTPS properly, and add notes about the change so that you know when it occurred for future reference.
- Update your social share counts. There’s a lot of gotchas to this, in that some of the networks will transfer the counts through their APIs, while others will not. There are already guides for this around if you are interested in keeping your share counts.
- Update any paid media, email or marketing automation campaigns to use the HTTPS versions of the URLs.
- Update any other tools such as A/B testing software, heatmaps and keyword tracking to use the HTTPS versions of the URLs.
- Monitor everything during the migration and check, double-check and triple-check to make sure everything is going smoothly. There are so many places where things can go wrong, and it seems like there are usually several issues that come up in any switch to HTTPS.
There is a bit to do, especially if you don’t want to see traffic drops in migration. But this will be well worth it in the long run, especially if you get on to it now and your competitors don’t.
If you need more help with this please feel free to talk to me, I am always happy to answer questions or talk to your web designer to help make this move.