Chrome’s “Not secure” label usually means the browser cannot confirm a private connection to your WordPress site; it does not, by itself, prove that WordPress is defective. First identify the exact warning. A broken or missing HTTPS setup calls for a server and WordPress configuration check, while Chrome’s full-page red “Dangerous” warning is a separate Google Safe Browsing issue.
What Chrome’s warning means
Chrome uses connection-status labels to tell visitors whether their connection to a site is private. A “Not secure” label can mean the page is being served over HTTP rather than HTTPS. Google warns that information sent over a connection that is not private may be viewed or changed by someone else. Google Chrome Help says, “To resolve this issue, the site owner must secure the site and your data with HTTPS.” See Google’s explanation of connection security in Chrome.
HTTPS protects the connection between the visitor and the site; it does not certify that the site’s content or operator is trustworthy. Visitors should still check the site name, even when Chrome shows a secure connection.
Tell a connection warning from a dangerous-site warning
| What Chrome shows | What it points to | What to investigate |
|---|---|---|
| “Not secure” in the address bar | The connection may be using HTTP rather than HTTPS. | Whether HTTPS works for the domain, then redirects and WordPress URLs. |
| A certificate or private-connection error | Chrome could not establish a trusted HTTPS connection. | Certificate coverage and status, and the server’s HTTPS configuration. |
| A full-page red “Dangerous” warning | Google Safe Browsing has flagged the site. | The Safe Browsing issue itself—not just the certificate. Do not advise visitors to bypass the warning or enter personal information. |
The red warning is not interchangeable with an address-bar connection label. Google advises visitors not to enter personal information or use a site displaying its dangerous-site warning. More detail is available in Chrome Help.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
How to diagnose and fix a WordPress HTTPS warning
Follow the steps in order: make sure the server can serve HTTPS before changing WordPress’s addresses, then deal with redirects and any leftover HTTP content.
1. Identify the exact warning
Note whether Chrome says “Not secure” in the address bar, shows a certificate or private-connection error, or replaces the page with a red dangerous-site screen. These signals point to different problems. A red Safe Browsing screen needs a separate safety investigation; installing a certificate alone does not clear that diagnosis.
Rank #2
2. Check HTTPS and the certificate with your host
Open the HTTPS version of your domain and see whether it loads without a certificate error. WordPress supports HTTPS when a TLS/SSL certificate is installed and available to the web server. The WordPress Advanced Administration Handbook explains HTTPS and SSL for WordPress.
If HTTPS fails, ask your web host to check that the certificate is installed, covers the exact hostname visitors use, has not expired and is renewing correctly, and that the server’s secure virtual host is configured. A warning alone does not establish which of these is wrong, so do not assume the certificate is invalid without checking it.
Recommended Free Tools
3. Set WordPress’s two site addresses to HTTPS
Once HTTPS works at the server, go to Settings → General in a single-site WordPress dashboard. Check these separate fields:
- WordPress Address (URL): the address for the WordPress core files.
- Site Address (URL): the public address visitors use.
Set each to its intended HTTPS address. WordPress’s migration guide says both addresses should include https:// and should not end in a slash. The values can differ if WordPress is installed in a subdirectory, so do not make them identical unless that matches your setup.
Rank #4
If you cannot access the dashboard, WordPress documents configuration-file and database recovery options in its migration guide. Choose the method appropriate to the installation; direct database editing is not the default fix for every site. Back up before making database changes.
4. Redirect HTTP visitors to the chosen HTTPS address
After HTTPS loads correctly, configure the host or server to redirect old HTTP requests to the HTTPS version you intend to use as canonical. Test the homepage, representative inner pages, and both www and non-www addresses if both have been used.
If a redirect loops, look for conflicting rules in WordPress, the host, a CDN, or a reverse proxy. A proxy that terminates SSL must pass the protocol information correctly to WordPress; otherwise, WordPress may keep treating a secure request as HTTP and redirect repeatedly. WordPress describes this reverse-proxy issue in its HTTPS guidance. The correct redirect configuration depends on the hosting stack; there is no one rule that fits every server and CDN.
5. Find and correct leftover HTTP resources
A page can load at an HTTPS address yet still request images, scripts, styles, or other resources through HTTP. Inspect the affected page in the browser’s developer tools, including its console, and look for http:// references in the rendered page. Check media links, theme and plugin output, and third-party embeds. Where HTTPS is available, correct the original URL or setting rather than applying a blind global replacement.
If you need to replace URLs stored in the database, first make a database backup you can restore. WordPress warns that a naive search-and-replace can damage PHP serialized data. WP-CLI’s wp search-replace understands serialized data and provides --dry-run to preview changes. Review the preview, limit the replacement to the intended URLs and tables, and only then apply it. Multisite and custom installations may require a different scope. See the WP-CLI search-replace command reference.
6. Retest and classify what remains
- Check that HTTP requests redirect to the chosen HTTPS address.
- Open the HTTPS site and confirm Chrome does not report a certificate problem.
- Test key pages, login and admin access, and any pages where insecure resources appeared.
- If a red Safe Browsing warning remains after HTTPS works, investigate the flag separately; it does not, on its own, show that the WordPress URL settings are still wrong.
What Chrome’s planned HTTPS-default change means for site owners
Google’s Chrome Security Team announced on October 28, 2025, that Chrome 154, scheduled for October 2026, would change Chrome’s default settings to enable “Always Use Secure Connections” for public sites. Google also announced an earlier Chrome 147 step, scheduled for April 2026, for users who opted into Enhanced Safe Browsing. These are announced release plans, not evidence that the changes have already reached every user. The announcement is in Google’s “HTTPS by default” post.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Google reported that in a Chrome 141 experiment, the median user saw fewer than one warning per week and users at the 95th percentile saw fewer than three. Those are warning-frequency results from the experiment, not statistics about WordPress sites. Google also estimated HTTPS use for public-site navigations, excluding private-site navigations, at nearly 97% on Linux, 98% on Windows, and more than 99% on Android and Mac. These platform figures describe Google’s HTTPS transition, not an individual site’s security. See the same Chrome Security Team announcement.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
