site shows 'not secure' warning in chrome
the http vs https tls warning is one of the few things that scares visitors away in the first second. usually a 60-minute fix.
the 'not secure' warning lights up because the browser cannot verify that the connection to your site is encrypted and trusted. the encryption part is tls. the trust part is the certificate — a small file signed by an authority chrome trusts. most modern hosts give you a free let's encrypt certificate with one click, so the warning being on usually means the toggle is off, the certificate is expired, or you have mixed content on an otherwise-secure page.
what this looks like to a visitor
- chrome shows 'not secure' in the address bar
- lock icon is missing or has a warning triangle
- some pages load, others give a tls error
- google search console reports 'mixed content' warnings
what a public browser check can see
we connect, read the certificate, check whether the domain matches, whether it is expired, and which authority issued it. the public check tells you everything except the private key.
we try the http version of your site. if it serves content instead of redirecting to https, that is the first fix.
we check the rendered html for any asset (image, script, css, iframe) loaded over http on a page that is otherwise https. this triggers the 'not secure' state even when the cert is fine.
we read your response headers and report whether strict-transport-security is set. without it, the first visit to your domain in a fresh browser is still over http for a moment, and a hostile network can intercept that moment.
we do not log into your site. we do not scrape customer data. we open your public homepage in a real browser session and report what we see. no security claims unless we can prove them from the public surface.
the deeper picture
the four patterns: (1) ssl is off on your host. you are paying for hosting that offers free tls but the toggle was never flipped. wix, squarespace, shopify, kinsta, siteground all offer one-click ssl. (2) expired certificate. let's encrypt certs are 90 days. they auto-renew on most hosts, but if dns changed or the host's renewal cron broke, they do not. you have to renew manually or repoint the host. (3) mixed content. your site is on https but the homepage loads an image, video, or analytics script from a http:// url. chrome flags this. fix by updating the embed url to https or removing the embed. (4) hsts missing. less urgent — visitors get the warning only on the initial visit before they have https in their session. fix with one header set by your host or a security plugin.
fix it yourself
if you are on a managed host (wix, squarespace, shopify, webflow), enable ssl in your host's dashboard — it is usually a one-click toggle and uses let's encrypt under the hood. if you are on wordpress / shared hosting, get a let's encrypt cert through your control panel and force https through .htaccess or your host's redirect setting. fix mixed content by editing image and embed urls to start with https://. add the strict-transport-security header through your host or a plugin.
run the audit on YOUR site — check for "site shows 'not secure' warning in chrome"
we open your homepage in a real headless browser and report what we see. no login, no plugin install.
public browser check · no signup · result on the next page
or pay us once.
this is one of the cheapest fixes there is in time and money. if you are technical, the self-fix takes an hour. if your host is one of the managed platforms, it is a single toggle. if it is more tangled — old wordpress, custom server, weird hosting reseller — the $99 contact form repair tier covers it: we get the certificate live, fix mixed content, set hsts. one-time, done in a day.
frequently asked
no. let's encrypt is free, trusted by every browser, and auto-renews on every modern host. paid extended-validation certs are only useful for banks and very large e-commerce.
yes, but the effect is small and indirect. google has used https as a ranking signal since 2014 but it is a tiebreaker, not a multiplier. the bigger effect is on bounce rate — visitors leave when they see the 'not secure' warning.
you can, but you will lose visitors who do not know what the warning means. some browsers also block forms and downloads on http pages entirely.
the certificate has to cover both versions, or you need a redirect from one to the other. most hosts handle this automatically; some require you to add the second variant to the cert. the public check tells you which is covered.
other fix guides
- why is my wordpress site slow— what an external browser sees when your wordpress homepage takes too long to render — and the four things that are almost always behind it.
- shopify checkout feels broken — how to find out why— a public browser check of your shopify storefront can surface the visible reasons people abandon. here is what we look for.
- contact form looks fine but i'm not getting emails— this is the most common silent failure mode of small-business websites. four reasons it usually is — and how a public check can rule out the wrong ones.
- wix site not showing on google — what a public check can tell you— your wix site exists, but it does not appear in google search results. four reasons that explain almost every case.
built by vøiddo — a small studio shipping ai-flavoured products, free dev tools, chrome extensions and weird browser games. legal · support@voiddo.com