Check · C06 · Security & bots

HTTPS check: does the scan land on an encrypted URL

The check looks at whether the page is served over HTTPS after all redirects. No is critical, because then the tracking requests travel in plain text too.

What we check

Over HTTP: the scan follows all redirects of the entered URL and looks at where it lands. If the final URL starts with https://, the line is "ok"; otherwise it is critical, noting that tracking requests run unencrypted. The destination is what gets rated. If you enter http:// and get cleanly redirected to HTTPS, you therefore get "ok".

What the scan does not rate: the certificate itself (an invalid one makes the scan fail instead of producing a line), mixed content on the page, HSTS and the TLS configuration. HSTS lives in the security headers finding.

Why it matters

HTTPS has been standard for years, which is exactly why the exception stands out: a site still answering over HTTP in 2026 usually has no security headers, no consent setup and tracking from the same era either. For the measurement itself HTTP means: every client ID, every cookie and every event parameter crosses every network between visitor and server in readable form. Browsers flag such pages as "not secure", and pixels and consent platforms often no longer load there at all. No banner, no measurement. And the parallel variant without a redirect splits the signals across two origins, so sessions and referrers fall apart in reporting.

Common causes

The certificate expired or does not cover the subdomain, the browser warns.
The HTTP variant does not redirect, both versions run in parallel and split the signals.
Mixed content: the page itself is HTTPS but loads individual resources over http://.
A landing page or microsite subdomain was set up without a certificate while the main domain is clean.

The fix

A certificate for every domain and subdomain visitors reach; Let's Encrypt is free and renews automatically. Then a 301 redirect from every HTTP URL to its HTTPS counterpart, not just from the homepage, and after that Strict-Transport-Security with a one-year lifetime so the browser never requests HTTP again. Finally, the network tab. Filter for mixed content and swap every resource still loading over http://.

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

We have a certificate, but the scan still reports critical. How come?

The scan rates the URL it lands on after all redirects. If the HTTP variant answers with 200 instead of redirecting to HTTPS, the scan stays on HTTP and reports that. Both variants then run in parallel, and whoever types the link without a protocol gets the unencrypted one. The fix is a 301 from HTTP to HTTPS, then HSTS.

What about mixed content and expired certificates?

This line sees neither. An expired certificate usually stops the scan from loading at all, and the result then says "unreachable". Individual resources over http:// on an HTTPS page the scan does not detect; the browser blocks them silently, and a tracking script loading that way never runs. Filter the network tab for "mixed content".

Why is this a tracking topic?

Because every measurement ping uses the same connection as the page. Over HTTP, client IDs, cookies and event data cross the network in plain text, and modern browsers flag the page as insecure before anyone sees the banner. On top, tag managers, CMPs and most pixels refuse to work on HTTP pages or get blocked by the browser.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint