Search Console HTTPS Report: Why Aren't Your Pages Served Over HTTPS?

In short, this report tells you whether your HTTPS migration is truly finished from Google's point of view. A padlock in your browser is not enough. Google may still treat the old HTTP version of some pages as the main address. At Talha Aslan and team, we open this report early in every technical audit.

Google's official HTTPS report help page also describes the ideal state clearly: the report should list no HTTP URLs at all. So your goal is to push the HTTP count as close to zero as you can.

Where do you find the HTTPS report, and which properties support it?

You open the report from the All reports and tools section in Search Console. However, it does not appear for every property type. According to Google, the HTTPS report works only for Domain properties and for URL-prefix properties that start with HTTPS.

This detail matters in practice. For example, if you created an HTTP URL-prefix property for http://example.com years ago, you will not find the report there. In that case, we recommend adding a Domain property. Then you see HTTP, HTTPS, www and non-www versions on one screen.

• Domain property: the report is available and covers all protocol and subdomain versions.
• HTTPS URL-prefix property: the report is available and covers only that prefix.
• HTTP URL-prefix property: the report does not appear.

If you are new to Search Console, start with our guide to Google Search Console. Until property verification is complete, you should not rely on the data in this report.

What do the numbers in the HTTPS report actually tell you?

The report shows two main counts: indexed HTTPS URLs and indexed HTTP URLs. Then it groups the HTTP URLs by issue. So at first glance you read the ratio, and at second glance you read the error breakdown.

Keep one point in mind, though. Google states that the report shows a sample, not a complete list of every URL. Therefore 40 URLs in the list does not mean the problem affects only 40 pages. Read the report as a map of symptoms. Then look for the root cause in your server setup, your CMS settings or your templates.

In practice, it helps to split the listed URLs by page type. For instance, if blog posts, product pages and category pages come from separate templates, you quickly see where the issue clusters. That way you fix it in one place and watch the effect across the whole group.

Also note how the comparison works. For each HTTP URL, the report looks for the exact same path on HTTPS and ignores parameters. On the other hand, it does not consider an alternate HTTPS version with a different URL structure. For example, if you moved http://example.com/product?id=5 to https://example.com/products/5, the report will not link the two.

Why are your pages not served over HTTPS?

Google's help page sorts the causes into named issue groups. Below are the groups you will meet most often, with the names Google uses:

1. HTTP marked with canonical tag.
2. HTTPS has invalid certificate.
3. Sitemap points to HTTP.
4. HTTPS has redirect.
5. Blocked by robots.txt: HTTPS URL is roboted.
6. HTTPS not evaluated.
7. Other issues.

Most of these groups come from a single template or server rule. For example, one wrong canonical setting can affect thousands of pages at once. That is why we suggest finding the shared cause first instead of fixing the list page by page. The next sections cover each cause separately.

What does "HTTP marked with canonical tag" mean?

This issue means your HTTP page declares itself canonical through a rel="canonical" tag. In other words, even if the page loads over HTTPS, the tag tells Google "my main address is HTTP." Google may then follow that signal and keep the HTTP version in its index.

You often see this on older themes and hand coded templates. For example, if the template builds the canonical URL with a fixed "http://" prefix, the tag keeps printing the old protocol after the migration. Likewise, if the site address in your CMS settings still says HTTP, plugins also generate the wrong canonical.

The fix is to declare the HTTPS version as canonical. For missing HTTPS cases, Google also names explicit HTTPS canonical marking as the recommended solution. We explain the basics in our canonical tag guide. In addition, our post on detecting canonical issues in Search Console shows how to find inconsistencies in bulk.

How do you fix the invalid certificate issue?

This issue means the HTTPS URL has an invalid SSL certificate. According to Google, a certificate problem usually affects the whole site rather than one page. So if you see this issue, check the certificate itself first.

Here are the causes we run into most often:

• The certificate expired and automatic renewal failed.
• The certificate covers the www version but not the non-www version, or the reverse.
• The intermediate certificate chain is incomplete, so some clients reject the connection.
• You moved the domain to a new server, and the old certificate stayed behind.

