Is it true that HTTPS is just a minor ranking signal, or has it become a must-have criterion?

What does “minor ranking signal” really mean?

Google categorizes this information as light ranking signals, similar to content freshness or certain aspects of mobile usability. This means that HTTPS alone does not significantly change the ranking of a page that would perform poorly on all other criteria.

A site with weak content, dubious backlinks, and a terrible user experience will not magically jump to page 1 just because it switches to HTTPS. The signal acts more like a tie-breaker among pages of comparable quality when all other factors are equal.

Why does Google consistently favor the HTTPS version?

The nuance is critical: even though its weight in the algorithm remains low, Google displays the secure version preferentially in its results as soon as it is detected and properly implemented. This logic aims to accelerate the web's transition to systematic encryption.

Chrome now marks HTTP sites as “not secure” in the address bar, which affects user trust and behavior well before the algorithm comes into play. A user who sees this message hesitates, goes back, or clicks elsewhere. The bounce rate increases, and organic click-through rates drop.

Does the type of SSL certificate really matter?

Mueller clarifies that the level of encryption is of little importance: whether it's a free Let's Encrypt certificate, DV, OV, or EV, Google makes no distinction. The engine simply checks that the certificate is valid and that the connection is encrypted.

This technical neutrality avoids discrimination between sites with different budgets. A personal blog with a free certificate is not penalized compared to a multinational with an EV. What matters is clean implementation, free from mixed content or broken redirects.

• HTTPS remains a light ranking signal, not a dominant criterion like content quality or backlinks
• Google consistently displays the secure version when it exists and functions properly
• The type of SSL certificate (free, paid, validation level) has no impact on rankings
• The indirect impact (user trust, click-through rates, browsing behavior) often weighs more heavily than the direct algorithmic signal
• A poorly executed HTTPS migration can cause a sharp traffic drop if redirects or mixed resources are not properly managed

Does this statement align with real-world observations?

Yes, and this is precisely what creates confusion for many practitioners. On paper, HTTPS has officially been a minor signal since its introduction. In the day-to-day reality of audits, we observe that HTTP sites are performing worse and worse.

This paradox can be explained by the cascading effect: Chrome's “not secure” labeling degrades perceived user experience, which deteriorates behavioral metrics (time spent, pages viewed, bounce). These behavioral signals carry significant weight. The direct HTTPS signal is weak, but its indirect consequences are enormous.

What are the grey areas in this communication?

Google never specifies the true intensity of the signal in its overall weighting system. “Minor” could mean 0.5% of the total weight, or 3%. It's impossible to quantify. [To be verified] in large-scale controlled A/B tests, but few players have the necessary resources.

Another ambiguity: Mueller talks about a preference “when HTTPS is available,” but does not detail edge cases. What happens if the HTTPS version loads 2 seconds longer than the HTTP version due to poor server configuration? Does Google still favor HTTPS at the expense of speed? The official discourse remains vague on these trade-offs.

In what scenarios is HTTPS absolutely not enough?

A valid certificate never compensates for poor content, chaotic site architecture, or a toxic link profile. I have audited perfectly implemented HTTPS sites that stagnated on page 5 simply because their content was shallow and their backlinks nonexistent.

Another problematic case is sites with mixed content (HTTP resources embedded on HTTPS pages) or incomplete redirects. Google detects these errors and may refuse to index the HTTPS version, or worse, continue to display the HTTP version. A haphazard migration can do more harm than a complete absence of HTTPS. Execution quality takes precedence over intent.

What concrete steps should be implemented on an existing site?

The first step: install a valid SSL certificate (Let's Encrypt is more than sufficient for 99% of sites). Next, configure the server to force all HTTP connections to HTTPS via permanent 301 redirects, not temporary 302 redirects.

Next, check each resource (images, CSS, JavaScript, iframes) to eliminate any mixed content. A single file loaded via HTTP on an HTTPS page triggers a security warning in the browser. Test with Chrome DevTools, Console tab, to identify these errors before going live.

What critical mistakes to avoid during an HTTPS migration?

Never allow both versions (HTTP and HTTPS) to coexist without strict redirection. Google will index both and consider it duplicate content, diluting your authority. Using a canonical tag is not enough: a 301 server redirect is necessary.

Another classic pitfall: forgetting to update internal URLs in the XML sitemap, menu links, canonical tags, and hreflang tags. A poorly coordinated HTTPS migration creates unnecessary redirect chains that slow down crawling and degrade user experience.

How to validate that everything works properly after migration?

Test with SSL Labs (Qualys) to ensure that the certificate is correctly recognized and that encryption is optimal (minimum grade A). Crawl the entire site with Screaming Frog or Sitebulb while forcing HTTPS to detect mixed resources, 404s, or faulty redirects.

Monitor Search Console for 4 to 6 weeks: the coverage report should show a gradual shift from HTTP URLs to HTTPS. If after a month the old HTTP URLs still dominate the index, a redirect or canonical tag is misconfigured.

• Install a valid SSL certificate (Let's Encrypt, Certbot, or another recognized provider)
• Configure permanent 301 redirects for all HTTP URLs to HTTPS at the server level (htaccess, Nginx, etc.)
• Correct all mixed resources (images, scripts, CSS) to load via HTTPS
• Update the XML sitemap, canonical tags, internal links, and hreflang tags
• Submit the new HTTPS version in Search Console and monitor the indexing progress
• Test the site with SSL Labs and crawl the entire site to detect residual errors