Why Does My WordPress Site Say "Not Secure"? (SSL Fix)

Open your site in Chrome and look at the address bar. If it reads "Not Secure" next to your domain, the browser is telling every visitor the same thing: the connection between them and your server is not encrypted, so anything they type — a contact form, a login, a card number — could be read in transit.

The warning has exactly one meaning, but five common causes. Some take a single click to fix. Others need a change inside WordPress or a line in a config file. Work through the sections below in order; the diagnosis step tells you which fix you actually need, so you can skip the rest.

What "Not Secure" Actually Means

Every page your site serves travels over one of two protocols. HTTP sends data as plain text. HTTPS wraps that data in encryption, using an SSL certificate installed on your server to prove the site is really yours.

Chrome, Safari, Edge, and Firefox all mark plain HTTP pages as "Not Secure." The warning is not about your site being hacked or infected — it says only that the connection is unencrypted, or that the certificate protecting it is missing, expired, or does not match the domain being visited.

Two consequences follow. Visitors who see a security warning on a business site hesitate, and many leave without converting. Google also treats HTTPS as a ranking signal, so an HTTP site carries a small search penalty on top of the trust problem.

Diagnose It in Two Minutes

Before changing anything, find out which of the five causes you have. Two checks are enough.

Check 1: type the HTTPS address directly

Enter https://yourdomain.com in the address bar, with the https typed explicitly. What you see next tells you a lot:

A full-page privacy error ("Your connection is not private," NET::ERR_CERT_*): there is no valid certificate. Go to Fix 1, then check Fix 5 if a certificate does exist but is expired.
The page loads, but the padlock is missing or crossed out: the certificate works. Your problem is mixed content — go to Fix 3.
The page loads with a clean padlock, but the plain domain still shows "Not Secure": HTTPS works, yet visitors are not being sent to it. Go to Fix 2 and Fix 4.

Check 2: read the certificate

Click the icon to the left of the address bar, then open the connection or certificate details. Confirm the certificate is issued to your exact domain, then confirm it has not passed its expiry date. A certificate issued to www.yourdomain.com alone will fail on the bare yourdomain.com, which is a common cause of an intermittent warning.

Fix 1: Install an SSL Certificate

If the HTTPS address throws a privacy error, no valid certificate is installed. This is the most common cause on older sites, on sites moved from a host that included SSL to one that does not, or on brand-new installs where nobody ever switched it on.

Nearly every reputable host issues free certificates from Let's Encrypt. In your hosting control panel, look for SSL, TLS, or Security, select your domain, then issue the certificate. cPanel hosts usually label this "SSL/TLS Status" with a "Run AutoSSL" button. Issuance takes a few minutes.

Two things to confirm once it is issued. The certificate must cover both yourdomain.com and www.yourdomain.com — most free certificates include both, but only if both were selected. It must also be set to renew automatically. Let's Encrypt certificates last 90 days, so a manual renewal you forget becomes a site-wide outage warning three months later.

If your host charges for SSL or has no free option, that is a reason to move. Free automated SSL is standard on any host worth using, including our own managed WordPress hosting.

Fix 2: Update Your WordPress URLs to HTTPS

A certificate alone does not switch WordPress over. WordPress stores its own address in the database. If that address still starts with http://, WordPress keeps building links, canonical tags, and asset paths on the insecure protocol.

In your dashboard, go to Settings, then General. Set both WordPress Address (URL) and Site Address (URL) to the https:// version of your domain, then save. WordPress logs you out; log back in over HTTPS.

If the fields are greyed out, they are hard-coded in wp-config.php. Open that file and update the two constants:

define( 'WP_HOME', 'https://yourdomain.com' );
define( 'WP_SITEURL', 'https://yourdomain.com' );

If a wrong value here locks you out of the dashboard entirely, edit wp-config.php over SFTP to correct it — the file always overrides whatever the database holds.

Fix 3: Clear Mixed Content

Mixed content is the cause people find hardest, because the site looks fine. The page loads over HTTPS, yet it pulls in at least one image, stylesheet, font, or script over http://. The browser will not vouch for a page that is partly insecure, so it downgrades or removes the padlock.

The insecure URLs are usually old references stored in the database: images inserted years ago with absolute http:// paths, a hardcoded script tag in the theme, or an embed from a third party that still serves over HTTP.

Find the offending URLs

Load the page, open your browser's developer tools (F12), then read the Console tab. Every mixed content warning names the exact insecure resource. That list is your work queue.

Fix them in the database

Do not hand-edit posts one by one. Run a search-and-replace across the database, swapping http://yourdomain.com for https://yourdomain.com. The Better Search Replace plugin does this from the dashboard — run it in dry-run mode first, review the count of affected rows, then run it for real. Take a backup before you start.

