Blog

Your SSL certificate is installed, your site should be secure, but the browser is still warning visitors that something is wrong.

That usually means mixed content. The site itself is loading over HTTPS, but one or more images, scripts, stylesheets, fonts, videos, or embeds are still being requested over plain HTTP.

The good news: mixed content is usually fixable without rebuilding your WordPress site. The annoying part is that the problem can hide in page builder content, old image URLs, theme settings, CSS files, caching layers, or third-party embeds.

What mixed content means

Mixed content happens when a secure HTTPS page loads something from an insecure HTTP URL.

For example, your page might load here:

https://example.ca/about/

But the logo, background image, stylesheet, or tracking script might still be referenced like this:

http://example.ca/wp-content/uploads/logo.png

That mismatch is what triggers the warning.

Browsers are stricter about this in 2026 than they used to be. They may quietly upgrade some image requests, block scripts completely, or show a warning beside the address bar. If checkout scripts, form scripts, or page builder files are blocked, parts of the site can break.

Quick distinction: Having an SSL certificate is only step one. Your site also needs to actually use HTTPS everywhere.

How to tell if you have mixed content

The most obvious sign is a browser warning. You may see “Not secure,” a broken padlock, or a warning icon beside the address bar even though the page URL starts with HTTPS.

Other signs include:

• Images missing on secure pages
• Layout issues after installing SSL
• Fonts not loading correctly
• Sliders, maps, or forms not working
• Checkout buttons or payment fields behaving oddly
• Browser console errors mentioning “mixed content”

Some pages may be fine while others are not. The homepage might show a secure padlock, but an older blog post, landing page, product page, or contact page may still contain HTTP links.

Before you start fixing anything

Do not run a database-wide replacement or install three SSL plugins before doing a quick safety check. Mixed content is fixable, but a rushed fix can create broken images, duplicate redirects, or serialized data problems.

Before making changes:

• Take a fresh backup of the files and database
• Confirm the SSL certificate is valid and not expired
• Check that WordPress Address and Site Address use HTTPS
• Clear any caching plugin, server cache, and CDN cache after each major change
• If the site is important for sales or leads, test changes on staging first

If you want a broader SSL overview first, read SSL Certificates: Why Your Site Needs HTTPS.

Step 1: Confirm WordPress is using HTTPS

Start in the WordPress dashboard. Go to the general site settings and check both the WordPress Address and Site Address fields.

They should use:

https://

Not:

http://

This sounds too basic, but it is one of the most common causes of mixed content after SSL is installed. If WordPress still thinks the site lives at the HTTP version, it can keep generating insecure links for media, scripts, stylesheets, and internal URLs.

After changing these settings, log out and back in if needed. Then clear cache and test again in a private browser window.

Step 2: Find the exact insecure files

Do not guess. Find the exact HTTP resources causing the warning.

The fastest way is your browser’s developer tools:

1. Open the affected page in Chrome, Firefox, Edge, or Safari
2. Right-click the page and choose Inspect
3. Open the Console tab
4. Reload the page
5. Look for messages mentioning “Mixed Content”

The console will usually show the insecure URL. Copy it somewhere. You are looking for patterns.

For example:

• All problem URLs are old images from your own uploads folder
• Only one plugin is loading an HTTP script
• A page builder section has an HTTP background image
• A third-party widget is using an insecure embed
• The CDN is still serving old HTTP references

Once you know the source, the fix is much easier.

Step 3: Fix internal media URLs

If the insecure URLs point to your own domain, they are usually old database references.

This often happens when a site existed for years on HTTP, then SSL was added later. Old posts, pages, widgets, menus, and page builder layouts may still contain full HTTP links.

You can fix these with a careful search and replace from:

http://example.ca

To:

https://example.ca

Use a tool that understands WordPress serialized data. Many WordPress site owners use plugins such as Better Search Replace, or WP-CLI if they are comfortable with command line work. Check the official documentation for whichever tool you use, because interfaces and options can change.

Do not manually export the database and run random SQL replacements unless you know exactly what you are doing. WordPress stores some data in serialized formats, and careless replacements can break page builder layouts, widgets, and plugin settings.

If using WP-CLI, a typical approach is to run a dry run first, review what would change, then run the real replacement. Many developers skip the GUID column when replacing URLs, but the right choice depends on the site and migration history.

If that sentence made your eyes glaze over, that is a sign to use a WordPress-safe plugin or ask someone technical to handle it.

