You open your WordPress login page to make a quick change and notice “Not Secure” beside the address. The homepage looked fine a moment ago, so you stop before entering your password and start wondering whether your SSL certificate has expired, your site has been hacked, or you’ve somehow locked yourself out.
If you searched for “WordPress login not secure,” you’re probably looking for a clear answer, not another vague instruction to “install SSL.”
Take a breath: this warning is often caused by a mismatch between the login URL, certificate, WordPress settings, or hosting setup, and it can usually be traced without making risky changes. This guide will help you understand what the warning means, identify the problem safely, and confirm that your login page is secure before you sign in.
TL;DR: Check the login URL, certificate, and HTTPS settings first, then inspect redirects, CDN or proxy settings, mixed content, and stale caches. If you need help managing HTTPS after the certificate is installed, compare WordPress SSL plugins by the specific problem they solve. Keep a security plugin active for additional malware, vulnerability, and login protection. Only change advanced settings such as
FORCE_SSL_ADMINor database URLs after creating a backup and confirming which part of the connection is failing.
Why does only the WordPress login say “Not Secure”?
The homepage and login page may not follow exactly the same path. They can use different redirects, assets, cached responses, or hostnames. A secure homepage does not prove that your WordPress login is using the same secure connection. The warning may appear because:
- The login URL still uses HTTP.
- The certificate does not cover the hostname.
- The site switches between
wwwand non-www. - A CDN or reverse proxy passes the wrong protocol to WordPress.
- The login page loads a script, stylesheet, image, or font over HTTP.
- A cache is serving an older version of the page.
HTTPS protects the connection between your browser and the website. For that protection to work properly, the hostname, certificate, server, CDN, proxy, and WordPress settings must agree about the site’s identity.
This is the mistake I see most often: someone changes a WordPress setting before checking the certificate or proxy. A small configuration problem can then turn into a redirect loop or a login failure. There’s no need to panic, but it is worth checking each layer in the right order.
Check the exact login URL first
Because the warning appears on the login page, begin with the address you are actually visiting. The homepage can look perfectly normal while the login URL points somewhere else. Before entering your password, confirm that the login page uses HTTPS, the correct hostname, and a valid certificate. Check that:
- The address begins with
https://. - The hostname is correct, such as
example.comorwww.example.com. - The certificate is valid for that exact hostname.
- The browser does not report an expired, invalid, or untrusted certificate.
- The address does not switch between HTTP and HTTPS.
- The address does not switch unexpectedly between
wwwand non-www.
For example, https://example.com/wp-login.php and https://www.example.com/wp-login.php are different hostnames. A certificate may cover one but not the other.
If the certificate is missing, expired, incorrectly installed, or not renewing, contact the provider that manages it. That may be your hosting company, CDN, certificate authority, or IT provider. If no certificate exists, first get an SSL certificate for the WordPress site, then follow the correct process to install the SSL certificate for that hosting setup. An SSL plugin cannot issue or renew a certificate simply because it is installed. The service that controls the certificate must install, configure, or renew it.
📝 Note: Never bypass a browser “Your connection is not private” warning to submit your password. Removing the warning from view does not make the connection safe.
Confirm the WordPress URL settings
If the certificate looks valid, WordPress itself is the next sensible place to check. Its URL settings tell the site which address to use when generating links and handling requests. The WordPress Address and Site Address should normally use the same HTTPS protocol and canonical hostname.
In WordPress, open Settings > General and check both addresses. They should use the same format, such as:
https://example.comhttps://example.com
Avoid a mismatch such as:
- WordPress Address:
http://example.com - Site Address:
https://www.example.com
That kind of mismatch can create HTTP links, unexpected redirects, login loops, or a login form that submits to the wrong address. If you cannot access wp-admin, don’t guess at database values or paste a configuration change from an unrelated tutorial. Create a backup or host snapshot first, then ask your host or WordPress administrator to confirm the correct values.
Check redirects, CDNs, and proxies
If the URL settings look right but the browser keeps changing the address, the problem may be between a visitor and your WordPress installation. A CDN, or content delivery network, serves site content from distributed servers. A reverse proxy sits between visitors and your hosting server and can handle traffic before it reaches WordPress.
A redirect loop or return to HTTP usually means that WordPress, the server, or a proxy disagrees about whether the original request used HTTPS.
For example, a visitor may connect to the CDN over HTTPS, while the origin server receives the request without being told that HTTPS was used. WordPress may then generate HTTP links or redirect the visitor back to HTTPS, creating a loop. Check whether:
- The browser requests the intended HTTPS hostname.
- The CDN or proxy keeps the same hostname.
- The origin server receives the correct HTTPS status.
- WordPress generates HTTPS links.
- The login form stays on the same secure hostname.
If the address cycles between HTTP and HTTPS, check the CDN’s SSL mode, origin redirect rules, and WordPress URL settings together. Review the correct way to redirect WordPress from HTTP to HTTPS for your stack. Avoid copying an .htaccess rule, proxy header, or server configuration from another website because the correct setting depends on your hosting stack.
Check for mixed content
If the certificate and redirects are working, the page may still be loading individual resources through an insecure connection. Mixed content means an HTTPS page requests an image, script, stylesheet, font, or other resource through HTTP.
Open your browser’s security details or developer tools and identify the exact insecure URL. Common sources include:
- A theme or plugin asset, including CSS that WordPress still loads over HTTP instead of HTTPS
- A login logo
- An old stylesheet or JavaScript file
- A page-builder setting
- A database value saved before HTTPS was enabled
- A cached copy of the login page
Once you find the source, fix that setting or file and then clear the relevant caches. Avoid a blind database search-and-replace because WordPress can store serialized data, and careless editing can damage those values.
📝 Note: Create a tested backup before changing database URLs. If you cannot identify the old URL confidently, ask your host or a WordPress developer to trace it first.
Clear caches after fixing the cause
At this point, you may have corrected the problem but still see the old warning. That can happen when a browser, caching plugin, host, or CDN continues serving an earlier response. Clearing a cache can reveal a fix, but it cannot repair a certificate, redirect, or proxy problem. Clear caches in a controlled order:
- Open the login page in a private browser window.
- Purge the WordPress caching or optimization plugin.
- Purge the hosting cache.
- Purge the CDN or reverse-proxy cache if it serves the login page or its assets.
Then open the exact login URL again. Check that it stays on HTTPS, uses the correct hostname, shows a valid certificate, and loads without mixed-content warnings.
Should you force the admin area to use HTTPS?
Only consider FORCE_SSL_ADMIN after the HTTPS path already works. It is an enforcement setting, not a repair tool.
FORCE_SSL_ADMIN requires HTTPS for the login and administration areas, but it does not install a certificate or fix a proxy configuration. Before enabling it, confirm that:
- The certificate covers the login hostname.
- HTTPS reaches the origin correctly.
- WordPress uses the intended HTTPS URLs.
- The CDN or proxy passes the correct protocol information.
- You have a backup or host snapshot.
- You know how to reverse the change if login stops working.
If you do not manage wp-config.php or the server, ask your host for the supported procedure. Adding a setting in the wrong place, or enabling it while the proxy is misconfigured, can cause errors or lock you out.
What if you cannot access wp-admin?
Being locked out can make the problem feel worse than it is, but the exact error will usually tell you which layer needs attention. Tell your host whether you see a certificate warning, redirect loop, 403 error, 500 error, or blank page because each symptom points to a different problem.
If the certificate is invalid, contact the provider that manages it. If the page loops between URLs, ask your host to inspect the redirect and proxy path. If a recent URL or configuration change caused the lockout, use a known-good backup or host snapshot after confirming what it will restore.
When contacting support, provide:
- The exact login URL
- The hostname shown in the browser
- The full error or warning
- Whether the page redirects
- Whether the homepage still works
- When the problem began
That information gives support something useful to investigate. It is much more effective than simply asking them to “install SSL.”
Verify the login before entering your password
Once you have made a change, test the complete login path before signing in. You want to confirm that the warning has disappeared for the right reason, not just because one browser stopped displaying it.
The problem is resolved when the URL, certificate, redirects, form action, and page resources all use the same trusted HTTPS identity. Check that:
- The login URL starts with HTTPS.
- The hostname is correct.
- The certificate is valid and current.
- The address does not switch to HTTP.
- The address does not switch unexpectedly between
wwwand non-www. - The page has no mixed-content warnings.
- The form submits to an HTTPS URL on the same hostname.
- A private window or second browser shows the same result.
Only after these checks pass should you enter your password and test wp-admin.
Add a security plugin and protect the account
Fixing HTTPS protects the connection, but it does not protect your WordPress account from every other threat.
HTTPS protects your password while it travels between your browser and the site, while a security plugin can add malware scanning, vulnerability checks, firewall rules, or login protection, depending on the product and plan. You should also use:
- Strong, unique WordPress passwords
- Two-factor authentication for WordPress accounts
- Current WordPress, plugin, and theme versions
- Limited administrator access
- Login rate limiting or firewall protection
- Reliable backups
- Malware and vulnerability monitoring
A security plugin cannot issue a certificate or repair WordPress URLs, CDN settings, proxy rules, or server redirects. Fix the HTTPS path first, then use security tools for the risks they are designed to manage. So, if your login page suddenly says “Not Secure,” don’t assume the worst. In most cases, the warning identifies a configuration problem that you can trace and correct safely.
FAQs
Why does my WordPress login say “Not Secure”?
The login request may use an invalid certificate, HTTP URL, old hostname, insecure redirect, mixed content, or incorrect proxy configuration. Check the exact login URL rather than relying on the homepage.
How do I fix an unsecured WordPress login?
Check the certificate and hostname, confirm that the WordPress URLs use HTTPS, inspect redirects and proxy settings, identify mixed content, clear caches, and test again before changing advanced settings.
Why is my homepage secure but my WordPress login is not?
The homepage and login page may use different redirects, assets, cached responses, or hostnames. A secure homepage does not prove that the login form uses the same HTTPS path.
Can I force WordPress admin to use HTTPS?
Yes, you can use FORCE_SSL_ADMIN after confirming that the certificate, server, proxy, hostname, and WordPress URLs are correct. Enabling it too early can cause a redirect loop or lockout.
Is HTTPS enough to protect my WordPress login?
No. HTTPS protects data in transit, while strong passwords, multi-factor authentication, updates, limited permissions, rate limiting, backups, security plugins, and malware monitoring protect against other risks.
Conclusion
A WordPress login marked “Not Secure” usually needs a careful check of the entire login path, not a rushed SSL plugin installation. Start with the exact hostname and certificate, then make WordPress, the server, and any CDN or proxy agree on HTTPS before checking mixed content and caches.
Once the login stays on a valid HTTPS connection in a private browser window, add the account protections your site needs and document an administrator account-recovery path. If the certificate or proxy is managed by your host, give support the exact URL and error instead of changing settings blindly. This is usually fixable, and a careful check is safer than a rushed one.
