Why You’re Seeing a WordPress Site Not Secure Warning and How to Fix It

Seeing a WordPress site not secure message beside your website’s public URL can be alarming, especially if you are worried that your WordPress site has been hacked.

In most cases, however, this warning does not mean your site has been compromised. It usually indicates that your website is using HTTP instead of HTTPS, or that the browser cannot verify a trusted SSL connection for your page or one of its resources.

The good news is that this is typically a connection and security configuration issue that you can fix.

Do not install another SSL plugin for WordPress or paste server rules until you know whether the failure is the certificate, URLs, a loaded resource, a proxy, or a cache.

What the warning means

HTTPS is the encrypted version of HTTP, the standard way browsers request web pages. It uses TLS and a certificate to establish a trusted connection to the domain. The warning usually means one of these things:

• The page is still loading over HTTP.
• The certificate is missing, expired, untrusted, or issued for another domain name.
• The hostname does not match the certificate. Visitors may use the www version while the certificate covers only the version without www, or the reverse.
• The page contains mixed content. An HTTPS page may load an image, script, style file, font, video, form, or other resource over HTTP. The browser can warn about, block, or partially load that resource.
• A CDN or reverse proxy disagrees with WordPress. Either can make WordPress misread whether the visitor is using HTTPS.
• A cache is showing an older response. A browser, plugin, host, or CDN may still serve a copy from before the HTTPS change.

“Not secure” is different from “Your connection is not private,” and both are different from malware, phishing, blacklist, or “This website has been reported as unsafe” warnings. A connection warning does not diagnose an infected site. If you also see suspicious redirects, changed files, or unknown administrator accounts, run a separate malware investigation.

⚠️ Note: If the warning appears only on a login page that is not secure, payment, or contact page, inspect that exact page and its loaded resources first. The homepage can be secure while one form, embedded service, or older template still uses HTTP.

Find the failing layer first

Open the exact URL visitors use, including the correct www or non-www version. Check both the HTTP and HTTPS versions in a private browser window, then match the symptom to the right fix.

• HTTP loads but HTTPS fails: Start with the certificate and the host or CDN configuration.
• HTTPS shows a certificate error: Check the domain name, expiry date, trust status, and certificate chain. NET::ERR_CERT_INVALID needs certificate or hostname repair. ERR_SSL_VERSION_OR_CIPHER_MISMATCH can indicate a TLS or certificate configuration problem that your host should inspect.
• HTTPS loads but parts of the page are not secure: Inspect mixed content in the browser’s developer tools. Reload the page and find requests beginning with HTTP.
• The public page works but WordPress redirects repeatedly, the login page loops, or the server returns 403: Stop adding redirect rules and check the server, proxy, or security logs. A 403 means access is forbidden, but it is not automatically an SSL failure.
• The warning appears only on a local or staging site: The certificate may be trusted only on that development computer. Do not apply local-certificate advice to a public production site.

🔍 Note: Test the hostname people actually visit. A certificate for example.com does not automatically prove that www.example.com, a subdomain, or a CDN endpoint is configured correctly.

Fix the warning in the right order

Follow these steps in order. If a step changes the symptom, stop and retest before making another change.

Backup your files and database before changing HTTPS

Create a current backup of the site files and database with a backup plugin before changing URLs, enabling redirects, replacing stored links, or editing server settings. For a step-by-step walkthrough, see how to back up a WordPress site. Confirm that you can restore the backup. Broad replacements can damage plugin settings stored in a special format.

🛡️ Note: A backup is useful only if it contains both the database and files and you know where the restore control is. If the host offers a staging environment, test URL changes there before editing the production site.

Check the certificate on the hostname visitors use

Inspect the certificate in the browser and use an independent certificate checker if needed. Confirm that:

• It is active and has not expired.
• Normal browsers trust it.
• It covers the exact hostname visitors use, including www, the root domain, and relevant subdomains.
• Its certificate chain is complete.
• The public endpoint serves it, rather than the hosting panel merely showing it as active.

