WordPress mixed content after moving to HTTPS: find the http:// links first

The certificate is installed, the address bar says https, and the slider still will not load. That is WordPress mixed content: the page arrives over https, but some of the files it asks for still use http:// addresses. The certificate did its job. The old links did not change with it.

What is WordPress mixed content?

It is a secure page that loads one or more files over plain http. MDN’s web docs split those files into two groups.

Images, audio and video are upgradable. The browser quietly asks for the same file over https instead.

Everything else is blockable. Scripts, stylesheets, iframes, web fonts and font files loaded from CSS are refused outright. The developer console logs a warning either way.

Why do only some parts of the page break?

Because of those two groups. A logo on an http address usually still shows, since the browser upgrades it. A slider script or a font file on an http address is blocked, so the slider stops and the text falls back to another font.

There is one catch. MDN lists an image with a srcset list as blockable, not upgradable. The srcset lists WordPress builds itself follow the site’s https address. One pasted into a post or a custom HTML block by hand keeps whatever addresses it was given, so an http:// one can go missing while a plain image next to it still shows.

On sites under our WordPress care plan, we run this check after every host move and every certificate change.

Where do the old http:// links hide?

In four places:

1. Post and page content, where every image added before the switch was saved with its full http:// address.
2. Theme and page builder settings, such as a logo, a background image or a custom font file.
3. Plugin settings and widgets, saved as serialized data in the options table.
4. Hard-coded files: a child theme’s CSS, a tracking script pasted into the header, an old iframe embed.

Settings, then General, also holds the WordPress Address and the Site Address. If either still starts with http://, every link WordPress builds starts there too. Change those two with care: a typo locks you out, which is what our site address lockout guide walks through.

Does the Site Health HTTPS button fix it?

Partly. Since WordPress 5.7, Site Health can switch both addresses to https with one click when the host supports it.

For old links in content, WordPress then rewrites http:// addresses on your own domain as the page is shown. That only happens when the switch was flagged as needing it (the https_migration_required option) and both addresses use the same domain. The Make WordPress Core note lists where: post content, excerpts, widget text and the Customizer’s custom CSS. The database still holds the http:// version, and page builder fields, theme options and plugin settings are outside that list.

How do you find mixed content on your site?

Open the page in Chrome or Firefox, open the developer tools, and read the Console. Each blocked or upgraded file has its own warning with the full http:// address.

On a whole site, a quick pass from the command line helps:

curl -s https://yoursite.com/ | grep -o 'http://[^"]*' | sort | uniq -c

Run it on the home page, the blog index and one long post. Each line it prints is an http:// address in the HTML. Some will be plain links to other sites, which are fine. Anything on your own domain, and any script, stylesheet or font, is a lead.

How do you replace the http:// links for good?

Take a backup first. Then, if your host gives you WP-CLI, run a dry run:

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

The dry run shows how many replacements it would make in each table and column, and saves nothing. Read the counts, then run the same line without --dry-run. The WP-CLI docs skip the guid column in their own examples, since those values are IDs, not links.

Use WP-CLI or a plugin built on the same idea, never a raw SQL replace. Plugin and theme settings are stored as serialized PHP, which records the length of every string. Swap http for https by hand and the length is off by one, and those settings stop loading. WP-CLI recalculates the lengths for you.

After that, fix what the database does not hold: hard-coded http:// paths in a child theme, and third-party scripts pasted with an http:// address.

If the site loops instead of loading once you switch, that is a different fault. The too many redirects guide covers it.

What did our own site show?

We checked distrocode.com with curl on the evening of 16 Oct 2026 (21:37 ET). A request to https://distrocode.com/ came back as a 301 to the https address. The https response carried Strict-Transport-Security: max-age=31536000, which tells the browser to use https for this domain for 365 days.

It also carried upgrade-insecure-requests, twice, in two separate Content-Security-Policy headers. Then we counted http:// strings in the HTML of the home page, the blog index and our post on email spam. All three came to zero.

That last number is the one that matters. The two headers are a safety net. MDN is clear that upgrade-insecure-requests fails with no fallback to http when a file is not on https, and that HSTS does not cover the very first http visit.

What should you do right now?

Open your home page, press F12 (Cmd+Option+J on a Mac in Chrome), and read the Console. If it lists Mixed Content warnings, note the addresses and check which of the four places above they come from.

Want us to look instead? Send the site address and the page that breaks. We do a free site check and reply within 2 business days with a written report on where the http:// links live and the work to replace them. Send us the site and the page. A new site fix goes up each day on DistroCode’s LinkedIn Page.

Not sure what is wrong yet? Ask for the free site check: send the site address and we reply in writing within 2 business days. If you already know what to fix, the one-off fixes are listed here.