WordPress Mixed Content: Fix Every HTTP Resource Fast

Mixed content warnings appear when your WordPress site is served over HTTPS but at least one resource on the page — an image, script, stylesheet, or font — is still loaded over plain HTTP. The browser blocks or flags that resource, the padlock turns grey or shows a warning triangle, and visitors see a site that looks broken or untrustworthy. The good news: every case has a specific cause and a specific fix, and you can resolve most of them in under an hour without touching a line of code.

What You're Actually Seeing

Open your browser's developer tools (F12 in Chrome or Firefox), click the Console tab, and reload the page. Mixed content errors look like this:

Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS,
but requested an insecure resource 'http://yoursite.com/wp-content/uploads/image.jpg'.
This content should also be served over HTTPS.

Chrome and Edge split these into two categories:

• Blocked mixed content — scripts and iframes loaded over HTTP. The browser refuses to load them at all.
• Mixed content warnings — images, audio, and video loaded over HTTP. The browser loads them but flags the page as not fully secure.

Either way, the padlock won't go fully green (or fully closed, depending on your browser). In Chrome, you'll see an info icon or a "Not secure" label in part of the address bar.

Why This Happens on WordPress Sites

The most common trigger is a migration or late SSL activation. You built the site on HTTP, then added a certificate later — or moved the site to a new host that enforced HTTPS. WordPress stored every URL as http:// in the database, and those URLs didn't change automatically when SSL was switched on.

Other causes include:

• A plugin or theme that hardcodes http:// URLs in its output
• Embedded iframes (YouTube, Google Maps, forms) using the old HTTP embed code
• External fonts or scripts loaded from a third-party CDN over HTTP
• Custom HTML blocks or widgets in the block editor that contain http:// links pasted in years ago
• Your wp-config.php or the WordPress Address / Site Address fields not yet updated to https://

Step 1: Confirm Your WordPress URLs Are Set to HTTPS

Before hunting down individual resources, make sure WordPress itself is broadcasting the right base URL. Go to Settings → General in your dashboard. Both WordPress Address (URL) and Site Address (URL) should start with https://. If either one still says http://, update it and save. WordPress will redirect all front-end requests to the HTTPS version.

Also check your wp-config.php for any hardcoded lines like:

define('WP_HOME', 'http://yoursite.com');
define('WP_SITEURL', 'http://yoursite.com');

If those lines exist, they override the Settings page. Update them to https:// or remove them if you'd rather control the URL from the dashboard.

Step 2: Find Every Mixed-Content URL

Don't just fix the homepage and call it done. Mixed content can exist on any page — especially posts with embedded images or old shortcodes. Use a combination of these tools:

• Browser console on key pages — homepage, a typical post, your contact page, your shop or checkout if you have one. The console names the exact file and the line that called it.
• Why No Padlock (whynopadlock.com) — paste your URL and it returns a full list of insecure resources without you needing to open DevTools.
• SSL Checker by JitBit (free, crawls up to 200 pages) — crawls your whole site and lists every page that has mixed content.
• A direct database search — if your site has hundreds of posts, use a search tool to find every http://yoursite.com occurrence in the database.

Step 3: Fix URLs Stored in the Database

This is where the bulk of mixed content lives — in post content, widget data, theme mods, and option values that were written when the site was on HTTP. The safest, most thorough tool for this is Better Search Replace (a real, free plugin in the WordPress repository).

1. Back up your database before you touch anything. Use your host's backup tool or a plugin like UpdraftPlus.
2. Install and activate Better Search Replace from Plugins → Add New.
3. Go to Tools → Better Search Replace.
4. In Search for, enter: http://yoursite.com
5. In Replace with, enter: https://yoursite.com
6. Select all tables (Ctrl+A / Cmd+A).
7. Run a dry run first — tick "Run as dry run?" to see how many rows would change without actually changing them.
8. If the count looks right (dozens to thousands is normal), uncheck dry run and run the real replacement.
9. Delete or deactivate Better Search Replace when you're done.

