Before we begin, I want to say two things.
- Yes, sometimes upon switching to HTTPS/SSL security on your website, you will experience a drop in rankings.
- Yes, you absolutely, 100% should implement SSL on at least part of your site.
I understand that a ranking drop can be bad. I also understand that not all sites absolutely need SSL for their site. However, if you have absolutely any reason for a user to input any personal information, including just an email opt-in form, you absolutely should be using SSL.
The Benefits of SSL
SSL has a lot of benefits for a website. For one thing, Google has been considering SSL to be a ranking factor since 2014. It’s been a minor factor – a site with good content will outrank a similar site with poor content and SSL – but it’s a very real boost if you have it implemented.
SSL also encrypts information sent to and from your website. It can only be read and understood by the people accessing your site directly. No one can initiate a man-in-the-middle attack. That old “don’t use the internet from Starbucks, anyone can snoop your traffic” concern is alleviated; if they were to intercept your traffic, all they would get is nonsense encrypted data. This also applies to using any sort of traffic redirect, like a proxy server or VPN that doesn’t use security of its own. Public VPNs that use HTTP rather than SOCKS protocols often read and sell your information for profit, or inject ads into your experience, so they can make money. Encrypted traffic alleviates that issue.
Of course, that’s more of a concern from the consumer point of view. However, as a website owner, you make your site more secure by using HTTPS. People are gradually learning that the green lock icon in their browser means a site is secure. A phishing site, a scam site, a hacked site; these won’t have SSL icons available to them. They will feel more comfortable giving you personal information. They will feel that their personal information is more secure. They will feel more willing to purchase products from you rather than through a storefront they trust, like Amazon or Google’s shopping center.
SSL only protects personal information in transit, of course. It does not prevent your site from being compromised in other ways. If someone gains access to your databases, the information could still be stolen, so you need to take other steps for a truly secure setup. However, SSL is a big part of that.
SSL is also required – absolutely required – if you want your site to be able to accept payments via a credit card. This is why a lot of ultra-cheap websites or low quality businesses only accept payment methods like Bitcoin or PayPal, that use external verification; they don’t need to pay for a security certificate. If you want to accept credit card payments directly, your site needs to be reviewed and certified by the Payment Card Industry regulators, an din order to do that, at the very least your payment page needs to be encrypted with at least 138-bit SSL encryption.
SSL also offers a few other benefits to your site. For one thing, you are able to use security seals offered by the companies that certify sites. These are small elements of social proof and confidence your users might look for when they’re considering whether or not to trust you. Also, SSL and various other forms of web security are increasingly important in this era of hackings and breaches. The more you have in place, the more future-proof your business becomes.
SSL is not without its downsides. The primary downsides are the usually temporary drop in search rankings, and the cost of obtaining an SSL certificate. SSL certificates can range from $56 per year all the way up to $2,000 per year, depending on what company issues it, what level of encryption it provides, how flexible it is, and how large a warranty it comes with. It also requires a certain level of upkeep, makes some information harder to access in analytics, and can be difficult to configure if you have no idea what you’re doing.
Now, given the question posed in the title, you might wonder why I’m going over all of this information first. Mostly, I’m just trying to convince you that, no matter how much your rankings dropped when you implemented SSL, it’s 100% worth keeping around. Don’t abandon security because it dropped your traffic volume for a few weeks; it will come back to bite you.
Why Did My Rankings Drop?
There are quite a few reasons why your Google search ranking might have dropped when you implemented SSL.
1: Your implementation just took effect. Google determines everything about a page based on the URL. The URL is the unique identifier; all other factors are associated with the URL. If you change the URL – be it a change in domain, a change in subfolder, or what have you – Google looks at it like it’s a new page.
What this means is that when you switch to SSL, the URL changes from HTTP to HTTPS. While it’s a minor change, it IS technically a different URL, so Google defaults to thinking it’s a different page. Almost every element of implementing SSL is concerned with telling Google that, yes, the HTTP and HTTPS versions of the page are the same. That’s why you redirect, that’s why you canonicalize, and that’s why you have to wait.
Generally, Google will get the idea sooner or later, and they will restore most or all of your rankings and traffic once they realize. The problem is that “sooner or later” aspect. Most reports say that it takes anywhere from two weeks to two months, with an average of one month before most rankings and traffic are restored. So, if you implemented SSL and haven’t waited at least a month, it’s natural for your ranking to be a little low.
For this reason, if you’re looking to implement SSL – and you should – I recommend waiting until one of your slower months to do so. That, or increasing ad spend to make up for the lost organic traffic.
3: You didn’t configure or install the certificate properly. Installing an SSL certificate can be a bit of a tricky process. In fact, that process will vary quite a bit depending on what architecture your web server is using, and what version of that architecture is applied. DigiCert, one of the main providers of certificates, has a pretty decent knowledge base to cover a lot of ground, but there are always edge cases for configurations that might be more unique.
If you have not properly configured your SSL, you will get errors on your site that users can see. Google will see that your site is not configured properly and won’t give you the benefit of the SSL security. More importantly, web browsers will show your users a page that looks like this:
The average user won’t know what to do and will assume your site is broken, though if they played with advanced configurations they could still get in.
4: You didn’t properly implement redirects to your secure URLs. When you implement site-wide SSL, you need to set up URL redirects from the HTTP to the HTTPS URL, so that Google knows to pass some value along rather than none at all while they figure out that the pages are the same.
You don’t technically need to do this. Google will, eventually, figure it out and restore your ranking. However, if you don’t implement the redirect, your new pages will have zero value and your old pages will be hidden away. A 301 redirect will preserve some SEO value, though not all of it. It’s a stopgap measure to preserve some value when you otherwise wouldn’t be able to.
You also need to make sure your redirects actually work. I recommend using a tool like Screaming Frog to crawl your site, implementing your redirects on a per-page rather than site-wide basis, then crawling it again to make sure there aren’t any broken redirects.
5: You’re using a CDN and it doesn’t play nice with your certificate. When you use a CDN for your site, which is generally a good idea, you gain some SEO value based on page speed and reliability, as well as some DDoS protection. However, when implementing SSL, you need to make sure your certificate is added to your CDN.
This means your CDN has to support your certificate type and provider, and needs to support SSL in the first place. Virtually every CDN will work with you to implement security, but some will require special instructions. Otherwise, you’re going to encounter issue #3 on this list.
6: Your internal links still point at HTTP versions of pages. It’s a pretty simple matter to just find-replace all links on your site with the secure version of your domain. You will probably need to use a crawling tool, again like Screaming Frog, to pull all of the internal links in case you have missed any.
Why does this lead to a loss of ranking? It’s a usability feature, mostly. If a user or Google follows an internal link and has to process a redirect every time, it slows down the page loads and it’s an unnecessary step. By fixing all of your links, you alleviate that issue. If you’re using WordPress, there are plugins that can help.
7: You have canonical tags pointing at HTTP versions of pages. Canonicalization is important when you switch a site from insecure to secure configuration. The primary reason is that having two URLs with the same content looks like duplicate content in the eyes of Google. Canonicalization prevents this from happening, though you have to make sure to point to the right version of the page as the “real” version. If you don’t have canonicalization, it’s a simple matter to add it. If you had canonicalization before, you will need to make sure to change it properly.
8: Some pages ended up blocked when you made changes. This is pretty rare, but sometimes when you change part of a site configuration, some pages are not properly indexed or are even somehow blocked from indexing. This often happens if you’re using some kind of URL whitelisting with your robots.txt or if you have non-standard forms of your URL blocked. Generally this means you should be simplifying your robots.txt more than anything, but it’s worth checking.
9: Your site map still points at the insecure versions of pages. When you change an element of configuration on your site, you should make sure the right versions of your pages are listed in your site map and you should resubmit it to Google. This will do three things: first, it makes sure that Google is aware that you have made a major change to your site. Second, it makes sure that Google indexes all of your pages with their new URLs. Third, it makes you check your sitemap, which some people forget to do.
10: You didn’t enable HSTS. HSTS is the HTTP Strict Transport Security setting. When you enable it, you submit your site to a list maintained by Google, of servers that force SSL for their content. This speeds up site loading for SSL security.
Normally, when your site uses SSL, the browser needs to check if it does or not when a user loads the page. This is an extra call-and-response to a server, where the server confirms that it does use SSL. With HSTS enabled, the server sends this information along with the initial load information, eliminating that question and answer.
HSTS is also one of the recommended, but optional, additions to SSL in the Google list of best practices.
11: You’re checking results for HTTP rather than HTTPS URLs. It’s entirely possible that you’re just looking at the wrong results when you’re scraping for search engine data. If you’re searching for the wrong URL, you’ll see little or no traffic, even with traffic reaching your site normally through the right URL.
12: Some of the “traffic” you lost was in bad bots that now can’t exploit your site. Security has the added benefit of preventing a lot of the easiest web exploits. There are a lot of bots that crawl the web looking for potential targets. When you implement SSL, these bots will blacklist you because they can’t exploit your site anymore, so that traffic drops. This, of course, only applies to traffic, not rankings, and only if you don’t have most bot traffic filtered from your reports.
13: You’re using the weakest possible SSL certificate. Just having SSL is not enough; you have to use good SSL. SHA-1 is one such common-but-broken certificate that a lot of people still try to use. It’s technically better than nothing, in the sense that having a front door on your house is better than not having one, but it’s functionally not even a lock anymore. You can read about it here.
Hopefully, one of these is your solution, and you can fix it and get your rankings back as soon as Google notices the fix. If not, well, you might have some more elaborate coding or indexation issues going on, and there’s no way I can help you without directly investigating your site. Good luck!