After SSL is enabled, a page can still appear insecure or look broken if images, CSS, JavaScript or embedded resources are requested with http://.
Confirm it is mixed content
Open the browser developer console and look for mixed-content warnings. Note the exact insecure resource URLs before making replacements.
Check WordPress URLs
In Settings → General, WordPress Address and Site Address should use HTTPS. Hostinger also recommends checking this when forcing HTTPS on WordPress.
Replace old HTTP references carefully
After a migration or SSL change, database content may still contain the old HTTP domain. Back up the database before bulk search-and-replace operations and use a tool that handles WordPress data safely.
Do not assume every HTTP URL supports HTTPS
For third-party resources, verify the secure version actually works. Hostinger describes several WordPress-specific approaches in its current mixed content guide.
Test more than the homepage
Check representative articles, images, forms and scripts in a private window. A homepage padlock does not prove that every page is free of mixed content.
Related TechGuru guide
If images broke after moving the site rather than after enabling SSL, see WordPress images not showing after migration.
Mixed-content diagnosis matrix
Use the symptom as evidence. Change one variable at a time so you can tell which action actually fixes the problem.
| What you see | What it suggests | Best next check |
|---|---|---|
| Images alone use HTTP | Old media/content URLs | Update the affected stored URLs safely |
| CSS/JS uses HTTP | Theme/plugin or hard-coded asset URL | Locate the source before replacing database values |
| Only one page warns | Page-specific embed or content | Inspect that page in the browser console |
| Warnings after migration | Old-domain HTTP references remain | Back up, then use a WordPress-safe search/replace method |
What not to do
Do not run an unrestricted database replacement without a current backup. WordPress stores some structured/serialized values that can be damaged by unsafe replacement methods.
How to verify the fix
Open representative pages in a private window and inspect the browser console. The fix is complete when no active resource is requested over HTTP and page functionality remains intact.
When to escalate
If the problem persists after the evidence-based checks, preserve screenshots, timestamps, the exact affected URL and any relevant error/log entry before contacting hosting or plugin support. That gives support a reproducible case instead of a generic “site not working” report.
