Secure your site with HTTPS

Protect your site and your users

If you already have an existing HTTP property that you want to migrate from HTTP to HTTPS, follow the instructions in the Site Moves with URL Changes. This article describes HTTPS and best practices for using it.

What is HTTPS and how does it work?

HTTPS (Hypertext Transfer Protocol Secure) is an internet communication protocol that protects the integrity and confidentiality of your users' data between the user's computer and the site. For example, when a user enters data into a form on your site in order to subscribe to updates or purchase a product, HTTPS protects that user's personal information between the user and the site. Users expect a secure online experience when providing data via a website. We encourage you to adopt HTTPS in order to protect your users' connection to your website.

Data sent using HTTPS is secured via Transport Layer Security protocol (TLS), which provides three key layers of protection:

  1. Encryption—encrypting the exchanged data to keep it secure from eavesdroppers. That means that while the user is browsing a website, nobody can "listen" to their conversations, track their activities across multiple pages, or steal their information.
  2. Data integrity—data cannot be modified or corrupted during transfer, intentionally or otherwise, without being detected.
  3. Authentication—proves that your users communicate with the intended website. It protects against man-in-the-middle attacks and builds user trust, which translates into other business benefits.

Best practices when using HTTPS

  • Use robust security certificates You must obtain a security certificate as a part of enabling HTTPS for your site. The certificate is issued by a certificate authority (CA), which takes steps to verify that your web address actually belongs to your organization, thus protecting your customers from man-in-the-middle attacks. When setting up your certificate, ensure a high level of security by choosing a 2048-bit key. If you already have a certificate with a weaker key (1024-bit), upgrade it to 2048 bits. When choosing your site certificate, keep in mind the following:
    • Get your certificate from a reliable CA that offers technical support.
    • Decide the kind of certificate you need:
      • Single certificate for single secure origin (e.g. www.example.com).
      • Multi-domain certificate for multiple well-known secure origins (e.g. www.example.com, cdn.example.com, example.co.uk).
      • Wildcard certificate for a secure origin with many dynamic subdomains (e.g. a.example.com, b.example.com).
  • Redirect your users and search engines to the HTTPS page or resource with server-side 301 HTTP redirects.
  • Use relative URLs for resources that reside on the same secure domain. For example, use <a href="/about/ourCompany.php"> to refer to a page on your site example.com, rather than <a href="https://example.com/about/ourCompany.php">. Doing so ensures your links and resources always use HTTPS. It also has the side benefit of making local development less error prone because images, pages, and other resources are loaded from your local development environment instead of the production environment.
  • Use protocol relative URLs for all other domains (e.g. //petstore.example.com/dogs/biscuits.php), or update your site links to link directly to the HTTPS resource.
  • Use a web server that supports HTTP Strict Transport Security (HSTS) and make sure that it's enabled. HSTS tells the browser to request pages using HTTPS automatically, even if the user enters http in the browser location bar. It also tells Google to serve secure URLs in the search results. All this minimizes the risk of serving unsecured content to your users.
    Important: If you use HSTS, verify that your HTTPS pages can be crawled and indexed by Google: do not block your HTTPS pages by robots.txt files or include meta noindex tags in them if you want them to be crawled and indexed. Use Fetch as Google to test that Googlebot can access your pages.

Common pitfalls in using HTTPS/TLS

Throughout the process of making your site secure with TLS, avoid the following mistakes:

Issue Action
Expired certificates Make sure your certificate is always up to date.
Certificate registered to incorrect website name Check that you have registered your certificate to the correct host name. For example, if you register the certficate for www.example.com and your website is configured to use example.com, you'll have a certificate name mismatch error.
Missing Server name indication (SNI) support Make sure your web server supports SNI and that your audience uses supported browsers, generally. While SNI is supported by all modern browsers, you'll need a dedicated IP if you need to support older browsers.
Crawling issues Don't block your HTTPS site from crawling using robots.txt.
Indexing issues Allow indexing of your pages by search engines where possible. Avoid the Noindex meta tag.
Inconsistent linking from HTTPS to HTTP URLs on your site Use protocol relative URLs (e.g. //example.com/script.js instead of http://example.com/script.js)
Old protocol versions Old OpenSSL versions are vulnerable; make sure you have the latest and newest versions of TLS libraries.
Mixed security elements Only embed HTTPS content on HTTPS pages.
Different content on HTTP and HTTPS Make sure the content on your HTTP site and your HTTPS is the same.
HTTP status code errors on HTTPS Check that your website returns the correct HTTP status code. For instance 200 OK for accessible pages, or 404 or 410 for pages that do not exist.

Migrating from HTTP to HTTPS

If you migrate your site from HTTP to HTTPS, Google treats this as a site move with a URL change. This can temporarily affect some of your traffic numbers as described here:

  • You may experience a temporary fluctuation in site ranking during the move. With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site. As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer. The speed at which Googlebot and our systems discover and process moved URLs largely depends on the number of URLs and your server speed. Submitting a sitemap can help make the discovery process quicker, and it's fine to move your site in sections.
  • Beware of common HTTPS/TLS pitfalls that can affect ranking. Review the Common pitfalls section on this page to learn the most common mistakes that we see when sites move from HTTP to HTTPS.
  • HTTPS sites receive a small ranking boost, but don't expect a visible change. Google uses HTTPS as a positive ranking signal. This signal is one amongst many others, and currently carries less weight than high-quality site content; you should not expect a major SEO advantage for moving to HTTPS in the short term. In the longer term, Google may increase the strength of the HTTPS boost.
  • Review our G+ post on HTTPS move FAQs. We published a G+ post containing some questions and answers to specific technical questions when moving to HTTPS. You can ask questions there, but please read the existing comments first, as your question may already be answered.
  • If you have problems, Google Webmaster Central is a great resource. There is plenty of good advice on Google Webmasters and specific cases answered in our user forums. If you can’t find an answer, you can ask a live question to one of our Webmaster Trends Analysts during our Webmaster Central office hours.

More information

More details on implementing TLS on your site:

Was this article helpful?