When WordPress shows a Not secure warning or mixed-content errors after SSL, the cause is not always “HTTPS is broken.” Sometimes the certificate is fine and the page still loads scripts, images, or CSS over http://. Other times the certificate itself is wrong, expired, or not covering the hostname you type. Browser icons vary. Check the connection details and exact warning; a missing padlock alone does not mean HTTPS is broken.
Work this checklist in order. Prefer staging when you can. Take a backup before changing Site Address / WordPress Address, running a database URL replace, or editing .htaccess on production. Once the browser reports a secure connection and the console shows no mixed-content errors on the homepage and a typical post, restore any temporary plugin changes and recheck checkout or forms if you use them. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- Note the exact browser signal: certificate warning, “Not secure” with a loaded page, mixed-content console errors, or a redirect loop when forcing HTTPS. Browser icons vary—read the connection details, not the icon alone.
- Open the site on the hostname visitors use (
www or apex) over https:// in a private window.
- If the browser reports ERR_TOO_MANY_REDIRECTS after an SSL change, fix the loop first with the too many redirects checklist.
- If the whole site is offline or returns 403/500/502, use the site down or 403/500/502 checklist before chasing HTTPS warning details.
Mixed content versus certificate problems
- Certificate / connection problem — the browser blocks or warns before the page is trustworthy: name mismatch, expired or not-yet-valid cert, untrusted chain, or HTTPS not offered on that hostname. Fix this with the host or CDN certificate settings first. Content search-replace will not repair a bad cert.
- Mixed content — Mixed content means an HTTPS page requests assets over HTTP. Browsers may automatically upgrade some images, audio, and video to HTTPS and block other insecure requests, including scripts and stylesheets. Update the source URLs to HTTPS where supported, or replace or remove the affected assets.
- Both can appear together after a migration: wrong cert on one hostname plus hardcoded HTTP media on another. Clear the certificate path, then clean content URLs.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Browser certificate warning / privacy error | TLS on host or CDN | Host-led cert coverage for the exact hostname; expiry; full chain |
| Page loads on HTTPS; console shows mixed content | Content / theme / plugin URLs | Browser Network/console for http:// assets; theme options; widget HTML |
“Not secure” or HTTPS warning; Site Address still http:// | WordPress URLs | Site Address (home) and WordPress Address (siteurl) on the intended HTTPS host |
| HTTPS works at CDN; origin or Admin still HTTP-confused | Proxy headers | Host-documented HTTPS detection behind the load balancer/CDN |
| Started right after “force SSL” or a security plugin | Plugin redirects | One HTTPS strategy only; disable stacked force-SSL plugins on staging |
Safe triage order
- Host-led certificate check first. Ask the host or CDN whether a valid certificate covers the exact hostname visitors use, whether HTTPS is enabled on that hostname, and whether the chain is complete. Do not bulk-edit the database while the browser still shows a certificate error.
- Confirm WordPress knows the public HTTPS URL. Check that Site Address (home) points to your public site and WordPress Address (siteurl) points to the WordPress installation. Use the intended HTTPS hostname and preserve each correct path; a subdirectory installation may need different paths. Prefer a host-approved update method (Admin when reachable, or host tools). Take a backup before changing these values.
- Find leftover HTTP assets. With the homepage open over HTTPS, use the browser console/Network panel for requests that still start with
http://. Common sources: theme/customizer URLs, Elementor or page-builder image URLs, widgets, old hardcoded links in post content, and plugin settings that store absolute HTTP URLs.
- Update URLs with a backup—not a blind replace. On staging first, use a WordPress-aware search-replace (or your host’s approved tool) from the old
http:// site URL to the correct https:// URL. Avoid hand-editing serialized data in a raw SQL dump. After replace, purge page cache and CDN cache, then recheck the console.
- Align CDN / proxy HTTPS handling. If the edge terminates SSL, keep one clear HTTPS policy: WordPress and the CDN should not fight over scheme. Ask the host which proxy headers WordPress should trust. Stacking several “force HTTPS” plugins often creates mixed content fixes that trade for redirect loops.
- Retest the surfaces that matter. Recheck homepage, a post with images, Admin, and checkout or forms if used. Restore temporary plugin changes and confirm the browser reports a secure connection and the console shows no mixed-content errors.
Common causes
- Certificate missing, expired, or issued for the wrong hostname (
www vs apex).
- Site Address / WordPress Address still on
http:// after SSL was enabled at the host.
- Hardcoded
http:// image, script, or font URLs in content, theme options, or builders.
- CDN or reverse proxy not forwarding HTTPS detection the way WordPress expects.
- Multiple SSL/redirect plugins each rewriting URLs differently.
- Cached HTTP HTML at the CDN after the origin was already fixed—purge and retest in a private window.
- Active mixed content from a third-party script that only offers HTTP—replace or remove that tag.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help with one clearly defined SSL or mixed-content issue on one WordPress site. Name the exact browser warning, the hostname that fails, whether the console shows mixed content, when it started, and the last change you made (SSL install, migration, CDN, plugin). We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, new custom features, full migrations, account-wide host outages, and multiple unrelated issues are outside this offer. If forcing HTTPS created a redirect loop, see WordPress too many redirects. If a plugin update broke HTTPS along with other features, see also plugin update broke WordPress site.
Related checks
If the checks do not identify the cause, send your host the failing hostname, browser warning text, whether mixed-content URLs appear in the console, and the start time. Suspected compromise needs a security investigation as well as restoring clean HTTPS.