Originally published on CodingCush.
If your WordPress site shows a mixed content error after installing an SSL certificate — a “not fully secure” warning, a broken padlock, or images that suddenly vanish — it means the page itself loads over secure HTTPS, but some files inside it, like images, scripts or stylesheets, are still loading over old, insecure HTTP. Browsers block or warn about that insecure content because it weakens the protection HTTPS is supposed to give. The fix is to find every http:// address on your site and update it to https://: change the WordPress and Site Address in settings, update old links in the database, force HTTPS with a redirect, and clear your caches. Once no HTTP requests remain, the padlock returns and the warning disappears.
This error has cruel timing. You do the responsible thing, install SSL, feel proud for a full minute — and your site rewards you with a warning triangle and missing images. Do not panic, and definitely do not uninstall the certificate. Your SSL is working; your content just has some old addresses to tidy up.
What Mixed Content Actually Means
Think of HTTPS as a locked, armoured van delivering your web page. Mixed content is when that van carries a few boxes that arrived on an open bicycle. The page is secure, but some of its parts travelled insecurely, so a snooper on the network could tamper with those parts. The MDN guide to mixed content explains the two kinds browsers deal with: passive content like images, which browsers may load with a warning, and active content like scripts and stylesheets, which browsers block outright because they can change how the page behaves.
That is why symptoms vary. Sometimes you only lose the padlock and see “Your connection is not fully secure”. Sometimes a slider, font or menu breaks completely, because its JavaScript or CSS was blocked. If the whole HTTP versus HTTPS topic is still fuzzy, our plain-English explainer on the difference between HTTP and HTTPS fills in the background before you start fixing.
Step 1: Confirm Your Site Address Uses HTTPS
Start with the setting everything else follows. In your dashboard, go to Settings > General and check the two address fields: WordPress Address (URL) and Site Address (URL). Both should begin with https://, not http://. If they still say http, update them carefully — type slowly, because a typo here can lock you out of the dashboard — and save.
If the dashboard is not available, the same values live in the database, in the wp_options table as siteurl and home. WordPress's official guidance on administration over SSL also covers forcing the login and admin area to use HTTPS, which is a sensible extra once your public pages are fixed. One caution: only force HTTPS after confirming your certificate really works — visit the https version of your homepage and check it loads without a certificate error first.
Step 2: Find Exactly Which Files Are Still HTTP
Do not guess which images or scripts are guilty; browsers will tell you precisely. Open your homepage in Chrome or Firefox, press F12 to open Developer Tools, and click the Console tab. Mixed content warnings are listed there in friendly yellow or red, each naming the exact insecure URL, something like:
Mixed Content: The page at 'https://example.com/' was loaded
over HTTPS, but requested an insecure image
'http://example.com/wp-content/uploads/logo.png'.
Check more than the homepage: open a blog post, your contact page and a shop page if you have one, because different templates load different files. You can also run a free online mixed-content scanner for a full-site list. Write the guilty URLs down — the pattern matters. If they are all images in old posts, it is a database job. If one plugin's script appears everywhere, it is a plugin job.
MDN's mixed content documentation — the reference browsers themselves follow when they block insecure files.
Step 3: Update Old URLs in the Database
The most common cause is history: images you uploaded and links you pasted before SSL arrived still contain http:// in your post content, widgets and settings. Changing the site address does not rewrite the past. The safe way to update everything is a search-and-replace plugin such as Better Search Replace, which handles WordPress's serialised data correctly — something a raw database find-and-replace can break.
Run it like this: search for http://yourdomain.com and replace with https://yourdomain.com, selecting all tables, and always run the plugin's dry run first to preview how many changes it will make. Take a backup before the real run. Yes, backups are boring. So is every safety step, right up until the day it saves you. After the replacement, reload the pages you tested in Step 2 and watch the console again — most sites go fully green at this point.
Step 4: Use a Plugin for the Leftovers — Carefully
A popular plugin called Really Simple SSL detects mixed content and fixes much of it automatically, including setting redirects. It is a reasonable helper, especially for beginners, but understand what it does: part of its fix works at runtime, adjusting output as pages load, rather than correcting the underlying database. That is fine as a seatbelt, but the database update in Step 3 is the real repair. Use the plugin if you like — just do not let it be the only thing standing between your site and the warning, because deactivating it one day would bring every warning back at once.
Step 5: Force HTTPS and Fix Hardcoded Links
Visitors and search engines should only ever reach the HTTPS version, so add a redirect from HTTP to HTTPS. Many hosts offer a “Force HTTPS” switch in the control panel; otherwise, on Apache hosting, this block near the top of your .htaccess file does the job:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Then hunt the stubborn leftovers: links typed by hand inside theme files, Customizer settings, menus, widgets and page-builder content sometimes keep the old http:// address. Update those spots to https:// — or better, use relative or full HTTPS URLs the builder offers. If a page suddenly breaks badly while you edit server files, take a breath and follow our guide to fixing the critical error in WordPress, which shows how to undo changes calmly.
Step 6: Clear Every Cache and Check Again
Caches love serving yesterday's version of your site. After your fixes, clear your caching plugin, your hosting cache if there is one, and your CDN cache (for example Cloudflare) if you use it. Then test in an incognito window so your own browser cache cannot fool you. Use this final checklist:
| Check | Pass looks like |
|---|---|
| Homepage padlock | Padlock shown, “Connection is secure” |
| Console on key pages | No mixed content warnings |
| http:// version of your URL | Redirects to https:// automatically |
| Images, sliders, fonts, menus | All load and display normally |
| Login page | Loads over HTTPS |
Frequently Asked Questions
Will mixed content hurt my SEO?
Indirectly, yes. Browsers warning visitors makes people leave quickly, and blocked content makes pages look broken. Fixing it protects both trust and rankings, and lets you get the full benefit of moving to HTTPS.
Why did the error appear only after installing SSL?
Because before SSL, everything was HTTP and nothing was “mixed”. The moment pages started loading over HTTPS, the old HTTP files inside them became a problem browsers could see.
Can I just install Really Simple SSL and skip the rest?
You can start there, but do the database search-and-replace as well. Fixing the actual URLs means your site stays fixed even if you remove the plugin later.
Why do only some pages show the warning?
Because only those pages load an insecure file — often one old image in one old post. The browser console on that exact page will name the file responsible.
My padlock is there but grey. Is that fixed?
A grey or “not secure” padlock area usually means some passive content, like an image, is still loading over HTTP. Check the console; one leftover image is the usual story.
Conclusion
Mixed content is not an SSL failure — it is your site's old HTTP past showing up inside its new HTTPS present. Update the site address, find the guilty files in the console, replace old URLs in the database, force the redirect, and clear your caches. The padlock will return, your images will come home, and your responsible security upgrade will finally look as good as it actually is.
Top comments (0)