WordPress still shows http or mixed content after SSL

If your padlock is missing or the browser flags "mixed content" after SSL is active, the certificate itself is almost never the problem. Something on the page is still requesting http:// resources: images, scripts, stylesheets, or the site URL itself stored in the database. Force HTTPS at the site-settings level, then search-replace any remaining hardcoded http:// references.

Confirm the certificate is actually live

Before touching WordPress settings, rule out a DNS or certificate issue. Free Let's Encrypt SSL is auto-issued about 5 minutes after your domain's DNS points to Flashcloud, and it auto-renews. Load https://yourdomain.com directly in the browser. If you get a certificate warning (not just "not secure" in the address bar, but an actual interstitial), DNS likely isn't pointed at us yet, or the certificate hasn't issued. Check that first. If the padlock shows fine on a fresh load but the "not secure" warning or mixed-content icon appears once the page finishes loading, the certificate is fine and the problem is in the page itself. That's what the rest of this article covers.

Cause 1: siteurl and home still say http

WordPress stores its own address in two database options, siteurl and home. If these were set before SSL existed on the domain, they still say http://yourdomain.com, and WordPress will build every link, redirect, and asset URL from that value regardless of what the visitor typed.

Check wp-admin → Settings → General. Both "WordPress Address (URL)" and "Site Address (URL)" should read https://. If they say http://, update them and save.

If you have shell access, the same fix from the command line:

cd /home/your-user/public_html
wp option update home 'https://yourdomain.com'
wp option update siteurl 'https://yourdomain.com'

This is the same underlying mechanism covered in changing your WordPress site's domain, just scoped to a protocol change instead of a full domain change.

Cause 2: hardcoded http links in content and settings

Fixing siteurl and home stops new page loads from starting on http, but it doesn't touch old content. Posts, pages, widget settings, and theme options can all have http://yourdomain.com/... stored in them from before SSL, image URLs in post content being a common culprit. Browsers block or warn on these because a page served over https that pulls in a resource over http is mixed content.

The reliable fix is a database search-replace, not manual editing:

• Install the Better Search Replace plugin.
• Go to Tools → Better Search Replace.
• Search for http://yourdomain.com, replace with https://yourdomain.com.
• Select all tables, or at minimum wp_options, wp_posts, and wp_postmeta.
• Run it as a dry run first, review the count of replacements, then run for real.

This plugin handles serialized data correctly, meaning it won't corrupt widget settings or theme options that store arrays as serialized strings, which a manual find-and-replace in a text editor would break. With shell access, wp search-replace does the same job:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com'
wp rewrite flush

This exact search-replace approach, including the wp-cli equivalent, is covered in more depth in changing your WordPress site's domain if you want the full walkthrough.

Cause 3: a plugin, theme, or CDN forcing http

If siteurl/home are correct and a search-replace still leaves mixed content, look outside the database:

• A caching or CDN plugin may be serving a cached version of the page from before SSL was active. Clear the site's cache. On Flashcloud, WordPress installs get the LiteSpeed Cache plugin pre-configured, so purge the cache from the LiteSpeed Cache plugin in wp-admin rather than assuming a stale plugin cache from something else.
• A theme or page builder may store absolute http URLs in its own options table separate from post content, common with drag-and-drop builders that save image URLs per-element. A full-table search-replace (above) covers this as long as you selected all tables, not just the core WordPress ones.
• An external asset, a font, script, or image loaded from a third-party domain, might itself be served over http. This won't be fixed by anything on your database; you'd need to update the embed code or link to that resource's https version.

If your site was previously flagged by wp-admin → Tools → Site Health for an HTTPS-related warning, that's the same underlying issue; see WordPress Site Health warnings and which ones matter for how to read the rest of that report without chasing false positives.

Still showing http after all three checks

If siteurl and home are https, the search-replace dry run showed zero remaining http references, and the cache is purged, but the browser still warns, open a ticket from the portal (Support → New ticket). Include the exact URL where you see the warning and what the browser's mixed-content console message says (open browser dev tools, Console tab, reload the page). A Flashcloud support ticket goes to a real person who can trace it from there.