Cookie preferences

Skip to content
SearchCub
  • On-page SEO
  • Explainer

Does HTTPS Affect SEO? What to Check After Switching

Editorial responsibility: SearchCub

Created: Edited:

HTTPS matters for SEO mostly indirectly: Google called it a "very lightweight signal" in 2014, and its current guidance says page experience aspects other than Core Web Vitals don't directly help a site rank higher. What HTTPS does change is whether Chrome warns your readers, and which version of each page Google indexes. This guide explains what Google and Chrome say, then gives five checks to run after you move a blog to HTTPS.

What Google has said about HTTPS and rankings

In August 2014, Google announced it had begun using HTTPS as a ranking signal, but "only a very lightweight signal—affecting fewer than 1% of global queries", and one that weighed less than signals like high-quality content (Google Search Central Blog). It added that it might strengthen the signal over time.

Google's current page experience guidance, last updated 22 September 2026, asks whether your pages are delivered securely as one of its self-assessment questions. Its FAQ then separates Core Web Vitals from the rest of page experience: the other aspects, it says, "don't directly help your website rank higher in search results." Those aspects can still make a site more pleasant to use, it adds, which generally fits what Google's ranking systems aim to reward.

So don't plan on a ranking jump from switching. Plan on removing a warning your readers would otherwise see, and on getting Google to index the secure version of your pages.

What Chrome's "Not secure" label means

Chrome shows a security symbol on the left side of the web address. For a site that doesn't use a private connection, Chrome's help page explains that the "Not secure" symbol means others could see or alter the information passing between you and the site. It adds that the site owner must fix this by securing the site with HTTPS.

The label has applied to every HTTP page since Chrome 68, released in July 2018 (Chromium Blog, February 2018). In May 2018, Chrome also announced a red "not secure" warning when people enter data on HTTP pages, starting with Chrome 70 (Chromium Blog, May 2018). On a blog, that means newsletter forms, comment boxes and contact pages.

Some readers get more than a label. When a reader turns on Chrome's Always use secure connections setting and a site lacks HTTPS support, Chrome warns that the connection to that site is not secure.

A different message, the full-page "Your connection is not private" error, means something is wrong with the site, the reader's device or the network. If every visitor sees it on your site, start with your certificate.

Why HTTPS still matters to Google

Google prefers the secure version of a page. Search Console's HTTPS report help says that when a page has both an HTTP and an HTTPS address, "Google prefers to index the HTTPS version." Google's canonicalization documentation lists the problems on the HTTPS page that can override that preference:

  • its SSL certificate is invalid;

  • it loads insecure resources other than images;

  • it redirects visitors to an HTTP page, or through one on the way;

  • its rel="canonical" link points to the HTTP page.

Each one is easy to leave behind during a switch. That is why the checks after the move matter more than the move itself.

Five checks after moving to HTTPS

Google treats a move from HTTP to HTTPS as a site move with URL changes, and its site move guide covers the full process. For a blog, these five checks cover the points above.

1. The certificate is valid

For many site owners, the web host gets and manages a free certificate from Let's Encrypt, either automatically or through a setting you turn on. Let's Encrypt is a nonprofit certificate authority that issues free TLS certificates.

Open your home page and one post at their https:// addresses in Chrome. You should see the default symbol with no "Not secure" label and no full-page connection error. In Search Console, an invalid certificate appears as HTTPS has invalid certificate, which Google says typically affects an entire site.

2. Every http:// address redirects to its https:// version

Type the http:// address of your home page and of an older post. Each should land on the same page at https://. Your browser may go straight to https:// without hitting the redirect, so Google's site move guide suggests testing individual URLs with the URL Inspection tool, in a property that covers http:// (check 5). Google recommends a permanent server-side redirect, which returns a 301 or 308 status code (Google: redirects). Its site move guide says to leave the redirects in place for as long as you can, generally for at least 1 year. If your host or platform has a setting that forces HTTPS, your host can confirm which status code it sends.

Check the opposite direction too. An https:// page should not redirect back to http://; Search Console reports that as HTTPS has redirect.

3. No mixed content

Mixed content means the page itself loads over HTTPS while some of its images, scripts or stylesheets still come over HTTP (web.dev: mixed content). Browsers now upgrade insecure images, video and audio to HTTPS and block other insecure requests (MDN: mixed content). A blocked script or stylesheet can break part of your page, and insecure dependencies other than images can stop Google from preferring the HTTPS version.

On a blog, look for old http:// addresses in post images, theme settings, widgets and embed codes. MDN suggests browsing your site with the browser's developer console open and watching for mixed content warnings. Change each address you find to https://, or to a relative link for files on your own site.

4. Canonical tags, internal links and the sitemap use https://

Google's site move guide says every new URL should carry a canonical tag pointing to itself, and that you should update internal links. If a page's canonical still names its http:// address, Google can choose the HTTP version; Search Console calls one form of this HTTP marked with canonical tag. Links in your posts that point to http:// still work through the redirect, but Google notes that redirects slow users down, so change them at the source. Internal links for SEO explains how those links guide readers and crawlers through your site.

Your sitemap should list only https:// addresses; otherwise Search Console can report Sitemap points to HTTP. To check one page, SearchCub's Page checks reports whether it is Served over HTTPS, and its Canonical URL points to this page row prints the canonical address it found. Read that address and confirm it starts with https://.

5. Search Console follows the https:// version

Search Console has two property types. A URL-prefix property "includes only URLs with the specified prefix, including the protocol (http/https)", while a Domain property covers every protocol and subdomain (Search Console Help: add a property). An http:// URL-prefix property therefore leaves out your https:// pages. Add the https:// version or a Domain property, and submit your https:// sitemap there.

Google's site move guide says to verify both the HTTP and HTTPS variants. It also says the Change of Address tool is not needed for an HTTP-to-HTTPS move.

Then open the HTTPS report, which is available only for HTTPS URL-prefix properties and Domain properties. It counts your indexed HTTP and HTTPS URLs, and ideally no HTTP URLs remain. Its error names point back to the checks above:

  • HTTPS has invalid certificate. What it means: the certificate is invalid, usually for the whole site. What to do: fix or renew it (check 1).

  • HTTPS has redirect. What it means: the https:// page redirects to an http:// page. What to do: remove that redirect or point it to an https:// page (check 2).

  • HTTP marked with canonical tag. What it means: a canonical tag declares the http:// page canonical. What to do: declare the https:// page as canonical (check 4).

  • Sitemap points to HTTP. What it means: your sitemap lists an http:// address that Google indexed as canonical. What to do: list the https:// address (check 4).

  • HTTPS URL is roboted. What it means: robots.txt blocks the https:// page. What to do: remove the block.

  • HTTPS not evaluated. What it means: Google couldn't assess the https:// version, for example because it doesn't exist or other errors stopped processing. What to do: fix the other errors first, then make sure the https:// page exists.

Some errors clear on their own once Google crawls the new pages (Search Console Help: HTTPS report). Expect some movement in the meantime: Google says visibility may fluctuate temporarily during a site move and that rankings settle down over time. For a small to medium-sized site, most pages can take a few weeks to move. If an important post still isn't indexed at its https:// address after that, why Google hasn't indexed your page shows how to inspect it.

Where to go next