Crossing the HTTPS Finish Line

This post was originally published on this site


Last year, we started transitioning The Atlantic from serving pages over HTTP to using the secure HTTPS protocol. It’s been a gradual process, but today we’re happy to announce that our articles are served 100% over HTTPS.

Traffic to HTTPS pages on TheAtlantic.com

As we wrote in an earlier article, the HTTPS conversion strategy for our stories had several phases:

  1. Enforce HTTPS for newly published articles
  2. Find and update any HTTP embeds in our article archive
  3. Migrate our full archive to being HTTPS only
Redirect the user to the HTTPS version if necessary

We handled the first phase by first adding a bit of code in Ollie, our custom CMS, that both prevented users from adding HTTPS-incompatible HTML into any new articles and then also flagged all of these new articles as being HTTPS only in our database. On the front end, if a user tried to access one of these new articles via HTTP, they would automatically be redirected to the HTTPS version of our website.

Finding and fixing non-HTTPS compatible embeds

We were able to achieve the second phase by scanning our archive for HTTP content embedded in our old articles and updating if possible. This required automatically checking to see if a HTTPS version of the embed existed online and then updating the HTML accordingly.

The final phase, which involved setting the ‘HTTPS only’ flag on all published articles was the simplest technically, however, it actually took the longest to accomplish. This is because one of the biggest obstacles that any site with a sizable back catalog of HTTP content will run into is figuring out how to make the transition to HTTPS without being penalized by Google. Since Google announced in 2014 that they were going to start rewarding sites for using HTTPS, the idea that switching from HTTP to HTTPS could hurt a site’s SEO might seem counterintuitive. However, Google treats transitioning from HTTP to HTTPS similar to changing domain names, and warns that it “can temporarily affect some of your traffic numbers”.

So, while going all in on HTTPS might give us a slight long term boost in our search rankings, we wanted to proceed carefully to avoid the penalties that other media companies have seen. To that end, after enforcing HTTPS for newly published articles, we waited until we had a good sized buffer of new HTTPS content before we began migrating our archive. Next, our analytics team carved our articles up into ten tranches based on search engine referrals, with a few SEO heavy hitters at the top, and the great mass of articles with little search engine traffic at the bottom. Using that data, we could set articles to be HTTPS only tranche by tranche, slowing working our way up the list. By migrating our data in this way, we spaced out any damage done to our search rankings and avoided the negative network effect that might be incurred by redirecting our entire article archive all at once.

Now that we’re delivering all of our articles over HTTPS, we’ll be able to leverage some additional technologies. First, we can use the faster 2.0 version of the HTTP protocol which most browsers only support when coupled with HTTPS encryption. Second, we can work on implementing HTST headers and preloading which will help ensure that browsers never try to access our website using an insecure protocol. Finally, standardizing on HTTPS allows us to use a JavaScript technology known as service workers which enables features like push notifications, improved offline reading, and improved performance.


Crossing the HTTPS Finish Line was originally published in Building The Atlantic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