HTTPS migration: don’t get left behind

Nichola Stott outlines the top line preparation and process needed for a smooth migration to HTTPs URLs, plus a few common mistakes to avoid.

Warning shots have been fired and by the end of January 2017, sites that collect any personal user data — via payment or membership, for example — and fail to use the correct level of security protocol can expect a “Not secure” warning label in Chrome.

If your site falls into this group, you can expect your bounce rates to rise and traffic numbers to fall; and this is just the start. 

Benchmark
If you’re about to embark on any structural or sizeable SEO activity, it’s really important to begin by benchmarking your current KPIs. Every well managed project will end with a reflection and evaluation phase, therefore we need a baseline against which to measure.

When it comes to HTTPs migrations, the best we can hope for is performance parity. Even if we’re told that HTTPs is a ranking signal and perhaps there’s a little greater credence given to secure sites, I wouldn’t expect any ranking boost until this contributing factor is dialled up.

To benchmark your pre-migration status, measure the following:

• Indexed URLs
• # Ranking keywords (in a data set such as Searchmetrics or Sistrix)
• Average of rankings per position range (again using one of the same tools)
• Site speed on desktop and mobile device tests (use Pingdom or GTmetrix)
• Separate time to stages in your speed analysis, e.g. DNS, SSL, server connect, browser data send, information receipt (TTFB) and full render

Not all migrations will go smoothly no matter how well you prepare and how thorough you are.

We’ve seen a couple of instances whereby the additional latency caused by the handshake between CDN to webserver to host to webserver impacted speed more than the HTTPs contribution contributed positively; the net effect being a slight decay to some rankings.

Due to benchmarking, this cause was identified and corrected, which meant a quick change to the CDN/host set-up which wasn’t in the resource plan.

Select your certificate
Not all SSL certificates are created equal. While I’m not in the business of security, you may want to consider advice on the level of security required.

If you’re an affiliate and you’re not really collecting payments or taking much in the way of personal data, then your decisions may be led more by user experience and impact to search performance as opposed to level of encryption your SSL affords you.

If you’re an operator, however, you’re likely to need more robust encryption systems so your security needs will be greater. 

Do consider that the level of SSL certificate you choose can have two important considerations outside of security: namely the browser display and how long it takes to get hold of your certificate.
A general secure certificate may appear in the browser as follows:

Whereas if you go up to an “EV” or enhanced validation level of security the display will be further enhanced; this may contribute to user trust.

Do consider though that there are further security stages, and manual checks, required to obtain this level of certification before your certificate can be issued. You need the certificate to be installed on the server before it is possible to migrate so this dictates your development window.

Migrate
When it comes to the real business of migration, the critical component is the redirection plan; particularly with large complex suites of sites.

In such cases it may be best to phase migration to URLs of a particular section, e.g. core site versus blog, country by country or sub-domain by sub-domain if in use. If we condense the considerations to a checklist, you need a plan and timing consideration for each:

1. Migration plan or redirection map if simple/small site
2. Create a new Search Console/Bing Webmaster Tools, Yandex, etc. account for the HTTPs URL
3. Configure your respective webmaster accounts, carrying over any existing settings that may apply, e.g. parameter handling
4. Create new sitemaps to reflect the HTTPs URLs and make sure these are uploaded to the root of your site instead of the existing HTTP versions               
5. Submit your sitemaps through your respective webmaster accounts and consider manual fetches for top nav URLs (to facilitate fast crawl and indexing of new HTTPs URL variants)
6. Audit all of your other owned and operated properties such as sister sites, social media profiles and such to ensure that the URL is changed to refer to the HTTPs version and isn’t going through the HTTP redirect
7. Finally don’t forget to do quality assurance and re-benchmark around two weeks after completion

As a final point to consider in the migration process, if you’re not the business owner you should consider informing those who need to know that there will always be some ranking/SERP flux experienced for at least a couple of days or maybe even weeks depending on the size of your site(s) and how fast your new HTTPs URLs are indexed and old HTTP ones dropped.

Although it often leads to some turbulence in the short term, if you’re collecting personal user data, migrating to HTTPs will soon become essential to maintain your search performance. It acts as future-proofing for your business, as well as giving trust signals to both search engines and users alike.

With the correct process and monitoring, the risk of migrating can be minimised. On the other hand, the risk of remaining non-HTTPs can be far greater.

Nichola Stott is founder of organic search and content marketing agency theMediaFlow.