Unfortunately, over the years I have found more SEO risk switching to HTTPS, than the claimed SEO value. In fact, I oftentimes feel that switching to HTTPS provides such a large risk for SEO, that in many cases it’s not warranted or even desired to do such a change. However, now Google is applying more and more pressure on webmasters to implement secure URLs. And admittedly HTTPS is the right choice for protecting your users.
Most of the SEO risk associated with switching to HTTPS is a result of mistakes made during the redirection process. This is true for changing any URL structure, however, special hurdles are often presented when changing at the protocol level. Below are 10 common mistakes I’ve seen over the years of helping clients make this change and fixing their mistakes. You should be mindful of all of the below possible issues. As well as thoroughly test your implementation prior to launch.
Using a 302 redirection
A 302 redirection means a temporary redirection. Where a 301 means a permanent redirection. When redirecting a URL it’s important to use a 301, otherwise Google and other search engines may not follow or apply the same signals to the new URLs. This is a common mistake made by people that do not practice SEO. However it is also extremely easy to make this mistake if you are an experienced SEO. This is because the htaccess directives and other server functions are extremely similar to each other. I myself have made this mistake before after doing SEO for about 8 years. Always double-check your htaccess redirection rules to make sure you’re applying the right redirections.
Not updating legacy redirects
Let’s say that when your site first launched, your URL structure included “www”. However maybe a year later you may have decided to remove the “www”. To do so you may have used a 301 redirect to the non-www state. Now you’ve decided to switch to https and you setup redirects to the HTTPS version. If you fail to update the original redirects away from the”www” version, then you have inadvertently created a redirect chain from the URL structure that the site was originally launched with. This means any inbound links that were acquired within the first year site was launched are likely losing significant link equity because those links have to pass through a second redirect to get to the HTTPS version.
Because of this, legacy redirects generated prior to the HTTPS switch should be updated from the original URL structure directly to the new HTTPS version. Failure to do this may result in significant backlink equity loss.
I once found a client that lost about 80% of its back link profile because of this scenario.
Not updating canonical tags
Canonical tags are vital to communicate to Google the preferred structure and protocol of the page. If HTTPS is not included in the canonical tags, it may send mixed signals to Google’s crawlers as to which URL standard should be applied.
Failure to update internal links
Many SEOs and web developers assume that if redirections are in place they do not need to update internal links that point to the new HTTPS urls. This is problematic because most modern web browsers will detect that there are links on the page to unsecured pages on the same domain and may provide an error when visiting the page. Failure to update internal links also creates sitewide redirections on all URLs that the crawler hits on each page. Despite the fact that Google claims that 301 redirections do not affect link equity, it’s likely that if there are 1000s of links that are not updated at scale will affect not only the loss of link equity but exacerbate and maybe deplete Google’s crawl budget for the domain, because of the extra work of processing the redirects. All internal links should point directly at the HTTPS version of the site.
Not anticipating how your SSL provider deploys
In some instances an SSL certificate provider may implement redirections without consulting their customers. I have seen this happen twice before and it causes major issues if a web developer has already set up their own server side redirects. This typically occurs if you purchase your SSL certificate from your DNS provider. Therefore, you should touch base with your SSL provider to make sure you fully understand how they deploy, and if there are any built-in redirections already in place. Otherwise, you may be at risk of creating a redirection loop or possibly timing out the server. This is critical.
Conflicts with CMS
Some Content Management Systems also deploy automatic redirection after changing the internal URLs. If you do not anticipate this happening and you have already generated your own redirections on the server it can again create redirection loops or possibly server timeouts. Testing your content management system prior to changing your URL structure is smart.
Failure to update CDNs
Many high traffic sites utilize Content Delivery Networks to host images and other third-party resources. These URLs must be updated to HTTPS versions in order to maintain a secure browsing experience as well as to provide the correct signals to Google and any Canonical URLs. This is especially important for CDNs that use a subdomain mask like cdn.example.com
Failing to update vital 3rd party resources. (like XML site maps)
In some cases a site (especially e-commerce sites) may choose to house their XML sitemap on a third-party server. I personally advise against this behavior, however if a website chooses to go this route they should make sure that their XML sitemap is updated with fresh URLs as well as the direct URL path to the site map itself.
Not adhering to existing canonical URLs within redirects.
If a canonical URL structure is in place prior to implementing HTTPS, that same structure should be applied during the redirection. This means not accidentally adding a forward slash “/” or removing a file extension at the end of certain URLs.
Only securing part of the site.
In several cases I have seen domains implement only a section of the site for HTTPS such as the shopping cart or contact forms. While this may seem like a fair middle ground, it can actually create more problems by confusing the crawler and inadvertently breaking canonical URL structures. If you are switching to HTTPS, you should do it “domain wide” and not isolated to one section of the site.
Conclusion: Plan and test everything.
I can’t stress this enough. Every process during the implementation of HTTPS URLs needs to be planned and tested thoroughly before deploying. This includes understanding every element of the process and testing each before launch day. The vast majority of issues arise when webmasters take a cavalier attitude to making such a significant change.
If you have more questions or would like a completely custom strategy for your site implementation please get in touch with us as soon as possible. We have experience planning and implementing these types of changes for a diverse array of different types of websites.