You set up an SSL certificate in Hostinger, flipped your WordPress Site Address to HTTPS, and the padlock icon is still broken. Or worse: your browser console is loaded with warnings, layouts look broken, and scripts are blocked outright because the page loaded over HTTPS while static assets are still sneaking in over plain HTTP.
I’ve run into this exact issue across dozens of Hostinger sites. Here is how to track down the offending URLs, scrub them from your database without breaking serialized data, configure LiteSpeed’s reverse proxy headers, and drop clean .htaccess rewrite rules in place without causing an infinite redirect loop.
Diagnose the Mixed Content Source in Chrome DevTools
Mixed content hits whenever your base HTML document loads securely over HTTPS, but subresources—images, scripts, stylesheets, fonts, or iframes—still pull from unencrypted http:// endpoints. As detailed in the MDN Web Docs on Mixed Content, modern browsers distinguish between passive mixed content (like images, which degrade the padlock) and active mixed content (like scripts and stylesheets, which get blocked outright).
Before touching any config files, open Chrome DevTools with Ctrl + Shift + I (or Cmd + Option + I on a Mac) and hop over to the Console tab. Look for lines that look like this:
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure stylesheet 'http://example.com/wp-content/themes/custom/style.css'. This request has been blocked;
the content must be served over HTTPS.Check whether the flagged URLs are internal (under your own domain in /wp-content/) or external (third-party CDNs, Google Fonts, or embedded trackers). If your SSL certificate itself failed to generate or bind properly on the server, tackle our guide to fix SSL installation failures on Hostinger before trying to debug assets.
Clean the Database: Why Simple Redirects Fail
A rewrite rule in .htaccess will redirect an HTTP request to HTTPS, but that does not prevent browsers from throwing mixed content warnings. Browsers parse the raw HTML document and evaluate resource protocols before any redirects fire. If your markup explicitly says http://, the browser flags it immediately.
Almost every mixed content issue traces back to hardcoded database records created before you switched on SSL. You have to swap every plain HTTP URL in the database to HTTPS.
Grab SSH access from Hostinger’s hPanel under Advanced > SSH Access, connect to your server, and run WP-CLI straight from your WordPress root:
cd public_html
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-runThe --dry-run flag shows you exactly how many rows will change in tables like wp_posts, wp_postmeta, and wp_options without modifying anything yet. Once you confirm it matches your target URLs, run the actual update:
wp search-replace 'http://example.com' 'https://example.com' --all-tablesWP-CLI handles PHP serialized strings properly so you won’t corrupt theme mods, widgets, or site builder data. For a deeper breakdown of flags and table filters, check out our guide on how to safely update WordPress URLs with WP-CLI search-replace.
Configure LiteSpeed Web Server and .htaccess Rules
Hostinger runs LiteSpeed Web Server (LSWS) behind an edge proxy. LiteSpeed interprets Apache .htaccess directives, but it evaluates them through its own rewrite engine. If you force HTTPS using generic rewrite rules without accounting for the proxy headers, you’ll immediately trigger an ERR_TOO_MANY_REDIRECTS loop.
Open your public_html/.htaccess file using hPanel’s File Manager or nano via SSH. Paste these rules right at the top of the file, before the # BEGIN WordPress block:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Pay close attention to that second condition: RewriteCond %{HTTP:X-Forwarded-Proto} !https. Hostinger terminates SSL at their reverse proxy before passing the traffic down to the LiteSpeed backend worker. If you don’t check X-Forwarded-Proto, the backend thinks every incoming connection is plain HTTP on port 80 and redirects indefinitely.
Fix Hostinger Reverse Proxy and SSL Headers in wp-config.php
Sometimes LiteSpeed hands requests over to PHP without WordPress recognizing that HTTPS is live. When that happens, core functions like wp_enqueue_script(), plugins_url(), and wp_upload_dir() keep writing out http:// URLs on uncached page loads.
Open your wp-config.php file. Add this block directly above the line that reads /* That's all, stop editing! Happy publishing. */:
// Handle reverse proxy SSL offloading
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on';
}
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') { $_SERVER['HTTPS'] = 'on';
}
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Hardcoding WP_HOME and WP_SITEURL inside wp-config.php locks your root URLs to HTTPS and prevents database mishaps from drifting back to HTTP. For deeper context on how WordPress detects reverse proxies, check out the official WordPress Administration over SSL guide.
Purge and Reconfigure the LiteSpeed Cache Plugin
A classic gotcha on Hostinger: you run your search-replace, patch wp-config.php, test in your logged-in browser, and it looks fixed. But incognito visitors still hit mixed content warnings. That happens because LiteSpeed Cache saved the old HTML output containing the insecure asset URLs directly on disk.
Log into your WordPress admin panel. In the top admin bar, hover over the LiteSpeed icon and hit Purge All. Then make sure your cache rules aren’t holding onto stale assets:
- Head to LiteSpeed Cache > Cache > [1] Cache.
- Check that Enable Cache is ON.
- Confirm Cache Mobile is set properly for your theme setup.
- Navigate to LiteSpeed Cache > Page Optimization > [2] CSS Settings.
- If you’re using CSS Minify or Combine, run a dedicated Purge All – CSS/JS Cache to wipe the generated static files.
If you’re using object caching, flush that as well so cached transients aren’t storing stale HTTP links. We have a full guide to help you enable Redis object cache on Hostinger if your hosting tier includes it.
Enforce HTTPS via Content-Security-Policy (CSP)
If you have older plugins or legacy page builder templates inserting hardcoded http:// links that aren’t showing up in standard database tables, you can tell the browser to rewrite them on the fly before making the network request.
You can do this by setting a Content-Security-Policy header with the upgrade-insecure-requests directive. For more on how LSWS evaluates headers, check out the official LiteSpeed Cache documentation.
Open your .htaccess file and place this rule right after your HTTPS redirect block:
Header always set Content-Security-Policy "upgrade-insecure-requests;"
Whenever a browser parses this header, it translates any call for http://example.com/asset.png into https://example.com/asset.png in memory before sending the request. No console warning, no blocked scripts.
You can verify that your server is actually sending the header using curl:
curl -I https://example.comYou should see a clean 200 OK response with both your security policy and LiteSpeed cache headers attached:
HTTP/2 200
content-type: text/html; charset=UTF-8
content-security-policy: upgrade-insecure-requests;
x-litespeed-cache: hitFor more edge cases and manual file inspections, check out our general mixed content troubleshooting checklist.
Frequently Asked Questions
Why does mixed content return after editing a page in Elementor or Divi?
Page builders compile their own static CSS files with absolute file URLs and store them in /wp-content/uploads/. Even after running a search-replace, those compiled stylesheets still contain the old HTTP links. In Elementor, go to Elementor > Tools > General and hit Regenerate Files & Data. In Divi, clear the static CSS cache under Divi > Theme Options > Builder > Advanced.
Will Content-Security-Policy fix images hosted on external HTTP domains?
The upgrade-insecure-requests directive forces the browser to request external assets over HTTPS. If the external domain has an active SSL certificate, it loads fine. But if the external host doesn’t support HTTPS at all, the request fails with a connection error instead of falling back to HTTP. In those cases, download the file and host it locally in your own media library.
Why did my .htaccess edits disappear after updating plugins?
WordPress core and security plugins rewrite .htaccess whenever permalinks or cache configs change. They only touch the content between their generated comments, such as # BEGIN WordPress ... # END WordPress. Always place your custom redirect rules and headers at the very top of the file so automated updates don’t wipe them out.
Can I use a mixed content plugin like Really Simple SSL instead?
Plugins like Really Simple SSL work by intercepting output buffers in PHP and rewriting URLs before outputting the page. It works, but it adds unnecessary PHP overhead to every single uncached request. Running a one-time WP-CLI search-replace and setting up LiteSpeed headers via .htaccess fixes the root issue at the server level without bloating your stack.
Next Steps for Hostinger Performance
With clean headers and an active SSL padlock, your site can take full advantage of HTTP/2 and HTTP/3 multiplexing without browsers pausing to block insecure resources. Just remember to purge your LiteSpeed cache whenever you run bulk search-and-replace updates, and verify that any new media uploads are explicitly mapped to HTTPS.
