WordPress Mixed Content Checklist: Find and Fix HTTP Assets

Trace mixed-content warnings to the specific resource being requested over HTTP. The page itself can use HTTPS while an image, script, font or embedded service still references an insecure address. Replacing the certificate alone does not correct that reference.

Capture the warning and resource

Open the affected HTTPS page and inspect the browser’s console and network tools. Record the insecure URL, resource type and page that requested it. Note what visitors actually lose: an image, a style, a script or a functional integration.

Cloudflare’s mixed-content guidance describes HTTP resources referenced from HTTPS pages and browser blocking. Different resource types and browser behavior can produce different symptoms, so use the observed request rather than assuming that every missing image is mixed content.

Find where the address is stored

Identify whether the reference comes from page content, theme code, a plugin setting, generated CSS or an external embed. Check a few representative pages to distinguish a single article image from a sitewide asset.

For WordPress, ask the maintainer to review the current site addresses and the component creating the reference. Do not begin with an unbounded database replacement. The exact source matters, especially when URLs are stored in structured page-builder data or generated files.

Verify HTTPS support before changing the URL

Check that the intended asset is available over HTTPS and works in the expected context. If an external vendor does not provide a suitable secure resource, ask it for a supported replacement or remove the dependency through the approved site workflow.

Do not make a browser ignore warnings or switch the whole website back to HTTP. Those actions do not repair the underlying resource reference. Use certificate verification when the secure asset itself has a certificate problem.

Correct the source and refresh generated copies

Edit through the component that owns the reference. A page-builder setting may need its supported save and regeneration process; a theme reference belongs in a reviewed theme change. Save the prior value and test on staging when the edit affects many pages.

After the source is corrected, refresh relevant generated files and caches using the host or plugin’s supported controls. CDN rewrites can help in some configurations, but they should not replace understanding where the insecure URL originates. HTTPS redirection alone is not a complete mixed-content fix.

Retest the affected workflow

Reload the page with a fresh request and check the console and network result. Test images, styling and any affected form or checkout behavior. Repeat on another page using the same component, then check a logged-out view.

Record the insecure reference, its owner, the supported correction and the successful secure request. Close when the browser evidence and the visitor workflow agree. A clean homepage does not prove that every older article or external embed has been corrected.

Trace the exact insecure asset to its source

A hypothetical HTTPS page has an image URL inside a generated stylesheet that still uses HTTP. Record the asset URL and the stylesheet or element that requested it. Confirm the asset’s HTTPS endpoint works, correct the owning setting or content and rebuild relevant generated files through the supported workflow. Broad search-and-replace is premature until the source and affected scope are known.

Sources and scope

Official documentation checked October 6, 2026: Cloudflare: Mixed content errors; Cloudflare: Always Use HTTPS. This is HRL’s general diagnostic workflow, not a diagnosis of your website. Server and security changes belong with the authorized administrator and the host’s supported procedures.

Related guides

Test broad changes on staging · Understand cached copies · Understand hosting HTTPS features