How to fix mixed content warnings in WordPress

Step by step

1. List the insecure requests

Open an affected page, open the browser's developer tools and look at the Console. Each problem is reported as Mixed Content, with the page URL and the insecure resource URL. Note the resource addresses and sort them into three groups: your own domain, a domain you control such as a CDN or subdomain, and third parties. Check the homepage, a post, a category page and any page built with a page builder, because each pulls assets from different places.

2. See what WordPress already fixes on the fly

If you switched to https from Tools → Site Health, or changed both site URLs on a site that had content, WordPress sets a flag and replaces http:// versions of your own site address with https:// each time it renders post content, excerpts, text widgets and custom CSS. That hides many warnings without touching the database. It only covers those places and only your exact site address, so it is a safety net and not the fix.

3. Back up, then dry-run the replacement

Export the database first. Then ask WP-CLI what it would change:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

The report lists each table and column with a count. --skip-columns=guid leaves post GUIDs alone, since they are identifiers and not links. If your old URLs used www, run a second pass for http://www.example.com.

4. Run the replacement

Remove --dry-run and run it again. WP-CLI handles serialized data, which is why it is safer than a plain SQL REPLACE: page builder layouts, widget settings and theme options store URLs inside serialized arrays, and a raw replace corrupts them when the string length changes. Without shell access, use a search-replace plugin that states it supports serialized data, and delete it afterwards.

5. Fix what the database pass cannot reach

• Theme files. Search the active theme for http:// in header.php, footer.php, functions.php and CSS. Fonts and scripts loaded with a hard-coded http:// address are common in older themes. Change them to https://.
• Page builder CSS files. Builders that write generated CSS to disk keep the old URLs until you use their regenerate CSS or clear cache tool.
• Customizer and theme options. Logos and background images saved as full URLs sometimes need re-selecting.
• Third-party embeds. An http:// iframe or script from another site must be changed to https://. If that service has no https version, remove the embed, since browsers will not load it.

6. Purge caches and retest

Purge the page cache, any minification or CSS cache, and the CDN. Reload the pages you checked with the console open. No Mixed Content lines means the page is clean. For a wider check, crawl the site with a tool that reports insecure resources, or sample your most visited templates by hand.

7. Add a safety net header, if you want one

The response header Content-Security-Policy: upgrade-insecure-requests tells browsers to request every http:// resource on the page over https instead. It is useful while you hunt down the last few URLs, because it prevents warnings for assets that do exist on https. It does not help with a resource that has no https version, and it should not replace cleaning the stored URLs.

Why it matters beyond the padlock

An image that fails to load can be the largest element on the page, which changes how the page measures on Core Web Vitals. A blocked stylesheet changes the layout Google renders. A blocked script can remove content that is added by JavaScript. None of this is a penalty. It is the page working worse than you think, for visitors and for the crawler that renders it.

Mistakes to avoid

• Replacing http:// with https:// globally, without your domain in the search string. It rewrites links to every other site you mention, including ones that do not support https.
• Editing URLs directly in SQL. Serialized values break.
• Using protocol-relative URLs (//example.com/...) as the fix. They work, but plain https:// is clearer and what WordPress itself generates.
• Forgetting the CDN hostname. If assets come from http://cdn.example.com, that string needs its own search-replace.