How to Fix Mixed Content Errors After Enabling HTTPS

You installed the SSL certificate, your site loads over https:// — and yet the browser padlock still shows "Not Secure," or parts of the page (images, styles, scripts) refuse to load. The certificate is fine. The problem is mixed content: your HTTPS page is still asking for some resources over plain HTTP, and the browser doesn't like it.

This is one of the most common post-SSL headaches on WordPress, and it's entirely fixable. Below: what mixed content is, how to find every offending URL in minutes, and five fixes in the order you should try them.

The Quick Answer: Update the URLs, Not Just the Certificate

Installing a certificate secures the connection. It does not rewrite the links inside your pages. If your content, theme, or database still references http:// URLs, those requests stay insecure — and the browser flags or blocks them.

The fix sequence that works for most WordPress sites:

1. Find the insecure URLs with browser DevTools (5 minutes).
2. Update WordPress Address and Site Address to https:// in Settings → General.
3. Replace old http:// URLs in the database (with a backup first).
4. Fix any hardcoded URLs in theme/plugin files.
5. Add the upgrade-insecure-requests header as a safety net.

Work through them in order — most sites are fixed by step 3.

What Mixed Content Actually Is

"Mixed content" means a page loaded over HTTPS that requests sub-resources (images, scripts, stylesheets, video, iframes) over HTTP. The main page is encrypted; the sub-resources are not. An attacker on the network could intercept or modify those insecure requests, which undermines the whole point of HTTPS.

Browsers don't treat all mixed content the same. The current standard (documented by MDN) divides it into two categories:

Blockable content — always blocked

Scripts, stylesheets, iframes, and other "active" content that can change how the page behaves. Because a tampered script could steal passwords or rewrite the page, browsers block these outright. If your site's JavaScript or CSS loads over HTTP, it simply won't run — which is why a mixed-content problem can make a site look broken, not just show a warning.

Upgradable content — auto-upgraded, then blocked

Images, audio, and video. Modern browsers (Chrome since versions 80–81, Firefox similarly) first attempt to rewrite the http:// URL to https:// automatically. If the resource actually exists over HTTPS, it loads and you may never notice. If it doesn't, the browser blocks it. This auto-upgrade is helpful, but it's a bandage — you should still fix the underlying URLs.

Why the padlock disappears even though "HTTPS works"

The padlock reflects the entire page load, not just the main document. One blocked script or one un-upgradable image is enough to downgrade the security indicator. That's why the fix is about hunting down every insecure reference, not about the certificate itself.

How to Find the Insecure URLs

Don't guess — let the browser tell you exactly which URLs are the problem.

1. Open the affected page in Chrome (or Edge/Firefox).
2. Press F12 to open Developer Tools.
3. Click the Console tab and reload the page. Mixed content warnings appear here, each naming the blocked or upgraded URL, e.g.:

Mixed Content: The page at 'https://yoursite.com/' was loaded over HTTPS, but requested an insecure image 'http://yoursite.com/wp-content/uploads/old-photo.jpg'.

1. For the full picture, open the Security tab in DevTools — it lists every insecure origin the page touches.

Copy the offending URLs into a note. You'll notice patterns: maybe they're all old media uploads, or all from one plugin, or all hardcoded in the theme. The pattern tells you which fix to apply.

Fix 1 — Update WordPress Address and Site Address

This is the single most common cause of site-wide mixed content, and the easiest to fix.

In your WordPress dashboard, go to Settings → General. Look at the two URL fields:

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

If either still starts with http://, WordPress itself generates internal links, asset URLs, and redirects using the wrong protocol — causing mixed content on every page, not just specific posts.

Change both to https:// and save. Then clear any cache (plugin cache, server cache, CDN cache) and reload the page. For many sites, this alone clears the warnings.

Caution: on some setups (notably sites behind a reverse proxy or load balancer), WordPress may not detect HTTPS correctly and saving these settings can cause a redirect loop. If the site breaks immediately after saving, revert the two fields via the database (wp_options table, siteurl and home rows) or ask your host — this is a known configuration quirk, not a mixed-content problem.

Fix 2 — Replace Old URLs in the Database

If warnings persist after Fix 1, old http:// URLs are baked into your content. The usual hiding spots:

• Post and page content — an image inserted two years ago was saved with an http:// URL, and that URL is still sitting in the wp_posts table.
• Text widgets and customizer fields — manually added HTML in widgets often keeps the old protocol (wp_options and wp_postmeta tables).
• Menu items and metadata — less common, but worth checking.

The reliable way to fix these is a database search-and-replace: search for http://yoursite.com and replace with https://yoursite.com across the relevant tables (wp_posts, wp_postmeta, wp_options at minimum).

Two warnings before you touch the database:

1. Back up first. Always. A bad search-replace can break serialized data (WordPress stores many settings as serialized PHP strings where the character count matters). Use a tool that handles serialization correctly — the well-known "Better Search Replace" style plugins do; a raw SQL REPLACE() does not.
2. Be precise with the search string. Replace http://yoursite.com, not bare http:// — a blanket replace can corrupt external links, oEmbed data, or URLs that legitimately point elsewhere.

After running the replacement, clear all caches and re-check with DevTools.

Fix 3 — Fix Hardcoded URLs in Theme and Plugin Files

Some http:// references live in files, not the database. Common hiding spots:

• header.php / footer.php — hardcoded logo, script, or stylesheet links.
• Stylesheets — background-image: url(http://...) in CSS. These are easy to miss because they don't appear in page HTML.
• Plugin files or plugin settings pages — check the plugin's own settings first; many have a URL field you can simply update.
• Child-theme overrides that copied the parent's old URLs.

Search the theme folder for http://yoursite.com (any decent code editor or the Theme File Editor's search can do this) and update each match to https://. Better yet, where the resource is on your own domain, use relative URLs (/wp-content/uploads/photo.jpg) or protocol-relative URLs (//yoursite.com/...) — these automatically follow whatever protocol the page uses and can never cause mixed content.

Don't edit the parent theme directly if you're using a child theme — your changes will be wiped on the next theme update. Fix it in the child theme, or better, fix the source (the setting or content) rather than the file.

Fix 4 — Handle Third-Party Embeds and External Resources

Sometimes the insecure URL isn't yours at all — it's a Google Font, a jQuery CDN link, a Vimeo embed, or an ad/analytics snippet pointing at http://:

• http://fonts.googleapis.com/...
• http://code.jquery.com/...
• http://player.vimeo.com/...

The fix is usually trivial: change http:// to https://. Virtually every major service supports HTTPS in 2026 — re-copying the embed code from the provider's site will typically give you an HTTPS version by default.

If a service genuinely has no HTTPS version, you have three options, in order of preference:

1. Host the resource yourself over HTTPS (download the file, serve it from your own domain).
2. Find an alternative service that supports HTTPS.
3. Remove it. Any third-party service that still doesn't support HTTPS is a security liability you don't want on your pages anyway.

Check where the URL comes from before editing: it might be in a widget, a plugin's settings screen, or hardcoded in the theme (Fix 3's territory).

Fix 5 — Add the upgrade-insecure-requests Header

This is a safety net, not a substitute for fixing URLs — but it's a good one. The W3C-standard upgrade-insecure-requests Content Security Policy directive tells the browser: "before requesting any http:// sub-resource on my pages, rewrite it to https:// automatically."

It achieves two things the browser's built-in auto-upgrade doesn't fully cover: it applies to all sub-resources (not just images/media), and it works without editing a single line of content — useful for archived or legacy pages you can't easily update.

On Apache servers (the most common shared-hosting setup), add this to your .htaccess, in the website's root folder:

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

Notes:

• This only upgrades requests — if the HTTPS version of a resource doesn't exist, the request still fails. It doesn't magically create secure versions of insecure-only resources.
• It doesn't fix the underlying http:// references; keep working through Fixes 1–4 so your site is genuinely clean.
• If your host runs Nginx instead of Apache, the equivalent goes in the server block config — ask your host, since you typically can't edit that file yourself on shared hosting.

When a Plugin Is the Right Call

If the manual route feels risky — especially the database step — a dedicated plugin can do the heavy lifting:

• Really Simple SSL / Really Simple Security — detects your SSL setup and rewrites http:// URLs to https:// on the fly as pages render. Fixes the visible symptoms for most sites in minutes.
• SSL Insecure Content Fixer — offers graduated fix levels (Simple → Content → Widgets → Capture). Start with the lightest mode that works; the aggressive "capture" modes rewrite output buffers and can affect performance.

Be clear-eyed about what these do: on-the-fly rewriting masks the problem rather than fixing the stored URLs. Your database still contains http:// references. That's acceptable as a quick win or for sites you can't easily edit, but the permanent fix is still Fixes 1–4 above. And as always: back up before installing anything that touches URLs.

Frequently Asked Questions

I installed SSL but the site still says "Not Secure." Is the certificate broken?

Probably not. "Not Secure" after a successful SSL install is the classic mixed-content symptom: the certificate secures the connection, but the page still loads some resources over HTTP. Work through the DevTools check above — you'll almost always find one or more http:// URLs to fix. If DevTools shows no mixed content and the warning persists, then check the certificate itself (expiry, domain mismatch) — but mixed content is the far more common cause.

Will mixed content hurt my Google rankings?

Indirectly, yes. Google uses HTTPS as a ranking signal, and a page with blocked scripts or missing images delivers a worse user experience — higher bounce rates, broken layouts — which search engines do notice. More importantly, visitors who see "Not Secure" trust the site less. Fixing mixed content is one of the cheapest trust wins available.

Can I just use a plugin and skip the manual fixes?

You can, and for many sites that's enough to make the warnings disappear. But plugins rewrite URLs at render time — the http:// references remain in your database and files. If you ever disable the plugin, the warnings come back. Treat a plugin as a fast first aid; schedule the database cleanup (Fix 2) as the permanent cure.

Why do only some pages show the warning?

Because mixed content is per-URL, not per-site. A page shows warnings only if that page references insecure resources. Old blog posts with images inserted years ago are the classic case — the homepage looks fine while a 2021 article throws warnings. That's actually good news: it means the problem is contained, and the database search-replace (Fix 2) will sweep it up.

My images were auto-upgraded by Chrome and look fine. Do I still need to fix them?

Yes. Chrome's auto-upgrade of images (since version 81) is a browser convenience, not a fix. Other browsers may behave differently, the underlying http:// references are still there, and any resource that can't be upgraded gets blocked. Clean URLs are the only reliable state.

I fixed everything but the warning is still there — what now?

Run this checklist: (1) hard-refresh with cache disabled (Ctrl+Shift+R, or DevTools open with "Disable cache" checked) — stale cached pages are the #1 false alarm; (2) purge every cache layer — plugin, server, and CDN; (3) re-scan with DevTools on the exact page showing the warning; (4) check for the URL in places people forget — CSS background-image, RSS feeds, and hardcoded URLs in email templates or structured data. If it's genuinely clean in DevTools and still warns, verify the certificate itself hasn't expired.

Still seeing warnings after the cleanup? Double-check the certificate side with our guide on fixing a "Not Secure" warning — and if you're planning hosting changes around the fix, our hosting plan guide covers what to look for before you move.