This separates a certificate failure from a WordPress configuration failure. A certificate marked “active” in a hosting panel can still be wrong for the public hostname.

Install or renew the certificate through your host

If the certificate is missing or expired, follow your host’s current SSL or TLS instructions to install an SSL certificate on your WordPress site.Many hosts offer a free option through their dashboard if you are unsure where to start, check our guide on how to get an SSL certificate for WordPress. A paid certificate is not automatically more encrypted than a free, trusted certificate.

If your host does not manage certificates, follow the certificate provider’s instructions. Server setups differ, so do not copy another host’s files or commands.

Installing a certificate in a control panel does not prove that the exact public hostname serves it. Test the live URL after installation or renewal.

🧭 Note: Certificate setup is tied to the server and DNS architecture. If the site uses a CDN or reverse proxy, the edge certificate and the connection from the proxy to the origin may be separate settings; use the provider’s documented connection mode instead of guessing.

Change both WordPress URLs to HTTPS after the certificate works

In WordPress, open Settings > General and check these two fields:

• WordPress Address (URL): where WordPress files are located.
• Site Address (URL): the address visitors use.

Both should use the same official HTTPS address. If you cannot access the dashboard, use a host-supported recovery method, database tool, or WP-CLI, a command-line tool for managing WordPress. Do not guess at configuration-file edits on a live site.

Choose one owner for the HTTP-to-HTTPS redirect. It may be the host, CDN, web server, or a tested WordPress setting. Do not activate several force-HTTPS plugins or redirect systems at once.

A CDN or reverse proxy has browser-to-CDN and CDN-to-host connections. Check its connection mode, host certificate, and DNS records. Do not paste a configuration snippet into a live site until it matches your setup.

🔁 Note: HTTPS between the visitor and a CDN does not by itself tell WordPress that the origin request was HTTPS. A mismatched proxy setting can create a redirect loop even when the browser shows HTTPS.

Find and replace mixed-content URLs without risking the database

A certificate does not rewrite URLs already stored in WordPress. Old addresses can remain in posts, plugin settings, and page builders leading to issues like WordPress not loading CSS over HTTPS, broken scripts, or unencrypted images.

Use developer tools or a mixed-content checker to find the failing resource, then fix the URL where it originates. An image may be in post content, a script in the theme, or a form or font in an outside service. Replace any outside resource that does not support HTTPS.

If many internal URLs need changing, use a WordPress search-and-replace tool that handles stored data safely. Search for the exact old site address, run a dry run, select only the intended tables, and keep the backup. Reload affected pages because plugins, themes, CDNs, and outside services may generate separate URLs.

🧩 Note: Do not replace every occurrence of http with https. Replace the old site address, review the tables in scope, and check third-party resources separately. Some WordPress data is serialized, so a tool that understands WordPress storage is safer than editing rows manually.

Clear caches and test every important visitor path

Clear caches only after the configuration is corrected. Check the WordPress cache plugin, host cache, CDN cache, and browser cache. For broader WordPress performance and cache guidance, review which layer you are changing. A private window helps show the current response, but clearing a cache cannot repair an expired certificate or an HTTP resource.

Test the actual hostname, not only the homepage in one browser. Check:

• HTTP redirects to the intended HTTPS URL once.
• The homepage, older posts, landing pages, and any subdomains or account areas visitors use.
• Login, contact, newsletter, payment, and checkout forms, when those features exist.
• Images, scripts, styles, fonts, video, embedded content, and the certificate expiry.

🧪 Note: If a private window works but a normal window does not, stale browser or edge cache is a reasonable suspect. If both fail, return to the certificate, URL, redirect, and loaded-resource checks; cache purges do not repair those settings.

Recover from common HTTPS breakages

If you lose dashboard access after changing URLs, stop making changes and contact the host if you are unsure how to recover. Likely causes include mismatched URLs, a redirect loop, a proxy problem, a plugin conflict, or a server security rule.