To fix it, renew the certificate and make sure it covers every hostname you use. Then open the site in a few browsers and devices. We cover the basics in our post on what an SSL certificate is. If your hosting company manages the certificate, review the renewal settings with them.

What should you do if your sitemap points to HTTP?

This issue means your sitemap lists an HTTP URL, and Google indexed that HTTP URL as canonical. Google notes that this issue appears only if it crawled and indexed the HTTP URL successfully. So your sitemap is still recommending the old address to Google.

The fix is simple: update your sitemaps to list the HTTPS versions. However, the problem often hides in an old sitemap file someone added by hand. For example, a site may serve both a dynamic sitemap from a plugin and a static file uploaded years ago.

Google's site move guide also recommends creating a sitemap with the new HTTPS URLs and submitting it in Search Console. After that, you can remove the old sitemap. If Search Console cannot read your sitemap at all, see our post on the sitemap couldn't fetch error.

Where is the problem when HTTPS redirects to HTTP?

This issue means the HTTPS URL exists but redirects visitors to an HTTP URL. Google's advice is clear: remove the redirect, or redirect to an HTTPS page instead. Otherwise Google cannot choose the secure version as the main address.

So where does this reverse redirect come from? Usually it comes from an old server rule, a CDN setting or the site address field in the CMS. For example, if the server sends HTTP to HTTPS while the CMS sends every request back to HTTP, you get a loop. We cover that loop in our too many redirects guide.

Therefore you need to check every layer one by one: server rules, CDN settings, the CMS site address and the redirect list in your plugins. Then trace every redirect hop with your browser's developer tools. The final address must use HTTPS, and no HTTP hop should appear in between.

Could robots.txt be blocking your HTTPS URLs?

Yes, and the report lists this as a separate issue group. If a robots.txt rule blocks crawling of the HTTPS URL, Google cannot read the secure version. As a result, it keeps the HTTP page, the only readable version, in its index.

This usually happens in one of two ways. First, the HTTP and HTTPS versions serve different robots.txt files; for example, a "block everything" rule from development stayed on the HTTPS side. Second, a rule that blocks a folder starts to cover the new URL structure after the migration.

To fix it, open the robots.txt file on both protocols and compare them. Then correct the blocking rule. We list common mistakes in our post on robots.txt mistakes. After you change the rule, confirm in the robots.txt report in Search Console that Google reads the current file.

How do you resolve "HTTPS not evaluated"?

This group means Google could not evaluate the HTTPS version. Google's help page lists several possible causes. For example, no equivalent HTTPS URL exists, or it returns a 4XX error such as 404 or authentication required, or a 5XX server error. Or both versions exist, but Google picked the HTTP version as canonical.

Other causes are possible, too. Google may have hit so many errors that it stopped processing queued URLs. A site wide error such as a bad certificate may block evaluation. Or Google simply has not seen or crawled the URL yet.

Google suggests this order. If the report shows many other errors, fix those first, because that can unblock processing. For a recently crawled URL, wait a day and check again. If there are few other errors, look for site wide HTTPS problems, availability issues in the Crawl stats report and 404s in the Page indexing report. To find non indexed pages in bulk, use our guide on finding unindexed pages in Search Console.

Does mixed content affect the HTTPS report?

Mixed content happens when a page loaded over HTTPS pulls images, scripts or stylesheets over HTTP. The HTTPS report does not list mixed content as its own issue group. Still, it is one of the clearest signs that a migration is only half done.

According to web.dev's explanation of mixed content, browsers block some HTTP resources and load others with a warning. As a result, the page may look broken or lose its padlock. For visitors, that means a loss of trust.

Mixed content usually comes from old content URLs stored in the database. For example, images in blog posts written years ago still point to "http://" addresses. So fixing the template alone is not enough; you also need to update old URLs inside your content. Always back up the database before a bulk change.

The console tab in your browser's developer tools is a good place to start. When you open a page, it lists resources that load over HTTP as warnings. Then repeat the same check on a few pages from different templates. That way you can tell whether the issue lives in the template or in the content.

How should canonical tags and 301 redirects work together?

