How to switch to HTTPS: step-by-step instructions. How does HTTPS work?

In July 2014, Google announced an advantage in the ranking of sites with correctly installed SSL certificates. Converted and secure SSL sites began to appear as HTTPS (hypertext transfer protocol secure), unlike the earlier standard HTTP. Thus, an additional level of security has appeared that prevents unwanted access to stored data.

Today, Google, Safari, Firefox and most other popular browsers require this protocol for better ranking, geolocation, credit card entry and much more. The HTTPS security protocol also protects the website from unwanted advertisements that annoy visitors with intrusive, ugly information, sometimes containing malware. Since October 2018, Google began to display a warning about the danger of red when users enter data on HTTP pages or a lock in the address bar of green when security is normal on HTTPS.

Brief definition

HTTPS and SSL are visible on the site URL, which is reflected in the browser bar. Nearby you can also see the symbol of the castle. So modern browsers show that the user is on a site that uses SSL encryption. In some cases, the URL includes the name of the company. These signs indicate that the visitor is on a site that takes privacy seriously. It stands for HTTPS Secure Hypertext Transport Protocol. Its "brother" HTTP means the same without the "secrecy" at the end and is the communication protocol commonly used to facilitate web traffic.

The secure version uses SSL (Secure Socket Layer) certificate to establish a connection between the browser and the server. Therefore, it becomes clear how HTTPS works - any information exchanged becomes encrypted. Encryption is the process of replacing plain text information, such as usernames and passwords, with random numbers and letters. Thus, it can no longer be read by people, and it is more difficult to understand during interception.

A small clarification: technically, SSL is actually not the right term; in the late 90s, it changed to TLS (transport layer security). However, it is still often used in describing HTTPS processes.

The first thing to do to switch to HTTPS information security technology is to buy the right SSL certificate, which creates an encrypted tight connection between the browser window and the web server. Various types of certificates are available which differ in cost. The important point is that basically they all work on the same principle, so the user does not receive “greater security” just because he pays more.

There are different sets of functions:

1. Entry-level SSL domains. They are issued instantly and, before switching to HTTPS, they require only confirmation by e-mail, offer viewing HTTPS with a lock, there is no deep analysis process, only verification of domain ownership. Ideal for small, budget-conscious companies that do not accept online payments.
2. Organizational SSL certificates require a higher degree of verification of company ownership. With this type of certificate, the company name and domain name appear in the browser panel.
3. SSL with advanced verification, allows you to use the "green browser bar". They are more expensive than previous certificates and include legal, operational and physical verification.
4. After you purchase an SSL certificate, you will need to approve it. There are different levels of verification before issuing a certificate. For example, for domain SSL, it can be issued immediately as soon as the domain owner confirms his email address. If the site owner uses shared hosting, then before switching to HTTPS, they contact the provider for help in administering the server with an approved certificate.

The algorithm for switching to HTTPS:

1. Perform a full backup of the site. If hosting is managed by cPanel, you can use the built-in cpanel backup feature. Otherwise, contact your hosting company to find out if it offers a managed backup service.
2. Modify the site HTTP links to HTTPS. The procedure depends on the size of the site, which determines how HTTPS works. If the site has only a few pages, then you can use the manual process. If there are hundreds or even thousands of pages, they use tools that automate the process, especially if it is hosted on the WordPress engine.
3. Before switching to HTTPS, check the code libraries. This is an optional step and applies to more complex sites that use additional software such as JavaScript and Ajax.
4. They update all external links pointing to the site from social network accounts and lists in reputable directories.
5. Create a redirect to HTTPS 301. This sounds complicated, although in reality it is not. 301 is a method of redirecting traffic from one web page to another URL. This is an important point, because if a site has dozens, hundreds or even thousands of backlinks pointing to it from other sites, they will point to HTTP pages, and the ranking in search engines depends on the quantity and quality of backlinks. The 301 redirect setting depends on the type of web server that is being used. The most popular types of web servers are Apache, NGinx and LiteSpeed ​​and Windows. Before you switch to HTTPS, you need to update the htaccess file with Apache and LiteSpeed, with the NGinx file the NGinx configuration file, and with Windows, the web.config file.
6. If you are using a content delivery network (CDN) such as CloudFlare, you must also synchronize SSL with this system. CDN is a globally distributed network of servers that stores copies of web pages on its servers. This gives advantages not only in terms of speed, but also security, since it can recognize various patterns of malicious programs and prevent hacking of the site.
7. Updates any other tools and transactional emails, such as email marketing, automation, and landing page generators. You need to prepare a list of these programs and look for references to web pages that link to HTTP, then update them to HTTPS.
8. And last but not least, to follow the instructions for switching to HTTPS, you need to update your Google Analytics and Search Console accounts. In Analytics, you need to change the default URL to HTTPS. In the search console, you need to add a new site with HTTPS.

SEO Trap Prevention

Chrome warns users that the site is not secure when they fill out a form, such as a search box or email registration. This latest alert combined with the benefits of Google SEO has accelerated the transition to the new standard of many sites.

Numerous details and checklists exist for the engineering side, but sometimes the SEO specificity may be overlooked during the transition. An HTTP checklist for HTTPS that focuses only on SEO issues: planning, migration, and post-migration monitoring.

Using the Keylime Toolbox Query Analytics, you can combine HTTP and HTTP Secure query data from the Google Search Console and track trends in clicks, ranking, impressions over time and in aggregate, at the level of individual queries and for categories. Keylime Toolbox Crawl Analytics provides daily log analysis to help track Googlebot crawl, measure how long it takes for a full crawl and reindex, and identify any issues. If the site is large and conventional crawl is inefficient, consider introducing special elements of crawl efficiency before starting the migration.

Configure transition functions

When switching to Redirects, the following settings are configured. HTTP to HTTPS Migration Guide:

1. 301 redirect HTTP addresses to HTTPS URLs. To the extent possible, include all existing rules. Google will only crawl up to 5 redirects in the chain.
2. Updates all internal links to HTTPS URLs.
3. Updates metadata and structured markup.
4. Make sure all resources are moved to HTTPS, and the links are updated in the source code of the page.
5. Check the HTTPS property in the Google search console.
6. Create a set of properties that combines HTTP and HTTPS for monitoring purposes.
7. Configure the settings for the HTTPS version of the domain in the Google Search Console in accordance with the settings for the HTTPS installation.
8. Set international targeting.
9. Set the scan speed.
10. Make sure that the HTTPS robots.txt file has the same content that was previously specified for HTTP and does not prohibit everything.
11. Ensure that HTTPS pages do not have meta noindex attributes.
12. Be sure that the web analytics and other third-party tags are installed.
13. Submit XML Sitemaps for URLs to HTTPS and do not block HTTP URLs using robots.txt.
14. Track common search traffic in web analytics to make sure it’s stable.
15. Track rankings and other SEO-oriented data in the Google Search Console.
16. Manually check the display of search results to make sure everything looks correct, as HTTPS URLs are indexed.

Googlebot crawl

Process tracking data, how Googlebot scans HTTP and HTTPS, which URLs it scans and which response codes it receives, is available only if Crawl Analytics is used, which downloads server log files for processing. To do this, download the full list of crawl errors provided by Google for both HTTP and HTTPS, as well as link source data for each error.

It monitors aggregated ranking and HTTP and HTTPS traffic over time for branded and non-branded queries, as well as other SEO data, such as individual and aggregated clickthrough rates and the total number of clicks on which the site appears

If the site is large and crawling is inefficient, it may take some time for Google to re-crawl all of the HTTP URLs and replace them with HTTPS versions in the index to speed up the process. Log files are an excellent resource for identifying performance issues. Although Google claims that it handles the PageRank flow the same way for the 301st and 302nd, it still handles these redirects differently. Since 302 is technically “temporary”, Google continues to index the destination URL 302. When redirecting 301, Google removes the redirect URL from the index and only indexes the destination URL 301.

Redirection Consolidation

Googlebot only performs up to 5 redirects, and as URLs change over time and canonicalization rules are added, redirect chains become commonplace. However, they slow down the loading of pages especially on mobile devices.

