Why does a website still show Not Secure after SSL setup

After SSL is installed, a website can still show Not Secure if the browser detects that something on the page is not being loaded over HTTPS, if the certificate is not correctly applied to the active domain, or if there is a redirect, cache, or configuration problem. In many hosting and control panel environments, including Plesk-based setups, this is usually fixable without replacing the certificate.

Why a site can still show Not Secure after SSL setup

Installing an SSL certificate is only one part of enabling HTTPS. The browser must also confirm that the page, its resources, and its redirects are all using a secure connection. If even one element is still loaded through plain HTTP, the page may be flagged as not fully secure.

The most common reasons are:

The certificate is installed, but the domain still opens on http:// instead of https://.
The certificate does not match the exact hostname being visited, for example www versus non-www.
The website contains mixed content, such as images, scripts, stylesheets, or fonts loaded over HTTP.
A redirect is missing, incomplete, or creates a loop.
The browser is showing a cached version of the page or old security state.
The SSL certificate is installed on the server, but not assigned to the correct virtual host or domain in the control panel.
Security headers, proxy rules, or CDN settings are causing inconsistent HTTPS behavior.

What the browser actually checks

Modern browsers do not only check whether a certificate exists. They also evaluate whether the page is fully served over HTTPS and whether all loaded assets are secure. If the page includes a single insecure resource, the browser may display a warning icon, a “Not Secure” label, or a partially secure state.

Typical things that can trigger the warning include:

An image embedded from an HTTP URL.
JavaScript libraries loaded from a non-secure external source.
Stylesheets or fonts referenced with http://.
Forms sending data over HTTP.
Canonical, hreflang, or sitemap URLs still pointing to HTTP.
Old hardcoded links inside the website database or theme files.

Check whether the certificate is valid for the exact domain

One of the first things to verify is whether the SSL certificate covers the domain the visitor is using. A certificate issued for example.com does not automatically secure www.example.com unless it includes that hostname as well. The reverse is also true.

What to verify in the control panel

The certificate is installed for the correct domain or subscription.
The certificate includes the correct Common Name and Subject Alternative Names.
The active domain points to the same hosting account where the certificate is installed.
The certificate is not expired or replaced by a self-signed certificate.

In Plesk, it is common to check the domain’s hosting settings and SSL/TLS Certificates section to confirm that the correct certificate is selected for the site. If the certificate is only installed at the server level but not assigned to the website, the browser may still show warnings.

Make sure the website redirects all traffic to HTTPS

If visitors can still reach the site on HTTP, the browser may load the insecure version first. Even if HTTPS is available, users may see a warning or an insecure indicator when they land on the non-secure URL.

You should redirect all HTTP requests to HTTPS permanently. This helps both security and SEO because search engines and users consistently reach the secure version of the site.

Recommended redirect behavior

HTTP should redirect to HTTPS with a 301 status code.
Non-www and www versions should resolve consistently.
There should be one preferred canonical version of the domain.
The redirect should not create loops between HTTP and HTTPS.

In Apache environments, redirects are often configured in the website’s virtual host, .htaccess, or control panel rules. In managed hosting environments, the hosting platform may provide a built-in option to force HTTPS. If that option exists, use it carefully and confirm that the final destination is the secure version of the same site.

Look for mixed content on the page

Mixed content is one of the most common reasons a site still appears not secure after SSL setup. This happens when the main page loads over HTTPS, but some assets are still loaded over HTTP. Even a single insecure asset can reduce trust in the page.

Common mixed content sources

Theme images stored with absolute HTTP URLs.
Embedded video or map scripts from old links.
Third-party widgets that still use HTTP endpoints.
Inline CSS or JavaScript referencing non-secure assets.
Custom font files served from an insecure path.

To fix mixed content, search your website files, database content, and CMS settings for http:// references. Replace them with relative URLs or HTTPS URLs. If your website uses a CMS such as WordPress, Joomla, or another platform, update the site and home URLs in the application settings first, then perform a search-and-replace for internal content.

How to identify mixed content quickly

Open the browser developer tools and check the Console tab.
Look for “Mixed Content” warnings.
Inspect the Network tab for requests still using HTTP.
Test the page in an incognito or private window to reduce cache effects.

