If you plan to deploy always-ssl to your site soon, you’ll need to ensure it’s executed properly, as minor security and SEO boosts, essentially – can be very minimal compared to the potential loss in revenue if it isn’t implemented correctly.
As one of Google’s objectives is to move towards a more secure web, more and more webmasters are finding themselves migrating their site to https to receive the slight ranking boost that always-SSL offers. As awesome as it sounds and I’m all-in for making the web a more safer, secure place .. a lot of webmasters seem to be having problems implementing site-wide https – therefore they kill their Google presence and organic revenue for a short time due to the incorrect implementation. It’s horrible to see.
Implementing https isn’t an easy job, it involves some technical aspects and you’ll need an understanding of your site’s structure, hierarchy, security certificates, functionality and more – it’s not a 2-minute job, unfortunately. As stated in Google’s article re https, in January 2017 (1st phase) they plan to mark all non-https pages that contain password or credit card fields with ‘not secure’ text, as well as showing the ‘view site information’ icon that normally represents that the page you’re viewing isn’t secure. I’ve included an image below for you.
However, Google plan to /eventually/ mark all non-https pages as ‘not secure’ in big red writing, even if it’s an about page, forum post, blog post or anything for that matter if it isn’t https it will be marked as nonsecure. I’d suggest keeping an eye on the Google webmaster blog for further updates regarding this. So taking into consideration that Google is willing to give a slight ranking boost if https is detected in the URL, and now this, it’s quite clear Google are starting to favor secure sites. If I were you I’d get on board the always-SSL bandwagon soon, as having that big red nonsecure text on your site may start to scare away customers.
HTTPS Checklist To Preserve SEO Efforts
Therefore, taking into consideration the above I assume the rate of which https is implemented will be on the increase throughout 2017, so I have decided to give my thoughts across on the subject, as I have been involved in a wide range of https deployments recently. (I’m still yet to implement https to SEMtuts, I know). Below are quick reminders of what needs to be done before implementing https to preserve all of your SEO efforts. Please be aware that this isn’t the entire list, but these are the points that most webmasters tend to forget about when migrating.
- Update all external site plugins to ensure they are HTTPS compliant (everything .. social widgets, commenting, embeds etc);
- Ensure all of your ad code is updated to support HTTPS;
- All absolute URL’s need to be changed to use relative protocol when switching (footer links, header .. blog & more);
- Update your analytics systems to ensure they are tracking new HTTPs urls instead of HTTP;
- Preserve your social sharing counts (You’ll need to use code that counts non-https and https URLs);
- Create new https webmaster properties (re-upload disavow file & sitemaps);
- 301 redirects need to be in place on every page to redirect user to corresponding https version;
- Canonical tags throughout the site need to be updated to correctly reflect https;
- Hreflang tags need to also be updated to use HTTPs when appropriate (even self-reference tags);
- Sitemap entries need to be updated to use HTTPs protocol;
- Update your internal site search functionality to support HTTPs;
- Robots links to also be updated to https (or relative), this includes sitemap;
- Update old site redirects to correctly reflect https, to reduce the number of jumps.
Please be advised that the ‘slight ranking boost‘ that Google has announced is very minor, it isn’t worthwhile going through the trouble of implementing https for the ranking boost, remember: the user first. Once https has been implemented, remember to fix all of the mixed content errors on your site, otherwise implementing it will be rendered useless as your pages will still render as non-secure (due to both HTTP and https sources on your page). You can use the screaming frog to identify and fix mixed content errors once deployed – it’s important to do this, I’m seeing too many https sites that are rendering in Chrome as non-secure due to mixed content errors. It’s not good, you need the nice-looking green padlock on all your pages.