In many cases, HTTP / HTTPS and www / non-www redirects are done at the server level, and all the rest at the application level. In this case, the ideal scenario is to use one 301 at the server level for accounting, like HTTP / HTTPS.

This latest HTTPS redirect will include these rules:

1. From old URL patterns to current ones, make sure that all old rules are updated with current end goals. Case normalization, for example, from example.com/Page1 to example.com/page1 and a trailing slash, for example, from example.com/page1 to example.com/page1/. In this example, example.com/Page1 will redirect 301 directly to example.com/page1/ in a single HTTPS and www loop.
2. When you look at all the old rules, update them, and consolidate, make sure everyone has a value of 301, not 302. The URLs that redirect 302 can remain indexed, which leads to unpredictable elements for displaying search results. In them, not only the wrong URL may appear, but also other unwanted behavior. For example, if metadata, such as site links, is linked to the current URL, and the old one appears in the search results, then the additional links will not be displayed.
3. They update all internal links to the canonical URLs, which is useful because redirects increase page load time, especially on mobile devices. Ideally, internal links should be absolute, not relative, and should be updated to HTTPS URLs.
4. Use relative rather than absolute links, which eliminates the need for internal updates. This is normal, but not ideal and is due to the fact that internal links are a strong canonical signal for search engines, so if any URLs are incorrectly configured so as not to redirect, the site is accidentally duplicated on a subdomain or deleted. All links on these pages will be on non-canonical versions.

In most cases, a lot of work is not required to update internal links. Often they can be updated using configuration options, programmatically or all at once through a script.

Updating metadata and structured markup

When updating the canonical attribute values ​​to HTTPS URLs, if 301 is redirected from HTTP to HTTPS, but the HTTPS URLs have canonical attributes for HTTP, Google will see an endless loop, resulting in unpredictable indexing results. To fix the failure you will need:

1. To switch a site from HTTP to HTTPS, the page number attribute values ​​are updated at the HTTPS URLs.
2. Update hreflang attribute values ​​to HTTPS URLs.
3. Rel rel updates alternate values ​​if used for individual mobile URLs on HTTPS URLs.
4. Updating structured markup, such as videos, carousels, and the site link search box, at HTTPS URLs.
5. Be sure all resources are moved to HTTPS. All resources used by HTTPS pages must be served from HTTPS. This includes elements such as images, JavaScript, and CSS files.
6. Update social plugins, advertising calls and so on.
7. Use Google tools to search for “mixed content” on a site.

Search Console Setup

In order to configure the search console, create a set of properties that contains both HTTP and HTTPS versions of the domain for monitoring. Algorithm for sequential actions:

1. Configure the parameter processing configuration for the HTTPS version of the domain in the Google Search Console.
2. Set international targeting, if applicable, to match what was set for HTTP.
3. Update the scan rate if it is set for HTTP.
4. Download all disavowed files that are downloaded for HTTP.
5. Set your preferred domain.
6. Install Robot Exclusion Protocol for HTTP and HTTPS.
7. Be sure the robots.txt HTTP file redirects or 404s.
8. Make sure that the HTTPS robots.txt file has the same content as the previous HTTP, except for the link to the Sitemaps.
9. Make sure that HTTPS pages do not have the meta noindex attribute.
10. Make sure that the Web Analytics tags (and others) are still in place

In many cases, the site will continue to use the same web analytics tags, such as the Google Analytics property identifier. But if this is changed, make sure the pages on the site are updated. In addition, make sure that the source code containing the tags is not removed from the pages during the migration process. You can use a third-party tool that checks for tags, or set up a scanner, such as Screaming Frog, to check for tags.

If XML Sitemaps are added to the Google Search Console, you can use reports to track the decline in indexing. Begin crawling Google bots for HTTPS URLs when they are in Sitemaps XML files. You can track indexing increases using XML indexing reports. Always create XML Sitemaps that are comprehensive and canonical, not just for the transition from HTTP to HTTPS.

Search Console Monitor

You must submit the XML Sitemap for the URLs to HTTPS and maintain the existing XML Sitemap for HTTP. This will allow you to track index reduction for the HTTP property and index increase for the HTTPS property.

