Fix WordPress Mixed Content Warnings After SSL on Hostinger

You installed a Let’s Encrypt SSL certificate in Hostinger hPanel, visited your WordPress site, and you still get an insecure warning icon instead of a green padlock. Let’s track down every insecure HTTP asset on your site, safely rewrite your serialized database entries without breaking anything, and lock in clean HTTPS redirection at the server level.

Why Mixed Content Happens After Installing SSL

Mixed content happens when your main HTML document loads securely over HTTPS, but subresources like images, scripts, stylesheets, or fonts are still being pulled over plain HTTP. Browsers flag this immediately because insecure subresources expose the session to man-in-the-middle attacks.

Browsers split these into two buckets based on the MDN Mixed Content specification:

• Passive/Display Mixed Content: Insecure images, audio, and video tags. The browser usually renders them anyway, but it strips your secure padlock badge and shows a warning icon.
• Active Mixed Content: Insecure JavaScript, CSS stylesheets, web fonts, iframes, and AJAX calls. Modern browsers block these outright, which instantly breaks layouts, sliders, or checkout flows.

On Hostinger’s LiteSpeed infrastructure, enabling SSL in hPanel only tells the web server to handle TLS handshakes on port 443. It doesn’t touch hardcoded HTTP URLs sitting in your WordPress database or generated by older plugins.

Step 1: Diagnose Insecure Assets in Chrome DevTools

Before touching the database, let’s pinpoint the exact URLs triggering the warning. Open your site in Chrome, right-click anywhere on the page, and select Inspect (or hit Ctrl+Shift+I / Cmd+Option+I).

Jump to the Console tab. Chrome flags mixed content with yellow and red security warnings, showing you the exact offending asset and the script or line that called it.

You can also use the Security tab for a clean breakdown:

1. Open DevTools and switch to the Security tab.
2. Hard reload the page (Ctrl+F5 or Cmd+Shift+R).
3. Look at the left sidebar under Resources for anything marked “Non-secure origin”.
4. Click View requests in Network panel to filter down to the exact CSS files, SVGs, or images still requesting http://.

Step 2: Update Site Address in Hostinger hPanel and WordPress

Your WordPress site settings must use HTTPS before we update database records. If your site URL is still set to HTTP, WordPress will keep generating insecure canonical links across your templates.

Log in to your WordPress admin dashboard and head to Settings > General. Make sure both fields use HTTPS:

• WordPress Address (URL): https://yourdomain.com
• Site Address (URL): https://yourdomain.com

If these fields are grayed out, they’re hardcoded in your config file. Open wp-config.php in your root directory via SSH or Hostinger File Manager and check these lines:

define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');

Next, jump into Hostinger hPanel, go to Websites > Dashboard, scroll down to the WordPress section, and ensure Force HTTPS is toggled on. If you recently moved your site or tested changes, make sure you did not leave broken paths when you push WordPress staging to production.

Step 3: Run WP-CLI Search-Replace via SSH

Never run a raw SQL query like UPDATE wp_posts SET post_content = REPLACE(...) to fix HTTPS URLs. WordPress and most plugins store settings, widget configs, and page builder data as serialized PHP strings. A raw SQL replace changes string lengths without updating serialization metadata, which will corrupt widgets and blow up page layouts.

Hostinger includes SSH access across their plans. The cleanest, fastest way to update your database is WP-CLI’s built-in search-replace tool.

SSH into your Hostinger server:

ssh -p 65002 u123456789@your-server-ip

Move to your document root:

cd ~/domains/yourdomain.com/public_html

Always run a dry run first. This scans your tables, calculates changes, and shows you what would change without modifying data:

wp search-replace "http://yourdomain.com" "https://yourdomain.com" --dry-run

Check the summary table. If the replacement counts across wp_posts, wp_postmeta, and wp_options look right, run the real replacement:

wp search-replace "http://yourdomain.com" "https://yourdomain.com" --all-tables --precise

The --all-tables flag catches custom plugin tables (like WooCommerce logs or form submissions), while --precise ensures PHP handles serialized strings safely.

Step 4: Alternative Method Using Better Search Replace

If you don’t want to use SSH, you can handle the serialized replacement from the WordPress admin with the Better Search Replace plugin.

1. Install and activate Better Search Replace from Plugins > Add New.
2. Go to Tools > Better Search Replace.
3. Set Search for to: http://yourdomain.com
4. Set Replace with to: https://yourdomain.com
5. Select all tables in the list (hold Shift or Ctrl to highlight everything).
6. Leave Run as dry run? checked and click Run Search/Replace.
7. Review the dry run summary at the top of the page.
8. Uncheck Run as dry run? and click Run Search/Replace again to apply the database changes.
9. Deactivate and delete the plugin when you’re done.

Step 5: Regenerate Page Builder CSS and Elementor Files

Even after updating the database, page builders like Elementor keep compiled CSS files in wp-content/uploads/elementor/css/. Those static files often cache hardcoded background image URLs pointing to HTTP.