Step 4: Check page builders, theme options, and widgets

Search and replace fixes many mixed content issues, but not all of them.

Some themes and page builders store images, icons, fonts, or background settings in places that do not update cleanly. You may need to open the affected page, edit the section, remove the old image, and reselect it from the media library.

Check these areas:

• Header logo settings
• Footer logo settings
• Favicon or site icon settings
• Hero background images
• Custom CSS fields
• Sidebar widgets
• HTML blocks
• Page builder templates
• Popup builder content
• Old shortcode output

Background images are a classic culprit. They may not appear in the visible page editor, but the browser console will still show the HTTP image being loaded from a CSS rule.

Step 5: Fix hardcoded theme and custom code references

If the browser console points to a script, stylesheet, font, or image inside your theme, the URL may be hardcoded.

This can happen in:

• Theme template files
• A child theme
• Custom JavaScript
• Custom CSS
• Header or footer injection fields
• Tracking code snippets

Look for full URLs beginning with HTTP. Where possible, replace them with HTTPS versions or use WordPress functions that generate the correct site URL automatically.

If you are editing theme files, use a child theme or proper deployment workflow. Editing a commercial theme directly can cause your changes to disappear during the next theme update.

Step 6: Check third-party embeds and scripts

Not every mixed content issue comes from your own site.

You may have an old embed from a booking system, review widget, map provider, video player, analytics tool, chat widget, or payment-related service that still uses HTTP.

For third-party resources, do not simply change HTTP to HTTPS and hope for the best. First, check whether the provider supports HTTPS. Most reputable providers do, but old embed codes can linger for years.

Good fixes include:

• Replacing the old embed code with the current one from the provider
• Updating the plugin that provides the integration
• Removing the widget if the provider no longer supports HTTPS
• Switching to a maintained alternative if the old service is abandoned

This matters even more on contact forms, appointment forms, payment pages, and intake forms. Canadian businesses collecting personal information should take HTTPS seriously, especially where PIPEDA obligations are involved. For more on privacy expectations, see How to Comply with PIPEDA: Essential Privacy Policy Requirements for Canadian Websites.

Step 7: Clear every cache layer

Mixed content sometimes looks fixed in WordPress but still appears in the browser because cached files are being served.

Clear all relevant caches:

• WordPress caching plugin cache
• Server cache
• Object cache, if used
• CDN cache
• Browser cache
• Page builder generated CSS cache
• Minified CSS and JavaScript cache

If your site uses a CDN, check whether the CDN is rewriting, caching, or proxying assets. A stale CDN cache can keep serving old HTTP references after WordPress itself has already been corrected.

If you are not sure how caching works in WordPress, this article is a useful companion: WordPress Caching Explained: A Beginner's Guide.

Step 8: Set up proper HTTP to HTTPS redirects

Once the site is working over HTTPS, make sure visitors and search engines are redirected from HTTP to HTTPS.

This is usually handled at the hosting, server, CDN, or control panel level. Many hosts provide a simple “force HTTPS” option. Some WordPress plugins can also do it, but server-level redirects are usually cleaner.

A redirect helps when someone visits the old HTTP version of a page. It does not fully solve mixed content by itself, because the HTML may still request insecure assets. Fix the source URLs first, then use redirects as a safety net.

Also avoid stacking multiple redirect systems if you can. A hosting redirect, CDN redirect, WordPress plugin redirect, and manual redirect rule can create loops or slow chains.

Step 9: Be careful with HSTS

HSTS tells browsers to always use HTTPS for your domain. It can be useful, but do not enable it too early.

If your HTTPS setup is incomplete, HSTS can make testing harder and can lock visitors into a broken secure version until the policy expires. Get the certificate, redirects, mixed content, forms, checkout, and admin area working first.

Once everything is stable, HSTS may be worth considering, especially for sites that handle sensitive information. If you are unsure, leave it off until someone technical reviews the setup.

When an SSL plugin helps, and when it does not

Plugins such as Really Simple SSL or SSL Insecure Content Fixer can be useful, especially on smaller sites where you need a quick improvement.

They typically help with things like:

• Detecting SSL
• Updating common WordPress settings
• Adding HTTPS redirects
• Rewriting some insecure asset URLs on output

But they are not magic. They may not fix hardcoded third-party scripts, abandoned plugin output, broken CDN settings, or old embed codes. They can also hide the real issue instead of cleaning it up properly.

My usual advice: use an SSL plugin as a temporary bridge if needed, not as a permanent substitute for fixing the database, theme settings, and external resources.

Mixed content on WooCommerce stores

Mixed content is more serious on WooCommerce sites because cart, checkout, payment gateway, and account pages need to feel trustworthy and function reliably.

After fixing SSL issues, test:

• Product images
• Add to cart buttons
• Cart page
• Checkout page
• Payment fields
• Order confirmation page
• Customer login and password reset
• Transactional email links

If a payment gateway script is blocked because of mixed content, customers may not be able to pay. If trust badges, checkout styling, or product images break, customers may abandon the order even if the payment system technically still works.

For stores, do this on staging first if possible. A live checkout is not the place to experiment blindly.

Common mistakes to avoid

Only checking the homepage

The homepage is not enough. Check service pages, blog posts, landing pages, forms, checkout pages, and any older content that was built before SSL was installed.

Forgetting mobile

Some mixed content only appears on mobile layouts. A different logo, background image, menu script, or mobile slider may load only below a certain screen width.

Changing the database without a backup

Search and replace is powerful. It is also easy to make a mess. Always back up first.

Ignoring CSS background images

Visible image blocks are easy to spot. CSS background images are easier to miss, especially when they live inside generated page builder CSS.

Assuming the SSL certificate is the problem

If the certificate is valid and the page loads over HTTPS, the certificate may be fine. The problem is often the page content, not the certificate itself.

Leaving old third-party widgets in place

If a provider still serves assets over HTTP, it may be outdated or poorly maintained. That is worth reviewing beyond the mixed content warning.

A practical testing checklist

After making fixes, run through this checklist:

• Visit the HTTP version of the site and confirm it redirects to HTTPS
• Open the HTTPS version in a private browser window
• Check the browser padlock or security indicator
• Open developer tools and check the Console tab
• Test at least one page from each major section of the site
• Submit a test contact form
• Check images, fonts, icons, and layout
• Test on mobile and desktop
• Clear all cache layers and test again
• For WooCommerce, test cart and checkout carefully

If the warning disappears before cache clearing but returns after a few hours, look at caching, CDN rules, scheduled optimization tasks, or plugins that regenerate CSS.

What if the mixed content keeps coming back?

If mixed content keeps returning after you fix it, something is likely regenerating HTTP URLs.

Possible causes include:

• Incorrect WordPress site URL settings
• A migration plugin or old configuration still using HTTP
• A theme option that stores the old domain
• A page builder regenerating CSS from old settings
• A plugin loading assets with hardcoded HTTP paths
• A CDN or proxy configuration issue
• Old content being copied and pasted from another source

At that point, stop repeating the same search and replace. Find the source that is recreating the problem.

How Ambrite handles this for WordPress sites

Ambrite Web Services builds, hosts, and maintains WordPress sites from Fredericton, New Brunswick. On Ambrite Canadian cloud hosting, SSL certificates are included and auto-renewed on every plan.

For existing WordPress sites, mixed content cleanup is the kind of issue that can often be handled as part of ongoing care, depending on the site and the work required. Ambrite’s WordPress maintenance and security plans include updates, backups, monitoring, CDN support, speed checks, and monthly edit time, with plan details listed on the maintenance page.

If your site is already under maintenance, open a ticket or send an email with the affected page URLs. If you are not a client yet, you can contact Ambrite and include your website address plus a short note about where you see the browser warning.

When to get help instead of DIY fixing it

You can usually fix simple image-related mixed content yourself. If the console shows a few old image URLs from your own domain, a careful WordPress-safe search and replace may be enough.

Get help if:

• The issue affects checkout, payment, forms, or client intake pages
• You are not comfortable backing up and editing the database
• The site uses a complex page builder or custom theme
• The warning appears only sometimes
• Fixes disappear after cache clears or CSS regenerates
• You see blocked scripts rather than just insecure images
• You are dealing with sensitive personal information

Mixed content is not usually a disaster, but it does chip away at trust. Visitors do not care whether the warning is caused by one old background image or a serious security issue. They just see that the browser is unhappy.

Fix the URLs, clear the caches, test the important pages, and do not rely on a plugin to paper over something that should be cleaned up properly.

This article was written with the help of AI and reviewed by Ambrite. Pricing, features, and technical details may change, so always verify with official sources before making decisions.