Read the exact browser warning before changing WordPress settings. An HTTP connection notice, a full-page certificate error and an unsafe-site alert point to different problems.
Check the affected hostname and secure connection first, then correct site addresses or old resource links where the evidence calls for it.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Warning | First investigation | Next check |
|---|---|---|
| HTTP connection notice | Working HTTPS endpoint | Exact hostname and redirect route. |
| Certificate privacy error | Name, validity and trust | Served certificate at the failing address. |
| One device alone fails | Device time and browser-specific guidance | Same URL on a trusted second device. |
| Unsafe-site alert | Security incident | Warning details and site remediation. |
Identify which warning visitors see
Start with the complete URL and a copy of the message. Google’s connection security guide distinguishes connection notices from privacy errors and unsafe-site warnings. This distinction matters when you ask a host for help: a certificate problem should not be investigated as if it were an ordinary WordPress content error.
If the address begins with HTTP, check whether the intended HTTPS address works normally. If HTTPS instead produces a privacy error, keep the error code. Certificate name, trust, and date errors offer more useful clues than a general description that the site looks insecure.
Check the certificate for the exact address
Hostname check: compare the address visitors use with the names covered by the served certificate, including a relevant www address or subdomain. An installed certificate in a hosting panel is not proof that the failing endpoint serves it correctly.
Your hosting dashboard may show an installed certificate, but that alone does not establish that every address is covered and served correctly. Compare the domain in the browser with the domains included in the certificate. The www version and a separate subdomain deserve their own checks.
For example, your main homepage may load over HTTPS while a link to an old subdomain fails. That does not necessarily mean the main certificate is broken. It may mean that the old address needs its own configuration or that the link should point to the current destination.
Ask the hosting provider to confirm the certificate’s validity, renewal status, and delivery on the affected hostname. If a CDN sits in front of the host, identify which connection is failing rather than assuming that the dashboard showing a certificate belongs to the layer your browser sees.
Separate a site problem from a device problem
A second device or trusted network can provide a helpful comparison. If the same URL fails everywhere, the site’s configuration deserves attention. If only one device has the problem, check that device’s date and time and read the browser’s guidance for the specific error.
The Chrome error guide explains several privacy and certificate messages. Use the relevant guidance without bypassing the warning to enter a password or payment details. A comparison test is meant to locate the problem, not to make an unsafe connection appear acceptable.
Move WordPress to HTTPS after the connection works
WordPress can use HTTPS, but the secure server connection needs to be available first. Its HTTPS documentation describes that foundation. Changing a WordPress address to HTTPS before the host can serve it successfully may leave the dashboard difficult to reach.
Keep a backup and review the installation’s real URL arrangement with your host before changing addresses. WordPress installed in a subdirectory may have a different application address from the public homepage. A copied pair of example URLs is not a substitute for checking that arrangement.
Review old links and mixed resources
Once the main HTTPS page works, inspect any remaining browser messages and failed resources. An old image, stylesheet, or embedded resource may still use an HTTP address. The correction belongs to the specific source of that link, such as post content, theme settings, or an external embed.
Try one affected page first. Replace a confirmed old link with the working secure address and check the result. A broad database replacement needs a backup and a tool suited to WordPress data; casual text replacement across unfamiliar stored settings can introduce new errors.
Test the paths people use
- Check the intended HTTPS homepage.
- Check a normal post and the login route.
- Inspect an affected form or account page without entering sensitive data through a warning.
- Confirm an old HTTP link reaches the correct HTTPS destination without a loop.
Check the homepage, a normal post, the login screen, and any form or checkout page. Also try an older HTTP link and confirm that it reaches the intended HTTPS page without bouncing between addresses. A working homepage alone may miss the route used by a visitor’s bookmark.
When you contact support, include the failing hostname, exact warning, time of the test, and whether another device produced the same result. Those details help resolve the actual connection issue while keeping the visitor experience straightforward and trustworthy.
Confirm the connection and page resources
Repeat the affected URL on the original browser and a trusted comparison device. Inspect remaining failed resources after the main connection works. Keep the exact warning and confirmed hostname repair in maintenance notes; bypassing the warning is not a repair.