If you run into layout issues or builder load errors, see our guide on how to fix Elementor stuck on loading screen. To force Elementor to rebuild all style files with HTTPS URLs:

1. Go to Elementor > Tools in your WordPress dashboard.
2. Under the General tab, find Regenerate CSS & Data.
3. Click Regenerate Files.
4. Switch to the Replace URL tab.
5. Enter http://yourdomain.com in the old URL field and https://yourdomain.com in the new URL field.
6. Click Replace URL.

If you get file permission errors during regeneration, check your folder permissions using our tutorial on how to fix upload failed to write file to disk on Hostinger.

Step 6: Enforce HTTPS Redirects in .htaccess on LiteSpeed

Hostinger runs on LiteSpeed Web Server, which reads standard Apache .htaccess directives. To redirect raw HTTP requests before they even hit WordPress PHP workers, add a 301 rewrite rule at the very top of your .htaccess file.

Open /public_html/.htaccess via SSH or the File Manager and place this rule right above the # BEGIN WordPress block:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This checks the %{HTTPS} variable. If a request hits port 80 without SSL, LiteSpeed returns a 301 Moved Permanently straight to the HTTPS version before running any WordPress code.

Step 7: Add Content Security Policy upgrade-insecure-requests Header

If your site loads third-party fonts, tracking scripts, or CDN images that use legacy HTTP links, browsers will block them. You can tell modern browsers to auto-upgrade every insecure subresource request to HTTPS using the CSP upgrade-insecure-requests directive.

Add this header directly inside your .htaccess file within a mod_headers block:

Header always set Content-Security-Policy "upgrade-insecure-requests;"

Alternatively, you can hook it into your child theme’s functions.php:

function isitdev_force_ssl_header() { header("Content-Security-Policy: upgrade-insecure-requests;");
}
add_action('send_headers', 'isitdev_force_ssl_header');

When the browser parses an HTML tag like , this header forces the browser to fetch https://cdn.example.com/logo.png before sending the request across the wire.

Step 8: Hardcoded HTTP Assets in Theme Template Files

If DevTools still flags insecure URLs after a full database update and Elementor flush, you likely have hardcoded HTTP strings inside your active theme’s header.php, footer.php, or enqueue functions.

Search your theme files for hardcoded protocols using grep from your theme directory:

grep -rn "http://" ~/domains/yourdomain.com/public_html/wp-content/themes/your-theme-name/

Common culprits include manually pasted external fonts or old tracking pixels:

When enqueueing scripts or styles in WordPress, always rely on dynamic helpers like get_template_directory_uri() or explicit HTTPS URLs:

function isitdev_enqueue_custom_scripts() { wp_enqueue_script( 'custom-slider', get_stylesheet_directory_uri() . '/js/slider.js', array('jquery'), '1.0.0', true );
}
add_action('wp_enqueue_scripts', 'isitdev_enqueue_custom_scripts');

For more best practices on WordPress SSL configs, refer to the official WordPress HTTPS documentation.

Step 9: Purge LiteSpeed Cache and Redis Object Cache

Hostinger caches full HTML pages aggressively through LiteSpeed. If a page was cached while your site still had HTTP assets, LiteSpeed will keep serving that outdated HTML to visitors even after your database is clean.

Flush your caching layers in this order:

1. LiteSpeed Cache: In the WordPress admin bar, hover over the LiteSpeed diamond icon and click Purge All.
2. Object Cache: If you use object caching, flush it via WP-CLI or check our guide on how to configure Redis object cache on Hostinger.
3. Browser Cache: Open an Incognito window or do a hard refresh (Ctrl+F5) to verify the padlock appears properly.

Frequently Asked Questions

Can I just install the Really Simple SSL plugin instead?

Plugins like Really Simple SSL fix mixed content dynamically by buffering output HTML and rewriting http:// to https:// on every single request. It works, but it adds unnecessary PHP overhead on every page load. Running a one-time WP-CLI search-replace fixes the root issue in your database for good without adding plugin bloat.

Why is my CSS broken after forcing HTTPS on Hostinger?

When stylesheets load over plain HTTP on an HTTPS page, modern browsers block them under Active Mixed Content rules. Without CSS, your site displays unstyled HTML. Fixing your site URLs in wp-config.php and regenerating page builder files will resolve this immediately.

Why does the lock icon appear on my homepage but not on blog posts?

Your homepage probably only pulls dynamic, current assets, whereas older blog posts might contain inline images with hardcoded http:// source URLs in the post_content column. Running a search-replace across wp_posts cleans up those older articles.

Does Hostinger’s free SSL auto-renew after fixing mixed content?

Yes. Hostinger handles Let’s Encrypt renewals automatically every 90 days. Mixed content warnings don’t block certificate renewals; they only affect how browsers handle asset requests inside your site’s HTML.

Next Steps

With your site serving clean HTTPS without warnings, make sure your server memory and file upload limits are dialed in so media uploads don’t time out. Check out our guide on how to increase WordPress PHP memory limit and max upload size in Hostinger.