How to fix mixed content errors in WordPress

What a mixed content error means

When a page is served over https, everything it loads should come over https too. If the HTML is secure but an image, script or stylesheet comes from an http address, an attacker on the same network could read or change that part of the page, so browsers treat it as a risk.

So mixed content is not only a cosmetic warning. A blocked stylesheet can make a page look unstyled, and a blocked script can stop a checkout or contact form working. For search engines, the page itself is still https, but a broken render hurts how the page looks and works for visitors and crawlers alike.

Where the http links come from in WordPress

The database is usually the biggest source. WordPress saves full URLs in post content, in options and in post meta, so changing the site address does not touch links that were written in years ago.

How to find every insecure URL

Load a page over https, open Chrome DevTools and look at the Console. Each warning or error names the page and the exact http URL. Check the home page, a post, a page, an archive and any shop or form pages, because templates differ.

From a terminal you can list the http references in the HTML a page sends:

curl -s https://example.com/ | grep -oE "(src|href)=[\"']http://[^\"']+" | sort -u

That catches links in the HTML, but not those added by scripts or inside CSS files. The security audit lists mixed content found on a page alongside the certificate and redirect checks.

Counting them in the database

With WP-CLI on the server, a dry run of the search and replace counts matches per table without changing anything:

cd /var/www/example.com
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run --report-changed-only

The report shows which tables and columns hold old links, typically wp_posts, wp_postmeta and wp_options. Matches outside the database, in theme files or plugin settings stored elsewhere, need fixing separately.

Fixing the settings and the database

1. Set the site addresses

In Settings, General, change both WordPress Address (URL) and Site Address (URL) to https. If those fields are greyed out, they are fixed in wp-config.php:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

2. Back up, then replace old links

Take a database backup first, then run the real replacement. WP-CLI handles serialised PHP data correctly, which a plain SQL REPLACE query does not; editing serialised values with SQL can corrupt widget and theme settings.

wp db export before-https.sql
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid
wp search-replace 'http://www.example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid
wp cache flush

The guid column is skipped because WordPress uses it as a permanent identifier for feed readers, not as a link. Run the second line only if your old links used www and your site now uses the bare domain. If you have no shell access, a search and replace plugin that supports serialised data does the same job from the dashboard.

3. Behind a proxy or CDN

If a CDN or load balancer handles HTTPS and talks to WordPress over http, WordPress believes every request is http and writes http asset URLs. Add this near the top of wp-config.php, above the line that loads WordPress settings:

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

Only trust this header when your server can only be reached through the proxy. The full explanation is in mixed content behind a proxy.

Fixing themes, page builders and plugins

Search the active theme and child theme for hard-coded http addresses:

grep -rn "http://" wp-content/themes/example-child/ --include=*.php --include=*.css --include=*.js

Replace hard-coded addresses with WordPress functions, which always use the configured https address:

<img src="<?php echo esc_url( get_stylesheet_directory_uri() . '/images/logo.svg' ); ?>" alt="Example Bakery">
wp_enqueue_script( 'example-slider', get_stylesheet_directory_uri() . '/js/slider.js', array(), '1.0', true );

Plugins should load files with wp_enqueue_script and wp_enqueue_style, which follow the site address automatically. If a plugin still loads an http file, update it, check its settings for a stored URL, or replace it. Page builders keep their own copies of URLs and generated CSS: after the database replacement, use the builder's tool to regenerate CSS so cached files pick up the new addresses. Also check the Additional CSS panel under Appearance and any custom HTML widgets.

When an SSL plugin helps

SSL plugins can rewrite http to https in the page output on the fly, add the HTTPS redirect and set the proxy fix. That is a quick way to clear warnings on a site you cannot fix properly yet, but the old links stay in the database and every page is rewritten on every request. Treat it as a stopgap: fix the database and theme, then the plugin's rewriting is no longer needed. As an extra safety net, a Content-Security-Policy: upgrade-insecure-requests header tells browsers to request every http resource on your pages over https; see security headers in WordPress.

Worked example: a bakery site after its HTTPS switch

Example Bakery moved to https, but its menu page showed missing photos and the slider stopped working. The Console listed eleven mixed content messages.

1. Nine were images under http://www.example.com/wp-content/uploads/ inside post content. A WP-CLI dry run found 412 matches in wp_posts and 37 in wp_postmeta.
2. One was the slider script, loaded by the child theme's functions.php from a hard-coded http address. It was blocked outright, which is why the slider failed.
3. One was a background image in the page builder's generated CSS file.
4. The owner exported the database, ran the search and replace for the www and bare http addresses with --skip-columns=guid, and flushed the cache.
5. They changed the theme to load the script with get_stylesheet_directory_uri(), regenerated the builder's CSS and purged the CDN.
6. The Console was clean on every template, and the security audit reported no mixed content.

The fix, step by step

Edge cases worth knowing

• Third-party resources without https. If an external service has no https version, the browser keeps blocking it. Host the file yourself or replace the service.
• Multisite. Run the replacement with --network, and update each site's address in the network admin as well as in the wp_blogs and wp_site tables.
• Links in emails and feeds. Old newsletters and feed readers may still point at http pages; a working 301 redirect handles those, as covered in WordPress redirects.
• Warnings only for logged-in users. Admin bars and editor plugins can load their own assets. Test logged out in a private window, which is what visitors see.

Keeping mixed content away

Make sure every http request redirects to https in a single hop, following HTTPS redirects, so any old link still lands on a secure page. Teach editors to upload images through the media library rather than pasting addresses from other sites. After installing a new theme, plugin or page builder template, check the Console on a few pages. When you move the site to a new domain or host, run the same search and replace as part of the move; WordPress migration fixes covers the rest of that checklist. Run the security audit every few months to catch anything new.