6 Ways to Fix the "Not Secure" Warning in WordPress

In 2023, over 89% of phishing sites used a valid TLS certificate to appear legitimate, according to Google's Transparency Report. That statistic underscores a painful irony for WordPress site owners: the green padlock, meant to signal trust, is now the bare minimum for any credible website. When your own site shows a "Not Secure" warning in the address bar, every visitor sees a red flag that screams "avoid me." The first thing you need to know is this: the most common cause is a missing, expired, or misconfigured SSL certificate, and the quickest fix is renewing or reinstalling your certificate through your hosting control panel. This article walks you through eight to twelve proven solutions, starting with the easiest checks and moving to deeper configuration fixes, so you can restore the padlock fast.

Before you start: what you must do first

Before touching any setting, back up your entire WordPress site — both files and database. A misstep with an .htaccess edit or a wp-config.php change can take your site offline. Most hosts offer one-click backups in cPanel or through a plugin like UpdraftPlus. Also export a copy of your database via phpMyAdmin. This safety net means you can revert every change if something goes wrong.

Common causes of the "Not Secure" warning in WordPress

1. Is your SSL certificate valid?

The fix: Log into your hosting control panel (cPanel, Plesk, or your host's dashboard) and look for the SSL/TLS section. Click "Manage SSL Sites" or "Let's Encrypt." If you see an expiry date in the past, renew your certificate. Many hosts offer free auto-renewal via Let's Encrypt — enable it if available.

If no certificate is listed, install one. Let's Encrypt is free and supported by most hosts. After installation, wait up to 15 minutes for propagation, then visit your site in an incognito browser window. If the padlock is still missing, proceed to the next fix.

2. Are your WordPress URLs set to HTTPS?

Even with a valid SSL certificate, your site will show "Not Secure" if WordPress still thinks your site is on HTTP. Go to Settings → General in your WordPress dashboard.

Locate WordPress Address (URL) and Site Address (URL). Both must start with https:// — not http://. Change them, save, and your site will reload securely. This single change resolves roughly 40% of warnings.

3. Is mixed content causing the warning?

Mixed content happens when your page loads over HTTPS but pulls in images, scripts, or iframes from HTTP sources. Browsers block or flag these as insecure. To find mixed content, open your site in Chrome, right-click and select "Inspect," then go to the Console tab. Any HTTP resource errors will show as "Mixed Content" warnings.

The fix: Use a search-replace tool in your database. Plugins like Better Search Replace or Velvet Blues Update URLs can change all http://yoursite.com references to https://yoursite.com in one pass. Run the tool on the postcontent and options tables. For theme and plugin hardcoded URLs, edit the relevant PHP files or use a constant in wp-config.php.

4. Have you forced HTTPS via .htaccess or server config?

Even after updating URL settings, visitors may still reach your site over HTTP if no redirect is in place. Add the following code to your .htaccess file (located in the root WordPress folder via FTP or cPanel File Manager), just above the # BEGIN WordPress line:

<IfModule modrewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

Save and test your site. On Nginx servers, add a similar redirect inside the server block. If you use Cloudflare, enable the Always Use HTTPS rule under the SSL/TLS tab.

5. Is your browser or plugin cache serving old HTTP versions?

Browsers aggressively cache HTTPS status. Clear your browser cache completely (in Chrome: Settings → Privacy and security → Clear browsing data → check "Cached images and files"). Also purge all caches from your WordPress caching plugin (WP Rocket, W3 Total Cache, or caching layer on your host).

If you use a CDN like Cloudflare, use the Purge Cache button in your dashboard. A hard refresh (Ctrl+F5 on Windows or Cmd+Shift+R on Mac) in an incognito window is often enough to confirm the fix.

6. Is your CDN or reverse proxy configured for SSL?

Services like Cloudflare, Sucuri, or StackPath sit between visitors and your server. If your SSL setting inside the CDN is "Flexible" instead of "Full" or "Full (strict)," the connection between the CDN and your server remains HTTP, causing mixed content. Log into your CDN dashboard and set SSL to Full or Full (strict).

Additionally, ensure your WordPress installation knows it's behind a proxy. Add this to wp-config.php (just before the / That's all, stop editing! / line):

if (isset($SERVER['HTTPXFORWARDEDPROTO']) && $SERVER['HTTPXFORWARDEDPROTO'] == 'https') {
  $_SERVER['HTTPS'] = 'on';
}

7. Could a plugin or theme be forcing HTTP?

Some security plugins, SEO plugins, or custom themes hardcode HTTP in their settings. Temporarily deactivate all plugins and switch to a default WordPress theme like Twenty Twenty-Four. If the warning disappears, reactivate plugins one by one until you find the culprit.

