DEV Community

Sandeep Singh
Sandeep Singh

Posted on

Mixed Content and Missing Images: A Practical Fix Guide for Store Owners

#seo #ecommerce #webdev #beginners

Two problems turn up on almost every store that has been around for a few years: mixed content (insecure http:// files loaded on a secure https:// page) and missing images (product photos, banners or icons that return an error, leaving an empty box or a broken-image icon).

They often share a root cause, usually a migration, an HTTPS switch, or media copied from another site, and they're fixed with similar tools, so it makes sense to tackle them together. This guide explains what's going on in plain terms and gives you fixes for Shopify, WooCommerce and everything else.

Part 1: Mixed content

What it is

Your page loads over HTTPS, which means the connection is encrypted. If that page then pulls in an image, script, stylesheet, font or iframe over plain http://, that file travels unencrypted. MDN's definition: mixed content means "securely loaded web pages that use resources to be fetched via HTTP or another insecure protocol" (MDN: Mixed content).

What browsers do about it today

This is where a lot of older advice is out of date. According to MDN, modern browsers:

  • Auto-upgrade images, video and audio (for example an <img src="http://…">) to https://. If the file exists at the HTTPS address, it loads. If it doesn't, it fails and you get a missing image.
  • Block almost everything else outright: scripts, stylesheets, web fonts, iframes, fetch() calls, and images set through srcset or <picture>.
  • Block even upgradable types when the URL uses an IP address instead of a domain name.

For a store, that means:

  • An http:// script (an old tracking pixel, a reviews widget, a chat embed) is blocked, so that feature silently stops working.
  • An http:// stylesheet or font is blocked, so parts of the page lose their styling.
  • An http:// image on a server without HTTPS fails after the auto-upgrade, so a product photo disappears.
  • An http:// iframe (an embedded size chart, video or map) is blocked and shows a blank box.

So mixed content is no longer mainly a "Not secure" padlock warning. It's a broken features problem.

How to find it

In the browser (any platform): open the page, press F12, and look at the Console. Chrome and Firefox log a warning for every mixed-content request, saying whether it was upgraded or blocked, and with the exact URL. Check your homepage, a product page, a collection/category page, the cart and a blog post, since each uses a different template.

With Lighthouse (built into Chrome DevTools): run the Best practices category. The "Uses HTTPS" audit lists insecure requests it found on that page (Chrome for Developers).

Across the whole site: a crawler checks every page rather than the five you happened to open. Screaming Frog SEO Spider's free version (up to 500 URLs, limits) reports mixed content under its Security tab. Note the source page for each hit so you know where to fix it.

How to fix it

The rule is simple: every resource on your site should be requested over HTTPS. How you get there depends on where the http:// reference lives.

1. Your own files: change http://yourstore.com/... references to https:// or to relative paths (/wp-content/uploads/..., /cdn/shop/files/...).

2. Other people's files: change http:// to https:// if the provider supports it. Paste the HTTPS version into a browser tab to check it loads. If they don't support HTTPS, host the file yourself or find a different provider. An embed that can't load securely shouldn't be on a checkout-adjacent page anyway.

3. Where the references hide, by platform:

WooCommerce / WordPress

  • Most mixed content on WordPress comes from old URLs saved in the database before the switch to HTTPS, in post content, product descriptions, widgets and page-builder data.
  • First, check Settings → General: both WordPress Address and Site Address should start with https:// (see WordPress's HTTPS guidance).
  • Then do a database search-and-replace from http://yourstore.com to https://yourstore.com with a tool that handles WordPress's serialized data, such as the free Better Search Replace plugin. Take a full backup first, and run it as a dry run before the real thing.
  • Check theme options, header/footer script boxes and any "custom HTML" widgets by hand. These often contain pasted embed codes.

Shopify

  • Shopify serves storefronts over HTTPS, so mixed content almost always comes from pasted code: old embed snippets in theme files, custom Liquid sections, product descriptions written in HTML view, or apps that inject http:// assets.
  • In Online Store → Themes → … → Edit code, use the code editor's search to look for http:// across theme files.
  • In product descriptions and pages, switch the rich-text editor to HTML (<>) and search for http://.
  • If an uninstalled app left code behind, remove its snippet references. App developers usually document which files they touched.

Any platform

  • A Content-Security-Policy: upgrade-insecure-requests header tells browsers to upgrade all requests to HTTPS. It's a useful safety net, but it doesn't help if the HTTPS version of a file doesn't exist, so still fix the source.
  • If you use a CDN, its "automatic HTTPS rewrites" option can rewrite links on the fly. Again, treat that as a backstop.

Part 2: Missing images

Why images go missing

  • Deleted from the media library or Files while still used in a product description, banner or blog post.
  • Migrations where image paths changed (/images/ → /wp-content/uploads/2026/10/ or Shopify's CDN) but old content still references the old path.
  • Hot-linked images pulled from a supplier's or another site's server, which later moved or blocked hot-linking.
  • Auto-upgrade failures, the mixed-content case above: http:// image, no HTTPS version, nothing loads.
  • Missing resized versions. WordPress generates several sizes for each upload and references them in srcset. After a theme change or migration, some sizes may not exist, so certain screen widths show a broken image while others look fine.
  • Case and character mismatches. Product-Photo.JPG and product-photo.jpg are different files on most Linux servers.
  • Lazy-loading or optimisation plugins that rewrite image URLs. If the plugin is removed or misconfigured, the rewritten URLs can point nowhere.

How to find them

Quick check: open DevTools → Network, filter by Img, reload the page and sort by Status. Anything with 404 (or 403) is a missing image. Do this on desktop and in the device toolbar at a phone width, because srcset picks different files for different screens.

Whole site: in a crawler, look at image URLs with 4xx responses, then use the "inlinks" or "source" view to find which pages reference each one. Fix at the source page, not just the file.

Also worth checking while you're there: images with missing alt text. Alt text is how screen-reader users understand product photos, and Google uses it, along with surrounding content, to understand images (Google Search Central: image SEO). Describe the product plainly ("Navy linen shirt, front view"). Don't stuff keywords.

How to fix them

  1. Re-upload the file to your own media library (WordPress) or Content → Files (Shopify) and update the reference to the new URL. Don't hot-link.
  2. Regenerate thumbnails on WordPress after a theme change, using a regenerate-thumbnails plugin or WP-CLI (wp media regenerate), so every srcset size exists.
  3. Fix paths in bulk after a migration with a search-and-replace on the old path prefix (WordPress), or a bulk product CSV export, edit and import (Shopify).
  4. Remove or replace images you no longer have rights to or can't recover. An empty space is better than a broken-image icon on a product page.
  5. If an image URL was shared externally (Pinterest, ads, marketplaces), add a redirect from the old image URL to the new one where your platform allows it.

A 15-minute routine to keep both under control

  • After any theme change, migration, app removal or bulk import: open the homepage, one product, one collection, the cart and one blog post with the Console and Network tabs open.
  • Monthly: crawl the site and export mixed-content and image-4xx lists.
  • Before pasting any embed code, check that every URL in it starts with https://.
  • Keep product images in your own store's media, never on a supplier's server.

Automating the check

These problems usually appear right after a change, which is exactly when nobody is looking. A scheduled crawl catches them sooner.

Disclosure: I build Uchik. Uchik is a hosted monitor that crawls your store daily with read-only requests and emails a report of mixed content, missing images, broken links and redirect chains, each with the source page and the exact HTML tag. The features page explains how it reads src and srcset attributes on images, and the sample report includes an http:// image flagged on a checkout page. You can sign up for free. It reads the HTML your server sends, so images injected only by JavaScript still need the DevTools check above.

Summary

Symptom Likely cause Fix
Widget or embed stopped working http:// script or iframe blocked Switch to HTTPS version or replace the provider
Page partly unstyled http:// stylesheet or font blocked Update the reference to HTTPS/relative
Blank product photo Image 404, or auto-upgrade to missing HTTPS file Re-upload to your own media; update reference
Photo broken only on phones Missing srcset size Regenerate thumbnails
Console full of warnings after HTTPS move Old http:// URLs in database Backup, then search-and-replace

Serve everything over HTTPS, host your own images, and check the console after every change. That covers almost every case.

Top comments (0)