Confirm that the correct website version is being served

Sometimes the SSL certificate is correctly installed, but the domain is still serving another site, an old alias, or a default hosting page. This can happen when DNS, virtual host mapping, or domain alias settings are not aligned.

Things to check in hosting setup

The domain’s DNS points to the correct server.
The website is attached to the correct subscription or hosting package.
The document root contains the intended application files.
No staging site or temporary alias is overriding the live site.
The certificate is assigned to the domain that is actually resolving in DNS.

If you recently changed DNS records, remember that propagation can take time across Europe and beyond. During propagation, some visitors may reach the new secure site while others still see the old environment.

Check browser cache and cached SSL state

Browsers store website data, redirects, and security state. After you fix SSL settings, your browser may still display the old warning because it has cached the previous version of the site.

Practical checks

Clear browser cache and cookies for the domain.
Open the website in a private browsing window.
Test from another browser or device.
Check whether a service worker or local cache is serving old resources.

This step is especially useful when the site looks correct for some visitors but not for others. If the issue appears only in one browser, the hosting configuration may already be correct and the problem may be local caching.

Verify SSL settings in Plesk or a similar control panel

In managed hosting platforms and control panels, SSL installation usually involves more than uploading a certificate. The certificate must be active for the site, and HTTPS must be enabled at the web server level.

Typical items to review

The domain uses the intended certificate.
“SSL/TLS support” or the equivalent option is enabled.
The website is configured to accept HTTPS connections on port 443.
The certificate chain is complete, including intermediate certificates.
The correct certificate is assigned after renewal.

If a certificate was renewed but not reselected in the control panel, the site may still present the old certificate or an invalid one. In some cases, the site appears secure on the server but insecure to browsers because the certificate chain is incomplete or misconfigured.

Check for certificate chain and intermediate issues

Even when a certificate is valid, browsers can mark the site as insecure if the server does not deliver the full certificate chain. This is less common with modern setups, but it still happens in manually configured Apache environments or after a certificate import.

Symptoms may include:

Warnings on some devices but not others.
Trust issues in older browsers or mobile browsers.
The browser shows the certificate, but the padlock is missing or reduced.

The solution is to ensure the full chain is installed correctly. In many hosting platforms, this is handled automatically when you use the built-in SSL management tools. If you imported the certificate manually, confirm that the intermediate certificate bundle is included.

Review redirects, aliases, and canonical URLs

A website can be secure in one version and insecure in another. Common examples include example.com, www.example.com, and subdomain variants such as shop.example.com. If one version is secure and another is not, visitors may see inconsistent browser behavior.

Best practice

Choose one primary HTTPS version.
Redirect all other versions to the preferred canonical URL.
Update internal links, canonical tags, and sitemaps.
Make sure all subdomains that need SSL have valid certificates.

Search engines also benefit from this consistency. A clean HTTPS setup reduces duplicate URLs and avoids confusion between secure and insecure versions of the same page.

Use a site-wide HTTPS replacement if content is hardcoded

Many older websites contain hardcoded absolute links in templates, widgets, or database content. If those links point to HTTP, the browser may continue to mark the site as not fully secure even after SSL setup.

Where to search

Theme files and templates.
CMS settings for site address and base URL.
Database content with embedded links.
Custom HTML blocks and page builder elements.
Email templates, header scripts, and footer scripts.

For websites managed through a control panel or CMS, a replacement tool can help update internal links from HTTP to HTTPS. Always create a backup before making bulk changes.

Check CDN, proxy, and load balancer settings

If your website uses a CDN, reverse proxy, or load balancer, SSL may terminate at one layer while traffic continues insecurely at another. Misaligned settings can cause warnings, redirect loops, or mixed content.

What to verify

The CDN is configured to serve the site over HTTPS.
Origin certificates or secure origin connections are set correctly.
The proxy forwards the original scheme correctly.
Application code recognizes HTTPS behind a proxy.

In some platforms, applications need to know they are behind HTTPS-aware proxies. Otherwise, they may generate HTTP links even when the browser is visiting the secure version.

Step-by-step checklist to fix Not Secure after SSL setup

