Maintenance

Mixed Content Warnings After Moving WordPress to HTTPS: How to Fix Them

Padlock missing after moving WordPress to HTTPS? How to find insecure http images and scripts, run a safe search-replace, and fix CDN and theme settings.

Mixed Content Warnings After Moving WordPress to HTTPS: How to Fix Them
On this page
  1. What mixed content is
  2. Why it appears after moving to HTTPS
  3. Step 1: Find the insecure files
  4. Step 2: Confirm WordPress's own addresses
  5. Step 3: Search and replace old URLs safely
  6. Step 4: Fix hardcoded links in the theme and scripts
  7. Step 5: Check the CDN and clear every cache
  8. Quick fixes: useful, but not the cure
Key takeaways
  • Mixed content means an https page still loads some images, scripts or styles over http, which removes the padlock or breaks the layout.
  • Find the insecure files in the browser console, then fix them at the source with a serialisation-safe search-replace and edits to hardcoded theme and script links.
  • Check CDN settings, purge every cache, and treat SSL plugin fixers and the upgrade-insecure-requests header as a stopgap, not the cure.

You installed an SSL certificate and your site now opens on https, yet the browser still won't show a secure padlock. Some images may have vanished, a slider has stopped working, or the layout looks broken. The usual cause is mixed content: a secure page that still loads some of its files over plain http. Here's how to find every insecure link and fix it properly, rather than just hiding the warning.

What mixed content is

A page is only fully secure when everything on it, including images, stylesheets, scripts, fonts and embedded videos, loads over https. When an https page pulls in even one file over http, browsers treat the page as not fully secure.

Browsers generally handle it in two ways:

  • Scripts, stylesheets and iframes loaded over http are blocked outright, which can break menus, sliders, forms and layouts
  • Images, audio and video are often upgraded to https automatically, and blocked if the file isn't available that way

Either way, visitors see a missing padlock or a broken page, and a checkout or enquiry form without a padlock is exactly where people hesitate. For other certificate warnings, see SSL certificate errors explained.

Why it appears after moving to HTTPS

Installing a certificate doesn't change the links already stored in your website. WordPress saves full URLs, including the http part, in many places:

  • Images and links inside posts and pages
  • Page builder data, widgets and theme customiser settings such as the logo
  • Theme files and custom CSS with hardcoded http addresses
  • Old tracking codes, chat widgets, fonts and embeds pasted into the header or footer
  • A CDN or caching plugin still set to an http address

Step 1: Find the insecure files

  1. Open the page in Chrome, press F12 and look at the Console tab. Each mixed content warning names the exact http file being requested.
  2. Right-click, choose View Page Source, and search for http://. Ignore normal links to other websites; you're looking for images, scripts, stylesheets and fonts.
  3. Check different page types, not just the homepage: a blog post, a service page, a product page, the cart, checkout and contact page. Different templates pull in different files.

Note down where each URL comes from. A pattern usually appears quickly, such as all older blog images, or one script in the footer.

Step 2: Confirm WordPress's own addresses

In Settings → General, both the WordPress Address and Site Address should start with https. If these fields are greyed out, they're set in wp-config.php, and a developer should change them there. Take a full backup before changing either setting, because a mistake here can lock you out of the dashboard; see the backup and restore guide.

Also make sure the http version of every page permanently redirects to https, usually through your host's "force HTTPS" option or a server rule. Set this up in one place only, or you risk a redirect loop.

Step 3: Search and replace old URLs safely

Most mixed content lives in the database, so the lasting fix is to replace http://yourdomain.com with https://yourdomain.com throughout it. Do it carefully:

  • Use a tool that understands serialised data. WordPress and plugins store many settings in a format that breaks if text is changed blindly with a raw database query. Plugins such as Better Search Replace, or WP-CLI's search-replace command, handle this correctly.
  • Back up first and do a dry run to see how many changes will be made before committing them.
  • Replace only your own domain, including the www or non-www version you used before. Never replace every "http://" on the site, because some external sites you link to may not support https.
  • Elementor sites: Elementor has its own Replace URL tool under Elementor → Tools. Afterwards, regenerate its CSS files from the same screen so the stored styles update too.

Anything outside the database needs finding and editing by hand:

  • Theme files: look for http links in header and footer templates, and background images in CSS files. Make edits in a child theme so theme updates don't undo them.
  • Additional CSS and theme options: logo, favicon and background image fields sometimes store a full http URL.
  • Header and footer scripts: old analytics, chat, font or map snippets may still use http. Replace them with the provider's current https code.
  • Third-party embeds that don't support https at all should be replaced or removed.

If a premium theme or plugin itself outputs http links, update it first; current versions usually handle https properly.

Step 5: Check the CDN and clear every cache

If a caching plugin rewrites file URLs to a CDN, make sure the CDN address in its settings starts with https and that the CDN has a valid certificate. With a proxy CDN such as Cloudflare, features like automatic HTTPS rewrites can catch leftover links, but treat them as a safety net rather than the fix. See what a CDN is for how the two common setups differ.

Then purge the caching plugin, the server cache, the CDN cache and your browser cache. Old cached pages often keep showing the warning after the real problem has been fixed.

Quick fixes: useful, but not the cure

  • SSL plugins often include a mixed content fixer that rewrites http links as each page loads. It works, but adds processing to every page view, and the warnings return if the plugin is ever switched off.
  • The upgrade-insecure-requests header tells browsers to request your http files over https instead. It only helps when those files are actually available on https; see security headers explained.

Use these as a temporary bridge while you fix the source links. Afterwards, add a quick mixed content check to your routine after every redesign, migration or new embed, and test forms and checkout on https each time.

Moving a site to HTTPS or a new host? I handle SSL setup, redirects and mixed content clean-up as part of WordPress migration, and keep it all in check afterwards with WordPress maintenance.

Need help with your website?

I'm Sameer, a freelance WordPress developer building fast, SEO-friendly websites since 2020. Tell me what you need and I'll reply with a plan and a fixed quote within 24 hours.

Found this useful? Share it:
Contact

Let's build your next website

Available for freelance projects, agency white-label work and long-term maintenance. Feel free to pass this along to your team or company.

Your details are emailed to me, then WhatsApp opens so we can chat right away.

Chat now