Short answer: your page is served over HTTPS but some images, scripts or stylesheets are still requested over HTTP. Browsers flag or block those, so the padlock disappears and some functionality may silently stop working.
Why it matters beyond the padlock
A missing padlock damages trust at the worst moment — on checkout and contact pages. Worse, browsers block mixed active content such as scripts outright, which can break sliders, forms, analytics and payment widgets with no visible error.
Find exactly which resources are insecure
Open the browser console on the affected page; it lists every “Mixed Content” resource and its URL. That tells you whether the culprit is post content, a theme setting, a plugin, or an external host that has no HTTPS.
Fix the source, not the symptom
- Set Site and WordPress addresses to
https://in Settings › General. - Update stored URLs with WP-CLI:
wp search-replace 'http://yourdomain' 'https://yourdomain' --skip-columns=guid— this handles serialised data safely. - Correct any plugin or theme setting holding absolute HTTP asset paths.
- Replace or remove external resources that genuinely cannot be served over HTTPS.
Why a rewriting plugin is a weak answer
Plugins that rewrite output on the fly hide the warning without fixing the stored data — they add work to every page load, and the moment the plugin is disabled the problem returns. Reasonable as a temporary measure, not as a repair. After fixing, check the home page, a post with images, the contact page and checkout with the console open, and confirm no insecure requests remain.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
Mixed content is stored or generated HTTP references inside an HTTPS page. The console names each source, which is more useful than installing an output-rewrite plugin blindly.
List every blocked or warned resource from the browser console.
Classify each URL as content, theme option, plugin output or external host.
Use a serialized-data-aware search-replace for your own domain.
Correct proxy/HTTPS detection and replace external resources that lack HTTPS.
What must be verified
- Console and network show no insecure requests on representative pages.
- Forms, checkout and embedded widgets still function.
- Stored content no longer contains your old HTTP domain references.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →