On February 8th 2018 Google announced that, beginning in July of this year, Chrome will now be marking all HTTP sites as ‘not secure’, moving in line with Firefox, who implemented this at the beginning of 2017.
This now means that the 71% of web users utilizing either browser will be greeted with a warning message when trying to access HTTP websites.
Security has always been a top priority for Google. Back in 2014 they officially announced that HTTPS is a ranking factor. This was big, as Google never usually tells us outright what is or isn’t a ranking factor, for fear of people trying to game the system.
In truth, every website which stores user data shouldn’t need an extra incentive to prioritize security over convenience. In a previous article for Search Engine Watch, Jessie Moore examined the benefits and drawbacks of migrating your website to HTTPS, and determined that on net, it is well worth making the move.
However, if you are yet to make the switch, and nearly 50% of websites still haven’t, we’ve put together this guide to help you migrate to HTTPS.
1. Get a security certificate and install it on the server
I won’t go into detail here as this will vary depending on your hosting and server setup, but it will be documented by your service provider. Let’s Encrypt is a great free, open SSL certificate authority should you want to go down this route.
2. Update all references to prevent mixed content issues
Mixed content is when the initial page is loaded over a secure HTTPS connection, but other resources such as images or scripts are loaded over an insecure HTTP connection.
If left unresolved, this is a big issue, as HTTP resources weaken the entire page’s security, making it vulnerable to hacking.
Updating internal resources to HTTPS should be straightforward. This can usually be done easily with a find-and replace database query, or alternatively using the upgrade-insecure-requests CSP directive, which causes the browser to request the HTTPS version of any resource called on the page.
External resources, plugins and CDNs will need to be configured and tested manually to ensure they function correctly.
Should issues arise with external-controlled references, you only really have three options: include the resource from another host (if available), host the content on your site directly (if you are allowed to do so) or exclude the resource altogether.
3. Update redirects on external links
Any SEO worth their salt will have this at the top of their list, but it is still incredible how often this gets missed. Failure to update redirects on external links will cause every link acquired by the domain to chain, where the redirect jumps from old structure to new, before jumping from HTTP to HTTPS with a second redirect.
Each unnecessary step within a sequence of redirects allows Googlebot more of a chance to fail to pass all the ranking signals from one URL to the next.
We’ve seen first-hand some of the biggest domains in the world get into issues with redirect chains and lose a spectacular amount of visibility.
If you haven’t already audited your backlinks to ensure they all point to a live page within a single redirect step, you can get some big wins from this activity alone.
First, make sure you have all your backlink data. Do not rely on any single tool; we tend to use a minimum of Majestic, Ahrefs and Google Search Console data.
Next, run all referred pages through Screaming Frog to check the page still loads and do the following depending on the situation:
- Any ones which return a 4XX will need to be mapped to the secure version of the most relevant page still active on site.
- Any ones which go through multiple steps before resolving to a page will need the redirect updated to just point to the secure version of the destination page.
Finally, any which are working will be handled by the global HTTP to HTTPS redirect so do not require additional action.
4. Force HTTPS with redirects
Again, this will vary wildly depending on your setup. CMS’s such as WordPress and Magento will handle this for you automatically within the admin panel. Otherwise, you may need to update your .htaccess or webconfig files with a rule redirect, but this will be well documented.
One common issue we see with rule redirection is separate rules for forcing HTTPS as for forcing www. This will cause chains where first www. is added to the URL then HTTPS is forced in a second step.
Ensure you update any rule redirects to point to HTTPS as the destination to prevent this issue.
5. Enable HSTS
Using redirection alone to force HTTPS can still leave the system vulnerable to downgrade attacks where hackers force the site to load an unsecure version. HTTP Strict Transport Security (HSTS) is a web server directive which forces all requests for resources to be loaded through HTTPS.
You will need a valid SSL certificate, which must be valid for all subdomains. Providing you’ve do this, you’ll then need to add a line of code to your .htaccess or webconfig file.
6. Enable OCSP
Online certificate status protocol improves upon the certificate revocation list (CRL). With the CRL, browsers had to check the CRL for any issues with the server’s SSL certificate, but this meant downloading the entire list and comparing, which is both inefficient from a bandwidth and an accuracy perspective.
The OCSP overcomes these inefficiencies by only querying the certificate in question, as well as allowing a grace period should the certificate have expired.
7. Add HTTP/2
Hypertext transfer protocol is the set of rules used by the web which governs how messages are formatted and submitted between servers and browsers. HTTP/2 allows for significant performance increases due, in part, to the ability to process multiple requests simultaneously.
For example, it is possible to send resources which the client has not requested yet, saving this in the cache which prevents network round trips and reduces latency. It is estimated that HTTP/2 sites’ load times are between 50%-70% improved on HTTP/1.1.
8. Update XML sitemaps, Canonical Tags, HREF LANG, Sitemap references in robots.txt
The above should be fairly explanatory, and probably would have all been covered within point two. However, because this is an SEO blog, I will labor the point.
Making sure XML sitemaps, canonical tags, HREF LANG and sitemap references within the robots.txt are updated to point to HTTPS is very important.
Failure to do so will double the number of requests Googlebot makes to your website, wasting crawl budget on inaccessible pages, taking focus away from areas of your site you want Googlebot to see.
9. Add HTTPS versions to Google Search Console and update disavow file and any URL parameter settings
This is another common error we see. Google Search Console (GSC) is a brilliant free tool which every webmaster should be using, but importantly, it only works on a subdomain level.
This means if you migrate to HTTPS and you don’t set up a new account to reflect this, the information within your GSC account will not reflect your live site.
This can be massively exacerbated should you have previously had a toxic backlink profile which required a disavow file. Guess what? If you don’t set up a HTTPS GSC profile and upload your disavow file to it, the new subdomain will be vulnerable.
Similarly, if you have a significant amount of parameters on your site which Googlebot struggles to crawl, unless you set up parameter settings in your new GSC account, this site will be susceptible to crawl inefficiencies and indexation bloat.
Make sure you set up your GSC account and update all the information accordingly.
10. Change default URL in GA & Update social accounts, paid media, email, etc.
Finally, you’ll need to go through and update any references to your website on any apps, social media and email providers to ensure users are not unnecessarily redirected.
It does go without saying that any migration should be done within a test environment first, allowing any potential bugs to be resolved in a non user-facing environment.
At Zazzle Media, we have found that websites with the most success in migrating to HTTPS are the ones who follow a methodological approach to ensure all risks have been tested and resolved prior to full rollout of changes.
Make sure you follow the steps in this guide systematically, and don’t cut corners; you’ll reap the rewards in the form of a more secure website, better user trust, and an improved ranking signal to boot.
from Search Engine Watch http://ift.tt/2CJ4F0F
No comments:
Post a Comment