Technical SEO

SEO: How to Migrate an Ecommerce Site to HTTPS

Google began encouraging websites to move to encrypted SSL connections, which carry the HTTPS reference in the URL, as early as 2014. Google promised a ranking boost to sites that made the move.

I have helped clients move to HTTPS since then. Most moves have produced little-to-no ranking benefit. The process of moving to HTTPS is similar to an overall platform migration. The effort is similar, as are the risks to organic search traffic.

Your online store already has an SSL certificate for the checkout and payment process. But moving an entire site to HTTPS will likely result in much angst — as well as development and consulting costs. So, if the potential ranking boost is minimal, why make the move?

HTTPS: Pros and Cons

Google, in its “Online Security Blog,” published the following update in December 2016:

To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labeled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

Chrome now "marks" HTTP pages that collect passwords or credit cards as non-secure.

Chrome now “marks” HTTP pages that collect passwords or credit cards as non-secure.

I typically advise clients to not implement changes for a potential rankings gain. But, in the case of HTTPS, there is a potential to lose rankings and organic search traffic, especially since Chrome now accounts for roughly 60 percent of the browser market share. That may be reason enough to implement HTTPS.

There is a myth that if you move to HTTPS, your site will slow down because of the encryption process. That might have been the case several years ago, but today the opposite is true. Today’s servers are orders of magnitude faster, and many contain advanced features — such as HTTP/2 — that are available only to browsers with HTTPS connections.

You can compare the speed difference between secure and non-secure connections using HttpVsHttps.com. In my test, an HTTPS connection was 88 percent faster than HTTP.

You can easily compare HTTP vs HTTPS speed using accessible tools.

You can easily compare HTTP vs. HTTPS speed using accessible tools.

Most of my clients that have migrated to HTTPS have not experienced losses in organic-search traffic. But, in two recent cases, with large sites, there were drops in traffic after the move, even though we now treat HTTPS moves with the same rigor as a site migration.

What follows are steps to move your ecommerce site from partial HTTPS use to complete HTTPS, for the entire site. Implement these steps first on the staging version of your site, then move to production.

Implementing HTTPS

Redirect maps. You don’t really need to map URLs individually to move to HTTPS, because the URLs are, essentially, the same. You need to update your existing redirect rules to point to HTTPS, or create new redirects.

Redo forced HTTP. Some ecommerce platforms are set up so that the checkout funnel is forced to be HTTPS, and every other page is forced to be HTTP. Remove the rule that forces HTTP.

RewriteEngine On
 # This will enable the Rewrite capabilities

RewriteCond %{HTTPS} ==on
 # This checks to make sure the connection is HTTPS

#RewriteRule !(^/?order/.*) http://%{SERVER_NAME}/$1 [R,L]
 # This rule will redirect all users who are not using any part of /order/ to the same location but using HTTP.
 # i.e. https://www.webstore.com/category1/ to http://www.webstore.com/category1/

 

Broaden the forced HTTPS rule. If your platform is on a subdomain or third-party site, you will need to start the entire SSL setup from scratch. Google’s guide can help with this.

Assuming your checkout funnel is using HTTPS by default, these are the changes (for Apache servers) to force the entire site to HTTPS.

RewriteEngine On
 # This will enable the Rewrite capabilities

RewriteCond %{HTTPS} !=on
 # This checks to make sure the connection is not already HTTPS

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
 # This rule will redirect users from their original location, to the same location but using HTTPS.
 # i.e. http://www.webstore.com/category1/ to https://www.webstore.com/category1/
 # The leading slash is made optional so that this will work either in httpd.conf
 # or .htaccess context

 

Use protocol-relative page resources. Next, make sure all page resources — such as images, JavaScript, CSS, fonts, third party scripts — are using HTTPS. This is critically important because if any resource is using HTTP, the browsers will display ugly warnings.

Make sure all page resources — such as images, JavaScript, CSS, fonts, third party scripts — are using HTTPS. On this example, Jared.com is linking to an image via a HTTP connection.

Make sure all page resources — such as images, JavaScript, CSS, fonts, third party scripts — are using HTTPS. On this example, Jared.com is linking to an image via a HTTP connection.

An easy way to do this is to mass replace URLs from http:// to https://. The problem with this, however, is that third-party resources that are not available as https:// can break the pages. A clever shortcut is to mass replace page resources using protocol-relative URLs, which look like //webstore.imagecdn.com/logo.png. Note that I removed the protocol and colon. This causes the browser to load the page with whatever the site is using — HTTPS or HTTP.

This mass replace work needs to be done at the database level. Some ecommerce systems can handle this for you automatically.

Check for mixed content. When an HTTPS page includes resources that are linked using HTTP, browsers consider this a security exception, and display warnings to end users. You can identify these using my company’s free site crawler, or via a desktop crawler, such as ScreamingFrog.

Identify mixed content with a crawl tool, such as Screaming Frog.

Identify mixed content with a crawl tool, such as Screaming Frog.

With a page open that is displaying browser warnings, use this shortcut in Google’s Chrome Developer Tools, in the main menu, under More Tools > Developer Tools. Click on the Network tab, and type mixed-content:displayed in the filter search box.

Using Google’s Chrome Developer Tools, type mixed-content:displayed in the filter search box to check for secure or non-secure resources — mixed content — depending on the page.