Better Search Replace handles serialised data correctly, which matters because WordPress stores many options as serialised PHP arrays. A naive find-and-replace in phpMyAdmin can corrupt those values and break your site — so stick to this tool or WP-CLI if you're comfortable on the command line.

With WP-CLI the equivalent is:

wp search-replace 'http://yoursite.com' 'https://yoursite.com' --all-tables --dry-run

Remove --dry-run to execute for real.

Step 4: Fix Hardcoded HTTP in Theme and Plugin Files

If a resource is still insecure after the database replacement, the URL is probably hardcoded in a PHP template, a CSS file, or a JavaScript file. Search your theme and plugin directories for the string http://. In a local editor like VS Code you can use a project-wide search. On the server, SSH in and run:

grep -r "http://" /var/www/html/wp-content/themes/your-theme/ --include="*.php" --include="*.css" --include="*.js"

For theme files, make your edits in a child theme — never the parent — so updates don't wipe your changes. For plugin files, don't edit the plugin directly; that's a maintenance nightmare. Instead, look for a settings panel that lets you change the URL, or raise a support ticket with the plugin author, or find an alternative plugin. For more on safe theme editing, see Theme File Edits That Vanish on Update — And What to Do Instead.

Step 5: Handle External Resources and Iframes

Third-party embeds are a frequent culprit. If you embedded a YouTube video using an old http://www.youtube.com/embed/... URL, update it to https://. Same for Google Maps embed codes, Typeform or Gravity Forms embeds, and any custom HTML widgets.

For external fonts, check whether the provider (Google Fonts, Adobe Fonts, etc.) serves over HTTPS — they all do now. Make sure the <link> tag or @import in your CSS uses https://.

If you use a CDN for your own assets, confirm the CDN hostname is in your SSL certificate (or that the CDN provides its own certificate). Most major CDNs (Cloudflare, BunnyCDN, KeyCDN) serve over HTTPS by default.

Step 6: Use a Server-Level or Plugin-Level Fallback

After fixing the root causes, you can add a safety net to catch any stray HTTP references you missed. Two approaches:

• Really Simple SSL — a well-maintained free plugin that sets the correct WordPress URLs, flushes rewrites, and adds an output-buffer filter that rewrites any remaining http://yoursite.com references to https:// before the page is sent to the browser. It's a genuine fix tool, not just a band-aid, but treat it as a last-pass filter after doing the proper database and file fixes above.
• Content Security Policy (CSP) header — a server-level approach where you tell the browser to upgrade insecure requests automatically. Add this to your .htaccess or Nginx config: Content-Security-Policy: upgrade-insecure-requests;. This upgrades HTTP sub-resources to HTTPS at the browser level. It won't fix actively blocked mixed content scripts in all browsers, but it handles images and passive content cleanly.

How to Prevent Mixed Content Coming Back

• Set up a 301 redirect from HTTP to HTTPS at the server or CDN level so any future HTTP request is immediately upgraded before WordPress is even involved.
• Add an HSTS header (Strict-Transport-Security: max-age=31536000; includeSubDomains) so browsers remember to always use HTTPS for your domain.
• When pasting external embed codes, always check they start with https://.
• After any plugin or theme update, do a quick console check on your homepage — updates occasionally reintroduce hardcoded URLs.

When to Call a Professional

If you've run Better Search Replace, checked your Settings, and the padlock still won't go clean — especially if the offending URL is something obscure like a hardcoded font in a minimised CSS file, a third-party tag manager injection, or a WooCommerce payment gateway loading an HTTP resource — the hunt becomes genuinely tedious and easy to get wrong. Similarly, if your site is on a multisite network, the database structure is more complex and a blanket search-replace needs to target the right tables.

That's the kind of problem Mend exists to solve. A senior engineer will audit every page, trace every insecure resource to its source, fix it properly, and send you a plain-English report of what changed and why — usually the same day. Book a Quick Fix at a flat $129, or if you're not sure what you're dealing with, start with a free Diagnosis and get a quote before any work begins.

Mixed content is almost always fixable without rebuilding your site. Work through the steps above in order — WordPress URLs first, database second, files third, external embeds fourth — and you'll clear the padlock for good.