How to find and fix mixed content after an HTTPS move

Understand what the browser is protecting

A page delivered over HTTPS can still ask the browser to fetch an image, script, style sheet, font, frame, or download over HTTP. That creates a mixed-content risk: the main page is protected in transit, while a requested resource may be observed or changed before it reaches the customer. The effect is not uniform. Current browser guidance describes some image, audio, and video requests as candidates for automatic HTTPS upgrading, while scripts, styles, frames, fetch requests and other types are generally blocked when insecure. A picture that seems to load in one browser therefore does not prove that the page is correctly migrated. A blocked checkout script may instead stop a customer action outright.

The business decision is which journeys must work after migration and which owners can repair each dependency. Map the homepage, product detail, account access, checkout, confirmation, and any secure download that matters to your site. Include pages generated from a content system as well as code templates; an old image URL may be stored in editorial content rather than in source code. Identify third-party widgets and embedded services, but do not assume their HTTP endpoint has a working HTTPS twin. Test the actual endpoint, redirects, certificate, and requested resource. The secure padlock for the main page is useful context, not an inventory of everything the browser tried to load.

Trace each insecure request to its owner

Start with the browser developer console and network panel while exercising complete journeys, including actions that load resources later: opening a product variant, submitting a form, viewing an account page, or downloading a receipt. MDN says the console reports mixed resources that were upgraded or blocked. Record the initiating page, the requested URL, the resource type, the user action that triggered it, and the observed browser outcome. Then search templates, style sheets, application configuration, stored content, emails that link back to the site, and third-party embed settings for the originating HTTP reference. A text search finds many literal URLs, but it misses values assembled at runtime, so browser observation remains necessary.

Rank fixes by customer harm and control. A blocked payment dependency, account script, or essential stylesheet deserves attention before a decorative image. However, an auto-upgraded image is still migration debt: it may fail if the HTTPS host lacks that path, and an IP-address host is a documented exception to ordinary auto-upgrade behavior. Include resources referenced through srcset or picture elements, which MDN lists among blockable cases rather than treating every image alike. Keep the record tied to the actual browser and date of testing, since compatibility details can change. Avoid claiming that an apparent working page is secure merely because no customer complained.

Fix the source URL and its delivery path

Prefer a known HTTPS resource under your control or a verified HTTPS endpoint from the provider. Update the reference where it is authored, then check the final request the browser makes. For your own assets, relative paths can avoid hard-coded HTTP schemes when the same site serves the file over HTTPS; confirm that canonical hosts and redirects resolve as intended. For a third-party service, verify that its HTTPS version serves the same content and permits the intended embedding or cross-origin request. A global search-and-replace can turn an insecure URL into a broken URL, so review each resource class and each business-critical page. Retire a dependency if its provider cannot serve it securely and the journey requires a secure page.

Do not confuse resource repair with an HSTS rollout. HSTS concerns how browsers revisit a host over HTTPS; it does not create a missing secure asset or fix a third-party endpoint. A Content Security Policy upgrade-insecure-requests directive can help with legacy references by asking browsers to try HTTPS, as MDN documents, but it does not make an absent HTTPS service work. It is a migration aid that needs testing, not a substitute for updating source URLs. Mixed downloads deserve their own check: a secure page that offers a file over HTTP can expose or alter the file even if the surrounding page loaded successfully. Confirm the file response over HTTPS and the customer’s complete download path.

Rehearse a shop migration

Consider a fictional shop whose product page loads three old resources: a banner image on its own domain, a stylesheet from an old theme host, and a stock-status request from a supplier endpoint. After the page moves to HTTPS, the banner may appear because the browser upgrades it, the stylesheet may be blocked, and the stock request may fail. The right response is not to infer that the banner is solved and the other two are simply cosmetic. The team should check whether the secure banner path exists, replace or securely host the stylesheet, and test whether the supplier offers an HTTPS API with the same authorization and response contract. This is an illustrative scenario, not measured performance.

Run the scenario from a fresh browser profile and from the normal returning-customer state. Open the product page, select a variant, add to basket, proceed through a test checkout path that does not charge a real customer, and fetch a sample receipt. Compare network requests and visible behavior at each point. If a request redirects from HTTP to HTTPS, record the final path and still update the original reference so it starts securely. If a resource only works after a browser exception or manual override, the journey has not passed. Repeat on representative mobile and desktop browsers because the page layout and delayed resources may differ.

Set a release check that tests the whole journey

An acceptance check should identify the pages and actions tested, the browsers used, the absence of unexpected mixed-content warnings, and the result of each critical request. Distinguish fixed references from browser auto-upgrades; both may look green on the screen, but only the former removes the old dependency from your content. Keep a short list of residual items with owners and dates if some noncritical reference cannot be repaired immediately. Recheck after content edits, theme updates, or third-party widget changes, because any of them can reintroduce an HTTP URL. A crawler helps find broad coverage, while manual task runs catch resources that appear only after interaction.

Give the business owner a simple decision report rather than a dump of console messages. State which customer journeys passed, what was repaired, what remains, and whether a remaining issue changes a customer decision or exposes an insecure download. If checkout or account access still depends on a blocked resource, hold that journey until the dependency is repaired and retested. If an optional image is awaiting a provider fix, make the exception explicit and avoid presenting a silent browser upgrade as completed work. The next action is to schedule the owner of each unresolved URL to update its source and rerun the same task-based checks.

The team should also define what evidence closes an issue. A source-code change alone is insufficient if a deployed template, cached content item, or third-party widget still emits the old URL. For each repaired item, capture the new authored reference and repeat the browser action that produced the insecure request. Confirm the resource arrives over HTTPS, is the intended version, and does not introduce a new functional error. If the item is removed instead, verify the page still communicates the information it previously carried; deleting a stock indicator may hide a purchasing constraint. Keep these checks close to the business task they support, because a green security scan cannot by itself show that a customer can finish checkout or read a receipt. The result is a specific acceptance decision for the journey, with remaining dependencies named rather than disguised by a clean-looking screen.

When planning the fix, separate references you own from services you merely embed. For an owned asset, the team can usually change the page reference and confirm that the secure file is deployed. For a provider resource, ask the provider for its supported secure endpoint and any required configuration change; copying the HTTP path onto a new scheme may not preserve authorization or cross-origin behavior. If no secure route exists, decide whether the service is essential, whether a supported replacement exists, and how the page will communicate any lost function while it is removed. Record that decision with the page owner. This prevents a technical patch from hiding a commercial change, such as a missing delivery estimate that customers used when choosing a product. Revisit provider-dependent items when contracts or widgets change.

Include preview and staging pages in the investigation if they use the same content templates. A newly added HTTP reference can pass unnoticed until that content becomes public. Make the secure-resource check part of the content release routine, and give editors a way to report a provider link they cannot repair themselves.