Looks like 2018 won’t be either a boring or an easy year for publishers, seeking for compliance with the latest quality standards, set by Google.

While some website owners are rushing to prepare for Chrome ad blocker launch, expected on February 15, 2018, others are struggling to evaluate risks from the “Not Secure” browser warnings on their yet-to-be-switched-to-HTTPS webpages and accumulate resources for the pain-free migration.

The Story Behind

Back in 2017 Google announced the display of “Not Secure” warnings on HTTP websites in the Incognito mode in seav.62 or further, starting from October 2017.

Now that almost three months have passed, it’s become clear that postponing website migration further may have a gradually worse effect on its search ranking and even lead to a SEO ranking drop, so it’s time to “get things done”.

Even though the migration is, obviously, a time- and effort-consuming task, it’s possible to make it a bit less daunting.

Check out our guide for publishers on how to migrate website to HTTPS smoothly!
Stage 0. Cover the Basics

The Hypertext Transfer Protocol Secure (HTTPS) is an internet communication protocol aimed at protecting data confidentiality and integrity between one’s computer/device and a website.

Using HTTPS the data is being sent via the Transport Layer Security protocol (TLS), which ensures data encryption, integrity and authentication.

HTTP vs HTTPS

From a user’s perspective, the use of HTTPS ensures website surfing experience secure and private.

From a publisher’s perspective, the implementation of HTTPS enables substantially reducing the risk
of website/server/network attacks and hacks.

Stage 1. Obtain a website SSL certificate

To obtain a website SSL certificate:

1. Use OpenSSL command-line software to:

  • Generate a pair of 2048-bit RSA keys for your website (a public, i.e. encryption key and a private, i.e. decryption key).
  • Create a certificate signing request (CSR) that bundles the public key with website ownership metadata.

2. Submit the CSR to a reliable Certificate Authority (CA) that offers technical support.
3. Install the obtained website certificate on your web-server.

Stage 2. Enable HTTPS on server

Use available configuration tools, e.g. by Mozilla to set up your server support of HTTPS protocol.

Tip! Ensure avoiding the following pitfalls:

  • Expired certificate (consider checking its validity using SSL monitoring tools)
  • Incorrect website name in the registered certificate
  • Old protocol versions
  • Missing SNI support
Stage 3. Update intrasite links

Review and update all intrasite links to HTTPS or make them protocol-relative (i.e. with no HTTP/HTTPS specification): e.g. //yourwebsite.com/jquery.js

Namely, ensure updating:

  • references to content
  • scripts
  • images
  • links
  • canonical tags
  • hreflang, OG tags, if any.

In addition, update all plugins/modules/add-ons and make sure all external scripts that are being called support HTTPS.

Stage 4. Set up 301 redirects

1. Force server-side 301 (“permanent”) redirects to HTTPS pages.
2. Check and renew old redirects, if needed.

Tip! Since a 301 redirect remains “permanent” ONLY as long as the redirect does exist, arrange the ongoing log monitoring/renewal of redirects to prevent traffic loss.

Stage 5. Set up HSTS support

The HTTP Strict Transport Security (HSTS) mechanism forces the browser to automatically request HTTPS pages, before making a server call, even if a user enters the http address.

If the secure connection can’t be ensured, user access to website is blocked.

NB! Double-check the TLS deployment prior to enabling HSTS support!

Consider the following implementation flow:

1. Roll out a HTTPS website page without a HSTS header.
2. Set up a short max-age (in seconds) for its HSTS header.
3. Monitor organic/paid traffic fluctuations.
4. If you’re tracking minor/no traffic loss, begin raising the max-age slowly.

Addressing Major Migration Concerns

Search ranking concerns

If your website pages are available in both HTTP and HTTPS versions, make sure to do the following:

  • Add a separate HTTPS website property in Google Search Console.
  • Use two separate sitemaps: one for only listing HTTP links and the other – for HTTPS links, accordingly.
  • Create two separate robots.txt, pointing to one of the two (HTTP/HTTPS) sitemaps.

Tip! If you’re migrating in pieces, list updated links in only one sitemap or create a separate sitemap file – for the updated website section.

  • Disable the display of duplicate HTTP/HTTPS webpage versions.
  • Ensure the content on HTTP/HTTPS webpage versions is the same.
Website performance concerns

As the experts promise, the TLS performance concerns are relatively small, on a fast web host, if the content and application layers are well-tuned.

Tip! See the Performance Checklist, offered by I. Grigorik in his “High Performance Browser Networking” for more details, and also use synthetic monitoring tools,  if needed.

Ad revenue concerns

Due to the mixed security issues, the latest web-browser versions treat HTTP URLs in iFrame and Javascript tags on HTTPS webpages as blockable mixed content.

Basically, this means ONLY HTTPS links in video ad tags, for instance, will work on HTTPS webpages.

To prevent your video ad revenue loss, it’s vital to ensure all website ad tags include HTTPS links, especially if you’re working with multiple video ad providers: ad networks, video supply side platforms, direct advertisers, etc., before migrating your website to HTTPS.

Tip! If you monetize with AdPlayer.Pro demand partners, you may request filtering advertisers’ tags that use HTTP links – please contact your dedicated account manager with this inquiry.

If your video ad provider can’t verify the use of only HTTPS URLs in the video ad tags, consider detering from using relative intrasite links or even postponing the migration to HTTPS for a little while.