SitePoint users who pay attention to what’s in their browser’s URL bar will have spotted something over the last day or so: we’re now coming to you via HTTPS. Check out the fancy lock next to the URL! It’s a change we’ve been wanting to make for a long time, and earlier this week we finally flipped the switch! (It was much more complicated than flipping a switch.)
We’re not alone, recently BuzzFeed and The Washington Post made the change for their sites.
What the SSL?
For a rundown of exactly what HTTPS is, check out this handy SitePoint article (fancy that). The short version is that it adds an SSL/TLS encryption layer to make browsing safer and more private.
We’ve always encouraged our readers to follow best practices for everything they develop. When it comes to serving web pages to broswers, the accepted best practice is to serve secure pages. We’ve had SSL on our Premium site for as long as the site has existed, so transactions have been conducted over HTTPS, but it was time to expand that to all of SitePoint.
But HTTPS has been around for a while, what took us so long to implement it on SitePoint.com? Well, like most other publishers on the web, a big part of our business relies on advertising, and ad support for SSL has been patchy at best. Our advertising team has been working on transitioning over to only networks that support SSL for several months, and now was the right time to make the move.
Pulling Rank
The move means your browsing will be safer and more private, but we’re a little less clear on what it means for SitePoint.
We know that HTTPS is a ranking factor for Google’s search algorithm: for any two pages that are otherwise graded equally by Google’s algorithm, the secure page will be displayed higher up the search results page than the insecure one. Search provides the vast majority of our traffic, so while we hope the move has a positive impact on the number of readers to SitePoint, we don’t know what to expect.
The Process
According to senior dev Jude Aakjaer, the main technical challenges were third-party scripts including insecure assets. We had to go through and disable several ad networks that weren’t compliant with serving assets over SSL. (We’re still sorting this out.)
Jude said we actually already had SSL available on the website, but we were redirecting back to non-SSL due to the need to serve ads, so enabling it was fairly trivial and just reversing our redirects. We planned for the move by bringing up a staging environment that was served over SSL and using that to track down errors.
“We also made sure we could move back to our old setup by spinning up a fresh set of servers that we could fall back to if things started failing. Nothing has gone wrong so far.”
When I asked him for advice for other sites considering making the move, he was pretty blunt/awesome, so I’ll let him have the last word:
Do it. Ad networks need to get with the times and serve ads over SSL. Its irresponsible to be providing services to consumers and not be doing that over a secure channel. It will only be with groundswell support of publishers moving to HTTPS that ad networks will start doing things properly. We’ve made the decision to only work with ad networks that can offer HTTPS.
Adam RobertsAdam is SitePoint's head of newsletters, who mainly writes Versioning, a daily newsletter covering everything new and interesting in the world of web development. He has a beard and will talk to you about beer and Star Wars, if you let him.
