You install an SSL certificate, your site finally runs on https://, and you expect a clean green padlock. Instead the browser shows “Not secure” or a broken padlock with a little warning triangle. Nothing looks broken on the page, but that one missing padlock quietly tells every visitor your site might not be safe.
This is a mixed content warning, and it’s one of the most common things we clear after an SSL install or a site migration. The good news: your certificate is working fine. The page itself is secure — it’s just loading a few leftover files over the old insecure HTTP address, and the browser flags the whole page because of them. It’s closely related to the “Not Secure” warning you may have seen before, and it’s just as fixable. At ZenWeb, it’s routine work on the websites we build and maintain.
This guide explains what it is, what causes it, how to fix it step by step, and how to keep it from coming back. Watch the short walkthrough below, then work through the fixes.
Source video: How to Quickly Fix WordPress Mixed Content Warnings on YouTube
Quick Answer: A mixed content warning appears when a page loads over secure HTTPS but still requests some files — an image, a script, a font, an embed — over insecure HTTP. The page is “mixed”: part secure, part not. Browsers respond by dropping the padlock, and often by blocking the insecure file outright.
Your SSL certificate secures the connection between the visitor and your server. But a page also pulls in separate files — images, stylesheets, scripts, fonts, and embeds like maps or videos. If even one still points to an old http:// address, the browser sees an insecure request on a secure page, and won’t give a full padlock to a page it can’t fully trust.
Google’s Chrome team splits the problem into two kinds, and the difference decides what actually breaks:
Padlock still broken after installing SSL?
We clear these warnings as part of keeping client sites secure and stable. See how our web design and maintenance service works →
Quick Answer: Most mixed content comes from old HTTP links left behind after SSL was switched on: hard-coded links in pages and themes, HTTP URLs saved in the database, and third-party embeds copied over HTTP. The certificate secures new connections, but it doesn’t rewrite the links already sitting inside your content.
When you move a site to HTTPS — or move web host without downtime and add SSL along the way — the old http:// links don’t update themselves. Here’s how often each source is the culprit across the Malaysian SME sites we’ve cleaned up.
| Root cause | Share of incidents | % |
|---|---|---|
| Hard-coded HTTP links in pages, posts, or theme | 32% | |
| Old HTTP URLs saved in the database | 24% | |
| Third-party embeds (maps, video, widgets) over HTTP | 18% | |
| Plugin or theme assets requested over HTTP | 14% | |
| A CDN, subdomain, or image host not on HTTPS | 8% | |
| Hotlinked external images served over HTTP | 4% |
Source: ZenWeb support data across Malaysian SME sites, 2024–2026. Some incidents had more than one contributing source.
The top two — hard-coded links and database URLs — cause more than half of all cases, and both are leftovers from the pre-SSL site. That’s why a plugin or a database search-and-replace clears most warnings in one pass: it hunts down those old http:// strings and rewrites them to https://.
Quick Answer: Before touching any files, open your browser’s developer console and read the mixed content messages — they name the exact insecure files. Two minutes of looking tells you whether it’s one stray image or a site-wide database problem, so you fix the right thing instead of guessing.
The browser has already found your insecure files for you. In Chrome, right-click the page, choose Inspect, and open the Console tab — every insecure item is listed there, each pointing to a specific http:// file. Run through this quick triage first:
Quick Answer: Fix it in order of effort: back up, try an SSL plugin first, then run a database search-and-replace for stubborn URLs, swap any HTTP embeds by hand, and finally clear your cache so the fix shows. Most sites come clean within the first two steps.
You’ll need access to your WordPress dashboard, and for the deeper steps, your hosting file manager or database tool. Work through these in order and re-check the console after each — the moment the warnings disappear, you’re done.
http://yourdomain.com for https://yourdomain.com across the database. This catches old URLs saved inside posts, pages, and settings.http:// references in the template or theme options to https://.Quick Answer: Most mixed content warnings clear in 5 to 30 minutes. An SSL plugin is the fastest route and fixes the majority of small sites; a database search-and-replace and manual embed swaps take a little longer. Only stubborn, site-wide cases stretch past half an hour.
Knowing the typical time per method helps you decide how far to go before handing it over. These are the usual hands-on times once you know the cause.
| Fix method | Typical time | Best for |
|---|---|---|
| SSL/HTTPS plugin (e.g. Really Simple SSL) | 5–15 min | Most small sites — try first |
| Database search-and-replace | 10–20 min | Old HTTP URLs saved in content |
| Swapping a third-party embed to HTTPS | 10–30 min | Maps, video, and widget embeds |
| Manual theme or template edit | 20–45 min | Hard-coded links in the theme |
| Full professional cleanup after migration | 30–60 min | Stubborn or site-wide cases |
Source: ZenWeb support data across Malaysian SME sites, 2024–2026. Times are hands-on effort once the cause is known; individual cases vary.
Rather not touch the database yourself?
We clean up mixed content and lock the site to HTTPS so it stays green. Explore our web design and care plans →
Quick Answer: Images cause the most mixed content warnings, but they usually still show — they just break the padlock. Scripts, stylesheets, and iframes are more dangerous, so browsers block them, which is why a slider or form can suddenly stop working. Knowing the resource type tells you whether it’s cosmetic or breaking the page.
Not every insecure file behaves the same way. Google’s Chrome team splits them into passive content, which loads but breaks the padlock, and active content, which browsers block outright. Here’s what we see triggering the warning most often, and how the browser treats each.
| Resource type | Share of cases | Type | What the browser does |
|---|---|---|---|
| Images | 43% | Passive | Loads, padlock breaks |
| Embedded iframes (maps, video) | 20% | Active | Usually blocked |
| Scripts (JavaScript) | 17% | Active | Blocked |
| Stylesheets (CSS) | 11% | Active | Blocked |
| Fonts | 6% | Active | Blocked |
| Audio / video files | 3% | Passive | Loads, padlock breaks |
Source: ZenWeb support data across Malaysian SME sites, 2024–2026. Browser handling per Google’s mixed content guidance; behaviour varies by browser and version.
This is why two sites with “the same” warning can look completely different. A stray HTTP image just costs you the padlock, while a blocked script can take your booking form or slider down with it — the kind of quiet breakage that, left long enough, can even contribute to Google flagging a site as deceptive.
Quick Answer: A missing padlock quietly costs trust. Malaysian shoppers who see “Not secure” hesitate to enter a phone number or card, so more of them bounce and fewer complete a form. Clearing the warning restores the padlock and, with it, the confidence that turns visitors into enquiries.
The warning looks minor, but visitors read “Not secure” as “not safe to buy from”. Here’s the typical shift we see when we clear mixed content on an affected page.
| What you’re measuring | Before | After |
|---|---|---|
| Padlock shows a fully secure page | No | Yes |
| Mixed-content errors in the console (per page) | 6.8 | 0 |
| Average bounce rate on affected pages | 57% | 42% |
| Visitors who complete a form or checkout | 2.2% | 3.5% |
Source: ZenWeb client data, Malaysian SME sites, typical outcome after clearing mixed content, 2024–2026. Individual results vary.
There’s a paid-traffic angle too. If you’re sending Google Ads traffic to a page the browser marks “Not secure”, you’re paying for clicks that land on a page visitors don’t trust — and a poor landing-page experience can even get ads disapproved. Fixing the warning protects both organic and paid results.
Quick Answer: Once the warning is cleared, keep it gone by always using HTTPS links, forcing HTTPS site-wide, and checking the console whenever you add an embed or move host. Most repeat warnings come from a new HTTP link slipping in, not the old fix failing.
A warning that keeps returning is usually a fresh HTTP link sneaking in, not the original fix unravelling. These habits keep the padlock green, and we build all of them into the sites we look after:
https://.Quick Answer: Get help when a plugin and a database search-and-replace haven’t cleared the warning, when you’re not comfortable editing the database, when active content is blocked and breaking the page, or when the warning keeps coming back. A developer clears it safely and locks the site to HTTPS.
There’s no shame in handing it over, especially when your website takes enquiries or payments. It makes sense to get help when:
This is everyday work for our team. If you’d rather have it cleared and kept stable, ZenWeb looks after WordPress sites for Malaysian businesses through our web design and maintenance service.
A mixed content warning looks alarming, but it’s rarely serious. Your SSL certificate is doing its job — the page is just loading a few leftover files over the old HTTP address. Read the console to see which files, run a plugin or a database search-and-replace to rewrite them, swap any HTTP embeds, and clear your cache. In most cases the padlock is back in minutes.
The bigger win is keeping it clean: use HTTPS links by default and re-check after every change. If you’d rather not wrestle with the database while a “Not secure” label sits on your site, ZenWeb can clear it and keep your site fully secure.
Still seeing “Not secure” on your site?
Book a free 30-minute session — we’ll find every insecure file, clear the mixed content warning, and lock your site to HTTPS so the padlock stays green.
It means your page loads over secure HTTPS but still requests one or more files — often an image, script, or embed — over insecure HTTP. The connection is “mixed”, so the browser won’t show a full padlock. Your certificate is fine; the fix is updating those few file links from http:// to https://.
Because the certificate secures new connections, but it doesn’t rewrite links already saved in your content and theme. Old http:// images, scripts, and embeds keep loading on the insecure address, so the browser flags the page. Updating those links — usually with a plugin or a database search-and-replace — brings the padlock back.
Back up first, then try an SSL plugin like Really Simple SSL, which fixes most small sites in minutes. If warnings remain, run a database search-and-replace to swap http:// for https://, update any hard-coded theme links, re-copy HTTP embeds, and clear every cache. Re-check the browser console after each step until it’s clean.
Indirectly, yes. Google favours secure pages, and a “Not secure” label pushes visitors to bounce, which weakens the engagement signals that support ranking. Blocked active content can also break page features. Clearing the warning restores a fully secure page and removes those drags on both trust and performance.
No. The old HTTP links stay in your content until something updates them, so the warning persists until you fix it. Chrome may auto-upgrade some insecure images, but scripts and iframes stay blocked. The reliable fix is to find the insecure files in the console and rewrite them to HTTPS.
Complete the form and our team will contact you to discuss your goals. Let’s grow your business.

Online