Moving your website to HTTPS / SSL: tips & tricks

In 2014, we decided to switch over to the (now) commonly-used HTTPS to encrypt sensitive data that’s being sent across our website. This post describes some useful tips based on our own experiences that might come in handy if you’re considering switching. 

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

A little backstory

Back in 2014 HTTPS became a hot-topic after the Heartbleed bug became public. This bug allowed people with ill intent to listen in on traffic being transferred over SSL/TLS. It also gave them the ability to hijack and/or read the data. Luckily, this bug got patched quickly after its discovery. This incident was a wake-up call that properly encrypting user information over the internet is a necessity and shouldn’t be an optional thing.

To emphasize the importance of encrypting sensitive data, Google Chrome (since January, 2017) displays a clear warning next to the address bar whenever you visit a website that doesn’t encrypt – potential – sensitive data, such as forms.

How do I switch?

Because it’s important that your data is safe, we took steps in 2014 to ensure that we have SSL-certificates across our own websites. If you decide to switch (you really should!), there are a few things that you need to take into account to ensure your website fully works as intended once you’re done.

  • You need to change all your internal links. This also means updating links to assets (where necessary). Make sure to go through your theme and alter references to CSS, images and JavaScript files. Additionally, you can change all your links to start with // instead of https:// which will result in protocol-relative URLs.
  • Ensure your CDN supports SSL as well. We make use of MaxCDN, which allows you to easily set up SSL on your CDN subdomain.
  • There are various levels of SSL that you can choose from, each with their own pros and cons. You will find more information about that later on.
  • Ensure you have a canonical link present in the <head> section of your website to properly redirect all traffic coming in from http:// to https://.

Google also published a handy guide on how to move to HTTPS without massively impacting your ranking, which can be found here.

How does this influence my rankings?

Like stated in the previous section, moving from HTTP to HTTPS can influence your rankings slightly if you don’t plan accordingly. However, after you switch over to HTTPS, your rankings will actually improve over time. Google announced in 2014 that having an SSL certificate will be considered a positive ranking factor, so it’s worth the investment.

To make sure Googlebot can re-index your website more rapidly after the move, make sure you migrate to https:// during low-traffic hours. This way Googlebot can use more of your server’s resources. Just take into account that a medium-sized website might take a while to regain rankings. Have a sitemap? Then Googlebot might be able to recalculate and re-index your website even faster.

Setting up HTTPS & SSL on your server

Generally speaking, hosting providers have a service to allow you to enable HTTPS/order a certificate. There are a few types of certificates you can choose from, which differ in a few ways. Every variant also has their own price tag, so before purchasing one, make sure that you go with a certificate that fits your needs and budget!

If you’re a bit strapped for cash and tech-savvy, go take a look at Let’s Encrypt to acquire a free(!) certificate.

If you run and manage your own web server, there are a few things that you’ll have to enable in your server configuration before being able to use SSL certificates. This tutorial explains what steps to take to get a certificate running on your server.

OCSP stapling

Having to check the validity of an SSL certificate can result in a small hit in loading speed. To overcome this, you can make use of OCSP stapling. OCSP stapling is a feature that enables the server to download a copy of the certificate vendor’s response when checking the SSL certificate. This means that once a browser connects to the server, it checks the validity of the certificate based on the copy on the server instead of having to query the certificate vendor itself, resulting in a significant performance improvement.


Before enabling OCSP stapling on your Apache server, please check that you’re running version 2.3.3+ of Apache by running the command apache2 -v (or httpd -v) on your server. Lower versions of Apache do not support this feature.

If you went through the process of setting up HTTPS on your server as described in the ‘Setting up HTTPS & SSL on your server’ section, then you should have come into contact with a VirtualHost configuration specifically made for usage with HTTPS/SSL.

In that file, take the following steps:

  1. Inside the <VirtualHost></VirtualHost> section, you should add SSLUseStapling on.
  2. Just above the <VirtualHost></VirtualHost> section, add SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
  3. Check that the configuration is still valid by running apachectl -t. If so, reload Apache by running service apache2 reload.


Nginx also supports OCSP stapling. Before editing the server configuration, please check that you’re running version 1.3.7+ of Nginx by running the command nginx -v on your server. Lower versions of Nginx do not support this feature.

If you went through the process of setting up HTTPS on your server as described in the ‘Setting up HTTPS & SSL on your server’ section, then you should have come into contact with an Nginx configuration specifically made for usage with HTTPS/SSL.

In that file, add the following lines in the server {} section:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;

The last line references a file that contains a list of trusted CA certificates. This file is used to verify client certificates when using OCSP.