All URLs in the HTTP sitemap must have a status code of 301, and indexing should decrease over time. All URLs in an HTTPS sitemap must have a status code of 200, and indexing should increase over time. This process may take some time, and you may find that some HTTP URLs are still indexed months later.

The most common reasons for this are:

1. HTTP URLs are blocked by robots.txt, so Googlebot cannot crawl redirects and is partially indexed.
2. HTTP URLs are "non-canonical" and are not crawled very often.
3. HTTP URLs do not return 301, instead 302 or an error is returned.

Troubleshooting tips

Unfortunately, following a step-by-step instruction and switching to HTTPS is a rather complicated process and the user needs to understand what he is dealing with.

The main types of failures during the transition:

1. The most common problems that occur after a site switches to HTTPS are mixed content warnings. This happens when the browser finds insecure links on another secure page. This is usually a matter of updating links to jquery libraries, custom fonts, or their similar HTTPS versions. The user should take care of this when scanning his site before publishing it and if such warnings appear, they must check the sources that cause them.
2. Switching from HTTP to HTTPS can adversely affect the rating, although this is usually only temporary. If you configure 301 redirects, it processes only 90-99% of the link mass. That is why the rating may decline at the beginning. However, they should increase over time and benefit in the long run.
3. If you find that some URLs are still indexed months later, but the HTTP Search Console Search Analytics reports don’t show any clicks, then this problem might not be worth exploring. URLs are not ranked by query and do not cause problems. However, if clicks on the HTTP property appear, then the URLs are ranked by request.
4. The easiest way to start an investigation is to look at the server logs to see exactly what Googlebot gets when it crawls. In Excel, the log files in detail Keylime Toolbox Crawl Analytics include a tab that lists all URLs with a response code of 200, all URLs with a response code of 302, and so on.
5. You can crawl a site using a tool such as Screaming Frog to get a list of URLs that return 200 blocked by robots.txt. You can also look at the Google Search Console> Crawl> robots.txt Tester for the HTTP property to see if Google sees the robots.txt file and, if so, whether it blocks any URLs.

Other pitfalls not related to SEO

There are other possible problems for sites that switch to HTTPS:

1. Potential reduction in AdSense revenue. In the past, Adsense revenue declines were due to a large number of ads incompatible with HTTPS. It is important to note that if a user switches from HTTP to HTTPS, they need to update the AdSense code, otherwise they will receive the content problems described above.
2. There are frequent cases when a site loses all its shares in social networks when switching to HTTPS. Even a fantastic article that has collected tens of thousands of likes on Facebook can be reset after the transition. The Facebook documentation explains a workaround for this, which involves setting the og: url meta tags to specify the old http URL. However, he says that this only works if the old URL returns a 200 response. If you redirect http pages to https pages, then the "old" pages will return 301, not 200.
3. Switching to HTTPS may result in Google re-evaluating the site in terms of quality. This is the biggest problem during the transition and may mean that all pages on the site receive a new quality rating. It is possible that the techniques and loopholes that were used earlier will no longer work the same after the HTTPS offset, as a result of which the traffic will drop after switching to HTTPS.
4. Sitemaps must be updated. Before switching, make sure that a new site map is also created.
5. Disavow file must be uploaded to HTTPS.
6. Google still considers HTTPS and HTTP versions of the site to be different sites, and if you use the Google search console, you will need to create a new property for the HTTPS version. If the user has a disconnect file, then you need to upload it to the HTTPS version.
7. Verify that the certificate has not expired. If the site uses the HTTPS protocol and the security certificate expires, then when Google tries to send visitors to the site, they will receive a large full-screen warning that will definitely push people away.

Securing traffic is one of the most important issues for any website owner. In addition to conveying trust, the process benefits from increased speed and improved SEO. This is a great investment in the future, as the network is moving in this direction. As already mentioned, Google considers the use of SSL a positive ranking factor, so if a user moves his site to HTTPS, he will actually make it more attractive. It seems that after such weighty arguments, the user will no longer have a question about switching to HTTPS and why “fence a garden”.