If your site still shows a warning after installing SSL, use this checklist in order:

Open the site using https:// and confirm the correct domain is loading.
Check whether the certificate is valid for both the root domain and www, if both are used.
Confirm that HTTP redirects to HTTPS with a permanent redirect.
Inspect the page for mixed content using browser developer tools.
Search the site files and database for remaining http:// URLs.
Verify the certificate chain and certificate assignment in the hosting control panel.
Clear cache in the browser, CMS, and any caching plugin or reverse proxy.
Test the site from another browser, device, and network.
Review CDN, proxy, and load balancer settings if used.
Confirm that canonical URLs, sitemap entries, and internal links all use HTTPS.

Examples of common real-world causes

Example 1: SSL installed, but images still load over HTTP

A customer installs a certificate in Plesk, but the website logo and homepage banner are hardcoded with HTTP image links. The browser shows the site as not secure because those assets are mixed content. The fix is to replace the image URLs with HTTPS or relative paths.

Example 2: Certificate is valid, but the browser visits the wrong hostname

The certificate covers www.example.com, but the browser opens example.com. Since the certificate does not match the hostname, the browser cannot fully trust the connection. The fix is to add the correct SAN entry or redirect all traffic to the hostname that the certificate covers.

Example 3: HTTPS works after refresh, but not for all visitors

A recent redirect change is cached in one browser, but another browser still loads an older HTTP version from cache. The server configuration is correct, but the browser cache needs to be cleared and the redirect tested again.

When to contact hosting support

If you have checked redirects, mixed content, certificate validity, and cache but the site still shows Not Secure, the issue may be at the server configuration level. This is especially relevant in managed hosting environments where Apache, proxy rules, or certificate assignment are handled through the platform.

Contact support if:

The certificate is installed but not selectable for the domain.
The control panel shows SSL enabled, but the browser still reports an invalid chain.
HTTPS is forced, yet the site redirects unexpectedly.
The site appears secure on some domains but not others in the same subscription.
You suspect a server-side virtual host or proxy configuration issue.

How to prevent the problem in the future

Once HTTPS is working correctly, keep the site consistent by following a few maintenance practices:

Renew certificates before expiration and confirm they are reassigned after renewal.
Use HTTPS URLs in new content, templates, and integrations.
Audit the site after theme changes or plugin updates.
Keep redirects simple and permanent.
Review the site in a browser after every major deployment.

For websites managed through a hosting platform, it is helpful to make HTTPS part of the standard deployment process. That reduces the risk of reintroducing mixed content or broken redirects later.

FAQ

Does a valid SSL certificate always remove the Not Secure warning?

No. The certificate must be valid, correctly assigned, and the page must load fully over HTTPS without insecure resources.

Can mixed content cause a site to be marked Not Secure even with SSL?

Yes. Mixed content is one of the most common reasons a site remains partially insecure after SSL setup.

Why does the site look secure in one browser but not another?

Different browsers and devices may handle caching, certificate chains, or mixed content warnings differently. Test after clearing cache and checking the live network requests.

Is a redirect from HTTP to HTTPS enough?

It is important, but not always enough. The page itself and all its assets also need to use HTTPS.

Do I need separate SSL for subdomains?

Only if your certificate does not already cover them. Wildcard or multi-domain certificates can cover multiple hostnames, but they must match the actual site configuration.

What should I check first in Plesk?

Start with the assigned certificate, SSL/TLS support for the domain, and whether the site is redirected to HTTPS. Then check for mixed content in the page source.

Conclusion

A website can still show Not Secure after SSL setup if the browser finds an issue beyond the certificate itself. In most cases, the root cause is mixed content, a missing HTTPS redirect, a domain mismatch, or a hosting control panel configuration problem. By checking the certificate assignment, redirect rules, page resources, and cache, you can usually restore a fully secure HTTPS setup without replacing the certificate.

If the site is managed through a hosting platform or Plesk environment, focus on the active domain, certificate selection, and server-level HTTPS settings first. A correct SSL installation should result in a clean HTTPS connection, no mixed content, and a consistent secure browser indicator across all pages.

Why does a website still show Not Secure after SSL setup?