After adding these lines to the file, check that the configuration is still valid by running service nginx configtest. If so, reload Nginx by running service nginx reload

Become a technical SEO expert with our Technical SEO 1 training! »

Technical SEO 1 training$ 199 - Buy now » Info

Strict Transport Security header

The Strict Transport Security Header (HSTS) is another handy feature that basically enforces browsers to use the HTTPS request instead of the HTTP equivalent. Enabling this feature is relatively painless.


If you’re running Apache, first enable the Apache Headers module by running a2enmod headers. After this, it’s only a matter of adding the following line to your VirtualHost configuration (in the <VirtualHost></VirtualHost> section) that you set up earlier for HTTPS:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Reload the Apache service and you’re good to go!


Nginx requires you to add the following line in the server{} section of your server configuration file:

add_header Strict-Transport-Security max-age=31536000;


To see if your SSL certificate is working properly, head over to SSL Labs, fill in your domain name and see what kind of score you get.

Redirecting URLs

To ensure requests are properly redirected to the HTTPS URL, you need to add an extra line to you configuration. This way, traffic that tries to visit your website over HTTP, will automatically be redirected to HTTPS.


In your default VirtualHost configuration (so the one that’s used for HTTP requests), add the following to ensure URLs get properly redirected:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

As with the other changes we made before, don’t forget to reload Apache!


In Nginx, change the default configuration file that was used for HTTP requests and alter it as such:

server {
    listen 80;
    return 301$request_uri;

Don’t forget to reload Nginx before testing these changes.


“Should I switch over to HTTPS?” Short answer: Yes. Using HTTPS ensures that private (user) information is being sent across the web in a more secure manner. Especially if you’re dealing with monetary transactions, HTTPS is a must.

What type of certificate you end up going with, depends on your specific use case and budget. Make sure to properly research your options beforehand.

Read more: ‘WordPress security in a few easy steps’ »

Weekly SEO recap: Let’s disambiguate!

This week we had a few interesting things happening, from a potential update to some new features and an important change in Google Suggest. Let’s dive in!

Joost's weekly SEO Recap

Google adds disambiguation to Suggest

In a very interesting move this week, Google added disambiguation results to their suggest box, basically forcing you to choose for a specific topic when you’re searching. A search for [mercury] for instance shows this:

Google disambiguation results for Mercury

The 3 disambiguation results are marked with a long dash. Clicking on either 3 shows a knowledge graph panel on the right hand side, and, interestingly, none of the 3 results has Wikipedia as the number 1 result.

The disambiguation page for Mercury on Wikipedia has different options, so Google is at least not using that as its only source. A search for [ocampo] has 3 options, all of which do have a Wikipedia result as #1:

Disambiguation result for Ocampo

One more example, a search for [yahudi], delivers this:

yahudi disambiguation result

Whether you’re looking for the Jewish people or a film… Quite the difference of course in results. This makes it easier for Google to determine what it is you’re searching for, but it also makes it clear that you should optimize enough for Google to understand not just your keyword, but to understand your topic, which SearchEngineLand had a nice post about as well. This has profound implications for how you write articles, and for how you do keyword research.

Google to prefer HTTPS versions of URLs

Google has been giving a slight ranking boost to HTTPS URLs for a while now, at least, so they tell us. But now they’re going even further. When there is a working HTTPS version of your site, regardless of whether you link to it or not, Google will prefer the HTTPS URLs.

Google search update on the 16th?

Barry reported an update on the 16th, that sounded more to me like something had gone wrong somewhere. This sort of stuff happens all the time, and it seems in the comments that people were bouncing back after a few days. To me it’s always interesting to see when stuff goes wrong so badly.

Why having multiple XML Sitemaps can be useful

In an article on the SEM Post, they’re discussing whether you should have multiple or one single XML sitemap and what’d be the benefit of both. The most important thing John Mueller from Google says, in my opinion, is this:

I like to split up the sitemap file because in the Search Console you can look at the index stats by sitemap file and that sometimes makes it a little bit easier to understand what types of pages are currently being indexed and what pages aren’t being indexed.

That’s the exact reason why our Yoast SEO plugin has an XML Sitemap feature that creates a single index with XML sitemaps per post type. This makes it a lot more interesting to look at the XML sitemaps section of Google Search Console.

That’s it, see you next week!

joost signature

PS If you find disambiguation a nasty word, you’re not alone. I must have mistyped that about a dozen times while writing this post :)

Weekly SEO Recap: AMPing up to SSL all the Penguins