If the site redirects repeatedly, identify which layer issues each redirect. Remove or disable the duplicate redirect owner through a safe recovery path, then follow the host or CDN’s proxy guidance. Do not bypass a browser warning to regain access.

A 403 after enabling HTTPS is not automatically an SSL problem. It may be a WordPress 403 forbidden error caused by a server permission, firewall, or security-rule issue. Ask the host to check its access and security logs before changing server settings.

🚧 Note: A 403 means a layer refused the request. It can appear after a firewall rule, host security policy, or permission change, so changing certificates repeatedly can make the diagnosis harder.

If the certificate error remains, recheck the hostname, certificate chain, and expiry. Then check domain records and the CDN connection. Changing browsers can help confirm the symptom, but it will not repair the certificate.

Prevent the warning from returning

• Keep automatic certificate renewal enabled when your host supports it, and monitor renewal failures.
• Keep the official HTTPS URL in WordPress, plugins, themes, page builders, sitemaps, and external services.
• Document the single system that owns redirects and review it after host or CDN changes.
• Back up before major updates or database changes, and keep a tested restore path. Update WordPress, themes, and plugins, and remove components you no longer use.
• Use strong, unique passwords, suitable user roles, and two-factor authentication. Monitor important pages, forms, and certificate expiry.

If the whole site moved from HTTP to HTTPS, add or verify the HTTPS property in Google Search Console and check its HTTPS report. An HTTP-to-HTTPS change does not require Google’s Change of Address tool.

📈 Note: Treat the Search Console update as a reporting and discovery task, not as the fix for the browser warning. Google cannot make an expired certificate, mixed-content request, or redirect loop secure.

Add security beyond HTTPS

HTTPS protects data while it travels between the browser and the site. It does not scan WordPress files for malware, clean harmful code, block malicious requests, replace updates, or create backups.

Once the connection warning is fixed, add controls for those separate risks. A security plugin such as MalCare can provide malware scanning and cleanup along with WordPress firewall protection that filters malicious traffic. It is a separate security layer, not an SSL certificate installer and not a fix for a hostname mismatch.

🔒 Note: Keep the two diagnoses separate. A clean malware scan does not validate a certificate, and a valid certificate does not show that WordPress files or administrator accounts are safe.

FAQs

Is a “Not secure” WordPress site hacked?

Not necessarily. The label concerns the connection and can come from HTTP, a certificate, mixed content, a proxy, or an old cache. It does not prove that the site is infected. Run a malware check if you see suspicious redirects, changed files, or unknown users.

Why does the warning remain after installing SSL?

Check the live certificate and hostname first. Then review WordPress URLs, mixed-content requests, CDN or proxy settings, duplicate redirects, and caches. A hosting panel can show a certificate as active even when the public hostname serves a different one.

What should I do if HTTPS locks me out of WordPress?

Stop bypassing the browser warning and stop adding configuration rules. Use a backup or host-supported recovery path, then check WordPress URLs, proxy settings, and server logs. Ask the host to identify the layer issuing the redirect or denying access.

What does “parts of this page are not secure” mean?

It means an HTTPS page is loading one or more resources over HTTP. Find the request in developer tools and repair that URL in the post, theme, plugin, page builder, or outside service that supplies it.

Is HTTPS the same as WordPress security?

No. HTTPS encrypts the connection. WordPress security also needs updates, backups, and access protection. Malware detection, firewall protection, and monitoring cover other risks. A security plugin can help with some of those tasks, but it cannot replace a valid certificate.

Conclusion

The fastest safe fix is diagnosis first: confirm the live certificate and hostname, set both WordPress URLs to HTTPS, repair mixed content, keep one redirect owner, clear relevant caches, and test important pages and forms. If HTTPS causes a loop or blocks access, stop changing settings and involve the host.

HTTPS protects the connection, but it is only one part of WordPress security. Renew certificates, maintain backups and updates, and add a security plugin when you need separate malware scanning, cleanup, and firewall protection.