How to Fix Mixed Content Warnings With the Really Simple SSL Plugin

You installed an SSL certificate, your site loads over HTTPS, but the padlock still shows a warning and some images or styles refuse to load securely. That is mixed content: the page is secure, but some of its files are still being fetched over plain HTTP. The Really Simple SSL plugin (now named Really Simple Security) was built to fix exactly this, usually in minutes.

This guide explains what mixed content is, how the plugin fixes it safely, and how to handle the stubborn cases it cannot auto-repair.

Quick Answer

First make sure a valid SSL certificate is installed on your hosting. Then install and activate Really Simple SSL and click “Activate SSL” / “Go ahead, activate SSL” in its prompt. The plugin redirects all traffic to HTTPS and rewrites insecure internal URLs in your content on the fly. Check a few pages for the clean padlock; hard-coded HTTP links in themes or widgets may still need manual fixing.

What Mixed Content Actually Is

When an HTTPS page loads a script, stylesheet or image from an http:// address, browsers call it mixed content. Passive mixed content (images, audio, video) triggers warnings; active mixed content (scripts and stylesheets) is blocked outright, which is why a site can look broken right after moving to HTTPS. The usual sources are old posts where images were inserted with full HTTP URLs, hard-coded links in theme files and widgets, and third-party embeds from the pre-HTTPS era. Your certificate can be perfect while the site still warns, because the problem lives in the content, not the certificate.

Fixing It With the Plugin, Step by Step

1. Back up your site, or at least your database; you should before any site-wide change.
2. Confirm your certificate works by visiting https://yourdomain.com directly; if the certificate itself errors, fix that with your host first.
3. Install and activate Really Simple SSL from Plugins → Add New.
4. Click the activation prompt (“Go ahead, activate SSL”); the plugin checks your setup before switching.
5. Let it enable the 301 redirect to HTTPS and the mixed content fixer, which rewrites insecure URLs in output as pages render.
6. Clear your cache plugin and CDN cache so visitors get the corrected pages.
7. Browse your homepage, a post, and your contact/checkout page, confirming the padlock is clean on each.

What the fixer does and does not do

The fixer rewrites URLs in the rendered page without editing your database, which is fast and reversible (deactivate the plugin and the rewriting stops). It handles content, widgets and most theme output. It cannot rewrite URLs buried in CSS files or hard-coded in a theme’s PHP in every case, and it does not fix external embeds whose source simply has no HTTPS version. Those need the manual steps below.

The plugin’s documentation at Really Simple Security’s site details its current feature set, and the WordPress.org listing tracks compatibility. For the broader hardening picture, see our cyber security guides.

Fixing Stubborn Mixed Content Manually

Find the culprits with your browser: open a warned page, press F12, and read the Console, which names every insecure URL and its source. If the URL is an image in old posts, update the post content or run a careful database search-and-replace from http://yourdomain.com to https://yourdomain.com (a job for a proper tool and a fresh backup). If it is in a widget or theme setting, update that field. If it is a third-party embed with no secure version, replace or remove the embed; there is no safe workaround.

Verifying the Fix Like a Browser Would

Do not trust the padlock on the page you have open; browsers cache aggressively and your logged-in session hides things visitors see. Verify in a private/incognito window, logged out, and check more than the homepage: an old blog post (where HTTP image URLs hide), your contact page, and any page with embeds. Open the browser console on each and look for lines beginning “Mixed Content”; the goal is silence. A free online mixed-content scanner can crawl several pages at once if you want broader coverage. Only when incognito visitors on multiple templates see a clean padlock with an empty console is the job genuinely done.

When to Fix the Database Instead of Relying on the Fixer

The plugin’s fixer is a translator standing between your database and your visitors; it corrects output without touching the original text. That is perfect as a first response, but a mature site should eventually fix the source. If you plan to change domains, migrate hosts, or hand the site to another developer, permanent database URLs make everything simpler and remove a (tiny) processing step from every page load. The safe sequence is: fresh full backup, then a dedicated search-and-replace tool that handles serialized data correctly, then clear all caches and re-verify with the console method above. Never edit the database by hand with raw SQL unless you fully understand serialized strings; that way lies corrupted widgets.

After the Padlock: HSTS and the Remaining Five Percent

Once the padlock is clean everywhere, one optional hardening step remains: HSTS, a header that tells browsers to only ever contact your site over HTTPS, closing the tiny window where a first visit could be intercepted on HTTP. The plugin’s premium tier and many hosts can enable it; treat it with respect, because a misconfigured HSTS on a site whose certificate later breaks will lock visitors out hard. Enable it only when your HTTPS setup is stable and your certificate renewal is automatic. Beyond that, resist gold-plating: the padlock, the redirect and the database cleanup described earlier constitute a finished job for the overwhelming majority of sites, and the remaining effort belongs to content and speed.

Checking the Pages Behind the Scenes

Public pages get verified; the stragglers hide in the corners. Check your login page, a password-reset email link landing page, and any page served after form submission, since mixed content there frightens visitors at the exact moment they are deciding whether to trust you. If you run a store, walk the full path from product to checkout in an incognito window and watch the padlock the whole way. Ten unglamorous minutes in the corners finishes the job the activation click started.

Common Mistakes and Tips

The number-one mistake is activating SSL fixes before a valid certificate exists, which locks visitors out behind browser errors. Never stack the plugin’s redirect with a second redirect rule from another plugin, or you can create redirect loops. Update your address in Google Search Console and analytics to the HTTPS version, and check your sitemap is generating HTTPS URLs. Finally, leave the plugin active; removing it removes the fixer and the redirect in most setups.

Conclusion

Mixed content is a content problem wearing a security costume, and Really Simple SSL solves the bulk of it automatically once your certificate is valid. Activate it, purge caches, verify the padlock on key pages, and chase any console-listed stragglers by hand. Your visitors get the clean, trustworthy padlock your certificate promised.

Frequently Asked Questions

Do I still need this plugin if my host offers one-click HTTPS?

Host tools install the certificate and sometimes the redirect, but old content URLs often remain HTTP. The plugin’s mixed content fixer is the part that cleans those up, which is why it stays useful.

Will the plugin slow down my site?

Negligibly. The fixer processes page output, and on a cached site the impact is effectively zero for visitors.

What if I get a redirect loop after activating?

It usually means another redirect (from a caching/security plugin, CDN or .htaccess rule) is conflicting. Disable the other redirect, keep the plugin’s, and clear caches; the plugin’s support docs list the common cloud-proxy setting that causes it.

Does the plugin fix insecure links to other websites?

Ordinary text links to http:// pages elsewhere are not mixed content and do not trigger warnings. Only resources loaded into your page (images, scripts, styles, iframes) count.

Should I also update URLs in my database permanently?

It is good long-term hygiene to replace your own domain’s HTTP URLs in the database with a proper migration tool, after which the fixer has nothing left to do. Always back up first.