This is one of the most common tickets any hosting support desk receives. Someone buys a plan, activates the SSL certificate, opens their site over HTTPS, and instead of a padlock the browser shows a warning triangle or a flat "not secure" label. The first conclusion is usually that the certificate was installed wrong. It almost never is. The problem is called mixed content, and it is not fixed from the certificate — it is fixed from inside the site.
What mixed content actually is
When someone visits your page over HTTPS, the browser first downloads the HTML encrypted. So far so good. But that HTML is only the skeleton: inside it are references to dozens of other files — images, stylesheets, fonts, scripts, embedded videos.
If any of those references points to an address starting with http:// instead of https://, the browser finds itself asked to load an unencrypted piece inside an encrypted page. And it does the right thing: it warns you. Because a page is only as secure as its least secure part, and that unencrypted file could be tampered with along the way.
The two types, and why one is much worse
Browsers distinguish between passive and active mixed content, and treat them very differently.
Passive means images, video and audio. Elements that display but cannot change how the page behaves. The browser loads them anyway, but strips the padlock and shows the warning. It is ugly and it damages trust, but the site works.
Active means scripts, stylesheets, iframes and server requests. Elements that can alter the entire page. Here the browser does not negotiate: it blocks them outright. And that is the moment your site looks broken, unstyled, or with features that stopped working. If your site fell apart right after moving to HTTPS, this is the cause nine times out of ten.
How to find the offending resource
No guessing required. Open the page in your browser, press F12 to open developer tools, and go to the console tab. The browser lists every problem resource one by one with its full address. There you will see exactly which file is being requested over HTTP.
If the console shows nothing, reload with cache disabled, since these warnings appear at load time. And check inner pages too, not just the home page: it is very common for the home page to be clean while the problem lives in an old blog post with an image hotlinked from somewhere else.
Where those references come from
Images uploaded before the SSL was installed. The number one cause. WordPress stores the full address of every image in the database. If you uploaded a hundred photos while the site ran over HTTP, there are a hundred addresses starting with http sitting in that database.
Links written by hand in the content. Someone pasted an image from another site by copying the address as-is, and that address was HTTP.
Themes and plugins with hardcoded addresses. Some load fonts or libraries from addresses written directly into their code.
Site configuration. If your general settings still list the site address with HTTP, everything WordPress generates inherits that prefix.
External services that do not support HTTPS. Increasingly rare, but it happens with old widgets, ancient visitor counters, or maps from discontinued providers.
The proper fix: replace in the database
The definitive repair is changing every stored address. In WordPress you do this with a database search-and-replace tool, looking for http://yourdomain.com and replacing it with https://yourdomain.com.
Two important warnings. First: take a full database backup before touching anything. A botched replacement can leave the site unreachable. Second: do not run a raw SQL query by hand, because WordPress stores a lot of settings in a format where text carries its own length recorded alongside it, and changing the text without correcting that number breaks your plugin configuration. Use a tool built for this, which recalculates those lengths for you.
After the replacement, also check general settings so both the site address and the WordPress address use HTTPS.
The quick patch, and why it is only a patch
There is a directive that tells the browser to automatically upgrade any HTTP request to HTTPS. You add it as a security header and it clears the warning instantly.
It is useful as an emergency measure, especially if you run a large site and need it to stop looking broken today. But it has two problems. If the original resource does not exist over HTTPS, now it simply fails to load. And the dirty addresses remain in your database, waiting to cause trouble the next time you migrate or change domains. Use it to buy time, not to close the case.
Making sure nobody arrives over HTTP in the first place
Once the content is clean, the final step is ensuring nobody browses your site unencrypted. You do that with a permanent redirect from HTTP to HTTPS in the server configuration. With that in place, anyone typing your domain without the prefix ends up on the secure version anyway.
One detail people overlook: make sure the redirect does not create a loop. If your host already forces HTTPS from the control panel and you add it yourself on top, some configurations enter an infinite cycle and the site stops loading. When in doubt, enable it in one place only.
The right order so you never go through this again
If you are building a new site, the order that saves you all this work is: activate the certificate first, configure the site address with HTTPS from minute zero, and only then upload content. Free certificates with automatic renewal have been standard for years and there is no reason to leave this for later.
If your hosting plan includes the certificate and renews it on its own, as BanaHosting does, the certificate stops being a topic at all and you can focus on the only part that genuinely takes work: making sure your site content points where it should.