Insufficient HTTPS coverage on your site

Does anyone know why Google Search Console is reporting ‘Insufficient HTTPS coverage on your site’ when my site is fully HTTPS? The site in question is https://www.fixfire.co.uk/


Here is my site Read-Only: https://preview.webflow.com/preview/fixfire?utm_medium=preview_link&utm_source=dashboard&utm_content=fixfire&preview=b6547784705bd452281a3b6e326f4fd0&mode=preview
(how to share your site Read-Only link)

1 Like

Hi Neil. I also have been looking for answers. I’ve seen a few people asking about this today.

It seems from the response below, SNI support is no longer acceptable. We need to use DNSSEC and ESNI perhaps. The post mentions privacy concerns with SNI.

I have responded to a post here Insufficient HTTPS coverage on your site (Page Experience) - Google Search Central Community asking for confirmation.

1 Like

Hi James, thanks for the reply. A bit over my head with regards to ‘SNI support’ etc. I may contact Webflow directly to get their input regarding hosting and if this affects it.

Aside from this, I’ve spotted the following URLS below - it appears these are generated when I create any SVG file and place intoa WF site:
175563750_10101906892369527_738828833751765952_n

I’m going to wait for Google to respond. I believe it may be possible that they have this warning due to the points I mentioned and they will either confirm the support I mentioned is needed or they will change something from their side to halt these warnings.

It seems they have not published my response yet.

The thread starts with this image, and then a response discussing SNI and SSL LABS grading for HTTPS.

My Response to the thread I linked previously (awaiting publish and reply).

I’ve seen a few posts about this now across different discussion platforms, all in the last few days.

It seems I am not the only one who has noticed this recently.

Thank you Brian for your responses.

I have an A+ rating , https://www.01systems.co.uk/ but also use SNI on some sites and have the same issue described in the post.

Are we to understand that we should no longer be using SNI to serve multiple domains off one IP?

I’m guessing from your response this is the case. Any ideas on when this came into effect? Thank you

=== Is this the Correct Answer? ===

It seems then from my assumptions SNI support is no longer acceptable.

We need to use DNSSEC and ESNI perhaps. The post mentions privacy concerns with SNI. The cloudflare page mentions DNSSEC and ESNI.

I’m guessing thats what we need to support now.

Someone has responded on that thread - no answers yet, but its being looked into.


Hi all,

We are aware of this issue in the reports, product experts have escalated it and it’s being looked into.

It doesn’t seem to be SNI based, I have plenty of properties that use SNI, but don’t have this issue.

You might want to follow this thread: Insufficient HTTPS coverage on your site, Page experience report. - Google Search Central Community (click the subscribe button when you get there!)

We will add an update there if / when we hear any news.

Thanks

SNI is used by millions of sites where the server IP is shared. If Google penalized sites for using a standard, then a vast majority of websites would be penalized. There is no conceivable way this could be the case IMHO. This issue is that there is no “FIX” for this currently. With SNI there is a privacy problem, namely it leaks information about the site being visited because that was not encrypted as part of the handshake.

If you wish to understand the problem I recommend reading → Encrypting SNI: Fixing One of the Core Internet Bugs (cloudflare.com)

The solution of ESNI is not going to happen for various reasons and Firefox was the only browser provider that supported it. Instead, Encrypted Client Hello (ECH) has been proposed.

You can read about it here → Good-bye ESNI, hello ECH! (cloudflare.com)

This feature represents a significant upgrade to the TLS protocol, one that builds on bleeding edge technologies, like DNS-over-HTTPS, that are only now coming into their own. As such, the protocol is not yet ready for Internet-scale deployment.

So the current state of affairs shows why this should be a non-issue. I suspect that “Insufficient HTTPS coverage on your site (Page Experience)” is actually a reporting error in the the Google product. We will see soon as lots of people are freaking out. The threads already shared in posts above can be monitored for a response by the Google team responsible.

Is there anything you can do right now? No actionable items at this time. If your site actually took a hit in the SERPS, so did your competition. So sit back and enjoy your favorite beverage.

1 Like

Thank you Jeff, great info there :grinning:
I also expect this to be resolved by their side.

Reply from Search Advocate at Google on Twitter:

Unfortunately there’s a bug there in Search Console. When we we show “Failing / Insufficient HTTPS coverage” in the Page experience report, that can just mean we don’t have the full data (instead of saying “not enough data” we incorrectly say “failing”). We’re fixing it.

Facing the issue and I want to know if the problem has been resolved. Surprisingly the same issue appears on google sites

Can anyone help as to how we can resolve this issue. Just publish a google site and not yet indexed and having the same issue of Insufficient HTTPS coverage on your site which happens to be a google site