Installing a certificate does not guarantee that every address and resource on your website is served securely. The homepage may load over HTTPS while a second hostname presents the wrong certificate. An old image, form or script may still use HTTP. A visitor’s device can also report a problem that other devices do not reproduce.
The useful question is not simply whether SSL is installed. It is which connection fails, for which address, and under what conditions. This diagnostic sequence helps you collect that evidence before changing WordPress, hosting or CDN settings. Keep a record of the original configuration and make one targeted change at a time.
Record the exact warning and address
Copy the complete URL, including its hostname and path. Record the browser, device, time and wording of the warning. A label beside an HTTP address is different from a full-page certificate error. A blocked resource on an HTTPS page is another separate case. Treating them as the same symptom leads to unnecessary certificate replacements.
Check whether the issue affects the homepage, a particular article, the login screen or checkout. Repeat the affected address in a private window and on another device if possible. Do not bypass certificate warnings to enter passwords or payment details. Your goal is to identify the failure, not make the browser stop reporting it.
Test each hostname independently
Compare the www and non-www versions of the address. They are different hostnames, even when you intend one to redirect to the other. A visitor arriving over HTTPS needs a valid connection to the first hostname before the browser can follow its redirect. A redirect cannot repair a certificate error that prevents that initial connection.
Use your browser’s certificate information to check the names covered and the validity dates. If one hostname fails, ask the hosting or CDN operator to check the certificate actually served for that hostname. A certificate visible in a control panel is not proof that the same certificate reaches the visitor. Keep your preferred canonical hostname consistent once both entry points work.
Separate the document from its resources
Open the affected page’s developer tools and inspect its security information. Chrome’s security-panel documentation explains how to view certificate details and identify non-secure resource requests. This helps distinguish a problem with the main page from a problem introduced by something that page loads.
A useful incident note identifies the resource URL, its type and where it was requested. For example, an old banner image in a blog post needs a different fix from a third-party script injected by a plugin. If the browser points to a stylesheet, inspect the image or font reference inside that stylesheet rather than repeatedly editing the post body.
Repair mixed content at its source
Mixed content occurs when a secure page requests resources through an insecure connection. Browser handling depends on the resource type: some requests may be upgraded and others blocked. The MDN mixed-content guide describes these distinctions. A page that looks normal is therefore not sufficient evidence that its resource URLs are correct.
Find the stored source of each HTTP reference. It may be a post, widget, builder setting, stylesheet, plugin option or external embed. Verify that the resource is available over HTTPS, then update that specific reference. If the external provider cannot serve the resource securely, replace or remove the dependency. Do not disable browser protections to keep it working.
A broad database replacement deserves extra care because WordPress can store structured and serialized values. Use a tool that understands the relevant storage format, review a dry run and preserve a backup. Do not replace every occurrence of a domain just because one asset is wrong. Separate content links from resources loaded by the page.
Check redirects and proxy behaviour
Follow the redirect path for the exact failing URL. Look for a loop between HTTP and HTTPS, repeated jumps between hostnames or a final destination that unexpectedly returns to HTTP. Record the status and destination of each hop. Preserve the original path and query string when evaluating the intended result.
On sites behind a CDN or reverse proxy, the visitor connection and the origin connection are separate. Confirm how the proxy communicates the original scheme to WordPress and how the origin is configured. Avoid changing several HTTPS-enforcement settings simultaneously. A host-level rule, a CDN rule and a plugin can interact in ways that are difficult to untangle without a recorded baseline.
Investigate device-specific failures carefully
If the same URL works on other devices, check the affected device’s date and time and whether it uses a different network. A managed network, security application or browser extension can alter the connection path. Document the difference and involve the responsible administrator where appropriate. Do not remove managed security controls as a routine troubleshooting shortcut.
Similarly, a successful test from your office does not establish that every visitor receives the same result. Different hostnames, cached responses or network routes may expose different problems. Ask for the exact address and error rather than telling a visitor to clear everything. Their evidence can reveal a configuration gap your own test missed.
Verify the fix with a small test matrix
Retest the original failing URL and its alternate hostname. Check a representative article, contact form and any transaction page affected by the change. Confirm both the document connection and its resource requests. If you changed cached content, clear the relevant cache and repeat the signed-out test.
- The intended HTTPS address loads without a certificate error.
- Alternate entry addresses reach the intended destination.
- No required resource is blocked because it still uses HTTP.
- Forms and interactive elements still work after the change.
- The original device or network reproduces the successful result.
Keep the error evidence, change record and verification results together. If you need the broader setup sequence, see our website security-warning guide. A durable fix corrects the failing connection or reference; it does not rely on visitors ignoring the warning.
Frequently Asked Questions
Why does my site say Not Secure when HTTPS works?
Usually mixed content: images, scripts or stylesheets still loading over http.
How do I fix mixed content in WordPress?
Update the site URL to https, replace http links in the database and fix hard-coded theme or plugin URLs.
Does Not Secure affect SEO?
HTTPS is a light ranking signal, and security warnings reduce trust and conversions.
Who can fix SSL and security warnings?
Our web hosting team resolves certificate and mixed content issues.
