HTTPS Report

TL;DR — The HTTPS report in Google Search Console tells you how many of your pages Google is showing over the secure (HTTPS) version versus the old, insecure (HTTP) version — and, for any HTTP ones, why. Google would rather use the HTTPS version, so a healthy site should be at or near 100% HTTPS here.

What the HTTPS report is

If a page can be reached at both http://example.com/page and https://example.com/page, Google generally wants to show the HTTPS (secure) one in search. The HTTPS report is Google’s scorecard for how well that’s going on your site: it counts how many of your indexed pages are on HTTPS and how many are still stuck on HTTP.

A couple of things to know before you read it:

• It only covers pages Google has indexed — not every page on your site.
• It shows a sample, not a complete list. Don’t treat the count as an exact inventory.

Why an HTTP page shows up

When a page shows as HTTP, it usually doesn’t mean your security is broken. It can mean several different things: something on your site is telling Google to prefer HTTP, your HTTPS version is missing or erroring, Google backed off checking after site-wide errors, or the URL is simply new and hasn’t been evaluated yet. Start with the common culprits below — each one is a signal you can find and flip:

• A “canonical” tag on the page points at the HTTP address.
• Your sitemap lists the HTTP version of the URL.
• The HTTPS version redirects back to HTTP (the wrong direction).
• The HTTPS version is blocked in your robots.txt.
• The SSL certificate is actually broken.

What to do about it

Pick the matching cause above and flip the signal to point at HTTPS — fix the canonical tag, update the sitemap, fix the redirect so HTTP goes to HTTPS (never the reverse), or sort out the certificate. Then ask Google to recheck the page (URL Inspection lets you request a recrawl). Over time the HTTPS count should climb toward 100%.

The thing most people get wrong

HTTPS is not a big ranking factor. It’s a real but very lightweight signal. Switch to HTTPS for security, for visitor trust, and so your analytics and canonical URLs are clean — not because it’ll move you up the results. And if you see “HTTPS not evaluated,” don’t assume it’s harmless — it can mean several different things: a missing HTTPS version, Google backing off after site-wide errors, an HTTP canonical choice, or (the one genuinely low-stakes case) a URL that’s simply new and hasn’t been crawled yet. Check which one applies before deciding whether to fix something or just wait.

Want the full breakdown of every error row, plus how this ties into canonicalization and the Page Indexing report? Switch to the Advanced tab.

TL;DR — The HTTPS report shows how many of your indexed URLs Google serves over HTTPS vs HTTP — a sample, not a comprehensive list. Google prefers to index the HTTPS version of any page that exists on both protocols, but an HTTP row doesn’t automatically mean a conflicting signal beat that default — it can also mean a missing HTTPS equivalent, a site-wide processing failure, or a genuinely new/uncrawled URL. HTTPS preference is one signal among the many Google weighs for canonical selection; this report, the Page Indexing report, and URL Inspection are related but not interchangeable. HTTPS is a lightweight ranking signal — fix these for trust and clean canonicalization, not for a ranking lift.

What the report actually measures

Straight from the docs: “The HTTPS report shows how many indexed URLs on your site are HTTP vs HTTPS.” Two qualifiers do a lot of work there, and most people miss both.

First, indexed — the report is scoped to URLs Google has already indexed, not your full URL set. Second, it’s a sample: “The report isn’t a comprehensive list of all detected items.” So this is a diagnostic, not an inventory. If you’re trying to reconcile the count against your total page count, stop — they’re not the same population. The report is available for Domain properties and HTTPS URL-prefix properties.

Search Console matches each HTTP URL to its HTTPS counterpart while ignoring parameters — so query strings like ?utm_source= don’t break the match. It does not, however, treat an HTTPS URL with a different URL structure as the secure version of an HTTP URL. If your migration changed paths, not just the protocol, that HTTPS page won’t register as the match here even though it works fine. And because this is a sample of an indexed population, not a live crawl of every URL you own, a URL missing from the report isn’t necessarily fine — it may just not be indexed yet, or not in the sample. Use the report to spot patterns, not as a complete URL-by-URL audit.

Why HTTP rows happen at all

Here’s the mental model that makes the report click: “If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version.” HTTPS preference is the default — but an HTTP row doesn’t always mean a stronger signal overrode it. Work through the causes in this order:

1. Missing or erroring HTTPS. There’s no working HTTPS equivalent yet, or it errors out.
2. A conflicting signal. Something on your site explicitly votes for HTTP — a canonical tag, a sitemap entry, a wrong-way redirect, or a robots block. This is what the five named reason rows below cover.
3. A site-wide processing failure. Google hit so many errors it backed off processing queued URLs, or a site-wide issue (like a broken certificate) is blocking evaluation everywhere.
4. A genuinely new or uncrawled URL. Google hasn’t seen it, or has seen it but hasn’t crawled it yet — this is the only case where Google’s own guidance points to a short wait (about a day) before rechecking.

HTTPS-vs-HTTP is one signal among the many Google weighs when picking a canonical URL — it’s not a fixed count, and I’m not going to repeat an exact number without a source I can verify. Each named error row below matches cause #2 above; “HTTPS not evaluated” spans causes #1, #3, and #4.

The error rows — “why HTTP pages aren’t served over HTTPS”

These are the report’s status rows. Each one is a specific conflicting signal, and each has a specific fix.

• HTTP marked with canonical tag — “The HTTP page has a <link rel="canonical"> tag, indicating that the HTTP version is canonical.” You explicitly told Google the HTTP URL is the preferred one. Fix: declare the HTTPS URL as canonical instead.
• HTTPS has invalid certificate — “The HTTPS URL has an invalid SSL certificate.” Google won’t test an HTTPS URL unless the certificate is valid, and this typically affects the whole site rather than one page. Fix the cert.
• Sitemap points to HTTP — “A sitemap on your site is pointing to an HTTP URL that was indexed as canonical.” Your sitemap is voting for HTTP. Fix: update the sitemap to list the HTTPS URLs.
• HTTPS has redirect — “The HTTPS URL exists, but redirects to an HTTP URL.” This is the redirect pointing the wrong way. The correct direction is always HTTP → HTTPS, never the reverse. In Ahrefs’ technical-SEO study of over a million domains, a non-trivial share of sites get this exactly backwards.
• HTTPS URL is roboted — “The HTTPS URL is present, but is blocked from crawling by a robots.txt rule.” Google can’t crawl the HTTPS version to confirm it, so it falls back to HTTP. Fix: unblock the HTTPS URL in robots.txt.
• HTTPS not evaluated — an umbrella status, not a single failure. The docs say “This error can be caused by any of the following conditions”: the HTTP URL has no equivalent HTTPS URL; both exist but Google chose HTTP as canonical for some reason; Google hit so many errors of any type that it stopped processing queued URLs; there’s a site-wide error (e.g. a bad SSL certificate); or Google has never seen the URL, or has seen it but not crawled it yet. Don’t default to calling this benign — triage it by cause. A genuinely new or uncrawled URL is the one case Google gives conditional guidance for (give it about a day after a crawl before rechecking); a missing HTTPS equivalent, an HTTP canonical choice, or a site-wide error are real problems that need fixing, not waiting out.
• Other issues — “Another error occurred that is not covered in the list of errors.” The catch-all.

One important correction to a common myth: the current Help page does not list a “noindex” row or an “HSTS” row. Those are related concepts worth understanding — a noindex on your HTTPS page can certainly stop it being indexed and served, and HSTS forces HTTPS at the browser level and supports correct redirects — but they are not categories in this report. Don’t go hunting for rows that aren’t there.

How HTTPS preference, canonicalization, and the Page Indexing report connect

The HTTPS report isn’t a standalone tool, but it isn’t interchangeable with its siblings either. Three different Search Console surfaces can all be relevant to the same URL, and each tells you something distinct:

They can share a root cause — a canonical conflict can show up as an HTTP row here and as “Duplicate, Google chose a different canonical” in Page Indexing — but that’s a hypothesis to verify per URL, not a guaranteed one-to-one mapping. Check URL Inspection for the specific page before assuming the two reports are describing the same problem.

Mixed content and insecure dependencies

Mixed content — an HTTPS page that loads HTTP assets (images, scripts, stylesheets) — isn’t a named row in this report, and current Google documentation doesn’t list it as an HTTPS-report cause. It’s still worth fixing on its own merits: browsers warn on or block it, and it’s a real security gap. But don’t diagnose it through this report — if a page still shows HTTP here after you’ve ruled out the five named reasons above, treat mixed content as a separate check (browser DevTools or a site crawler), not as this report’s explanation. Same goes for HSTS: it’s a useful browser-level control, but it isn’t a report row either.

HTTPS as a ranking signal — the honest version

HTTPS has been framed as a ranking factor since 2014, when Google’s webmaster team (Zineb Ait Bahajji and Gary Illyes) announced it — reported at the time as a lightweight signal weighing less than things like content quality. I haven’t been able to re-confirm the exact wording of that 2014 post against a live copy for this update, so take the precise figure as reported rather than a verbatim guarantee; the durable point holds regardless of the exact number — HTTPS has never been positioned as a heavy ranking lever. HTTPS is also folded into the broader page experience guidance. And to be clear, none of this comes from the HTTPS report itself: the report doesn’t show ranking impact, clicks, or traffic — it’s a protocol-implementation diagnostic, full stop. So the honest framing: fix HTTPS issues for security, user trust, clean referral data in analytics, and tidy canonicalization — not for a ranking boost. It’s table stakes, not a growth lever.

Fixing and confirming

The workflow is the same regardless of which row you’re chasing — and it starts with the cause, not the row label:

1. Identify the cause. The report gives you a sampled starting point — confirm what’s actually happening: missing HTTPS, a conflicting signal, a site-wide error, or a genuinely new URL.
2. Repair it at the source. Fix the canonical, the sitemap entry, the redirect direction, the robots rule, or the certificate. Removing links to the affected URL isn’t a fix — it hides the symptom without addressing the underlying cause.
3. Confirm with URL Inspection, checking the live test and the indexed state separately — they can disagree right after a fix.
4. Watch the sampled cohort, not just the one URL. The HTTPS report reclassifies on its own schedule; there’s no universal SLA to promise here. The one case with conditional guidance is a genuinely new, uncrawled URL — give that roughly a day before rechecking.

I’ve migrated plenty of sites between protocols (my SMX East 2016 talk Better Safe Than Sorry with HTTPS is the long version), and the recurring lesson is the same: having an HTTPS version isn’t enough on its own. If your canonical tags, sitemaps, or redirects still point at HTTP, Google will happily keep indexing HTTP. Make every signal agree, and this report takes care of itself.

AI summary

A condensed take on the Advanced version:

• What it measures: how many of your indexed URLs Google serves over HTTPS vs HTTP. It’s a sample, not a comprehensive list, available for Domain and HTTPS URL-prefix properties. Matching ignores URL parameters but not a changed URL structure.
• The default: Google prefers to index the HTTPS version of any page that exists on both protocols — but an HTTP row doesn’t always mean a conflicting signal beat it. Check in order: missing/erroring HTTPS, a conflicting signal (the five named rows below), a site-wide processing failure, or a genuinely new/uncrawled URL.
• The seven rows: HTTP marked with canonical tag · HTTPS has invalid certificate · Sitemap points to HTTP · HTTPS has redirect (wrong-way HTTPS→HTTP) · HTTPS URL is roboted · HTTPS not evaluated (umbrella status — triage by cause, don’t assume benign) · Other issues.
• Myth-bust: there is no “noindex” row, no “HSTS” row, and no “mixed content” row in the current Help page — related concepts, not report categories.
• Three related surfaces: the HTTPS report (sampled protocol view), the Page indexing report (indexing status and chosen canonical), and URL Inspection (indexed vs. live state). They can share a root cause, but that’s a hypothesis to check per URL, not a guaranteed match.
• Ranking: HTTPS is a lightweight signal (introduced 2014) and part of page experience — but the report itself shows no ranking, click, or traffic data at all. Fix for trust and clean canonicalization, not a ranking boost.
• Fix loop: identify the specific cause → repair it at the source (don’t just remove links) → confirm with URL Inspection’s live test and indexed state separately → watch the sampled cohort trend toward 100% HTTPS, without a promised deadline.

