If your WordPress site has a certificate and loads over https://, but the padlock is missing or a slider, form, or checkout step stopped working, mixed content is the usual suspect. This guide shows a site or store owner how to do a WordPress mixed content fix properly: find the exact http:// file, work out where WordPress is storing it, and change it at the source.

Mixed content means the page itself arrives over HTTPS, but something on it, such as an image, script, stylesheet, font, or iframe, is still requested over plain HTTP. Chrome's DevTools documentation on the Security panel describes these pages as only partially protected, because the HTTP parts can be read or changed in transit.

Why it matters on a store, not just a blog

MDN's page on mixed content explains that browsers try to upgrade some requests, such as images, audio, and video, to HTTPS, and block the rest. For an owner, that means two different symptoms:

  • The page looks fine, but the padlock is downgraded. Usually an old image or media file.
  • Something quietly breaks. A blocked script or stylesheet can take a menu, a chat widget, a payment button, or a page-builder layout down with it, and visitors just see a broken page.

The second kind is the one that costs sales, and it often shows up only on one product template or one old landing page.

Step 1: Find the exact http:// file

Do not start with a plugin. Start by finding the URL.

  1. Open the page in a private window, so your logged-in admin view and cached files do not hide anything.
  2. Open the browser's developer tools and look at the Console. Google's web.dev guide to fixing mixed content notes that Chrome reports mixed content there as warnings and errors, naming the http:// URL.
  3. In Chrome you can also open the Security panel. Its Non-secure origins section links to the matching requests in the Network panel.
  4. Write each URL down next to the page you found it on.

The same web.dev guide points out the catch: the console only shows problems for the page you are viewing, and clears when you navigate. So check the pages that matter one by one: home, a product page, cart, checkout, the contact form, and any promo landing page you still link to.

Step 2: Work out where WordPress keeps that URL

The http:// address tells you a lot about where it lives:

  • It is your own domain, under /wp-content/uploads/. The link is almost always inside post or page content, a page-builder block, or a widget, saved from before the site moved to HTTPS.
  • It is your own domain, under /wp-content/themes/ or /wp-content/plugins/. The theme or plugin is building the URL itself, often from an old setting or a hard-coded path. Check the theme options first, then the plugin's settings.
  • It is another company's domain. A tracking pixel, font, map, video, or review widget pasted in years ago. Usually it sits in a header or footer script box, a custom HTML widget, or a plugin that inserts code.

Step 3: Check the two address settings first

Go to Settings, then General. The WordPress Address (URL) and Site Address (URL) should both begin with https://. The WordPress handbook page on HTTPS for WordPress covers this setup, including sites behind a proxy or load balancer.

Since WordPress 5.7, Site Health can also help. The core team's note on HTTPS detection and migration in WordPress 5.7 explains that Site Health can detect whether your hosting already supports HTTPS and offer a one-click switch. After a switch on a site with existing content, WordPress rewrites old http:// links to your own home URL on the fly as pages are shown.

That is useful, but know its limits. It covers links to your own site address, not third-party files. And it fixes the output, not the stored content, so the old links are still in the database.

Step 4: The lasting mixed content fix in WordPress, with a backup first

For your own domain, the lasting fix is to update the stored URLs from http:// to https://. You have three common routes:

  • Edit by hand. Fine for a handful of posts or one widget.
  • A search-and-replace plugin. Practical for many posts. Use a well-maintained one and read its instructions.
  • WP-CLI, if your host offers it. The wp search-replace command handles PHP serialized data, which matters because many themes and page builders store settings that way. It has a --dry-run option that reports what would change without saving, and its documentation shows how to skip a column such as guid.

Whatever route you use, take a full backup first and make sure you can restore it. A database-wide replace is hard to undo, and a mistyped string can break a lot at once. The WordPress handbook page on backups covers what to include, and our website backup and restore checklist walks through testing that a restore really works.

Replace the exact old address, such as http://www.yourshop.com, with the new one. Do not run a blanket swap of every "http:" in the database, which would also rewrite links to other sites that may not support HTTPS at all.

Step 5: Fix the theme, plugin, and third-party URLs

For files that come from your theme or a plugin:

  • Look for a URL field in the theme options, customizer, or plugin settings that still says http://, and update it.
  • If a child theme or custom code hard-codes the address, ask your developer to fix it there.
  • Update the theme or plugin. If it still loads an http:// file in its current version, report it to the developer.

For third-party files, the web.dev guide suggests checking whether the same file loads at its https:// address. If it does, update the snippet. If it does not, host the file yourself, find another provider, or remove the widget.

Step 6: Clear caches and check again

Once the links are fixed, clear every cache layer you have: a caching plugin, your host's cache, and a CDN if you use one. Then repeat Step 1 in a fresh private window on the same list of pages. A fix that only shows up in the admin view has not reached your visitors yet.

What about "just add a header"?

You will see advice to add the Content-Security-Policy directive upgrade-insecure-requests. MDN explains that it tells the browser to request HTTP resources over HTTPS instead. It can be a reasonable safety net, but it only works if each file is actually available over HTTPS, and it does not fix the stored links. If you want to go further with CSP, our Content Security Policy guide covers rolling it out without breaking the site.

Some plugins that "force SSL" work in a similar way: they rewrite links as pages are served. They can hide the symptom while the old links stay in your content, so treat them as a stopgap.

What this check does and does not prove

Clearing every mixed content warning on the pages you checked shows that those pages, at that moment, loaded all their files over HTTPS. It does not prove the site is secure. A clean padlock means the connection is encrypted. It says nothing about outdated plugins, weak admin passwords, or a malicious script that is itself served over HTTPS. Pages you did not open may still have problems.

Re-check after a theme change, a new plugin, a page-builder update, a CDN change, or a site migration. Those are the moments mixed content usually comes back. If your browser still says "Not Secure" after all this, our earlier guide on why a website says "Not Secure" and how to fix it covers the HTTP redirect and certificate causes.

A free outside-in scan, if you want a second look

We build HackerMe, a free outside-in website security scanner owned by Agura. If you want a second look at HTTPS redirects, TLS settings, and security headers, you can run a free website security scan of a domain you own or have explicit permission to test. The scan reports what it observed from outside on that run. It cannot see inside your WordPress admin or database, and it does not replace checking your key pages in a browser.

Find the file. Fix it where it is stored. Then check again on the pages your customers actually use.

Originally published on the HackerMe Substack.