Fixing Mixed Content Warnings After Enabling HTTPS

When SSL is active but the browser padlock is missing, broken or showing a warning, the cause is almost always mixed content: the page itself is encrypted but something on it is still being fetched over plain HTTP. This guide explains why that happens, how to find every offending resource, and how to fix it properly rather than papering over it.

What Mixed Content Is

A browser treats a page as secure only if the page and everything it loads arrived over HTTPS. If an HTTPS page pulls in an image, script, stylesheet, font or iframe from an http:// address, the browser flags it.

Browsers split this into two categories, and they behave very differently:

Active mixed content: scripts, stylesheets, iframes and XHR. Browsers block these outright. Layouts collapse, sliders stop, forms stop submitting. This is the destructive kind.
Passive mixed content: images, audio and video. These usually still load, but the padlock is downgraded or removed.

A site can therefore look completely fine and still be losing its padlock, or look broken with no obvious error in the page itself.

Why It Happens After Enabling SSL

Turning on SSL changes how your site is served. It does not change what is stored inside it.

WordPress writes absolute URLs into the database, so a site that ran on HTTP for any length of time has http:// addresses saved in:

Post and page content, including every image inserted through the editor.
Media attachment records.
Theme customiser settings and theme options.
Widget content and block settings.
Plugin settings, particularly page builders and slider plugins.
The siteurl and home options.

None of that updates itself. Enabling SSL and then wondering why the padlock is broken is one of the most common support questions there is, and this is why.

Step 1: Force HTTPS at the Server

Before you touch the database, make sure every visitor is landing on HTTPS in the first place.

Sign in to KPanel and click Websites in the left sidebar.
Click your site.
Open Settings.
Under Behavior, turn on Force HTTPS.
Click Save Changes.

Force HTTPS setting on a site in KPanel

Every HTTP request is now redirected to HTTPS at the server, before your site runs.

Force HTTPS handles requests coming in. It does not rewrite URLs already stored inside your database, so on its own it will not clear a mixed content warning caused by a hardcoded http:// image. You need both this and Step 2.

If SSL is not active yet, or the certificate looks wrong, start with SSL Certificates.

Step 2: Rewrite the Stored URLs

This is the fix that actually resolves mixed content.

Open the site, then the WordPress tab, then the Quick Actions section.
Find the Search & Replace card and click Configure.
In Find (old value) enter http://yourdomain.co.nz.
In Replace with enter https://yourdomain.co.nz.
Leave Dry run (preview only, no changes) ticked and click Preview.
Review the count and the per-table breakdown.
Untick Dry run, click Run, and confirm.

A full backup is taken automatically before the replacement, and every table is covered including those created by plugins. Serialised plugin settings are handled correctly.

Do not do this with a SQL query in phpMyAdmin. WordPress stores plugin and theme settings as serialised strings that record the length of every value, so a raw REPLACE() breaks them and the settings silently reset to empty. There is no repair short of restoring a backup. The full explanation is in Running a Search and Replace.

If your plan includes the console, the equivalent command is:

search-replace 'http://yourdomain.co.nz' 'https://yourdomain.co.nz' --all-tables --dry-run

Drop --dry-run to apply it, and take a backup yourself first: the console does not.

Step 3: Clear Every Cache

A cached copy of a page will keep serving the old HTTP URLs long after the database is fixed, which is why people often think the replacement did not work.

WordPress, then Quick Actions, then Flush Cache.
WordPress, then Caching, then Purge cache, if the full page cache is on.
Performance, then Kapsule CDN, then Purge, if the CDN is on. See Purging the CDN Cache.
Any caching plugin, from its own settings screen.
Your own browser. Test in a private window so you are not fooled by your own cache.

Step 4: Find What Is Left

Most sites are clean after Step 2. When a warning survives, find the exact resource rather than guessing.

Browser console. Open developer tools with F12, go to the Console tab, and reload. Mixed content appears as an explicit warning naming the full URL of the offending resource. That URL tells you which plugin or theme is responsible.

Network tab. Filter by http:// to list every insecure request the page made.

Page source. Load the page, view source, and search for http://. Ignore anything inside xmlns attributes and schema declarations: those are identifiers, not requests.

Common survivors, and what to do about each:

What you find	Fix
An image or logo in a theme customiser setting	Re-upload or re-select it in the customiser
A page builder module with a typed-in `http://` image URL	Edit that module and correct the URL
A slider plugin's own settings table	Re-save the slider, or run the search and replace with `--all-tables`
A font or script from a third party domain	Check whether the provider offers HTTPS. Most do now. Switch the URL
A tracking pixel or embed from an old vendor	If the vendor has no HTTPS, remove it. It is a broken dependency, not a Kapsule problem
Hardcoded `http://` in a theme template file	Edit the template, or better, use `https` or a protocol relative reference

If exactly one page is affected and the rest of the site is clean, the culprit is content on that page, not a site wide setting. Open it in the editor and look at the media it embeds.

Confirming It Is Fixed

Load the site in a private window.
The padlock should be solid, with no warning triangle and no crossed-out indication.
Click the padlock. The browser reports the connection as secure with no mixed content notice.
Open the console and reload once more. Zero mixed content warnings.
Check a deep page, not just the home page: an interior page, a blog post with images, and the checkout on a store.

Preventing It Coming Back

Leave Force HTTPS on. It is a one line setting that removes an entire class of problem.
Never type a full http:// URL into content. Use the media library, which now stores HTTPS addresses.
Check plugin settings after installing anything that asks for a URL.
Watch for a returning warning after a plugin update. Some plugins reset their own stored URLs.
Re-run the search and replace after any migration, since an imported database brings the old host's URLs with it: Migrating a Website From cPanel.

Troubleshooting

The padlock is fine for me, broken for a colleague. Cached page. Have them reload in a private window.

The site broke completely after the replacement. Restore the automatic pre-run backup: Restoring From a Backup.

The console shows a mixed content warning on a domain that is not mine. A third party resource. You cannot fix their server: either they support HTTPS and you switch the URL, or you drop the resource.

Everything is HTTPS but the site will not load at all. That is not mixed content. Start with Website Not Loading and check the certificate on SSL Certificates.

If you have worked through all of this and the warning persists, email support@kapsulehost.com with the affected URL and the exact text of the browser console warning.