AmaarDev.
Hire Me

How to Fix WordPress Mixed Content Errors (2026 Guide)

Fix WordPress mixed content errors - laptop showing Not secure browser warning

You installed an SSL certificate, your site loads over HTTPS, and yet the browser still refuses to show a clean padlock. Instead you get a warning, a broken padlock, or images and styles that simply do not load. In most cases, you need to fix WordPress mixed content errors: your page is secure, but some of its resources are still being requested over plain HTTP.

This guide walks you through finding those insecure resources and fixing them properly, from the database cleanup to forcing HTTPS at the server level. Follow the steps in order for a fix that stays fixed.

What Is a WordPress Mixed Content Error?

Mixed content happens when an HTTPS page loads one or more resources over HTTP. Those resources can be images, stylesheets, scripts, fonts, videos, or iframes. The page itself is encrypted, but the insecure parts are not, so the browser cannot vouch for the whole page.

Browsers treat two kinds of mixed content differently, and that difference explains why symptoms vary:

  • Passive mixed content — images, video, and audio. Browsers usually still load these, but they drop the padlock and may show a “Not fully secure” warning.
  • Active mixed content — scripts, stylesheets, and fetch or AJAX requests. Modern browsers block these outright, which is why a site can look unstyled or lose functionality after moving to HTTPS.

The most common cause is history, not a broken certificate. WordPress stores full URLs, including the protocol, in the database, so content created before the move to HTTPS still points to http://. A redirect alone does not rewrite those stored URLs inside the page.

How to Find the Insecure Resources

Do not guess which URLs are at fault. Find them first, because the list tells you which fix will actually work.

  1. Open the affected page in Chrome or Edge, right-click, and choose Inspect.
  2. Go to the Console tab and reload the page.
  3. Look for lines beginning “Mixed Content: The page at … was loaded over HTTPS, but requested an insecure resource …”. Each line names the exact HTTP URL.

Before You Start: Take a Backup

A database search-and-replace edits stored content across your site, so back up first. A full backup — database plus files — means you can roll back in minutes if a replacement goes wrong. If you do not have a backup routine yet, read my guide to backing up your WordPress site first.

Step 1: Update Your WordPress and Site URLs

  1. In wp-admin, go to Settings > General.
  2. Check that both WordPress Address (URL) and Site Address (URL) begin with https://.
  3. If either still shows http://, change it to https:// and save.

If those fields are greyed out, the URLs are hard-coded in wp-config.php with WP_HOME and WP_SITEURL — update them there instead. This step fixes newly generated links, but not old content already in the database.

Step 2: Run a Database Search-and-Replace

This is the fix that clears most mixed content in one pass. It replaces your old HTTP domain with the HTTPS version everywhere it appears in the database.

Use a tool that understands serialized data. WordPress stores some settings and builder data in serialized form, where each string carries its length; a raw SQL find-and-replace can corrupt it. Dedicated search-and-replace tools handle serialization correctly.

Option A: Better Search Replace plugin

  1. Install and activate Better Search Replace from Plugins > Add New.
  2. Go to Tools > Better Search Replace.
  3. In Search for, enter your old address, for example http://yoursite.com. In Replace with, enter https://yoursite.com.
  4. Select all tables, tick Run as dry run first, and review the count of changes it would make.
  5. Untick the dry run, run it for real, then clear your caches and recheck the page.