This was very much the “week after” for us. Yoast SEO 3.0.4 saw the light, but other than that most of us are still recovering. It was also a week full with tiny little nuggets of newsy niceness. From SSL on WikiPedia to AMP to Penguin. Let’s dive in!

Joost's weekly SEO recap

SSL all the things

This is a pet topic of mine and will be for a few more years to come. We all care about privacy, but not everyone realises that saying that means you also have to make some choices. In particular, we should all make the choice to use HTTPS for all our sites. I wrote about that in January 2014 and my thinking didn’t really change.

This week Jimmy Wales of Wikipedia gave an interview (via The SEM Post). Some of the key quotes highlight why HTTPS is so important. With HTTPS, you can’t block specific pages on a site, only the entire site. Jimmy Wales tells the story of Wikipedia in China:

Around the time of the Beijing Olympics Wikipedia was opened up, the Chinese had a period of liberalisation of the internet, and they opened up and they allowed access to almost all of Wikipedia. But they were filtering certain pages, they were filtering about the usual suspects: things that are sensitive issues in China. So the Tiananmen Square incident; the artist Ai Weiwei; there’s a religious cult called Falun Gong; anything to do with Taiwanese independence -these are the kinds of things they were filtering, just those pages.

Now that Wikipedia moved to HTTPS, that makes that impossible for the Chinese government:

With https, the only thing that the Chinese authorities can see today is if you’re talking to Wikipedia or not, they can’t see which pages you’re joining, which means they no longer have the ability to filter on a page-by-page basis, so they can’t block just Tiananmen Square. They now have a very stark choice: the entire country of China can do without Wikipedia, or they can accept all of Wikipedia.

Unfortunately, that means that right now, all of Wikipedia is blocked in China. But it also means that they can’t profile people based on which pages they’ve visited anymore. I hope that this situation improves in China, but I also hope you understand just one more very solid reason to move to an all HTTPS web.

Google AMPing up on AMP

Gary Ilyes of Google has been talking about AMP (Accelerated Mobile Pages) a lot, and in a blog post, Google gave us something to chew on:

Google will begin sending traffic to your AMP pages in Google Search early next year, and we plan to share more concrete specifics on timing very soon.

What that means? Good question. I don’t know any more than you do at this point. I still don’t like AMP much, so I hope it won’t mean they’ll force us all into it.

In other mobile search news, Google has told us that you really shouldn’t use spammy (mobile) networks. What a surprise.

Google Penguin is coming

Google Penguin always seems to be “coming”. It’s almost like winter. But now we know that the next Google Penguin update will be a true update, not just a data refresh, and it’ll be real time. And it’s coming. Really. Apparently still in 2015 too, according to Google’s Gary Ilyes. But he’s been wrong before.

That’s it, see you next week!

joost signature



Weekly SEO Recap: Google directions

A couple of interesting small tidbits this week, that all together show the direction (Google) search is heading in. Let’s dive into this weeks news:

Joost's weekly SEO recap

Google bolding answers to questions

Remember the Hummingbird update? Google worked on being able to parse questions better so it knew what you were searching for. This week, some people noticed Google was bolding the answer to their implied “question” in their query. For instance, when searching for “engineer salary”, Google was bolding the answer. I think this is just another sign of Google showing answers, not blue links.

Fetch & render gives a sense of urgency

Google’s fetch & render tool in its webmaster tools suite added a feature last year to also render out the page you’re fetching. Michiel described that in this post in our webmaster tools series. This week it added an urgency to the blocked resources, telling you whether you should go out and fix it immediately or you can put it on the “someday / maybe” list.

It mostly seems to be telling you that the urgency of blocked ads is low. I’m not sure (because I haven’t tested enough) whether this is always the same urgency for the same resource or whether it actually looks on where it is on the page. If it’s always the same it could actually give a false sense of security, as having 3 or more ads on a page above the fold could still get you in trouble…

More HTTPS warnings from Google

Google has been sending out a new type of https warnings, notifying you when the certificate you use on a given domain, doesn’t actually include the domain name. That’s like so much of a “d0h!” moment that I had to read twice whether that was really what they said.

Turns out that right now, according to Google, you get an https ranking boost in the search results when the URL is HTTPS, even when the certificate for that URL is invalid. HTTPS is notoriously hard to get right, but the fact that Google is sending out these messages tells you that they’re wanting to improve something there.

Google News allowing app promotion

If your site is listed in Google News and has an editors picks feed, you can now promote your mobile app to users. If you’re not in Google News, our News SEO plugin might be able to help you get everything you need to get listed. It can also create an editors picks feed for you!

That’s it, see you next week!

joost signature