Using Google’s Chrome Developer Tools, type mixed-content:displayed in the filter search box to check for secure or non-secure resources — mixed content — depending on the page.

Check for temporary redirects and redirect chains. Make sure your redirects do only one hop, and are 301 permanent redirects. Temporary redirects can delay indexing the new URLs, and redirect chains introduce extra latency and otherwise waste Googlebot’s crawl budget.

Update internal links. Updating all absolute internal links to use their HTTPS version is an optional but important step. While the redirect rules will land users on the right version of the pages, the redirects will introduce some additional time to each request.

These steps, above, should complete the move to full HTTPS. I’ll now address the extra steps needed to preserve your search engine rankings and traffic.

Preserving Search Engine Rankings

Use absolute canonicals. I often see retailers using relative canonical tags. This is an incorrect practice. If a page is available as http:// and https://, the canonical should be clear about which one is the preferred version. In this tutorial, we are moving to HTTPS. Thus the canonical should start with https://. When you use a relative canonical, you really have two canonicals, one for the https:// page and one for http://.

Update pagination tags, hreflang tags, alternate media tags. Similar to canonicals, update all URL-based SEO tags so they use https://. Don’t forget to update HTTP header tags.

Create a duplicate Google Analytics view to monitor the HTTP to HTTPS migration. It is important to update the Google Analytics default URL to HTTPS. I also like to create a separate view to review the traffic in both versions as the migration progresses.

Create a duplicate view in Google Analytics to monitor both HTTP and HTTPS.

Create a duplicate view in Google Analytics to monitor both HTTP and HTTPS.

Register Search Console profiles for HTTPS — desktop and mobile. Google tracks each URL path separately. It is not uncommon for site owners to panic — when their search analytics stats tank — because they are looking at the HTTP profile. Fortunately, Google introduced a feature last year to combine the profiles using sets.

Update URL parameters and disavow files. If you have URL parameters or disavow files in your HTTP profile, make sure to replicate them with new HTTPS version. This applies, too, if your mobile site is in a subdomain — replicate the HTTP configuration.

Create a separate XML sitemap and track both. Instead of just updating your XML sitemaps URLs to use https://, create a full copy of all sitemaps, and register two sets: one with http:// URLs and one with https://.

Registering duplicate XML sitemaps won’t create duplicate content. Sitemaps are primarily used for discovery and reporting. They don’t directly control indexing.

The main benefit of leaving both sets of XML sitemaps live is that you should be able to see as all HTTP pages removed from the index, and the corresponding HTTPS ones indexed.

Remove any HTTPS blocks in robots.txt. It is possible to have one robots.txt for the HTTPS version of your site, and one for the HTTP one.

Years ago, I incorrectly advised clients to block all pages on the HTTPS robots.txt. My thinking was that it would avoid duplicate content. Over time I realized that blocking pages via robots.txt is the worst possible solution to duplicate content problems. That is because pages blocked by robots.txt accumulate links and page reputation. You can confirm this by checking if pages you blocked are still getting indexed. In other words, crawling (which robots.txt blocks) and indexing are two separate processes.

The correct solution is to use absolute canonicals, which consolidate it instead.

Delay implementing HSTS, HSTS preloading. Many articles and guides about moving to HTTPS recommend activating HSTS, which is a fantastic security feature that forces browsers to always load the HTTPS version of your site, regardless of redirects. It can also prevent other sites from impersonating your site.

But I prefer to wait until after the move to HTTPS is complete and the site is functioning as intended, so that there are no traffic issues that might call for a rollback. An alternative is to roll out HSTS gradually by incrementing the max-age value in the HSTS header.

Consider rolling out HSTS gradually by incrementing the max-age value in the HSTS header.

Consider rolling out HSTS gradually by incrementing the max-age value in the HSTS header.

Finally, consider adding your site to the Chrome’s HSTS preload list.

Content delivery networks. If you are stuck in an ecommerce platform that won’t allow the move to full HTTPS, you can use a CDN, which will increase speed and most CDNs will handle the full HTTPS conversion for you.

Consider a gradual move. If your store takes more than 2-4 weeks to fully crawl, or if the store is responsible for high-volume sales, consider a gradual move. This involves removing forced redirects from sections of the site at a time, and updating the canonicals to get the HTTPS pages indexed. Monitor the traffic progress using the two Google Analytics views I recommended earlier, and continue the migration. Or, roll back if there are problems.

Test that HTTPS pages can be crawled and indexed. Using Google Search Console’s Fetch as Googlebot, make sure that Google can crawl and index the HTTPS pages. Check a sample product page, a category page, and other pages and sections. Also, check that Googlebot is picking up the redirects from HTTP correctly. Note that the Fetch as Googlebot tool won’t follow multiple redirects. So if there is a redirect chain, you will need to send multiple requests.

Publish your staging site to production. The details for this will vary based on your setup.

Monitor Progress in SERPs

In addition to tracking progress in Google Analytics, Google Search Console, and your web server traffic logs (if you can get them), it is important to track indexing progress directly in the search results using the site: command.

I prefer Chrome Developer Tools to follow the redirects, starting from the search result and clicking to the destination page on the site. I’ve found redirects that don’t work as expected, or worked one way in staging and another once released to production.

Have you switched your site to HTTPS? Please share your experiences and tips in the comments, below.

Hamlet Batista
Hamlet Batista
Bio   •   RSS Feed


x