HTTPS report: complete guide

Find indexed HTTP URLs and understand why matching HTTPS URLs were not selected.

GSC UI required Intermediate

Search Console's HTTPS report shows how many indexed URLs in the property use HTTP or HTTPS and explains why Google could not index the matching HTTPS version for sampled HTTP URLs. Its purpose is to reveal conflicts that leave insecure URLs in Google's index.

It is not a comprehensive URL inventory, TLS configuration audit, certificate-expiry monitor, mixed-content scanner, or migration validator. Use it to identify Google indexing patterns, then validate the implementation with URL Inspection, a crawler, browser and certificate tooling, and server evidence.

This guide reflects Google's documentation on July 18, 2026.

Report availability and scope

The HTTPS report is available only for:

Domain properties;
HTTPS URL-prefix properties.

It is not available in an HTTP URL-prefix property. A Domain property is usually the clearest choice for an HTTP-to-HTTPS migration because it covers both protocols and relevant subdomains.

The report counts indexed HTTP and HTTPS URLs. It does not count every URL Google discovered, every URL in a sitemap, or every page in the CMS. Google explicitly describes the displayed items as a sample.

This distinction matters:

an HTTP URL absent from the report might not be indexed;
a URL in the report is not necessarily a page the business still intends to keep;
the visible examples do not define the full affected set;
a clean chart does not certify all TLS and browser-security behavior.

How Google tests an HTTP URL

For each indexed HTTP URL, Search Console looks for a matching HTTPS URL while ignoring parameters. It tests the HTTPS form of the same URL structure.

For example, the natural match for:

http://example.com/products/shoes?color=blue

is based on:

https://example.com/products/shoes

The report does not treat a differently structured secure URL as the direct alternate. If HTTP /old-product redirects to HTTPS /catalog/new-product, that can be a valid migration mapping, but the HTTPS report's same-structure comparison may not describe the whole relationship. Use redirect, canonical, and indexed evidence to evaluate such mappings.

The desired end state

For a site intended to be fully secure:

public pages load successfully over HTTPS;
HTTP requests permanently redirect to the equivalent preferred HTTPS URL;
HTTPS pages declare HTTPS canonicals;
internal links, sitemaps, hreflang, and structured references use HTTPS;
HTTPS is crawlable and returns equivalent content;
certificates are valid for every served host;
secure pages do not rely on insecure active resources;
Google selects HTTPS canonicals and the report trends toward no indexed HTTP URLs.

Google prefers HTTPS over equivalent HTTP by default, but conflicting or broken signals can make HTTP the stronger choice.

Why an HTTP URL can remain indexed

An HTTP URL can persist when the secure alternative is missing, unavailable, inconsistent, or contradicted by site signals.

Common causes include:

no matching HTTPS page;
4xx, authentication, or 5xx responses on HTTPS;
an invalid or wrong-host certificate;
HTTPS redirecting to HTTP or through an HTTP hop;
HTTP or HTTPS declaring the HTTP URL as canonical;
sitemaps or hreflang continuing to list HTTP;
internal links predominantly pointing to HTTP;
the HTTPS URL blocked by robots.txt;
materially different content on HTTP and HTTPS;
insecure dependencies on the HTTPS page;
Google not yet crawling or evaluating the secure version;
widespread HTTPS errors causing Google to stop processing queued URLs.

Do not solve this by temporarily removing HTTP URLs in Search Console. Removals are not a canonicalization method and can hide all matching versions. Correct the migration signals and accessibility.

Read each HTTPS error correctly

HTTP marked with canonical tag

The HTTP page declares HTTP as canonical. This can come from a hard-coded base URL, environment setting, proxy misconfiguration, template cache, or a canonical derived from the incoming request.

Check both versions in URL Inspection and inspect the live HTML or response header. The preferred HTTPS page should normally self-canonicalize, and equivalent HTTP should permanently redirect to it.

HTTPS has invalid certificate

Google found a certificate problem on the HTTPS URL. A failure often affects a host or group of hosts rather than one template.

Validate:

certificate hostname coverage;
validity period and renewal;
complete certificate chain;
certificate served by each CDN, load balancer, edge, origin, and IPv4/IPv6 path;
redirects to hosts covered by a valid certificate.

Do not bypass certificate validation or fall back to HTTP. Correct the certificate and serving configuration.

Sitemap points to HTTP

Google indexed an HTTP URL listed in a sitemap. Sitemaps should contain the fully qualified preferred canonical HTTPS URLs.

Update sitemap generators, sitemap indexes, child sitemaps, and references in robots.txt or submission workflows. Resubmit or allow Google to refetch the corrected sitemap. A sitemap is a canonical hint, not a replacement for redirects and consistent page signals.

