In one paragraph
A site not served over HTTPS delivers its pages without TLS protection on that connection. Network intermediaries may be able to read or modify the traffic, and browsers restrict many features on insecure public origins. Configure valid HTTPS, update the application and its resources, and redirect the old HTTP URLs. Verify the complete user journey, not just the homepage.
Why it matters
HTTPS is HTTP carried over Transport Layer Security. Correctly configured TLS protects the confidentiality and integrity of traffic between the client and its TLS endpoint and allows the client to authenticate that endpoint through certificate validation. It does not prove that the application is free of vulnerabilities or that a business is trustworthy.
Even a site without accounts benefits. An attacker able to modify a plaintext response could change a phone number, replace a download, or inject a script into a public information page. Protecting the delivered content matters independently of collecting passwords.
Many browser APIs require a secure context. Public HTTPS pages generally provide one, while ordinary public HTTP pages do not. Local development addresses can receive special treatment; that exception should not be used to justify HTTP in production.
HTTPS is a sound security baseline, not a guarantee of better rankings or faster loading. Performance depends on the network, TLS configuration, protocol, caching, and application. Moving to HTTPS can enable modern delivery features, but does not automatically make a slow website fast.
How WebAuditOS evaluates this finding
The supplied rule checks the scheme of the origin used for the scan. An https:// origin passes; another scheme fails. This simple result does not establish that every hostname supports HTTPS, that HTTP redirects correctly, or that the certificate and all subresources are healthy. Those require separate checks. A scan started on HTTP also does not, by itself, demonstrate that no HTTPS endpoint exists.
How to fix it
- Identify where browser-facing TLS terminates: managed hosting, CDN, load balancer, or your own web server. Configure the certificate at that layer and confirm that it covers the production hostnames you actually serve, including www if used.
- Obtain and install a certificate from a suitable trusted certificate authority. Managed hosts commonly automate this; self-managed deployments can use an ACME client. Serve the required intermediate chain and configure reliable renewal. Keep private keys out of the public web root and source control.
- Test HTTPS before redirecting traffic. Check representative pages, forms, API calls, downloads, and authentication. Confirm certificate trust and hostname matching from an external client. If a CDN connects to an origin over TLS, verify that separate connection as well.
- Update application configuration. Set the public base URL to HTTPS, recognise the external scheme correctly behind trusted proxies, and replace insecure resource references. Review CMS content, CSS URLs, script-generated requests, form actions, and stored absolute links, not only templates.
- Update search-facing URL signals consistently. Internal links, canonical tags, sitemap entries, and alternate-language annotations should identify the intended HTTPS URLs. For Google Search Console, a Domain property can cover both schemes; URL-prefix properties are specific to their configured prefix. Do not assume all existing reporting properties automatically provide the same view.
- Add permanent server-side redirects from old HTTP URLs to their appropriate HTTPS destinations, preserving the intended path and query handling. Avoid redirecting every old page to the homepage. Test for loops and unnecessary hops.
- Review session cookie settings, then stage HSTS only after HTTPS is stable. Do not add includeSubDomains or preload without understanding the additional commitment.
- Rescan the HTTPS origin and check actual browser requests. Monitor errors, renewal status, and important user journeys after deployment. A certificate file on disk is not proof that the public endpoint is using it.
What the fix can break
Mixed content is a common migration problem. Browsers block or upgrade insecure subresources depending on their type and context; a page can therefore lose scripts, styles, images, or embeds after switching. Fix the resource sources rather than restoring HTTP.
Incorrect proxy trust can generate redirect loops or insecure absolute URLs. Cookie and cross-origin authentication behaviour can also change. Test payment returns, sign-in, and integrations explicitly.
Bulk content replacement needs a backup and platform-aware tooling. Naively editing serialised CMS data can corrupt it. Keep the rollback focused on application configuration and content; do not treat a return to plaintext authentication as an acceptable long-term fallback.
Questions
Do public information pages need HTTPS?
Yes. HTTPS protects the integrity of the content visitors receive, not just secrets submitted through forms. It also supplies the transport security expected by modern browsers.
Will enabling HTTPS automatically make the site faster?
No. It can support modern protocols and delivery features, but speed depends on the entire stack. Measure the result instead of promising a universal performance improvement.
Does passing this finding prove the certificate is valid?
No. The documented rule checks the scanned origin's scheme. Certificate validation, redirects, and mixed content need separate verification.
What should I check next?
Review HTTP-to-HTTPS redirects, password forms on HTTP, and the security headers guide.