Official documentation

Primary-source documentation from Google.

Google

• HTTPS report — Search Console Help — what the report shows, the error rows, and the “HTTPS not evaluated” sub-causes.
• The new HTTPS report in Search Console (Sep 2022) — the announcement when the report launched.
• HTTPS as a ranking signal (Aug 2014) — the original ranking-signal announcement.
• Indexing HTTPS pages by default (Dec 2015) — background on Google’s default HTTPS indexing.
• URL Canonicalization — how HTTPS preference fits among Google’s canonical signals.
• Consolidate duplicate URLs (rel=canonical) — declaring the HTTPS URL as canonical.
• Understanding page experience — where HTTPS sits in page experience.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what the report shows

• “The HTTPS report shows how many indexed URLs on your site are HTTP vs HTTPS.” — Search Console Help. Jump to quote
• “The report isn’t a comprehensive list of all detected items.” — Search Console Help. Jump to quote
• “If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version.” — Search Console Help. Jump to quote

Google — the error rows

• “The HTTP page has a <link rel="canonical"> tag, indicating that the HTTP version is canonical.” — Search Console Help. Jump to quote
• “The HTTPS URL has an invalid SSL certificate.” — Search Console Help. Jump to quote
• “A sitemap on your site is pointing to an HTTP URL that was indexed as canonical.” — Search Console Help. Jump to quote
• “The HTTPS URL exists, but redirects to an HTTP URL.” — Search Console Help. Jump to quote
• “The HTTPS URL is present, but is blocked from crawling by a robots.txt rule.” — Search Console Help. Jump to quote
• “Another error occurred that is not covered in the list of errors.” — Search Console Help. Jump to quote

Google — HTTPS as a ranking signal (Aug 2014)

• HTTPS is a “very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” — Zineb Ait Bahajji & Gary Illyes, Google Webmaster Central Blog, 2014. Read the announcement

The error rows — cheat sheet

What each row means and the fix. (Remember: the report covers a sample of indexed URLs. An HTTP row can mean a conflicting signal beat Google’s HTTPS-preference default — but it can also mean a missing HTTPS equivalent, a site-wide processing error, or a URL that’s simply new and unevaluated. Check the specific row.)

Not in this report (common myth): there is no “noindex” row, no “HSTS” row, and no “mixed content” row in the current Help page. They’re related concepts, not categories here.

Fast facts

• Scope: indexed URLs only, and a sample — not a full inventory.
• Availability: Domain and HTTPS URL-prefix properties.
• Default: Google prefers to index the HTTPS version when both exist — but an HTTP row isn’t automatically “a signal beat HTTPS”; check whether HTTPS is missing, evaluation stalled, or the URL is just new.
• Right redirect direction: HTTP → HTTPS (never HTTPS → HTTP).
• Ranking weight: lightweight, reported as under 1% of queries (2014) — and the report itself shows no ranking data at all.

HTTP-row triage checklist

When a URL shows as HTTP, walk this list to find the conflicting signal:

• Canonical tag — does the HTTP page’s rel="canonical" point at HTTP? Repoint it at the HTTPS URL.
• Sitemap — does any sitemap list the HTTP version? Replace with HTTPS URLs.
• Redirects — does the HTTPS URL redirect back to HTTP? Reverse it so HTTP → HTTPS.
• robots.txt — is the HTTPS URL blocked from crawling? Unblock it.
• SSL certificate — is the cert valid for the whole site? Google won’t test HTTPS until it is.
• Mixed content — does the HTTPS page load HTTP assets (insecure dependencies)? Switch them to HTTPS.
• “HTTPS not evaluated”? — don’t default to “it’s fine.” Check which cause applies: missing HTTPS, HTTP chosen as canonical, a site-wide error, or (the one low-stakes case) a genuinely new/uncrawled URL.
• Recheck — run URL Inspection, request indexing, and wait for re-evaluation.
• Cross-check — compare against the Page Indexing report’s canonical decision for the same URL.

The mental models

1. HTTPS preference is the default — but an HTTP row has more than one possible cause. Google prefers to index the HTTPS version of any page that exists on both protocols. When a URL shows as HTTP, ask in order: is HTTPS missing or erroring? Is something explicitly voting for HTTP (the named reason rows)? Did Google back off after site-wide errors? Or is this just a new URL Google hasn’t gotten to yet?

2. Every row maps to one conflicting signal. Canonical tag · sitemap entry · redirect direction · robots rule · certificate. Find the one that applies, flip it to HTTPS, done. That’s the whole repair loop.

3. “Not evaluated” needs triage, not a default assumption. This umbrella status covers real problems (missing HTTPS, an HTTP canonical choice, a site-wide error) alongside one genuinely low-stakes case (a new URL Google hasn’t crawled yet). Identify which one you’re looking at before deciding whether to fix something or wait.

4. This report, Page Indexing, and URL Inspection are related but not interchangeable. HTTPS-vs-HTTP is one signal among the many Google weighs for canonical selection. The HTTPS report, the Page Indexing report, and URL Inspection can share a root cause, but treat that as a hypothesis to confirm per URL — not a guaranteed one-to-one mapping.

5. Fix HTTPS for trust, not rankings. It’s a lightweight ranking signal and part of page experience. The real payoffs are security, user trust, clean referral data, and unambiguous canonicalization.

Prove an HTTPS fix took effect

Confirm the redirect and certificate

Test to run — Request the HTTP URL and follow its redirect chain with curl -I or a browser network panel, then load the final HTTPS URL. Expected result — HTTP redirects directly toward HTTPS, the final response is successful, and the browser reports a valid certificate. Failure interpretation — a wrong-way redirect, redirect loop, or certificate problem still prevents a clean HTTPS destination. Monitoring window — Immediate. Rollback trigger — Revert the redirect change if it loops, lands on HTTP, or makes the production URL unavailable.

Confirm every canonical signal agrees

Test to run — Inspect the live HTTPS page and its sitemap entry, then check the URL in Search Console URL Inspection. Expected result — the page’s canonical points to HTTPS, the sitemap lists HTTPS, and the inspected URL exposes the intended HTTPS canonical without a robots block. Failure interpretation — at least one site-level signal is still voting for HTTP or preventing Google from evaluating HTTPS. Monitoring window — Site signals are immediate; Google’s selected canonical may require a recrawl. Rollback trigger — Stop rollout if the change points canonicals at the wrong URL set or removes intended pages from the sitemap.

Confirm the page has no insecure dependencies

Test to run — Load the HTTPS page with the browser Console and Network panels open, then crawl a representative template set for http:// resources. Expected result — no active mixed-content errors and no required asset is requested over HTTP. Failure interpretation — templates, asset hosts, or stored content still emit insecure dependencies. Monitoring window — Immediate after deploy. Rollback trigger — Roll back if HTTPS conversion breaks required scripts, styles, images, or checkout flows.

Confirm Search Console reclassifies the URL