The strongest setup is one where every signal points to the same address. Google's guide on consolidating duplicate URLs explains that several signals feed into canonical selection. Redirects, canonical tags, sitemaps and internal links should all agree.

In practice, we recommend this setup:

• Every HTTP URL sends a permanent server side redirect (301 or 308) to the same path on HTTPS.
• Every HTTPS page lists its own HTTPS URL as canonical.
• The sitemap lists HTTPS URLs only.
• Internal links point straight to HTTPS URLs and skip redirects.

We explain the difference between redirect types in our post on 301, 302, 307 and 308 redirects. Also, if several redirects form a chain, reduce them to a single hop.

Which HTTPS report issue needs which fix?

The table below sums up the issue groups from Google's help page and the fixes Google suggests. Our team uses it as a starting map in technical audits.

The table also suggests an order. First, solve site wide issues such as the certificate and redirects. Next, move on to template issues such as canonical tags and sitemaps. Finally, look at individual URLs.

One more tip: log each fix with a date and a short note. Then, when the report changes, you can easily link the change to the step that caused it. Also, if several people work on the site, a log reduces the risk of changing the same setting twice.

What does a step by step HTTPS fix checklist look like?

When the report shows issues, we suggest following the order below. It closes the high impact problems first and cuts down on repeated work.

1. Confirm the certificate is valid and covers every hostname.
2. Test that the permanent HTTP to HTTPS redirect works in a single hop.
3. Check that HTTPS URLs never redirect back to HTTP.
4. Confirm the template outputs HTTPS canonical URLs.
5. Update the site address setting in your CMS to HTTPS.
6. Rebuild the sitemap with HTTPS URLs and submit it in Search Console.
7. Compare robots.txt on both protocols.
8. Update old HTTP resource URLs and internal links in your content.
9. Run a live test on a few sample URLs in the URL Inspection tool.
10. Monitor the report regularly for several weeks.

If you follow this list in the same order on every migration, you catch most issues early. Still, every site runs on a different stack, so treat the list as a framework, not a guarantee.

How do you test a fix with the URL Inspection tool?

Google's help page recommends the URL Inspection tool for testing the canonical issue. In the report, you click the inspect icon next to the URL. Then you choose URL Inspection and run a Live test.

When the live test finishes, you open View tested page. There you search the HTML Google sees for the canonical tag. If the tag shows the HTTPS URL, Google has picked up your template fix.

In the same tool, you can also compare the Google selected canonical with the user declared canonical. If the two differ, one of your signals still conflicts. In that case, review internal links, the sitemap and redirects again. Since the help page does not describe a separate validation feature for this report, the live test is the most practical check.

What should you prepare before an HTTPS migration?

The easiest way to avoid issues in the report is to plan the migration from the start. Google's site move guide recommends verifying both the HTTP and HTTPS versions in Search Console. It also states that you do not need the Change of Address tool for an HTTP to HTTPS move.

During preparation, we suggest you answer these questions:

• Do you have a full list of the site's subdomains?
• Does the certificate cover all of them?
• Which layer will manage redirects: the CMS, the CDN or the server?
• Do templates output canonical tags and internal links with the correct HTTPS address?
• Have you listed old sitemaps, URLs in third party services and ad landing pages?

If you close this list in advance, you reduce the chance of surprises on launch day. Moreover, the HTTPS report becomes much easier to read afterward, because any remaining issues point to true exceptions.

What happens if HTTP and HTTPS both stay live?

If both versions return a 200 response, Google sees two copies of the same content. According to Google, when a page exists on both protocols, Google prefers to index the HTTPS version. However, that preference holds only while other signals do not conflict.

For example, if the HTTP version carries its own canonical tag, internal links point to HTTP and the sitemap lists HTTP, Google may pick HTTP. In that case you see URLs under "HTTPS not evaluated." Google's help page names this cause directly: both versions exist, but Google chose HTTP as canonical.

So do not leave both versions running side by side for long. Turn on the permanent redirect on launch day. Then Google has only one readable version, and all signals merge on one address. Your visitors also always reach a secure connection.

How do internal and external links affect the HTTPS report?