For stubborn cases — a plugin that rebuilds insecure URLs on every page load — SSL Insecure Content Fixer rewrites them on output. Treat it as a patch, not a cure. The clean fix is correcting the stored URLs.

Third-party embeds

If the insecure resource sits on someone else's domain, change the embed to its HTTPS equivalent. When the provider offers no HTTPS version at all, remove the embed. One insecure third-party asset is enough to strip the padlock from an otherwise perfect page.

Fix 4: Force Every Visitor Onto HTTPS

With a valid certificate installed, both http:// and https:// versions of your site now answer. Anyone typing your bare domain, following an old link, or clicking a search result indexed years ago still lands on the insecure copy — complete with the warning.

Close that door with a permanent redirect. Many hosts expose a "Force HTTPS" toggle in the control panel; use it if you have it. Otherwise add this above the WordPress block in your .htaccess file (Apache or LiteSpeed servers):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The 301 matters. It tells search engines the move is permanent, so your existing rankings transfer to the HTTPS URLs instead of splitting across two versions of every page.

Finally, open Google Search Console. The HTTPS site counts as a separate property, so add it, then submit your sitemap so Google recrawls the secure URLs.

Fix 5: Expired or Mismatched Certificates

A site that was secure last week can start throwing warnings without anything changing on your end. Two failures explain almost every case.

The certificate expired. Let's Encrypt certificates are valid for 90 days, so renewal has to be automatic. When the cron job that renews them silently fails, the certificate lapses. Reissue it from your control panel, then confirm auto-renewal is genuinely enabled rather than merely listed.

The certificate does not match the domain. NET::ERR_CERT_COMMON_NAME_INVALID means the certificate covers a different name than the one being visited — typically www is covered while the bare domain is not, or the site moved to a new domain that the old certificate never included. Reissue the certificate with every hostname you serve.

One more possibility worth ruling out: if the browser reports that the certificate is not yet valid, check that your computer's clock is correct. A wrong system date invalidates every certificate on the web, not just yours.

Verify the Fix

Once you have applied the relevant fixes, confirm the result properly. Do not rely on your own browser — it caches aggressively.

Load the site in a private window. The padlock should appear on the home page, on an inner page, plus on any form or checkout page.
Test the plain HTTP address. Visiting http://yourdomain.com should redirect straight to the HTTPS version.
Test both hostnames. Check the bare domain as well as the www version; both must land on a secure page.
Run an external scan. SSL Labs grades your certificate, its chain, and its configuration from outside your network.
Clear every cache. Purge your caching plugin, your host's server cache, plus your CDN. A cached copy of an insecure page will keep serving the warning after the underlying fix is live.

WordPress "Not Secure" FAQ

Why does my WordPress site say Not Secure?

Your site is being served over HTTP instead of a valid HTTPS connection. There are five common causes: no SSL certificate is installed, the certificate has expired, WordPress is still configured with http:// URLs, the page loads some images or scripts over http:// (mixed content), or visitors are never redirected from HTTP to HTTPS. The fix depends on which one applies.

How do I fix the Not Secure warning on WordPress?

Install an SSL certificate through your host (most offer free Let's Encrypt certificates in one click), change your WordPress Address and Site Address to https:// under Settings then General, replace any remaining http:// links in the database, then add a redirect that forces every HTTP request to HTTPS. Reload the site in a private window to confirm the padlock appears.

Does an SSL certificate cost money?

Not necessarily. Let's Encrypt issues free, browser-trusted certificates, and most reputable hosts install them automatically at no charge. Paid certificates exist, but for a standard business website they offer no security advantage — the encryption is identical. Only specialized cases, such as an organization-validated certificate, justify paying.

Is the padlock still missing after installing SSL?

That is almost always mixed content: the page itself loads over HTTPS, but it pulls in at least one image, stylesheet, or script over http://. The browser downgrades the padlock as a result. Open your browser's developer console and look for mixed content warnings — they name the exact insecure URLs so you can fix them.

Does the Not Secure warning hurt SEO?

Yes, in two ways. HTTPS is a confirmed Google ranking signal, so an HTTP site is at a small direct disadvantage. The larger cost is behavioral: visitors who see a browser warning on your domain bounce, which damages the engagement signals search engines watch. Any site that takes form submissions or payments belongs on HTTPS.

When You Want It Simply Handled

SSL should be invisible. It should install itself, renew itself, redirect every visitor to the secure version, then never ask you about it again. On our managed WordPress hosting, that is the default: free certificates issued automatically, renewed automatically, with HTTPS forced site-wide.

Book a free call and we will get the padlock back on your site.