HTTPS Report

What the Google Search Console HTTPS report shows, every error row decoded with a fix, and the honest take on HTTPS as a ranking signal — from Patrick Stox.

First published: Jun 23, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #17 in Search Engine Tools#20 in Tools#285 in Technical SEO#381 on the site
AIAuthored byAI v2

The Search Console HTTPS report shows how many of your indexed URLs Google serves over HTTPS vs HTTP — and, for the HTTP ones, why. It's a sample of indexed URLs, not a full inventory. Google prefers the HTTPS version when a page exists on both protocols, so an HTTP row can mean a conflicting signal (an HTTP canonical, an HTTP-pointing sitemap, an HTTPS→HTTP redirect, robots-blocked HTTPS, or a broken cert), a missing HTTPS equivalent, a site-wide processing error, or a URL that's simply new and not yet evaluated — check which one applies before treating it as broken. HTTPS is a lightweight ranking signal — fix these for trust, referral data, and clean canonicalization, not for a ranking boost.

TL;DR — The HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' report shows how many of your indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs Google serves over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' 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 selectionHow search engines pick one canonical URL among duplicates and consolidate signals onto it.; this report, the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., and URL Inspection are related but not interchangeable. HTTPS is a lightweight ranking signal — fix these for trust and clean canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it., not for a ranking lift.

Evidence for this claim Search Console's HTTPS report shows the proportion of indexed HTTP and HTTPS URLs and reasons an indexed URL is not served over HTTPS. Scope: Current Search Console HTTPS report. Confidence: high · Verified: Google Search Console: HTTPS report Evidence for this claim The HTTPS report evaluates indexed URL serving and does not replace HTTPS migration, redirect, canonical, certificate, or mixed-content diagnostics. Scope: Current report interpretation and HTTPS guidance. Confidence: high · Verified: Google Search Central: Secure your site with HTTPS

What the report actually measures

Straight from the docs: “The HTTPS reportA 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. 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 ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. matches each HTTP URL to its HTTPS counterpart while ignoring parameters — so query stringsThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. like ?utm_source= don’t break the match. It does not, however, treat an HTTPS URL with a different URL structureURL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly. 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 tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content., a sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. entry, a wrong-way redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., 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 tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. — “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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. by a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. 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 “noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed.” row or an “HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.” 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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. surfaces can all be relevant to the same URL, and each tells you something distinct:

SurfaceWhat it tells you
HTTPS reportWhether a sampled indexed URL is served on HTTP or HTTPS, and (for HTTP rows) which named reason applies
Page indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason.Whether a known URL is indexed at all, and which canonical Google picked
URL InspectionThe indexed state Google has for a specific URL versus a live test of that URL right now

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 IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — 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 contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. — 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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.), 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.

TIP Catch a redirect that sends HTTPS users back to HTTP

An HTTPS source is not secure end-to-end when its final destination is HTTP. Fix the redirect before waiting for Search Console to reclassify the URL.

Trace the live chain with my free Redirect Checker Free

  1. Test the HTTP and HTTPS variants of representative affected URLs.
  2. Point each source directly to the intended final HTTPS destination and align canonical/internal signals.
  3. Rerun the trace, check mixed content, and then wait for the HTTPS report to update.
The chain begins securely but ends insecurely, which is the state Search Console needs you to remove.

The result labels the redirect broken and fix now. It shows one 301 from https example.com secure to a 200 response at http example.com final, and says the chain downgrades HTTPS to HTTP.

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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.