Does not use HTTPS: what it means and how to fix it

Quick answer: This audit fails when the page is served over HTTP or loads insecure mixed content. Fix it by installing a free TLS certificate, 301-redirecting all HTTP to HTTPS at the server or CDN edge, upgrading insecure subresource URLs to https, and adding a strong HSTS header.

Lighthouse fails this audit when the page is served over plain HTTP, or over HTTPS but loading some resources insecurely (mixed content). HTTPS is a baseline requirement for security, SEO, and access to modern browser APIs.

TL;DR

• What: Page served over http://, or HTTPS page pulling http:// subresources.
• Why it matters: It is a Google ranking signal, a hard requirement for many browser APIs and HTTP/2, and browsers flag HTTP pages as "Not secure".
• Fix: Install a TLS certificate, 301-redirect HTTP to HTTPS, upgrade insecure subresources, add HSTS.

What does the HTTPS audit check?

Two things: that the main document is served over HTTPS, and that it does not request active mixed content (scripts, stylesheets, iframes) over HTTP. Passive mixed content (images) may warn rather than fail but should still be fixed.

Why does HTTPS matter?

• SEO: HTTPS is a confirmed, if light, ranking signal, and Google indexes the HTTPS version preferentially.
• Trust: Chrome and Safari label HTTP pages "Not secure" in the address bar.
• Capability: Service workers, the Geolocation API, HTTP/2, HTTP/3, and many others require a secure context.
• Integrity: HTTP traffic can be read or modified in transit (injected ads, stripped content).

How do I migrate to HTTPS?

1. Install a TLS certificate

Almost every host and CDN issues free, auto-renewing certificates:

• Cloudflare, Vercel, Netlify, Fastly: automatic, nothing to configure.
• Self-managed servers: Let's Encrypt via Certbot, auto-renewed.

2. Redirect all HTTP to HTTPS

Do this at the server or CDN edge, never in JavaScript (JS runs too late to protect the request).

nginx:

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

3. Fix mixed content

Find and upgrade insecure subresources:

<!-- Before -->
<script src="http://cdn.example.com/widget.js"></script>
<!-- After -->
<script src="https://cdn.example.com/widget.js"></script>

As a safety net, add:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

4. Add HSTS

Tell browsers to always use HTTPS for your domain:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Only add preload once you are confident every subdomain is HTTPS, as it is hard to reverse.

What are common HTTPS mistakes?

• Redirecting in JavaScript. The insecure request already happened before JS ran.
• HTTPS home, HTTP deep links. Redirect rules must cover every path, not just /.
• Hardcoded http:// asset URLs. The most common mixed-content source. Use https:// or protocol-relative-free absolute HTTPS.
• Canonical or sitemap still pointing to http://. Conflicting signals; update them in the same change.
• Forgetting the www/apex variant. Both must serve HTTPS and redirect to the canonical host.

How do I verify HTTPS?

1. Re-run Lighthouse: the audit should pass.
2. Load the site over http://: it must 301 to https://.
3. DevTools → Console: no mixed-content warnings; padlock shows secure.
4. Check the Strict-Transport-Security response header is present.
5. Confirm canonical, sitemap, and internal links all use https://.

Related audits

• Document does not have a valid rel=canonical, keep the canonical on HTTPS
• Eliminate render-blocking resources, HTTP/2 (HTTPS-only) reduces request cost
• Document does not have a meta description, other core SEO hygiene

Audit your URL at https://lighthouse-md.com.