Weekly SEO Recap: antitrust ranking factors

Joost's weekly SEO recapI write this knowing that next week I’ll be in Munich with many friends of the SEO industry for SEOktoberfest, a conference unlike any other. We’ll talk shop with some of the best and brightest minds in our industry and to say I’m excited is an extreme understatement.

Google loses antitrust case in Russia

These headlines are coming more and more. This week, Google lost an antitrust case in Russia. This follows on similar cases in India, Europe and many countries throughout the world. It’s not all that surprising, given Google’s power, that governments everywhere are becoming nervous. We’ll see what all these cases together end up doing to how Google organizes itself and how it behaves. Google’s recent change to its corporate structure, creating Alphabet Inc, should probably be seen in light of these issues too.

In other legal news, Google was the suing party in a case against another firm impersonating Google in their robo-calls.

Structured markup and HTTPS as a ranking factor

We wrote about this not too long ago, saying structured markup is not a ranking factor. Obviously, Google reserves the right to start using it for ranking. I would say that too, if I were Google, and I wanted to get more people to add that kind of markup to their pages. We’ll believe it when we see the first research that confirms that they’re using it for ranking. This piece of user-research did show that having snippets on position 2 beats being in the first spot. What I did find curious was they incorporated an author image in the research, something that basically doesn’t exist anymore in the normal search results.

In a similar vein, Google said that HTTPS acts as a “tie breaker“. This is what I’d describe as a “weak ranking factor” at that point. Even if it is only a tie breaker, you should probably still do this for a myriad of other reasons: consumer trust, more reliable analytics data, etc. My thoughts on this are essentially the same as in January 2014.

Over-optimization a common issue?

In a recent hang out, Google’s Gary Ilyes once again stressed the important of quality content:

… what I see often is people try to rank for queries they don’t have high quality and great value content for, and that’s the problem. Sooner or later the algorithms will catch that, you don’t have to overthink it, it’s simple content analysis and they will adjust the rank for the site, and that’s it.

Of course, this is much in line with our own thinking on the topic. If you’re in doubt about your content strategy, our book Content SEO is a must-read. In that same hang-out, Gary also discussed the slowness of the Panda roll out, though we’ve seen reports that Google rolled back parts of Panda as well, we discussed those last week.

That’s it, see you next week!

joost signature

This post first appeared as Weekly SEO Recap: antitrust ranking factors on Yoast. Whoopity Doo!

Moving your website to https / SSL: tips & tricks

HTTPS EverywhereIn January I wrote about our plans in moving to SSL. We’ve since done that, with great results from an SEO perspective: we had no negative effect on traffic, whatsoever. Two weeks ago, we also moved our tool Quix to https. There are quite a few things we learned in the process of moving these two sites to SSL that we thought would be worth sharing with all of you. Also, some things happened in the last few weeks that make SSL a hot topic, so we’ll discuss those first.

Ranking benefit for completely SSL sites?

Last month, Search Engine Land reported that Matt Cutts had said about SSL that he’d “personally love to make it part of the ranking algorithm”. The Wall Street Journal picked up on this two days ago. Whether or not this actually happens (or, perhaps, has already happened) doesn’t really make much of a difference to me. A completely SSL site looks more trustworthy than a non-SSL one [reference needed].

From a spam fighting perspective I think I can see why Matt would like it. I don’t think many spam network creators would go through the hassle of setting up SSL for all their sites and buying certificates for all of them. The cost would soon become higher than the profit in many niches.


The recent Heartbleed debacle (if you don’t know what it is, read this and / or this simple explanation) showed us once again how vulnerable the web can be. The good thing about it is that when you think about people being able to “listen” to your web traffic, you suddenly realize it might actually make sense to encrypt a whole lot more of it.

Moving your site to https

In moving completely to https / SSL we figured out there’s a few things you need to be aware of:

  • All of your internal links should start to use https, not just to pages, but for images, JavaScript, CSS, etc. This means going through your theme with a fine comb and cleaning all of those up. Of course you can have your web server redirect http to https (more on that below), but not having to do the redirect is a lot cheaper.
  • Your CDN needs to support SSL too. Of course, we use and love MaxCDN and they can set up SSL for your CDN subdomain very easily.
  • SPDY, a networking protocol primarily developed by Google that you can enable for SSL traffic, is awesome. It makes your website faster and funnily enough that means that your fully SSLed site could actually be faster for those people who visit your site with modern browsers than your plain http site.
  • Not all SSL setups are equally safe. Once you’ve set up your site with SSL, it’s important to then make a conscious decision about how safe you want your traffic to be and act on that, more below.
  • You will need a static and unique IP for your site. This is “logical” if you know how SSL works, but it also means that most shared hosting servers won’t allow you to do this. – As mentioned by David in the comments: if your server supports Server Name Indication you don’t even need a dedicated IP.

