Site Not Secure Warning: What Causes It and How to Clear It

How to read the warning your client just screenshotted, find which layer it comes from, and clear it without guessing.

What a browser is actually telling you when it says a site is not secure

The wording sounds like a verdict on the business. It is not. A browser showing “Not secure” is reporting one narrow fact about the connection: this page was not delivered over a validated encrypted channel to this exact hostname. It says nothing about malware, nothing about the quality of the content, and nothing about whether the site was hacked. Understanding that distinction is what stops a five-minute DNS problem from turning into a panicked client call about a security breach.

For an agency, the warning almost always shows up in one of three moments: just after a custom domain is pointed at a new site, after a template or page is copied from somewhere else, or on the morning a certificate quietly stopped being valid. Each has a different cause and a different fix, and the browser gives you enough information to tell them apart before you touch anything.

The four things a browser can be complaining about

“Not secure” is a family of messages, not one message. Read the exact wording and the address bar together before deciding what is wrong.

That last row deserves more weight than it usually gets. A single screenshot from a client is not a reproduction. Check the hostname yourself from a private window and from a connection that is not the office network before you start editing anything.

Why the warning appears right after a domain is pointed

Adding a custom domain to a hosted site or funnel is a sequence, not a switch. The domain’s DNS record has to resolve to the platform, the platform then has to request and install a certificate for that exact hostname, and only then does the padlock appear. Between the DNS change propagating and the certificate being issued there is a window where the hostname resolves but has no certificate yet, and every visitor in that window sees a warning.

Three details make that window longer than it needs to be:

• Only one hostname was pointed. A certificate is issued for the names it was requested for. If DNS sends both the bare domain and the www version to the platform but only one was added in the platform, the other one has no certificate and warns.
• An old record is still answering. A leftover A record, a parking page, or a redirect service at the registrar can keep answering for the hostname long after you believe you repointed it. Resolve the name and see where it actually goes rather than trusting the registrar’s dashboard.
• The check was done in a browser that had already cached the failure. Browsers remember certificate errors and HTTPS upgrade rules aggressively. Verify in a fresh private window, and preferably a second browser.

The same DNS discipline that governs mail authentication governs this. If your onboarding already covers SPF, DKIM and DMARC records and a verified sending domain, add the site hostname’s certificate check to the same pass — it is the same registrar, the same zone, and the same person doing the work.

Mixed content: the warning that survives a correct certificate

This is the one that confuses people, because the certificate is fine and the page still refuses to look secure. An HTTPS page that loads an image, a font, a stylesheet, a script or an iframe over plain HTTP is asking the browser to accept part of the page through an unprotected channel. Browsers respond by blocking the resource, silently upgrading it, or marking the page, depending on what kind of resource it is.

The usual sources, in the order they turn up in agency work:

• An image URL hardcoded with http in a page builder element, often pasted from an older site.
• An embed or widget whose provider snippet is old enough to have shipped an http source.
• A template or snapshot copied from another account, carrying absolute asset URLs from the account it was built in. This is the same class of problem as the other things that travel with a copy — worth reading alongside what actually moves when you import a template.
• An iframe pointing at an http address, which will simply refuse to render inside a secure page. If a form or calendar frame is blank rather than merely mis-sized, check the protocol before you go down the frame height path.

Finding them is mechanical: open the page, look at what the browser reports as blocked, and search the page content for the literal string http colon slash slash. Fixing them is equally mechanical — change the protocol, or re-upload the asset to the site so it is served from the same hostname. Do not solve mixed content by disabling the browser’s protection in your own profile; that hides the problem from you and leaves it in place for every visitor.

Certificates expire, and they expire quietly

A certificate has a validity window. Automatic renewal is normal on managed platforms, but it can fail for reasons that have nothing to do with the platform: the DNS record moved, a CAA record at the registrar blocks the issuing authority, the domain was transferred, or a redirect now intercepts the validation request. Renewal failures are silent by design — nothing breaks until the old certificate runs out, which is often weeks later.

