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.
As we wrote in an earlier article, the HTTPS conversion strategy for our stories had several phases:
- Enforce HTTPS for newly published articles
- Find and update any HTTP embeds in our article archive
- Migrate our full archive to being HTTPS only
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.
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.