Internal links are a key part of how Google discovers your pages. If menu, footer or in content links point to HTTP, Google first hits the HTTP address on every crawl. Even when the redirect works, this adds an extra hop and sends a weak but conflicting canonical signal.

That is why we recommend changing internal links to point straight to HTTPS. Pay special attention to these areas:

• Main menu and footer links.
• In content links in older blog posts.
• Product descriptions and category copy.
• URLs inside structured data.

You cannot change old links on external sites one by one. Still, updating links from key partners and your own social profiles is easy. For the rest, the permanent redirect does the work, so keep it in place for a long time. We discuss this in our post on how long 301 redirects should stay.

How do you read the HTTPS report on multilingual sites?

On multilingual sites, language versions often live in separate folders or subdomains. So when you read the HTTPS report, first figure out which version has the problem. For example, if only URLs under en.example.com show up, the cause is most likely that subdomain's certificate or redirect rule.

Also check the URLs in your hreflang tags. If language versions point to each other with HTTP URLs, Google again gets a conflicting signal. In short, canonical tags, hreflang, sitemaps and internal links should all use the same protocol.

A Domain property helps a lot on these sites. You see all subdomains on one screen and quickly spot where the issue clusters. Then you can add a separate URL-prefix property for each subdomain for a closer look.

How often should you check the HTTPS report?

In the weeks right after a migration, we suggest checking the report often. During that period Google recrawls old and new URLs, so the report changes quickly. After that, a monthly check is enough for most sites.

That said, some events call for a fresh look. For example, a theme change, a server move, a new CDN, a new certificate provider or a new language version all qualify. After changes like these, open the report within a few days.

Also, do not read the HTTPS report in isolation. The Page indexing report, the Crawl stats report and the Sitemaps report together paint a clearer picture. Google also points to these reports for "HTTPS not evaluated" issues. In short, the HTTPS report should be a regular part of your technical SEO routine.

Why do some issues disappear on their own?

Google notes that some issues correct themselves over time. The reason is simple: Google may have crawled the HTTP page before the HTTPS page went live or before it crawled the HTTPS version. As a result, the report reflects the old state for a while.

So right after a new migration, do not rush to act on every row. Hasty changes can break a setting that works fine and make the picture messier. Instead, finish the structural checks first. Then give Google time to recrawl the site. Only if the same issue stays on the same URLs after a few weeks should you dig for a lasting cause.

Google adds one more warning. If it gets many 404 responses on the first HTTPS URLs it tries, it may stop crawling HTTPS pages. In that case the report may show issues such as "HTTPS crawling issue" and other issues. In short, leaving a migration half finished does far more harm than waiting.

Example scenario: why does the HTTP version stay indexed?

This section is an example scenario for teaching, not a real client case. A business moves example.com to HTTPS and adds a redirect rule on the server. However, a few weeks later it sees hundreds of HTTP URLs in the HTTPS report.

The review finds three shared causes. First, the theme builds canonical URLs with a fixed "http://" prefix. Second, an old static sitemap sits in the root folder, and Search Console still has that sitemap on file. Third, internal links in product categories still use HTTP in the database.

The fix order is clear, too. You correct the canonical template first, then remove the old sitemap and submit a new one. Finally, you update the internal links. Now redirects, canonical tags, the sitemap and internal links all point to the same HTTPS address. How fast the HTTP count drops depends on Google's crawl schedule, so promising a timeline would be wrong.

When should you hand HTTPS report issues to a specialist?

If the issue comes from a single template, you can often fix it yourself. However, when server, CDN and CMS layers tangle together, or when loops and conflicting canonical signals appear, working with a specialist saves time. On ecommerce and multilingual sites in particular, one wrong rule can affect thousands of pages.

As part of our SEO consulting, we at Talha Aslan and team review the HTTPS report, redirect setup, canonical signals and sitemaps together. We fix this issue on your site and then track it in Search Console. We do not guarantee rankings, but we clear technical blockers at the source and report progress openly.

If your HTTPS report shows issues you cannot resolve, you can request a quote on our SEO consulting page. A short intake form is all it takes; our team defines the scope for your site and gets back to you.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.