Website Not Secure? What It Means and How to Fix It

A customer mentions that your website "came up with a warning". You check, and there it is next to your own address: Not secure. Within about four minutes of searching you will be looking at somebody's certificate shop, because that is who writes about this. Two facts change the whole conversation before you spend anything. A certificate can genuinely cost nothing, and is very often already sitting in the hosting you pay for every month. And three completely different faults produce warnings that look alike to anybody who is not a developer, so buying something only fixes one of them.

There are two very different visitor experiences here, and they are worth telling apart because one is a quiet doubt and the other is a closed door.

The first is the label in the address bar. Chrome shows Not secure when it has not established a private connection, meaning somebody could in principle view or change what passes between the visitor and the site. Most people still carry on. Some do not, particularly at the moment they are about to type a phone number into a form.

The second is a full page they cannot get past: a certificate or connection warning filling the screen. That stops nearly everybody, and it is why this moves from something to sort out eventually to something to sort out now.

There is a third, separate thing worth naming so you can rule it out. A full red page marked Dangerous is Google Safe Browsing, and that is not a missing certificate at all. It means Google believes something harmful is on the site, and it needs the treatment covered in what to do when your website is hacked rather than anything here.

As for what the label costs you in customers: no credible source publishes a figure, and anybody quoting you one for your business is guessing. What is certain is the mechanism, and it is enough. A visitor deciding whether to trust you is being shown a browser telling them not to.

Five minutes here saves you buying the wrong thing.

Your address is still http. Type your domain with `https://` in front of it. If the secure version loads correctly, the certificate exists and the problem is that visitors are being served the insecure address. If it fails or times out, there is no working certificate on that hostname.

The certificate is broken. The full-page warning usually names the reason: expired, issued for a different hostname, or from an authority the browser does not trust. Note the exact wording, because those three have different fixes.

Mixed content. The padlock is there, the certificate is valid, and the warning persists on certain pages. That means the secure page is pulling in pieces over http: an image, a script, a stylesheet, a font, an embedded frame. Google's guidance on mixed content covers what browsers do with these, which ranges from reporting them to blocking them outright.

Check the apex domain and the www version separately, along with any other hostname you use. They can differ, and a certificate covering one but not the other is a common and confusing cause.

Order matters here because two of the steps can take the site offline if they are done blind.

Record the evidence first: the exact address, the exact warning text, the browser, the device and the time. Check it on a second device and a different network, since a wrong clock on one machine produces certificate warnings that have nothing to do with your site.

Then establish who controls what. Three separate things need an owner: the domain and its DNS, the server or platform serving the site, and whoever renews the certificate. On a managed platform these are often the same party. On an older setup they frequently are not, and that split is usually why nobody has fixed it.

Then ask the platform whether a certificate is already included and managed. This is the single highest-value question in the whole process and it is free to ask. Let's Encrypt's own guidance notes that many hosting providers obtain and manage certificates for customers automatically or with a setting.

Then, for an http site or an invalid certificate: confirm control of the domain, issue or renew the certificate, install it where traffic is actually served, configure site-wide redirects from http to https, and test the canonical hostname along with the alternates and a few real paths.

Then treat it as what it is. Google classifies a move from http to https as a site move with URL changes, which means mapping the URLs, testing the redirects, checking robots and noindex rules, and updating the sitemap. Skipping that is how a site gets its padlock and loses its search presence in the same week.

Finally, test the forms without using real customer data, then watch Search Console for crawl or coverage problems.

This is the case that makes owners think they have been sold something faulty, and the explanation is simple once you see it.

A page delivered securely can still ask the browser to fetch things over http. An old image path in a blog post from 2018. A tracking script somebody added. A font, a map embed, an old plugin's stylesheet. The page is secure; the pieces are not; the browser says so.

The fix lives in the page's own source rather than in anything you can buy. Chrome's developer tools report these under its Issues panel, which lists exactly which resources are the problem.

The important caution is not to bulk-rewrite every http address to https and hope. Google's mixed-content guidance is explicit that you should check the secure version of a resource actually exists before switching to it, because a resource that has no https version simply breaks instead. Some old third-party embeds have never supported https and need replacing rather than rewriting.

For a small site this is often a handful of specific URLs. For an older site with years of posts it can be a genuine job, and that is worth knowing before you agree a price based on "just install a certificate".

The certificate and the labour are two different things, and conflating them is how people end up paying for the wrong one.

On the certificate: Let's Encrypt's FAQ, updated 28 April 2025, says it charges no fee for its certificates, while noting an integrator such as a hosting provider may charge a nominal fee for administration and management. So, a quote that presents buying a certificate as unavoidable is describing one option rather than the requirement.

On the labour: no standard price exists for this work and any range presented as a market rate is invented. What genuinely moves it is scope. How many hostnames and environments. Whether anybody has access to DNS and the server. Whether validation is straightforward. How much mixed content there is, and whether any of it comes from third parties with no secure version. Whether the http to https change needs full migration checks. And whether somebody is being paid to monitor renewal afterwards.

