How to add HTTPS to your website and fix "Not secure"

Adding HTTPS to a website is free and usually a single toggle in your host or CDN - the certificate is the easy part. The real work is the 2 steps after: forcing every HTTP request to redirect to HTTPS, and fixing any "mixed content" - images or scripts still loaded over http:// - that keeps the "Not secure" warning up even once the certificate is live. A "Not secure" label in the browser almost always means one of those 3 things isn't done. This page walks each one, in order, then shows you how to confirm it actually worked.

The stakes are not abstract: 38% of Australian small-business websites still do not enforce HTTPS^* - which is to say more than a third of the country is running a site that browsers visibly flag as unsafe. For the full sequence of fixes around this one, see the website security checklist.

Step 1: get a certificate (free)

A certificate is the file that lets a browser verify your site is really yours and encrypt the connection to it. There is no longer any reason to pay for one. Let's Encrypt - a non-profit certificate authority backed by the major browsers - issues domain-validated certificates at no cost, and it has effectively become the default the entire web runs on. Your host or CDN almost certainly issues and renews Let's Encrypt certificates for you automatically.

Where the toggle lives depends on who serves your site:

• On a CDN or proxy (Cloudflare, and similar): SSL/TLS is on by default the moment your domain routes through them. There is usually nothing to do beyond confirming the encryption mode is set to "Full" or "Full (strict)" rather than "Flexible" - Flexible encrypts the visitor-to-CDN hop but leaves CDN-to-origin in plaintext, which is the kind of half-measure that passes a casual glance and fails a real one.
• On shared hosting (cPanel, Plesk and the managed-WordPress crowd): look for "SSL/TLS Status" or an "AutoSSL" / "Let's Encrypt" panel. One click issues the certificate, usually within a few minutes.
• On a platform host (Vercel, Netlify, the static-site services): certificates are provisioned automatically when you add your domain. No action at all.

The certificate renews itself on a 60-to-90-day cycle in every one of these setups - you do not diary it. The exception is the older arrangement where someone bought a paid certificate and installed it by hand; those do expire and surprise people. If that's you, read SSL certificate renewal explained, and if a browser is already complaining, my certificate has expired covers the immediate fix.

Step 2: force HTTP to redirect to HTTPS

Issuing a certificate makes the secure version of your site available. It does not make anyone use it. Until you add a redirect, http://yoursite.com.au still loads over plain HTTP - unencrypted, flagged, and indexed by Google as a separate URL from the https:// version. The redirect is what closes that door: a server-level rule that takes every HTTP request and bounces it to the HTTPS equivalent with a 301 (permanent) redirect.

Most platforms do this for you with a single setting:

• Cloudflare: turn on "Always Use HTTPS" (SSL/TLS → Edge Certificates). One switch, applies site-wide.
• cPanel / managed WordPress: there's usually a "Force HTTPS" or "HTTPS redirect" checkbox beside the SSL panel. WordPress sites can also use a plugin like Really Simple SSL, though the host-level toggle is cleaner when it exists.
• Vercel / Netlify: the HTTP-to-HTTPS redirect is automatic and can't be turned off - nothing to do.

If you manage your own server, the redirect is a few lines in your Nginx or Apache config - but the wrong move here is editing raw server config when a checkbox would have done it. Reach for the platform toggle first.

Why this matters beyond the padlock: without the redirect you're running two copies of every page in Google's eyes, which splits your ranking signals, and any visitor who typed or bookmarked the bare http:// address travels unencrypted. Whether you strictly need this step is a question we answer in full at do I need to redirect HTTP to HTTPS - the short version is yes. Once the redirect is on, a request for the HTTP version should land on HTTPS automatically, and the next step explains why the warning sometimes survives anyway.

Step 3: fix mixed content

This is the step that catches people out. The certificate is installed, the redirect is on, the page loads over https:// - and the browser still shows "Not secure", or a padlock with a warning triangle. The cause is almost always mixed content: the page itself loads securely, but something inside it - an image, a stylesheet, a script, an embedded font or video - is still being requested over http://. One insecure asset on an otherwise-secure page is enough to break the padlock, because the browser can't promise the page is safe when part of it arrived unencrypted.

Mixed content creeps in through hard-coded URLs: a theme that references http://yoursite.com.au/logo.png in its code, an old blog post with an http:// image pasted in, a third-party widget or analytics snippet loaded over plain HTTP. The browser knows the secure version exists; it just wasn't told to use it.

The fix, in order of effort:

• Find what's insecure. Open the page, press F12 for developer tools, and read the Console tab - it lists every mixed-content URL by name. That list is your work order.
• Update the references. Change each offending http:// to https://, or to a protocol-relative // path. On WordPress, a search-and-replace plugin (or the Really Simple SSL tool) rewrites them across the database in one pass. On a static site, it's a find-and-replace in your source.
• Catch the rest with a header. A Content-Security-Policy: upgrade-insecure-requests header tells browsers to silently load any stray http:// asset over HTTPS instead - a safety net for references you missed. That's one of several headers worth setting; see what security headers your site needs.

If the warning is still there after the certificate and redirect are both confirmed, mixed content is the explanation 9 times out of 10 - the background on why is at what mixed content is and what "not secure" means in the browser.

How to check it worked

Two checks, one quick and one thorough.

The quick one: open your site in a normal browser tab and look at the address bar. A clean padlock with no warning triangle, and the address starting https://, means the page in front of you is fully secure. Click into a few different pages - the home page passing doesn't guarantee an old blog post does, since mixed content hides page by page. Then type the bare http:// version of your address and confirm it jumps to https:// on its own; that's your redirect from Step 2 doing its job.

The thorough one: run your domain through a free public checker. SSL Labs' SSL Test (ssllabs.com/ssltest) grades your certificate and TLS configuration end to end and flags weaknesses a padlock can't show you - an aging protocol version, an incomplete certificate chain, a misconfiguration that works today and won't next year. Aim for an A. Or run a scan and the result correlates your certificate, redirect, headers and DNS in one view against the Australian small-business baseline, so you can see where you sit rather than guessing.

When this isn't enough

HTTPS is the floor, not the ceiling. Getting the padlock means traffic to your site is encrypted and the browser stops warning visitors away - necessary, and most of what a small business needs at the transport layer. But it is one item on a longer list, and a green padlock says nothing about the rest of it.

A correctly served HTTPS site can still be missing the security headers that stop clickjacking and content-sniffing (what a security header is is the starting point), can still have a certificate quietly counting down to an expiry nobody's watching, and can still have email-spoofing records that have nothing to do with the padlock but cost far more when they fail. The ACSC's Small Business Cyber Security Guide sets out where HTTPS sits in the broader picture - 12 readable pages, free, and the best single starting document in Australian small-business security.

So treat the padlock as done-and-dusted, then keep going. The website security checklist is the ordered list of what comes after - each item another small, one-time fix at the hosting or DNS layer, the same shape as the 3 steps you just finished.