Fixing Mixed Content Warnings After Forcing SSL/HTTPS

You installed the certificate, forced every request to HTTPS, and the browser still refuses to show a padlock. That happens because at least one asset on the page is still being requested over plain HTTP, and the fix is almost always a stale URL stored in your database, your theme files, or a third-party embed. Fixing mixed content warnings after forcing SSL/HTTPS is mostly detective work, and the whole job usually takes 20 to 40 minutes on a typical WordPress site.

Below is the order we work through it on customer sites, starting with the checks that catch 80% of cases.

What a Mixed Content Warning Actually Means

A page served over HTTPS that loads an image, script, stylesheet, font or iframe over HTTP is mixed content. The HTML arrived encrypted, but those sub-resources did not, so the connection can no longer be described as secure end to end. Browsers respond in one of two ways depending on the resource type.

• Passive mixed content (images, video, audio) usually still loads, but the padlock is replaced with a neutral or “Not secure” icon.
• Active mixed content (JavaScript, CSS, XHR/fetch calls, iframes) is blocked outright by Chrome, Firefox, Safari and Edge, which is why sliders vanish and layouts collapse.

Mozilla’s reference on mixed content behaviour lists exactly which request types get auto-upgraded and which get blocked. Since Chrome 86, most browsers attempt to upgrade HTTP sub-resources to HTTPS automatically and only block them if that upgrade fails, so a warning today often means the asset genuinely isn’t available over HTTPS.

Step 1: Find Every Insecure Request Before You Change Anything

Guessing wastes more time than scanning. Open the page in Chrome, press F12, and read the Console tab: each warning names the exact file being requested over HTTP. Reload with the Network tab open and filter by “http://” if the console output is noisy.

For a whole-site view, run the domain through Why No Padlock or JitBit’s SSL Check, which crawl internal pages and list insecure resources per URL. Check the templates that matter commercially first: home, a product or service page, the cart, and checkout.

Step 2: Rewrite the URLs Stored in Your Database

WordPress saves absolute URLs inside post content, options, widgets and serialized plugin settings. Changing the site address in Settings does nothing to those rows, which is why the warning survives a forced redirect.

Take a backup first, then run a proper search and replace that understands serialized data. WP-CLI is the fastest route:

• wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run to preview the count.
• Run it again without --dry-run once the numbers look sane.
• No SSH access? The Better Search Replace plugin does the same job from the dashboard.

Never run a plain SQL UPDATE across wp_postmeta. Serialized strings store their own character lengths, and a blind replace corrupts them, which can leave you staring at a broken site or chasing a database connection error instead of a padlock.

Step 3: Clear Hardcoded Links in Themes and Builders

Database rewrites miss anything written into PHP, JS or CSS files. Grep the active theme and any custom plugins for http:// and fix the matches by hand, or switch them to protocol-relative paths where the host supports both schemes.

Page builders deserve a second look. Elementor stores CSS in /uploads/elementor/css/ and needs its “Regenerate Files & Data” tool after a URL change; Divi and WPBakery cache similar artefacts. Background images set inside builder modules are the single most common leftover we see after a site migration.

Step 4: Sort Out the Proxy Layer Before Blaming WordPress

This is the part most tutorials skip. If your site sits behind Cloudflare, a load balancer or an Nginx reverse proxy, PHP may never see $_SERVER['HTTPS'], so WordPress generates HTTP URLs no matter what you set in the admin. Two symptoms give it away: an endless redirect loop, or canonical links that flip back to HTTP on every page load.

Add this near the top of wp-config.php, above the “That’s all, stop editing” line:

• if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }

Also move Cloudflare’s SSL mode from Flexible to Full (Strict). Flexible encrypts only the visitor-to-Cloudflare leg and is a reliable source of loops and mixed content on origin servers that already hold a valid certificate. Our managed SSL setup provisions and renews certificates at the origin, so Full (Strict) works without extra configuration.

Step 5: Handle Third-Party Assets You Don’t Control

Some remote resources genuinely have no HTTPS version: an old tracking pixel, a legacy font CDN, a partner’s badge image. You have three options, in order of preference.

1. Swap the provider or endpoint. Most major services have published HTTPS URLs for years.
2. Self-host the file. Download the image or script into /wp-content/uploads/ and reference it locally.
3. Add an upgrade header. Sending Content-Security-Policy: upgrade-insecure-requests tells browsers to retry HTTP sub-resources over HTTPS before loading them.

The upgrade header is a safety net, not a repair. Google’s guidance on preventing mixed content is clear that the underlying URLs should still be corrected, because a resource that only exists on HTTP will simply fail after the upgrade attempt.

Step 6: Purge Every Cache Layer, Then Re-Test

Plenty of “the fix didn’t work” tickets are cached HTML being replayed. Clear in this order: page cache, object cache, CDN edge cache, then your browser (or just test in a private window). Sites running LiteSpeed also store optimised CSS and JS copies that keep the old URLs until purged.

Once the padlock returns, confirm the certificate chain itself with SSL Labs and re-crawl the site. Keeping HTTPS clean across every template is part of ongoing WordPress security maintenance, especially on stores where a blocked payment script costs real money. For WooCommerce sites, test an actual checkout, not just the cart page.

Mistakes That Keep the Warning Alive

• Enabling HSTS before the site is fully clean, which locks browsers into HTTPS while assets still fail.
• Leaving a mixed-content fixer plugin as the permanent solution; its output filtering adds overhead on every request and hides the real URLs.
• Forgetting the sitemap, RSS feed and email templates, all of which carry their own absolute links.
• Updating the live database but not staging, so the next deployment reintroduces HTTP URLs.

Frequently Asked Questions

How Long Does It Take to Fix Mixed Content on a WordPress Site?

Most sites are clean within 20 to 40 minutes, including the database search and replace and a cache purge. Large multisite installs or stores with hundreds of hardcoded builder URLs can run two to three hours.

Will Mixed Content Warnings Hurt My Google Rankings?

HTTPS has been a lightweight ranking signal since 2014, but the bigger risk is blocked active content breaking navigation, forms or checkout, which damages engagement metrics. Chrome also shows a “Not secure” label that measurably reduces form completions.

Can I Just Use a Plugin Like Really Simple SSL?

Yes for a quick save, no as a permanent fix. These plugins rewrite output on the fly, so your database still holds HTTP URLs and the problem reappears the day the plugin is deactivated or conflicts with a caching layer.

Why Does the Padlock Show on Some Pages but Not Others?

Because mixed content is evaluated per page, and the offending asset usually lives in one template, post or widget. Check the console on each failing URL individually; it is frequently a single old image embedded in one blog post.

Do I Need to Reissue My SSL Certificate?

Almost never. A mixed content warning means the SSL certificate is working and the page itself loaded over HTTPS, so reissuing changes nothing unless the certificate has expired or does not cover the www variant.

Get Your Site Running Clean on HTTPS

If the warning is still there after the database rewrite and the cache purge, our support team will trace the request and fix it at the server level. Start a WordPress plan with WebVibo and we will handle the certificate, the redirects and the migration for you.