How to make correct HTTP to HTTPS migration of your website? Since Google announced that SSL is becoming a ranking factor, more and more sites on the web have switched to this standard, both for security reasons and in hopes of improving SEO visibility. Even though Google has released a set of SSL migration recommendations, they only cover part of the whole process.

At DWF, we have assisted dozens of sites in this process, to ensure that the migration is done correctly and does not reduce SEO visibility. Unfortunately, we cannot work with all companies that would need this, which is why we decided to develop this internal DWF procedure in the form of a Guide, which we will publish on the Blog.

You may use this Guide free of charge to migrate the site or online store you manage to the secure version. However, we recommend that this procedure be performed by a specialist, given that it involves significant risks both for site security and from an SEO point of view.

Please note: correct HTTP to HTTPS migration Guide is based on the internal agency working procedure. It is possible that after the publication of this material, the Agency procedure will be updated, depending on the latest Google updates.

How to make correct HTTP to HTTPS migration

1. Before launching the site

1.1. Purchase the SSL certificate according to your needs and install it on the server. In essence, there are two types of SSL certificate: Domain Validation (DV) and Extended Validation (EV). We recommend choosing a 2018 bit certificate.

1.2. Registration of the https version in the Google Search Console, both in the www and non-www version. On this occasion, it will be checked if the http version is registered correctly and, otherwise, the same will be done for it. If you have registered subdomains, replicate the registration of the https version for them as well.

1.3. Set up a ranking monitoring system (positions in Google) for a representative set of keywords. Normally, you should already use an SEO monitoring solution to see what the real situation of the site is before migration (aggregate visibility in organic Google, on the non-brand search segment).

1.4. Identify the landing pages with the best SEO visibility (which attract the most organic traffic), as well as the main keywords from which this traffic comes. In the absence of a monitoring solution that can segment not-provided traffic, use the data in the Search Console.

1.5. Performing an initial crawling of the website, to identify broken links or redirect chains. It is good that these are resolved before migrating to https. You can use the Screaming Frog program, which allows you to scan 500 pages from a site in the free version.

1.6. When working on a copy of the site, make sure that the images, css, js, pdf and other resources used are loaded from https urls. If this does not happen, after launching the site, the certificate will signal that the page is not actually secure.

1.7. Also in the development environment, consider the correct (re) setting of the canonical tag, in order to refer to the secure version of the site. Use absolute urls in this tag to avoid errors.

1.8. Check the correct operation of www / non-www redirects and urls with / without trailing slash. They must redirect as in the http version. For verification you can use Screaming Frog (site-wide) or punctually, with the Redirect Path extension for Google Chrome.

1.9. Prepare and test 301 redirects from http to https urls in the test environment. Keep in mind that they also work for images, css or other files. Usually, the best way to implement these redirects is through the .htaccess file (ask your hosting service provider for details).

1.10. Generate the new Sitemap.XML file, which contains https versions of other urls on the site. It will be uploaded to the Google Search Console after launching the site. Check that there are no non-canonical or redirect urls in the sitemap (you can also do this with Screaing Frog).

1.11. Prepare the robots.txt file to be published on the server after launching the site. In essence, you can replicate the settings that are for the http version, by changing the directions to https urls, if necessary (for example in the sitemap url indication).

1.12. Prepare the necessary changes in the related marketing campaigns (links from the newsletter, banners on partner sites, etc.).

1.13. Resend disavow files. Check for such requests sent to Google on the http version of the site. Update the information, if necessary, so that you can send it back to Google after migrating the site, thus associated with the https version.

1.14. If the domain you are migrating is geotargeted in the Google Search Console, make sure the setting is redone for the https version.

1.15. If you have special settings in the Google Search Console for managing parameters in urls, they must be replicated in the version of the Google Search Console account associated with the https version.

1.16. If the site uses the CDN system for the delivery of static resources, consider its configuration, to ensure that after migration things will work properly. Usually, the providers of such solutions have a simple setting by which they do this.

1.17. In the test environment, check if 3rd-party extensions or social media codes work properly after implementing ssl. Please note that some services implicitly offer to load these resources from http urls, not from secure addresses. They need to be updated.

1.18. Google Analytics configuration, to monitor the data from the secure version of the site. Under no circumstances should you create a new Google Analytics account when migrating to https!

 

Continue with correct HTTP to HTTPS migration

2. While publishing the HTTPS version

It is not enough to activate https on the server if you want a correct HTTP to HTTPS migration! If you only do this, the site may work on the https version of the urls, but from an SEO point of view the migration is not done correctly, likely to follow a significant decrease in organic traffic.

2.1. Effective launch of the https version. Publish on the live server the secure version of the site. After this point, most of the activities in this phase consist of verifications, which should confirm the successful accomplishment of the previously presented operations.

2.2. Check if the structure of the new urls (generated with https) is the same as the old links, the only difference being the addition of the s, as a mark of using a secure protocol.

2.3. Check if the internal links on the site refer directly to the https version. It is wrong for them to lead to the old form (http), even if it immediately redirects (301) to the corresponding https version.

2.4. Check the canonicalization of the urls (if the addresses in the canonical tag refer to the https version of that page).

2.5. Check the www / non-www, slash / non-slash, etc. redirects. Attention to redirect chains: there are cases of wrong implementations, in which, for example, when accessing http://example.ro, the following chain of redirections appears: (1) http://www.example.com (> 2) https: //www.example.com (> 3) https://www.example.com/ (with trailing slash).

2.6. Check if when accessing any url from the site in http format, a 301 redirect is automatically made to its https correspondent. The urls must be identical (except for s).

2.7. Add a comment in Google Analytics to mark the day the migration was made and check that the traffic is recorded correctly for https.

2.8. Check the implementation of SSL on the production environment, by using this tool (you can use other verification system, but the one offered by SSL Labs seems to provide the most technical details).

2.9. Update the robots.txt file to reflect the migration, according to point 1.11

Check if you have a correct HTTP to HTTPS migration

3. After publishing the secure version

3.1. Perform a complete crawl of the site to ensure that you have a correct HTTP to HTTPS migration and the https urls are the only ones accessible and are served without errors. In this process, elements such as canonicalization, indexability or redirections will also be verified. We recommend Screaming Frog for this process.

3.2. Add the sitemap.xml file with the https urls to the Google Search Console. This activity will be done 4-5 days after migration, during which time the old sitemap remained active. After this period, when you publish the new sitemap, you can delete the old one.

3.3. Check for unsecured resources. You can use this tool. If you identify images, pdfs, external resources, etc. what is loading from unsecured urls, you need to update this information.

3.4. In the Google Search Console, monitor the Googlebot crawling activity of the site (how many pages it accesses per day and the loading time). Also, follow variations in the number of pages indexed in Google (at the sitemap level or through the site command: in Google).

3.5. Monitor the SEO visibility of the domain, to quickly identify landing page errors or drops in organic traffic and act accordingly.