Once identified, check that plugin's settings for URL fields and update them to HTTPS. If the plugin hasn't been updated in years, replace it with a modern alternative. For custom themes, search the theme files for http:// and replace with https:// (use a child theme to preserve changes).

8. Is your database still storing HTTP URLs?

Even after updating WordPress settings, hardcoded URLs in posts, widgets, and menus may still point to HTTP. Run a global search-replace on your database. Use a plugin like Better Search Replace and target the following fields: postcontent, guid, optionvalue, metavalue. Replace http://yoursite.com with https://yoursite.com.

Pro tip: Do not change the home and siteurl rows inside the database directly — use the Settings page in WordPress instead. An incorrect value there can break your admin login.

9. Is your SSL certificate installed for all subdomains and domains?

A wildcard SSL certificate (e.g., *.yoursite.com) covers all subdomains. If you only have a single-domain certificate, visiting www.yoursite.com vs. yoursite.com may show the warning for the non-matching version. In your hosting control panel, ensure the certificate covers the exact domain your visitor types. Add both yoursite.com and www.yoursite.com to the certificate's Subject Alternative Names (SANs).

If your site is a multisite network, each sub-site needs its own SSL or a wildcard certificate covering the entire network.

10. Is your server time and date inaccurate?

SSL certificates rely on the server's clock to verify validity. If your server's time is off by more than a few minutes, the browser may reject the certificate as expired or not yet valid. On a VPS or dedicated server, run the command date via SSH. If it's wrong, update using sudo ntpdate -u pool.ntp.org or install ntp to keep it synced automatically. Contact your host if you cannot access the server shell.

11. Is your site being served from a different IP or domain?

If your DNS recently changed or your site loads from a staging domain (staging.yoursite.com) while your certificate covers only yoursite.com, you'll see the warning. Flush your DNS cache locally (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and verify the A record points to the correct IP. Staging sites often need separate SSL certificates or a temporary self-signed cert for testing.

12. What about content delivery networks and security firewalls?

Security firewalls like Wordfence or Sucuri can sometimes inject HTTP assets. Check your firewall plugin's settings for any "Force HTTP" or "HTTP only" options. For CDNs, confirm your Origin Pull certificate is installed on your server. Cloudflare offers a free origin certificate that you can upload via cPanel. After installation, set your CDN's SSL mode to Full (strict) to ensure end-to-end encryption.

How to prevent the "Not Secure" warning from returning

Enable auto-renewal for your SSL certificate. Most hosts offer a toggle for Let's Encrypt auto-renewal — turn it on immediately. Set up Google Search Console alerts for HTTPS errors so you're notified the moment a problem surfaces. Use a security plugin that scans for mixed content weekly. Finally, after any major WordPress update or plugin installation, check your site with the free SSL Labs test (ssllabs.com/ssltest) to catch issues early.

Frequently asked questions

Why does my WordPress site still show "Not Secure" after installing an SSL certificate?

An installed certificate is only half the battle. Your WordPress URLs may still point to HTTP, or your site may be serving mixed content. Follow the steps above — especially checking General Settings and running a search-replace for HTTP resources — to resolve the warning.

Do I need a paid SSL certificate for WordPress?

No. Let's Encrypt provides free, widely trusted certificates. Paid certificates offer higher validation levels (EV, OV) but the same encryption. For most WordPress sites, a free Let's Encrypt certificate is sufficient to remove the warning.

Will fixing the "Not Secure" warning improve my SEO?

Yes. Google uses HTTPS as a ranking signal. More importantly, visitors are far less likely to bounce from a site they trust. A secure site also passes referrer data in analytics, giving you cleaner traffic reports.

Can I fix the warning without accessing the WordPress admin area?

Yes. If you're locked out, use FTP or your host's file manager to edit wp-config.php and force HTTPS: add define('FORCESSLADMIN', true);. Then update the site URL using a database tool like phpMyAdmin — change the optionvalue for siteurl and home rows to HTTPS.

How long does it take for the "Not Secure" warning to disappear after applying these fixes?

Changes to URLs and redirects take effect immediately. Browser caching can delay the visual update by a few minutes up to 24 hours. Clear your browser cache and test in an incognito window. For CDN-cached sites, purge the CDN cache to see the padlock right away.

Final thoughts

A "Not Secure" warning kills trust before a visitor reads a single word of your content. The fixes here range from a 30-second settings change to deeper database and server configuration — but every single one is achievable with basic WordPress knowledge and a backup plan. Start with the SSL certificate status and the WordPress General Settings; eight times out of ten, that's all you need.

Once your site is healthy and secure, the next step is publishing content that keeps visitors engaged. nativeWP helps you automate that process — bulk-generate SEO-optimized articles with your own API key and schedule them straight to WordPress. Learn more about nativeWP.