What it is
This is the same underlying HTTPS setting covered in our technical HTTPS guide, but looked at here specifically from the visitor's point of view rather than the setup steps: HTTPS is what puts a padlock icon next to your address in the browser bar, and its absence is what triggers a visible "Not Secure" label instead. A visitor doesn't need to understand any of the technical details behind that padlock to react to it — the icon alone (or the warning alone) does the communicating.
This check flags the trust consequence of a missing HTTPS setup, distinct from the technical fact of the setup itself, which is covered separately.
Why it matters
Trust is fragile at the very start of a visit, before someone has any other information to go on — a security warning shown before they've read a word of actual content can be enough on its own to make them leave immediately, particularly if the site asks for any personal information, payment details, or even just an email address. This effect isn't limited to security-conscious visitors; the "Not Secure" label is designed by browser makers to be noticed by everyone, specifically because most people don't otherwise think about connection security at all.
This makes HTTPS one of the rare technical fixes with a direct, visible effect on visitor behavior and conversion — not just an invisible, backend improvement, but genuinely one of the first things a new visitor sees.
How to fix it
- Follow the setup steps in our HTTPS and redirect guide if you haven't already enabled HTTPS.
- Once enabled, visit your own site as a first-time visitor would and check what the address bar actually shows — confirm the padlock appears with no warning.
- If you see a padlock but also a mixed content warning, see our guide on mixed content — that's a related but separate issue.
- If your site collects any payment or personal information, treat this as a priority fix rather than an optional one, given how directly it affects a visitor's willingness to proceed.
- Re-run your Launch Readiness check to confirm this is now resolved from a trust standpoint.