Mixed content happens when an HTTPS page requests a resource over HTTP. Repair the component that generates the insecure URL, not just the warning shown in one browser. A theme file, page-builder field, stylesheet, plugin setting, or old database value may be responsible.
First distinguish mixed content from a certificate warning on the main page. If visitors cannot establish a trusted HTTPS connection at all, fix the certificate before investigating images and scripts. If HTTP and HTTPS repeatedly redirect to each other, use the redirect diagnosis.
Capture the blocked request and its initiator
Open the affected page in browser developer tools. In Console and Network, locate the precise resource URL, resource type, and initiating document or script. Reload with the tools open so the request is captured. Use a clean logged-out session for a public page.
Browsers treat resource types differently. Some insecure resources may be upgraded automatically while others are blocked. The MDN mixed-content guide describes that distinction. Do not assume that an image appearing means all dependencies are safe or that a script was successfully loaded.
For a form, identify whether the missing dependency affects validation, submission, or only presentation. A page that looks normal can still fail when a visitor presses Submit.
Check that the replacement actually exists
Before rewriting a URL from HTTP to HTTPS, request the proposed destination and confirm its certificate, response status, and content type. A 200 HTML fallback is not a usable JavaScript or image file.
For a harmless public asset, this reads headers without bypassing TLS verification:
curl -sS -I --max-time 15 https://example.com/assets/form.js
If HEAD and the browser disagree, inspect a GET response. Do not use an insecure TLS flag to make a failing check appear successful.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Repair the emitting component
Use the initiator to choose the edit. A CSS background URL belongs in the stylesheet or builder setting that generated it. A hard-coded script belongs in the responsible theme or plugin. A sitewide old-domain value may require a planned database migration.
For database replacements, back up first, scope the tables and exact old value, and use a WordPress-aware tool that preserves serialized values. Review a dry run before applying it. Blind SQL replacements can corrupt serialized settings or alter unrelated external URLs.
After a builder setting changes, regenerate its derived files through the supported controls. Purge the affected application and CDN caches after the source is correct. Cache clearing alone cannot permanently repair an HTTP URL that the source keeps generating.
Verify the user task, not just the console
Repeat the original journey on desktop and mobile. Confirm images, fonts, embedded media, and form or checkout actions work. Check a second template using the same component so the repair is not limited to one page.
Retain the original URL, emitting component, replacement, and test outcome in the change record. If a third-party asset has no working secure endpoint, ask its provider for a supported replacement rather than weakening browser protection.
Get help tracing insecure WordPress dependencies when the URL is generated dynamically or returns after each deployment. Bring a sanitized request and initiator, not cookies or a full unredacted network archive.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.