Fix WordPress Mixed Content Errors on Hostinger After SSL Activation

You flip the SSL toggle in Hostinger hPanel, load your WordPress site over HTTPS, and get slapped with a broken padlock or an insecure connection warning. It’s frustrating, but completely predictable. Here is how to track down the insecure assets, patch your database URLs cleanly without corrupting serialized data, force HTTPS at the server level, and purge Hostinger’s aggressive caches.

Why Mixed Content Happens After Installing SSL

Toggling SSL on in hPanel only fixes the transport layer—Hostinger provisions the Let’s Encrypt certificate at the web server layer. But WordPress loves storing hardcoded absolute URLs in the database. If you wrote posts, uploaded media, or built templates before activating SSL, your database is still loaded with http:// links.

Browsers divide mixed content into two buckets:

• Passive mixed content: Images, audio, and video files requested over HTTP. Browsers usually load these anyway, but they strip your clean green padlock and display a warning icon instead.
• Active mixed content: Scripts, stylesheets, iframes, and web fonts. Browsers block these outright to prevent man-in-the-middle attacks. When this happens, your site breaks—nav menus freeze, custom fonts revert to system defaults, and layouts collapse.

Inspect the Insecure Requests in Chrome DevTools

Do not guess which assets are failing. Finding the exact offenders takes about ten seconds in DevTools.

Open Google Chrome, navigate to your site on https://, and press Ctrl + Shift + I (or Cmd + Option + I on macOS). Open the Console tab. You will see yellow warning flags or red errors naming the exact file and the insecure URL it tried to pull.

Next, click the Security tab and hit View requests in Network panel. Chrome will filter the list down to non-secure assets. Usually, you will spot an old theme logo, a hardcoded font from an unmaintained plugin, or background images hosted under plain HTTP.

As outlined in the MDN Web Docs on Mixed Content, modern browsers will actively block non-secure scripts and stylesheets, which explains why elements on the page might have stopped working entirely.

Update the WordPress Site Address and Home URL

Start with the baseline URLs. If your WordPress core settings still point to HTTP, the engine will keep building internal links and enqueueing scripts insecurely.

Head to your WordPress dashboard, go to Settings > General, and check these fields:

• WordPress Address (URL)
• Site Address (URL)

Change both from http://yourdomain.com to https://yourdomain.com, scroll down, and hit Save Changes. WordPress will log you out and require you to sign back in over HTTPS.

If you are stuck in an infinite redirect loop or locked out of wp-admin, you can bypass the database and define these directly inside wp-config.php. Open Hostinger File Manager in hPanel, or jump in via SSH to your site’s public_html directory. Paste this right before the /* That's all, stop editing! Happy publishing. */ line:

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

These constants force the base URL at runtime and override whatever stale values are saved in your wp_options table.

Run a Safe Database Search-and-Replace with WP-CLI

Updating your site URLs fixes core links, but it does not touch URLs embedded in post content, custom fields, or widget settings. Whatever you do, do not run a raw SQL UPDATE query in phpMyAdmin. WordPress serializes arrays and objects in the database; editing string lengths manually will corrupt your theme options and widgets.

WP-CLI handles serialized data safely. If you don’t have an up-to-date snapshot yet, check our guide on how to restore a WordPress backup via SSH on Hostinger so you have an easy fallback if anything goes wrong.

Connect to your Hostinger server over SSH and navigate to your site’s document root:

cd ~/domains/yourdomain.com/public_html

Run a dry run first to see how many stale HTTP references are hiding in your tables:

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

WP-CLI will spit out a breakdown of affected tables. When I ran this on a migrated client site recently, we found 342 hardcoded HTTP references spread across wp_posts and wp_postmeta. Once you verify the count, run the actual replacement:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --precise --recurse-objects --skip-columns=guid

We explicitly pass --skip-columns=guid here. Following standard WordPress.org migration standards, modifying GUIDs makes RSS readers treat your entire back-catalog as brand-new articles and blast subscribers.

Force HTTPS via Nginx and .htaccess on Hostinger