Test to run — After recrawling, recheck URL Inspection and the HTTPS report row for the affected cohort. Expected result — Google sees the HTTPS version and the HTTP error cohort declines without a corresponding loss of intended indexed pages. Failure interpretation — Google has not recrawled yet or another conflicting signal remains. Monitoring window — Wait for Google to recrawl and refresh the sampled report; do not treat an immediate “not evaluated” state as failure. Rollback trigger — Investigate or reverse the change if intended indexed URLs fall while HTTPS errors persist.

Tools for working the HTTPS report

• Google Search Console — HTTPS report — the report itself: the HTTPS-vs-HTTP count and the “why HTTP isn’t served over HTTPS” rows.
• URL Inspection (GSC) — check how a single URL was crawled, rendered, and indexed, see its chosen canonical, and request a recrawl after a fix.
• Page Indexing report (GSC) — the sibling report; confirms whether a URL is indexed and which canonical Google chose.
• Browser DevTools — the Security/Console panels flag mixed content and certificate problems directly.
• Site audit crawlers — Ahrefs Site Audit and Screaming Frog SEO Spider surface HTTP-pointing canonicals, wrong-way redirects, HTTP sitemap entries, robots blocks, and mixed content at scale.
• Ahrefs Webmaster Tools — free crawl + audit for sites you verify.

Resources worth your time

My speaking

• Better Safe Than Sorry with HTTPS (SMX East 2016, SlideShare) — my talk on HTTPS migration, the long version of the “make every signal agree” lesson.

My related writing

• Google Uses ~40 Canonicalization Signals — where HTTPS preference sits among the canonical signals.
• 11 Types Of Redirects & Their SEO Impact — why the redirect direction is always HTTP → HTTPS.
• Ahrefs technical-SEO study (1M+ domains) — real data on sites redirecting the wrong way and other protocol issues.
• Website Migration: The Definitive Guide — for the HTTP→HTTPS migration audience.

From others

• HTTPS report — Search Console Help — the primary source.
• Google launches new HTTPS report in Search Console — Barry Schwartz’s launch coverage at Search Engine Land.
• Confusion over Google Search Console HTTPS is Invalid — Search Engine Roundtable documenting real-world community confusion around the “HTTPS is invalid” status.
• Why HTTPS Matters — web.dev primer on why HTTPS is important for security, trust, and performance, beyond SEO.
• Fixing mixed content — web.dev guide for tracking down and resolving HTTP assets on HTTPS pages (the “insecure dependencies” issue that can undermine HTTPS canonical selection).
• HTTPS as a ranking signal (Aug 2014) — the original Google announcement framing HTTPS as a lightweight signal.
• r/TechSEO — the community for “HTTPS is invalid / not evaluated” debugging.

Test yourself: the HTTPS report

Five quick questions on reading and fixing Search Console’s HTTPS report. Pick an answer for each, then check.

HTTPS report

A Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory.

Related: Google Search Console, Index Coverage Report

HTTPS report

The HTTPS report in Google Search Console shows how many of a site’s indexed URLs Google is serving over HTTPS versus HTTP. For the HTTP ones, it tells you why the secure version isn’t being used as the indexed/canonical page — invalid SSL certificates, canonical tags pointing at HTTP, sitemaps listing HTTP URLs, HTTPS URLs that redirect back to HTTP, or HTTPS URLs blocked by robots.txt.

It’s important to know what the report isn’t: it’s scoped to indexed URLs only, and it shows a sample, not a comprehensive list of everything on your site. An HTTP row doesn’t automatically mean a conflicting signal overrode Google’s default — it can also mean a missing HTTPS equivalent, a site-wide processing failure, or a genuinely new/uncrawled URL still waiting on evaluation.

Because Google prefers to index the HTTPS version of any page that exists on both protocols, a healthy site should trend toward 100% HTTPS in this report over time. It’s a related but separate surface from the Page Indexing report and URL Inspection — they can share a root cause, but that’s a hypothesis to verify per URL, not a guaranteed match. It’s available for Domain properties and HTTPS URL-prefix properties.

Related: Google Search Console, Index Coverage Report

Changelog