Two habits catch this before a client does. First, when you change anything in a domain’s DNS zone, note that a certificate for that hostname exists and will need to validate again. Second, put a recurring check on the hostnames you are responsible for, and treat the check as a step with a recorded result rather than a glance. That is exactly the kind of small, triggered procedure that belongs in a written SOP instead of in one person’s memory.

A fix order that does not waste an afternoon

Work outside in. Every step below either confirms the layer is fine or hands you the cause.

• Reproduce it yourself, on the exact URL, in a private window, on a network that is not the client’s office.
• Read the exact message and code. A name mismatch, an expiry and a mixed-content mark are three different problems that look similar in a screenshot.
• Resolve the hostname and confirm it points where you think. Check both the bare domain and the www version, because they are separate names.
• Inspect the certificate: which hostnames it covers, when it was issued, when it expires, and whether the chain is complete.
• Check the redirect path from http to https, and from one hostname to the other. A redirect chain that lands on a hostname with no certificate produces a warning that looks like it came from nowhere.
• Only then look at the page for mixed content.
• Re-check from a second device before telling the client it is fixed. Your browser is the one most likely to be showing you a cached result.

What to tell the client while you work

Say what the warning means and what it does not, in that order: the browser is reporting how the page travelled, not that anything was stolen or that the site was attacked. Give the layer you are working on and the next checkpoint. Avoid promising a time you cannot control — certificate issuance and DNS propagation are not on your clock, and a specific promise you then miss costs more trust than the warning did.

The durable fix is procedural. Put the domain and certificate step into the onboarding checklist with its own confirmation: both hostnames resolve, the certificate covers both, the http address redirects to https, and the live page shows no blocked resources. Four checks, recorded once, at the moment when fixing them costs nothing.

Frequently Asked Questions

Does a “site not secure” warning mean the site was hacked?

No. The message is about the transport layer only: the browser is saying the page did not arrive over a validated encrypted connection to that hostname. It is not a malware scan, it is not a judgement about the content, and it does not indicate a breach. A site can be completely compromised and still show a padlock, and a perfectly healthy site can warn simply because a certificate has not been issued yet.

Why does the warning appear on www but not on the bare domain?

Because they are two different hostnames and a certificate is issued for named hosts. If only one of them was added on the platform, only that one gets a certificate, while DNS may still be sending visitors to both. The fix is to make sure both names are configured on the platform, or to redirect one to the other at the DNS or hosting layer so that only the covered hostname is ever served.

How long after pointing a domain should the warning disappear?

It clears once DNS has propagated and the certificate has been issued and installed for that hostname, which is a sequence rather than an instant switch. Rather than watching the clock, check the two conditions directly: does the hostname resolve to the platform, and does the served certificate name that hostname? If DNS is correct and the certificate has not appeared, look for something intercepting validation, such as a leftover redirect or a CAA record.

What is mixed content and why does it break the padlock?

Mixed content is a secure page that loads part of itself over an insecure connection, such as an image, script, font or iframe with an http address. The browser cannot vouch for that part of the page, so it blocks or downgrades the resource and marks the page. The fix is to change those URLs to https, or to host the asset on the same site so it is served over the same connection as the page.

Only one person sees the warning. What should I check?

Start with their device rather than the site. A clock that is far out of date makes valid certificates look expired, and antivirus products and corporate networks sometimes inspect traffic by substituting their own certificate, which browsers flag. Ask them to try a different network and a different device. If the warning follows the person rather than the URL, the site is not the problem.

Can I just tell visitors to click through the warning?

Treat that as a last resort for your own testing, never as advice to visitors. Teaching people to dismiss certificate warnings removes the only protection they have against a genuinely intercepted connection, and on a page that collects contact details or payment information it is not an acceptable state to leave running. Fix the hostname or the certificate instead.

How do I stop this from happening again?

Make it a recorded step rather than a memory. When a domain is connected, confirm four things and write down that you did: both hostnames resolve to the platform, the certificate covers both, the http address redirects to https, and the live page loads with no blocked resources. Then re-run the same four checks whenever anything in that domain’s DNS zone changes, because that is when renewal quietly stops working.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

• Setup (one-time)$850
• Ongoing (per month)$38.80

Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.