How to Fix WordPress Mixed Content Errors After SSL (2026 Guide)

You installed a free Let's Encrypt or PositiveSSL certificate on your hosting server. You visited your website expecting to see a clean, encrypted padlock, only to find a grey warning icon or a bright red "Not Secure" notice in the browser address bar.

This is a mixed content error. Your server has an active SSL certificate, but your WordPress page is loading images, stylesheets, or JavaScript files using insecure http:// links. Modern browsers refuse to trust half-encrypted pages and downgrade your site's security status.

Here is the bottom-line fix: you do not need to pay $50 for a premium security plugin. You can resolve mixed content errors permanently in under ten minutes using three clean steps: database URL replacement, 301 server redirection, and theme cache regeneration.

---

What Causes Mixed Content: The Technical Breakdown

When a visitor visits https://yourdomain.com, the browser establishes an encrypted TLS handshake. However, as the browser parses the HTML code, it might encounter a line like this:

Because that image is requested over unencrypted HTTP, an attacker on a public Wi-Fi network could theoretically intercept the unencrypted data packet and inject malicious code. Browsers block or flag the connection to protect the user.

---

Step 1: Diagnose the Exact Insecure Assets in Chrome

Before touching any settings, identify exactly which files are triggering the warning.

1. Open your website in Google Chrome or Mozilla Firefox.
2. Right-click anywhere on the page and select Inspect (or press Ctrl + Shift + I on Windows / Cmd + Option + I on Mac).
3. Click the Console tab at the top of the Developer Tools panel.
4. Type mixed content in the filter box.
5. Review the red warning output. Chrome will display the exact URLs responsible: - Mixed Content: The page at 'https://yourdomain.com/' was loaded over HTTPS, but requested an insecure image 'http://yourdomain.com/wp-content/uploads/2025/hero.jpg'. This content should also be served over HTTPS.

Make a mental note of whether the insecure links point to uploaded images, theme fonts, or external third-party widgets.

---

Step 2: Update Core WordPress Site Addresses

Ensure WordPress knows it should be operating over HTTPS natively.

1. Log into your WordPress Admin Dashboard.
2. Navigate to Settings > General.
3. Verify the two core URL fields: - WordPress Address (URL): Change from http://yourdomain.com to https://yourdomain.com. - Site Address (URL): Change from http://yourdomain.com to https://yourdomain.com.
4. Scroll down and click Save Changes. You will be temporarily logged out. Log back in using your regular admin credentials.

---

Step 3: Run a Serialized-Safe Database Search and Replace

Updating the general settings only updates dynamic navigation menus. Images, logos, and custom layout modules you uploaded in the past remain hardcoded with http:// in the wp_posts and wp_postmeta database tables.

Do not edit SQL database dumps in a plain text editor like Notepad. WordPress stores data in serialized arrays; modifying character counts in a raw text file corrupts widgets and theme options.

Use the serialized-safe Better Search Replace plugin:

1. In your WordPress dashboard, go to Plugins > Add New.
2. Search for Better Search Replace (by WP Engine), install, and activate it.
3. Navigate to Tools > Better Search Replace.
4. In the Search for field, enter your old HTTP URL: http://yourdomain.com (do not add a trailing slash).
5. In the Replace with field, enter your secure HTTPS URL: https://yourdomain.com (do not add a trailing slash).
6. Under Select tables, highlight all database tables (hold Ctrl or Cmd to select all).
7. Keep Run as dry run? checked and click Run Search/Replace.
8. The tool will scan your database and report how many cells will be updated without altering data.
9. If updates are found, uncheck Run as dry run? and click Run Search/Replace again.
10. Deactivate and delete the plugin once the process completes.

---

Step 4: Regenerate Elementor and Page Builder CSS

If you use page builders like Elementor, Divi, or Beaver Builder, your layout CSS files are pre-compiled and saved to the disk with hardcoded URLs. Even after updating the database, the cached CSS files will continue loading old HTTP image paths.

For Elementor Users:

1. Navigate to Elementor > Tools in your sidebar.
2. Under the General tab, find Regenerate CSS & Data.
3. Click Regenerate Files.
4. Click Sync Library.
5. Switch to the Replace URL tab, enter http://yourdomain.com into the old URL field, enter https://yourdomain.com into the new URL field, and click Replace URL.

For Divi Users:

1. Navigate to Divi > Theme Options > Builder > Advanced.
2. Click Clear next to Static CSS File Generation.

---

Step 5: Force Server-Level 301 HTTPS Redirection (.htaccess / Nginx)

To ensure that any visitor or bot typing yourdomain.com or http://yourdomain.com is automatically routed to the secure HTTPS version, enforce a server-level 301 permanent redirect.

For Apache / LiteSpeed Servers (via .htaccess)

Connect to your server via SFTP or your hosting file manager. Open the .htaccess file in your public_html root directory and add this block at the very top, before the # BEGIN WordPress line:

For Nginx Servers (via nginx.conf)

If your host runs pure Nginx without Apache, add this redirect server block to your Nginx configuration:

---

Step 6: Fix Mixed Content at the Edge with Cloudflare

If your website uses Cloudflare for CDN or DNS management, you can enable edge-level security features that catch any rogue HTTP requests before they reach the browser.

1. Log into your Cloudflare Dashboard and select your active website.
2. Navigate to the SSL/TLS tab in the left sidebar and select Edge Certificates.
3. Locate Always Use HTTPS and toggle it to On. This forces Cloudflare to upgrade all incoming unencrypted requests at the DNS level.
4. Scroll down to Automatic HTTPS Rewrites and toggle it to On. Cloudflare will automatically rewrite insecure http:// paths to https:// for known safe third-party CDNs, fonts, and assets on the fly.

---

Why You Should Avoid Relying on "Really Simple SSL"

Many beginners install the popular Really Simple SSL plugin to fix mixed content with a single click.

While the plugin works, it functions as a temporary software patch rather than a permanent fix:

• It intercepts every HTTP request using PHP output buffering and replaces URLs on the fly in server RAM.
• If the plugin is deactivated or crashes during an update, your mixed content errors return immediately.
• It adds unnecessary PHP execution overhead to every page load, increasing your server's Time to First Byte (TTFB).

By executing a permanent database search and replace and enforcing .htaccess rules, your site remains permanently clean and fast without relying on background plugins.

---

Advanced Method: Fixing Mixed Content via WP-CLI (For Developers)

If you manage your server via SSH terminal or operate multiple WordPress installations, you do not need to install plugins. You can execute a high-speed, serialized-safe database replacement in three seconds using WP-CLI.

Connect to your server terminal, navigate to your web root (cd /var/www/html or cd public_html), and run these two commands:

The --precise flag ensures that PHP serialized objects are measured by exact byte length rather than character count, preventing broken serialized strings in complex theme settings.

---

Fixing Hardcoded Insecure URLs in Theme Files and Header Scripts

Occasionally, running a database search and replace fails to remove the mixed content warning because the insecure resource is hardcoded directly inside your active theme's header.php, footer.php, or style.css template files.

Follow this inspection routine:

1. In your Chrome Console, note the exact file URL that triggered the warning (e.g., http://fonts.googleapis.com/css?family=Roboto or an external analytics script).
2. Open your WordPress dashboard and navigate to Appearance > Theme File Editor (or inspect your child theme files via SFTP).
3. Check header.php and functions.php for hardcoded http:// calls.
4. Replace http:// with https:// (or remove the protocol entirely to use protocol-relative URLs like //fonts.googleapis.com).
5. Save the file. If you use a parent theme that receives regular developer updates, move the modified code into a Child Theme so updates do not overwrite your SSL modifications.

---

How to Prevent Mixed Content Regressions in the Future

Once your padlock is restored, implement these operational safeguards so future blog posts or editor uploads do not reintroduce insecure links:

• Enforce Strict HTTPS in wp-config.php: Add define('FORCE_SSL_ADMIN', true); to your wp-config.php file directly above the "That's all, stop editing!" line.
• Audit New Plugins Before Production Deployment: Test third-party widgets and donation buttons in a staging environment. Outdated plugins often load external JavaScript libraries from insecure HTTP origins.
• Enable Cloudflare Automatic HTTPS Rewrites: Keep Cloudflare's edge rewrites active as a permanent safety net that catches occasional human copy-paste errors automatically.

---

Verification: Confirming the Clean SSL Padlock

Once you have completed the steps above:

1. Clear your WordPress caching plugin (WP Rocket, LiteSpeed Cache, or W3 Total Cache).
2. Purge your browser cache (or open a private Incognito window).
3. Visit https://yourdomain.com.
4. Check the address bar: you will see a clean, unbroken padlock icon confirming that 100% of your page assets are securely encrypted.