Ask for those as separate lines. A recurring fee for certificate management is a legitimate thing to charge for. A one-off fee described as the compulsory cost of a certificate is worth a question, and what a website costs you every month covers the wider pattern of recurring items that arrive without explanation.

The first layer of this is entirely safe and it makes any conversation afterwards much shorter.

Copy the exact warning text and the address it appeared on. Try the https version without typing any personal information into it. Check whether it happens on another device and another network. List every hostname you actually use and every form that collects information. Then ask your platform the certificate question above.

While you are in there, two account habits are worth the five minutes. Use a unique password on the domain and platform accounts, and turn on multi-factor authentication. CISA recommends requiring it wherever possible, starting with administrator accounts and anybody handling sensitive data.

If you have documented access, you can update a known http asset to https once you have confirmed the secure version loads, or switch on a platform's own https and redirect setting where the platform documents it.

The line is sharper here than in most website work, because the failure mode is worse than the problem. Do not make untested changes to DNS, server configuration, private keys, redirects or the database. Do not turn https off to get back in. Do not click through a certificate warning and then submit real customer data. Let's Encrypt warns that tearing down servers without durable storage of certificates and keys can leave a site unable to get a new certificate for days because of rate limits, so a hasty rebuild can extend an outage rather than end it.

No Arlington or Dallas-Fort Worth rule requires https for an ordinary business website, and nobody should tell you a browser warning breaks a local ordinance.

Texas law does have something to say about the data, though not about certificates. Section 521.052 of the Business and Commerce Code requires a business to implement and maintain reasonable procedures, including appropriate corrective action, to protect sensitive personal information it collects or maintains from unlawful use or disclosure. It names no technology, so it neither mandates a particular certificate nor lets anybody claim it does.

The same chapter covers breach notice. Where a breach involves at least 250 Texas residents, the Attorney General must be notified as soon as practicable and no later than the thirtieth day after the breach is determined to have occurred. That provision has several conditions and is not triggered by a site having once displayed a warning. Any actual incident is a question for qualified counsel rather than for an article.

Locally, the City of Arlington's business page points owners to small business assistance and the Arlington Economic Development Corporation, and the City names the Greater Arlington Chamber, the Arlington Black Chamber and the U.S. Pan Asian American Chamber as network resources. Useful for general support, unrelated to certificates.

Almost every repeat of this problem is a renewal that lapsed, which makes the prevention specific and cheap.

Certificates expire on a schedule now measured in weeks rather than years. Let's Encrypt issues 90-day certificates and recommends renewing at 60 days, and its integration guidance suggests checking renewal information at least twice daily with an automatic renewal 30 days before expiry as a backstop. More broadly, public certificates issued on or after 15 March 2026 have a maximum validity of 200 days under the current CA/Browser Forum requirements, so the whole industry is moving toward shorter lifetimes and away from anything a person remembers to do annually.

The practical version for a small business is three things. Know who renews it and confirm that it is automatic. Have an expiry alert going to somebody who still works there. And check the site in a browser after any significant change, particularly one that touches hosting, DNS or a plugin.

The other recurrence is mixed content creeping back in, which happens when somebody pastes an old http image address or an embed into a new page. Checking a new page in the browser once before it goes out catches that on the day rather than in six months.

Why does my website say Not secure?

Most often because visitors are reaching the http address rather than the https one. It can also mean the certificate is expired, covers a different hostname, or comes from an authority the browser does not trust, or that a secure page is loading insecure pieces.

Do I have to buy an SSL certificate?

Not necessarily. Let's Encrypt charges nothing for certificates, and many hosting platforms obtain and renew one for you automatically or behind a single setting. Ask your platform before you buy anything.

I installed a certificate and the warning is still there. Why?

Almost always mixed content: the page is served securely but pulls in an image, script, font or embed over http. That is fixed in the page's source, and only after checking the secure version of each resource exists.

Can I just tell people to ignore the warning?

It is not something to ask of a customer, particularly on a page where they are about to type their details. And the full-page version stops most people before they read anything you wrote.

Will switching to https affect my Google rankings?

Google treats it as a site move with URL changes, which means it needs redirects, updated canonicals and an updated sitemap. Handled properly it is routine. Handled carelessly it can cost you search visibility, which is the risk worth managing.

How often do certificates need renewing?

More often than people expect. Let's Encrypt certificates last 90 days with renewal recommended at 60, and public certificates issued on or after 15 March 2026 have a 200-day maximum. Automatic renewal is the norm for good reason.

Two things settle most of this before any money changes hands. Find out whether your platform already includes and renews a certificate, because very often it does. And establish which of the three faults you actually have, because an http address, a broken certificate and mixed content need three different repairs and only one of them involves obtaining anything.

Once it is right, the maintenance is a renewal that runs by itself and a glance at the browser after anything significant changes. That is genuinely the whole ongoing job.

If you would rather somebody worked out which fault it is and told you what it takes, Arlington Website Designer looks after sites for businesses around Arlington, TX and this one usually ends cheaper than the first quote people are given. Send the exact warning text and the address it appeared on through the contact page, and you will get back which of the three you have and whether your hosting already covers it.