With the database clean, you need to catch visitors who still type plain http://example.com into their address bar. Depending on your plan, Hostinger runs LiteSpeed or an Nginx reverse proxy sitting in front of Apache.

Open your root .htaccess file via File Manager or SSH. Put these rewrite rules right at the top, before the default # BEGIN WordPress block:

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

If your account runs on Hostinger’s LiteSpeed infrastructure, you can also flip this switch inside hPanel:

1. Log in to hPanel.
2. Go to Websites > Manage on your domain.
3. Click SSL in the left sidebar.
4. Make sure the certificate status is Active, then toggle Force HTTPS on.

If you run into stubborn redirect loops or want to set strict HSTS headers, take a look at our guide on how to fix WordPress mixed content warnings and force HTTPS.

Fix Hardcoded Assets in Themes, Elementor, and CSS

Here is an issue that catches plenty of developers off guard: page builders like Elementor and Divi write static, compiled CSS files straight to disk in wp-content/uploads/. Those files cache absolute URLs for background graphics and fonts.

You can run database replacements all day, but those flat CSS files on disk will keep serving http:// asset paths until you force a rebuild.

Here is how to clear this out in Elementor:

1. Go to your WordPress Admin dashboard.
2. Navigate to Elementor > Tools.
3. Under General, click Regenerate CSS & Data.
4. Click the Replace URL tab.
5. Add your old http:// domain in the first box, your new https:// domain in the second, and click Replace URL.

If you’re maintaining a custom theme and hardcoded asset paths in functions.php or style.css, you will need to clean those up by hand. Swap out static strings for relative paths or WordPress helpers like get_template_directory_uri().

Clear Hostinger Object Cache and LiteSpeed Edge Cache

Hostinger caches pages and queries aggressively. If your browser still shows mixed content errors after updating the database and regenerating page builder assets, your server is simply serving stale cached HTML compiled prior to the SSL switch.

Clear your caches in this specific order:

1. WordPress Cache Plugin: If you use LiteSpeed Cache, hover over the LiteSpeed diamond icon in the top WordPress admin bar and click Purge All.
2. Hostinger Object Cache: In hPanel, head to WordPress > Overview, locate Object Cache, and toggle it off and back on to dump stale Redis data. If you run a custom Redis instance, check our guide on how to configure Redis Object Cache for WordPress on Hostinger VPS.
3. Browser Cache: In Chrome, open DevTools, right-click the browser reload button, and click Empty Cache and Hard Reload.

To ensure the server is serving clean headers without browser cache getting in the way, test it from your local terminal with curl:

curl -I https://yourdomain.com

Make sure you get a clean HTTP/2 200 or HTTP/1.1 200 OK response without any strange redirect hops bouncing back to port 80.

Mixed Content Troubleshooting FAQ

Why is my padlock still broken after running WP-CLI search-replace?

Third-party external assets are almost always the cause. If you embedded an external script, font, or tracker with a hardcoded http:// link pointing to a remote domain, WP-CLI will not touch it because it only looked for your own domain. Check the Chrome DevTools Console tab to see which external origin is causing the flag.

Can I use the Really Simple SSL plugin instead?

You can, but it is a band-aid. Really Simple SSL works by dynamically modifying the PHP output buffer on every single request. That adds unnecessary PHP runtime overhead. Fixing the URLs once in the database with WP-CLI and adding an .htaccess redirect gives you permanent HTTPS without adding plugin bloat.

Will fixing mixed content affect my SEO rankings?

It will help them. Search engines penalize sites that have insecure connection warnings or incomplete HTTPS setups. A clean 301 redirect chain preserves your link equity while delivering the secure HTTPS signal Google prioritizes.

What if my Hostinger staging site has mixed content after push?

When you push from staging to production inside hPanel, staging URLs sometimes get stuck in wp_postmeta or builder configs. Re-run the WP-CLI search-replace command, replacing your staging domain with your live HTTPS domain. For a clean deployment flow, check our walkthrough on managing a WordPress staging site in Hostinger hPanel.