What it means
Two related findings. No HTTPS: pages are reachable over plain HTTP, or HTTP requests do not redirect to HTTPS on every hostname. Mixed content: a page served over HTTPS requests a subresource — script, stylesheet, image, font, iframe — over HTTP, which undoes the guarantee the padlock implies.
Why it matters
Traffic over HTTP can be read and modified in transit by anything between the visitor and your server, and injected content is indistinguishable from yours. Browsers block mixed active content such as scripts and stylesheets outright, so pages break in ways that are hard to reproduce; mixed passive content such as images produces a downgraded security indicator and, increasingly, is upgraded or blocked too. Browsers mark HTTP pages with form fields as not secure, which visitors do notice on a checkout page. HTTPS is also a long-standing ranking signal, so the same defect shows up in the SEO findings.
How W3Audit detects it
Each hostname is requested over HTTP and HTTPS, with and without www, and the redirect path is recorded hop by hop. The certificate is checked for validity, expiry window, hostname coverage and chain completeness, and the negotiated protocol version is recorded. Every subresource request on every audited page is then checked for scheme, so mixed content is reported per page and per resource, split into active and passive. Cookie flags and HSTS presence are recorded alongside.
This is an external configuration review. It is not penetration testing, vulnerability exploitation or malware scanning — see the security audit page for exactly what is and is not covered.
How severe it is
Critical, and one of the few findings rated critical on a single instance. Any page reachable over HTTP is critical. Mixed active content is critical because it both breaks functionality and defeats the secure context; mixed passive content is high. A certificate inside its expiry window is critical on the grounds of imminence rather than current harm.
How to fix it
Redirect every HTTP URL to its HTTPS equivalent in a single 301, on every hostname, then eliminate HTTP subresources.
# one permanent hop to the canonical host 301 http://example.com/page → https://www.example.com/page 301 http://www.example.com/page → https://www.example.com/page # then declare HTTPS-only for future visits Strict-Transport-Security: max-age=31536000; includeSubDomains <!-- and fix subresources at the source --> <script src="http://cdn.example.com/a.js"> <!-- → https:// -->
Update hard-coded HTTP URLs in templates, CMS content, stylesheets and database fields rather than relying on upgrade-insecure-requests to paper over them. Add HSTS only once you are confident HTTPS works everywhere — it is deliberately difficult to reverse.
How to verify the fix
Request every hostname variant over HTTP and confirm a single 301 to the canonical HTTPS URL. Load key pages with the console open and confirm zero mixed-content warnings. Re-crawl to catch HTTP subresources on pages you did not check by hand, and confirm the certificate covers every hostname in use, including subdomains, with months rather than days of validity left.
Where this sits in your audit
This finding belongs to the Security category — see the security audit for everything else reviewed alongside it, or the methodology for how its severity and score contribution are calculated. The website audit checklist includes it as a step you can run yourself.