HTTPS has redirect

The HTTPS URL redirects to HTTP. This reverses the secure migration and strongly tells Google that HTTP is preferred.

Change the destination to the final HTTPS URL. Avoid chains such as HTTPS → HTTP → HTTPS; redirect directly to the final secure destination.

HTTPS URL is roboted

Google cannot crawl the HTTPS alternative because robots.txt blocks it. Protocol and host changes can expose different robots behavior through infrastructure, routing, or environment configuration.

Fetch the correct robots.txt for the HTTPS host and test the affected path. Allow crawling when the page should be indexed. A robots block also prevents Google from seeing page-level canonical and noindex directives.

HTTPS not evaluated

This is a state with several possible causes, not one root cause:

no matching HTTPS URL;
HTTPS returns 4xx, authentication, or 5xx;
both versions exist but Google selected HTTP as canonical;
Google stopped processing queued URLs after many HTTPS errors;
a sitewide problem such as an invalid certificate prevents evaluation;
Google has not seen, crawled, or processed a newer URL yet.

Fix specific HTTPS errors first. They can unblock the queued URLs labeled not evaluated. For a newly crawled URL, Google's documentation recommends allowing time and checking again; it says a day can be enough for some transient evaluation states.

If the status remains widespread, check certificate health, Crawl Stats availability, HTTPS response codes, Page Indexing errors, canonical selection, and whether Google can fetch representative URLs.

Other issues

This means the failure did not fit a named category. Build evidence at URL, host, and template level instead of guessing. Compare a working and failing HTTPS URL through DNS, TLS, redirect, response, robots, render, canonical, and indexing checks.

Distinguish transient processing from an implementation defect

Some report states can self-correct after Google recrawls. A recent migration might show HTTP indexed before the new HTTPS page is processed.

Wait only when current evidence is healthy:

HTTPS returns a stable 200 with valid TLS;
HTTP permanently redirects to the correct HTTPS URL;
canonical and sitemap signals use HTTPS;
robots allows crawling;
content is equivalent;
Google has not yet processed the change.

Do not wait out invalid certificates, HTTPS-to-HTTP redirects, 5xx responses, broad robots blocks, or contradictory canonicals. Those are current defects.

Build an HTTPS evidence matrix

For representative URLs, record:

Check	HTTP evidence	HTTPS evidence	Expected
Response	Permanent redirect	`200`	Direct HTTP → HTTPS mapping
Final URL	Preferred HTTPS	Preferred HTTPS	No HTTP hop or loop
Certificate	Not applicable	Valid for host	Trusted and renewable
Robots	Redirected or accessible	Crawl allowed	Google can fetch HTTPS
Canonical	HTTPS target	Self-referential HTTPS	One consistent preferred URL
Sitemap	Excluded	Included	HTTPS only
Internal links	No controlled HTTP links	Preferred destinations	HTTPS links
`hreflang`	No HTTP annotations	HTTPS reciprocal set	HTTPS URLs
Content	Redirect only	Complete equivalent page	No protocol-based mismatch
Google canonical	Transitioning or duplicate	Selected HTTPS	HTTPS indexed

Sample:

homepage and key hubs;
every hostname and subdomain;
each application or CMS;
static files and non-HTML documents;
important directories and templates;
URLs behind CDN, load-balancer, or regional routes;
examples from every report error;
a few newly published pages.

Implement the migration coherently

1. Make HTTPS production-ready

Serve the same intended content and functionality over HTTPS before redirecting users. Test certificate coverage, third-party services, APIs, forms, downloads, assets, cookies, authentication, webhooks, and redirects.

2. Map HTTP to HTTPS

Use permanent server-side redirects from each HTTP URL to its equivalent final HTTPS URL. Preserve useful paths and necessary parameters. Avoid sending every old URL to the homepage and avoid chains.

Google treats permanent redirects as a strong canonical signal. It documents no PageRank loss from correctly implemented permanent redirects.

3. Align canonical signals

Use self-referential HTTPS canonicals on preferred pages. Update:

XML sitemaps;
internal navigation and contextual links;
hreflang annotations;
structured-data URLs;
feeds, media URLs, manifests, and API-generated references;
campaign and canonical configuration.

Signals can reinforce one another. Conflicting canonical techniques make migration slower and less predictable.

4. Keep both properties observable

Use a Domain property or verify relevant HTTP and HTTPS URL-prefix properties. Monitor the old and new protocol views, indexing, sitemaps, Crawl Stats, and Performance during migration.

Moving only from HTTP to HTTPS is a URL change but does not use Search Console's Change of Address tool, which is for certain domain or subdomain moves.

5. Add HSTS only after HTTPS is dependable

HTTP Strict Transport Security instructs supporting browsers to use HTTPS. It strengthens user protection, but it can make certificate or host-coverage mistakes more disruptive.

Confirm HTTPS works across all intended hosts before choosing an HSTS lifetime or includeSubDomains. Maintain certificate renewal and rollback planning. HSTS does not override Google's strong preference for HTTP when HTTPS has a bad certificate or redirects back to HTTP.

Mixed content is outside the report's full scope

An HTTPS document can load images, scripts, stylesheets, frames, media, or other resources over HTTP. This is mixed content.

Insecure active resources can be blocked by browsers and can compromise the page; passive resources also weaken privacy and integrity. Google's canonical documentation lists insecure dependencies, other than images, among conflicts that can prevent HTTPS preference.

The HTTPS report is not a complete mixed-content inventory. Crawl rendered pages, inspect browser security and network output, and search templates, stylesheets, scripts, databases, and generated markup for insecure resource URLs. Upgrade resources to valid HTTPS endpoints rather than suppressing warnings.

What the report cannot prove

The HTTPS report cannot prove that:

every site URL uses HTTPS;
every certificate and host is configured correctly;
certificates will renew before expiry;
TLS protocol and cipher configuration meets an organization's standard;
pages contain no mixed content;
secure cookies, CSP, HSTS, and other security headers are correct;
forms, APIs, downloads, and third-party integrations are secure;
all users and Googlebot reach the same edge or origin;
the migration preserved traffic and functionality;
a sampled fix has propagated across the whole site.

Pair it with platform monitoring, certificate alerts, browser and security tests, crawls, logs, URL Inspection, and application QA.

Diagnose common patterns

A few HTTP URLs remain

Inspect each pattern. Legacy PDFs, old hostnames, isolated templates, HTTP sitemap entries, or stale canonical configuration often explain the tail.

Almost the whole site is HTTP

Confirm HTTPS exists at scale before focusing on individual rows. Google says widespread failed HTTPS probes can cause it to stop checking queued URLs, producing a small number of specific errors and many “Other issues” or not-evaluated states.

The browser is secure but Google keeps HTTP

Browser success proves only one current request path. Compare Google-selected canonical, page canonicals, redirect history, sitemaps, robots, content equivalence, certificate paths, and indexed timing.

Report counts changed without a release

The indexed set and Google's processing can change after recrawl. Check whether URLs entered or left the index, errors were reclassified, canonicals changed, or queued evaluations completed before attributing the movement to a site deployment.

Monitor the rollout

Track:

indexed HTTP and HTTPS counts;
error counts by reason and host;
Google-selected canonical on representative URLs;
HTTP redirect and HTTPS response health;
certificate expiration and renewal;
sitemap processing and HTTPS URL counts;
Crawl Stats availability and response codes;
Page Indexing reasons;
Googlebot requests to HTTP versus HTTPS;
Performance data in old and new URL-prefix properties where used;
browser mixed-content and security errors;
business conversion, authentication, checkout, and form behavior.

Annotate the migration and major fixes. Temporary ranking fluctuations can occur while Google recrawls and reindexes moved URLs; medium and large sites can take weeks or longer to transition broadly.

Automation boundary

The aggregate HTTPS report requires the Search Console UI and has no supported dedicated API. The URL Inspection API can return Google's indexed view for supplied URLs, but it does not run the live test or reproduce the aggregate HTTPS report.

Automation can:

crawl HTTP and HTTPS pairs;
validate status, redirect chain, final URL, canonical, robots, and sitemap membership;
monitor certificate validity and host coverage;
find controlled HTTP links and resources;
compare Google's selected canonical for sampled URLs;
alert on HTTPS-to-HTTP regressions.

SearchConsole.ai can inspect supplied URLs for indexed state, Google and user canonical, robots, and fetch evidence. It cannot retrieve the HTTPS report or certify TLS and browser security.

Ask SearchConsole.ai: Inspect these migrated HTTPS URLs. Group them by indexed status, Google-selected canonical, user-declared canonical, crawl permission, and fetch result. Flag any URL whose Google canonical is still HTTP.

Common mistakes

Treating the report as every URL on the site.
Looking for it in an HTTP URL-prefix property.
Assuming a differently structured HTTPS page is the report's direct match.
Waiting on invalid certificates, redirects to HTTP, or widespread server errors.
Redirecting every HTTP URL to the homepage.
Leaving HTTP URLs in canonicals, sitemaps, internal links, or hreflang.
Blocking HTTPS in robots.txt while expecting Google to process its signals.
Using Removals to force HTTPS canonical selection.
Assuming a browser padlock means Google selected HTTPS.
Ignoring mixed content and third-party resources.
Enabling broad HSTS before all subdomains support HTTPS.
Treating report improvement as a complete security audit.