
How to Fix Mixed Content CSS and JavaScript in WordPress
Browsers block HTTP scripts and styles on HTTPS pages. Trace the first insecure URL to its enqueue, setting, bundle, stylesheet, or provider and fix that source.
A certificate is easy to install and surprisingly easy to install in a way that leaves the padlock broken. The certificate itself is rarely the problem — what usually goes wrong is everything around it: assets still requested over http, redirects that loop, a proxy that does not tell WordPress the connection was secure.
These guides start with the certificate — installing one, reading what it actually says, checking expiry before a browser does it for you, and understanding the errors that appear when the name on it does not match the address people typed.
The largest group covers mixed content, which is the reason most sites show “Not secure” after a migration to https. A single stylesheet, script or image loaded over http is enough to break the padlock on an otherwise correct page, and the browser console will name it precisely if you know where to look. Forms and AJAX requests fail the same way, more visibly.
Then redirects, because forcing https is where sites most often break themselves: one rule too many and every request bounces until the browser gives up. Getting from http to https should take exactly one hop, and the same is true of choosing between www and non-www.
Finally the headers that make https stick — HSTS and its preload list, which is genuinely difficult to undo. Read the risks before you submit.

Browsers block HTTP scripts and styles on HTTPS pages. Trace the first insecure URL to its enqueue, setting, bundle, stylesheet, or provider and fix that source.

A WordPress migration can leave stale certificates, HTTP media, old hostnames, and broken callbacks. Align DNS, TLS, WordPress URLs, content, caches, and integrations in order.

Choose one canonical WordPress hostname, make both variants valid over TLS, and redirect the alternate directly while preserving paths and query strings.

When TLS ends at a proxy, WordPress must receive a trustworthy record of the original scheme. Fix proxy headers, URL generation, cookies, and redirects without accepting spoofed input.

Secure WordPress login and administration with valid HTTPS, correct proxy detection, and FORCE_SSL_ADMIN. Avoid redirect loops and preserve a recovery route.

HSTS preload removes the first insecure visit but commits an entire domain namespace to HTTPS. Review every subdomain, owner, and recovery path before submitting.

HSTS makes browsers use HTTPS for a cached period and can lock out unprepared subdomains. Roll it out gradually only after HTTPS and certificate renewal are reliable.

Flexible SSL can make Cloudflare request HTTP from an origin that insists on HTTPS, creating an endless loop. Move to authenticated origin HTTPS and choose one redirect owner.

A certificate name mismatch happens before WordPress can redirect the request. Check SAN coverage, DNS, SNI, and certificate bindings for every supported hostname.

A TLS handshake failure occurs before WordPress receives an HTTP request. Use the alert and handshake details to locate the incompatible client, edge, or origin setting.