Replace only your own domain, including the www variant if you used one (http://www.yoursite.com to https://www.yoursite.com). Do not blanket-replace every http:// on the site: a third-party resource that genuinely has no HTTPS version would break instead of being fixed.

Option B: WP-CLI, if you have command-line access

WP-CLI’s search-replace also handles serialized data, and it is faster on large sites:

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

Run the dry run first, check the numbers, then run it without the flag. As with the plugin, run it for your domain only.

Step 3: Force HTTPS for Every Visitor

Fixing stored URLs is not enough on its own. You also want every visitor who arrives over HTTP to be sent to HTTPS, so no one ever lands on the insecure version of a page.

On Apache, with .htaccess

Add this redirect near the top of your .htaccess file, before the WordPress block:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Use a 301 permanent redirect, and keep a copy of the original .htaccess before editing it.

A note on wp-config.php

You may see advice to add define('FORCE_SSL_ADMIN', true); to wp-config.php. That forces HTTPS for the admin area only — not for front-end visitors, and not for mixed content in posts. It belongs in a broader WordPress security hardening routine, not as a substitute for the redirect above.

Step 4: Fix Hard-Coded and Third-Party References

If the warning survives the database cleanup, something is generating HTTP URLs at render time rather than reading them from the database. Work through these in order:

  • Theme and child-theme files: search your theme for hard-coded http://yoursite.com references — a logo URL, a script enqueue, or a font link in header.php or functions.php. Change them to HTTPS, or better, to protocol-relative or site-relative paths where that makes sense.
  • Page-builder CSS: Elementor and similar builders can cache generated CSS files that still contain old URLs. After a search-and-replace, regenerate those files (in Elementor, under Tools > Regenerate CSS) and clear the builder cache.
  • Widgets and custom HTML blocks: check footer widgets, custom HTML blocks, and embed codes for old HTTP image or script URLs. These are easy to miss because they do not live in post content.
  • Third-party embeds: if an external script, font, or iframe only loads over HTTP, first try its HTTPS version — most providers support it. If it genuinely has no HTTPS version, replace it. Loading an insecure script on a secure page is not a trade worth making.
  • CDN or proxy settings: if you use Cloudflare or another proxy, check its SSL mode. “Flexible” SSL encrypts the visitor-to-proxy leg but talks HTTP to your origin, which is a classic source of mixed content. “Full (strict)” with a valid certificate on your origin is the correct setting.

A plugin such as SSL Insecure Content Fixer or Really Simple SSL can rewrite URLs on the fly as a stopgap, but it masks stored HTTP URLs instead of removing them. The database cleanup above is the permanent fix.

If the Warning Is Still There

  1. Clear every cache: your caching plugin, server cache, and CDN cache, then hard-refresh the browser (Ctrl/Cmd + Shift + R). Stale cached pages are the most common reason a fix looks like it failed.
  2. Recheck the Console and note whether the remaining URLs are the same ones or new ones. Same URLs mean your fix did not reach that source; new ones mean you are making progress and have a shorter list left.
  3. Watch for redirect loops: if you stack a plugin redirect on top of a server redirect and a CDN redirect, browsers can report too many redirects. Keep one redirect layer as the source of truth and disable the duplicates.

As a temporary safety net, a Content-Security-Policy: upgrade-insecure-requests header tells browsers to upgrade HTTP subresource requests to HTTPS automatically. It is a bridge, not a replacement for fixing the URLs, and do not enable HSTS until HTTPS is stable site-wide.

How to Prevent Mixed Content in Future

  • Always build and edit on the HTTPS address, so new content never stores HTTP URLs in the first place.
  • When migrating a site, run the search-and-replace as part of the migration checklist, not as an afterthought. My WordPress migration guide includes it in the sequence for exactly this reason.
  • Use relative URLs or WordPress functions such as site_url() and get_template_directory_uri() in theme code, instead of hard-coding a domain with a protocol.

Wrapping Up

To fix WordPress mixed content errors: confirm your site URLs use HTTPS, run a serialization-safe search-and-replace for your own domain, force HTTPS with a 301 redirect, then hunt down hard-coded stragglers and clear your caches. Most sites are clean after the first two steps.

If you would rather not dig through database tables and server files yourself, get in touch — a mixed-content cleanup is usually a quick job once the insecure URLs are identified.

Further reading: How to Fix Mixed Content Errors After SSL Installation and How to Fix Mixed Content & “Not Secure” SSL Errors in WordPress.