https & SSL Web server config

Because is hosted on Synthesis, we didn’t have to do much to allow for SSL with full support for SPDY, as they took care of all the details for that, which is only part of the reason we love them. For we had to do it ourselves, which meant re-compiling our NGINX with SPDY support and a few more bits and bobs. For most people it’s probably a better choice to either go with a smart hosting provider like Synthesis or hire someone to do this for you. If you’re not sure whether your current setup supports SPDY, you can use to check, or simply type spdy in Quix.

We did tweak our setup quite a bit though, as SSL can require more resources on your server and not setting it up properly could lead to load issues and delays. Below are the specific lines from our NGINX config related to the SSL session cache:

ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;

The next thing to tweak are the available ciphers. If you’re implementing this, I’d suggest referring to this article about hardening your web servers SSL ciphers as it explains in detail some of the settings below. That article is kept up to date so it’s better to check that than the code below, but for reference, this is what we currently use on

ssl_prefer_server_ciphers On;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;

Add-on: OCSP Stapling

In the comments there was a question from Jesin about whether we’d implemented OCSP stapling. We hadn’t, simply because I didn’t know what it was. I looked it up and saw several very positive mentions of the topic, for instance this CloudFlare post, so I implemented it straight away.

It means that you sent status info about your certificate along with the request, instead of making the browser check the certificate with the Certificate Authority. This removes a large portion of the SSL overhead, the CloudFlare post above explains it in more detail.

I used this guide, but it’s very easy, just add this to your NGINX config (this uses Google’s DNS for resolving and assumes your certificate file contains the entire certificate chain):

ssl_stapling on;
ssl_stapling_verify on;
resolver valid=300s;
resolver_timeout 10s;

Strict Transport Security header

One of the other cooler things you can do is add a Strict Transport Security header. This will force the browser to load all subsequent requests from the same host over https, even when you’ve linked to http.

In NGINX, you add this like this:

# This forces every request after this one to be over HTTPS
add_header Strict-Transport-Security "max-age=31536000";

For other servers, including Apache, check the WikiPedia page on the Strict Transport Security header, more specifically the implementation section. Note that if you run subdomains, you could also add those, but unfortunately not ALL our subdomains are on SSL yet, so we haven’t been able to do that yet. Luckily, our friends at MaxCDN were nice enough to turn it on for us.

BTW if you’re wondering why I use MaxCDN, their new tools site shows nicely how fast the already blazing fast is in comparison to, which is running at rocket speed, compare the two here. That tool is pretty useful to compare two sites in speed.

SSL test

qualys ssl a+ ratingIf you’ve done the above correctly, you should be able to pass the Qualys SSL test with flying colors, we sure do. If you use Quix, you can run that test on any domain simply by typing the command ssltest. I think you should aim for at least A in this test, though A+ is easily achievable when you add the above Strict Transport Security header.

Redirect from http to https

This last bit will help you tremendously when you’ve not updated every single link in your site yet. You can just add a straight server level redirect from http to https. In NGINX, we do this by having two servers defined in our config, the “right” one, that listens on port 443 and a simple one that listens on port 80 (normal http) and has just this:

server {
listen 80;
return 301$request_uri;

This seems to be the fastest way of doing this in NGINX, in Apache you’d do something like this:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

What type of SSL certificate should you get?

In my opinion, if you’re going to invest serious time in doing this, it’s only worth it when you make sure you get the maximum benefit. With Extended Validation certificates you get the green address bar, which is what you want:

extended validation SSL certificate

If you think that’s expensive, think again. For instance here at Namecheap an EV SSL cert could cost you as little as $139 a year, so go for that but be sure to check their different offers if you have multiple domains. Of course if you’re cheap you could get just a domain validation certificate which would cost you like $9 a year.

So… Should you move your website to https?

If you’re a web shop or otherwise transactional website you probably already have SSL for your checkout. If so, moving your entire website to https makes a LOT of sense to me, it’s probably actually easier to maintain and makes sure that you’re doing everything to make sure your SSL traffic (and thus the most important section of your site) is as fast as possible.

If you’re a purely informational website you might not need to make the move, but if some of that information could be privacy sensitive, I think it’d be a good idea to implement SSL anyway.

Would love to hear your ideas on moving your website to https and SSL in the comments!

This post first appeared on Yoast. Whoopity Doo!