You fix mixed content warnings by finding every resource that still loads over HTTP on your now HTTPS pages and switching each to HTTPS. The concept to hold onto is simple: mixed content means a secure page is pulling in insecure assets, an image, a script, a stylesheet, a font, or an embed served over HTTP, so the browser warns or blocks them because the page is only as secure as its least secure resource. After an HTTPS migration these come from a few predictable places. Hardcoded HTTP URLs sit inside your content and database, baked into old posts and settings. Theme and template files reference assets with explicit HTTP URLs. And third party embeds, widgets, or scripts may be loaded over HTTP. The fix is to update each to HTTPS, replacing hardcoded HTTP links in the database and content, correcting template references, and updating or replacing any third party resource that does not support HTTPS. A site wide search for HTTP references is how you find them all. WPBuildAI scans your site and returns each page’s content, so you can locate the pages still carrying HTTP references that trigger the warning.

Sweep the host variants too, not just the canonical one: Google’s June 2026 guidance treats every subdomain and both the www and non-www form as part of the same move, and a forgotten variant still serving assets over plain HTTP is a common source of warnings that appear fixed on the main hostname.

What mixed content actually is

Mixed content has a precise meaning worth getting right, because it guides the fix. When a page is served over HTTPS, the page itself travels securely, but a page is made of many resources, and each of those is fetched by its own URL. If any of those resource URLs is HTTP, that part of the page travels insecurely, which is mixed content: a secure document loading insecure pieces. As fixing mixed content explains, browsers respond by warning the user or outright blocking the insecure resource, because the security of the page is only as strong as its weakest link. So the goal is total: every resource a page loads must come over HTTPS, with no exceptions, or the warning persists.

Why a migration leaves HTTP references behind

It is worth understanding why this happens, because it tells you where to look. Moving to HTTPS changes the protocol your pages are served on, but it does not automatically rewrite every URL that was written down inside your site before the move. Years of content may contain image and link URLs typed with an explicit HTTP prefix. Settings and configuration in the database may store HTTP URLs. Templates may hardcode asset paths with HTTP. The migration flips the front door to secure, but all these old references still point at HTTP, and they keep doing so until something changes them. This is why mixed content is a classic loose end of an HTTPS move, covered as a risk in moving from HTTP to HTTPS without losing SEO, and why fixing it is mostly a thorough find and replace.

Source one: hardcoded URLs in content and the database

The largest source is usually your own content and database. Old posts and pages may embed images or links with explicit HTTP URLs, and site settings or plugin configuration may store HTTP URLs that get output into pages. The fix is to replace these HTTP references with HTTPS ones across your content and database, which on a content heavy site can be many references. Web Almanac 2024 (HTTP Archive) is a reminder of how image heavy and resource heavy pages are, so there are often more hardcoded references than expected. A careful, site wide search and replace of your own HTTP URLs to HTTPS, applied to both the content and the stored settings, clears the bulk of mixed content in one disciplined pass.

Source two: theme and template references

The second source is your theme and templates, which may reference assets, scripts, stylesheets, fonts, with explicit HTTP URLs in their code. These are not in your content; they are in the files that build every page, so a single hardcoded HTTP reference in a template can cause mixed content site wide. The fix is to update those references to HTTPS, or to protocol relative or HTTPS URLs, in the template code. Because template references repeat across every page that uses the template, fixing one can clear the warning from hundreds of pages at once, which makes the templates a high value place to look right after the content. Check the head and footer includes especially, where shared scripts and styles are commonly loaded.

Source three: third-party embeds and scripts

The third source is external: embeds, widgets, analytics, fonts, or scripts loaded from third party services over HTTP. Here the fix is the same in spirit, switch to the HTTPS version of the resource, but with a twist: you depend on the third party supporting HTTPS. Most reputable services do, so you simply change the embed to its HTTPS URL. If a third party resource genuinely does not support HTTPS, you cannot make it secure, so the right move is to replace it with one that does, because keeping an HTTP only resource means living with mixed content indefinitely. Audit your external resources after the move, switch each to HTTPS, and replace any holdout, so no part of your page depends on an insecure third party.

How to find every instance

The way to fix mixed content completely rather than piecemeal is to find every instance systematically. Load your key pages and check the browser for mixed content warnings, which name the offending resources. Then do a site wide search for HTTP references across your content, database, and templates, so you catch the ones not currently on a page you happened to check. Crawling the site to surface pages that still contain HTTP references turns a guessing game into a list. The principle behind why HTTPS matters is that security should be complete, so partial fixing leaves the warning in place. WPBuildAI scans your site and returns each page’s content, so you can find which pages still carry HTTP references rather than checking them one at a time.

Steps to fix mixed content after an HTTPS migration

  1. Confirm the symptom by loading key pages and reading the browser warnings.
  2. Search and replace HTTP URLs to HTTPS across your content and database.
  3. Fix template references in theme files, especially shared head and footer includes.
  4. Switch third party embeds to their HTTPS versions.
  5. Replace any resource that does not support HTTPS with one that does.
  6. Recrawl the site to confirm no page still loads an HTTP resource.

Worked example: clearing a site of mixed content

Imagine a site that moved to HTTPS but shows not secure warnings on many pages. The team starts by loading a few pages and reading the browser warnings, which point at images and a script. They run a site wide search and replace of their own HTTP URLs to HTTPS across content and database, fixing thousands of hardcoded image links in old posts. They check the theme and find the header loads a font and a script over HTTP, hardcoded in a template, and fixing those clears the warning from every page at once. They audit third party embeds and switch an analytics snippet and a map widget to HTTPS, and replace one old widget that did not support HTTPS. Finally they recrawl the site and confirm no page still loads an HTTP resource. The padlock returns site wide, because every resource now travels securely, completing the HTTPS move begun in moving from HTTP to HTTPS.

Limitation: mixed content is a completeness problem

It is fair to frame the boundary. Fixing mixed content is about completeness, not cleverness: there is no partial credit, because a single HTTP resource on a page keeps the warning, so the work is finding and fixing every instance rather than most of them. That makes thoroughness the whole challenge, especially on large, old sites with many hardcoded references. It also does not, by itself, improve your rankings; it removes a trust and functionality problem and completes your HTTPS move, which protects user experience and the secure status you migrated for. A slow or broken page from blocked resources can affect experience signals, related to why a site is slow after a redesign, but the direct payoff of fixing mixed content is a secure, unbroken page, not a ranking boost.

Common mistakes

  • Fixing the visible warnings on a few pages but missing site wide references.
  • Updating content while leaving hardcoded HTTP URLs in templates.
  • Forgetting the database and settings, which store HTTP URLs that get output.
  • Leaving a third party embed on HTTP instead of switching or replacing it.
  • Assuming the HTTPS migration rewrote existing references automatically.

Key points

You fix mixed content warnings by switching every resource that still loads over HTTP on your HTTPS pages to HTTPS, because a secure page is only as secure as its weakest asset and a single HTTP resource keeps the warning. The references come from three predictable places after a migration: hardcoded HTTP URLs in your content and database, explicit HTTP references in theme and template files, and third party embeds loaded over HTTP. Fix each by search and replace across content and database, by correcting template references that repeat site wide, and by switching or replacing third party resources, then recrawl to confirm none remain. This is a completeness problem, so thoroughness is the whole job, and it finishes the HTTPS move rather than boosting rankings on its own. WPBuildAI scans your site and returns each page’s content, so you can locate the pages still carrying HTTP references that trigger the warning. Send your web address for a free analysis.

Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.