You moved your site to HTTPS, but a visitor still sees a “Not secure” label in the address bar. In most cases the culprit is mixed content: an image, script or iframe on the page is still being fetched over HTTP. Here is what causes the warning, which parts of the page it breaks, and how to fix it in the order you would actually work through it.

What mixed content is, and why browsers block it

A page has mixed content when its initial HTML loads over a secure HTTPS connection but other resources, such as images, videos, stylesheets and scripts, load over insecure HTTP. The problem is that those insecure requests are vulnerable to on-path attacks, in which someone eavesdropping on the network can view or modify the traffic. Using those resources, an attacker can track users, replace images on your site, or, with active mixed content, take complete control of the page.

Browsers report mixed content warnings, but the report often comes too late: by the time you see it, the insecure requests have already been made. That is why most browsers now block mixed content instead of just warning about it. If you ignore it, some of your page may simply stop working.

Active vs. passive mixed content

The two categories behave differently, and the difference tells you what you are dealing with:

Type	Examples	What browsers do
Passive	Images, video, audio	Auto-upgrade the request to HTTPS; if the HTTPS version does not exist, the resource fails to load
Active	Scripts, stylesheets, iframes, and other executable code	Block the request entirely

An HTTP image will often still display because the browser quietly upgraded it, but the address bar shows the page is not secure. An HTTP script or stylesheet never loads, which can leave you with a page missing its menu, slider or styling with no obvious explanation.

Finding the mixed content on your pages

Work through your important pages in order of business value: home page, service or product pages, contact page, then anything with embeds or checkout forms.

1. Check the address bar. If the page loads over HTTPS but the lock icon is replaced with a warning or a “Not secure” label, the page has mixed content.
2. Open the browser developer tools. In Chrome, press Control+Shift+J (or Command+Option+J on a Mac) to open DevTools with the Console panel showing. Right-clicking the page and choosing Inspect also opens DevTools. When the browser reports mixed content, the warning appears there.
3. Search the page source. View the page source and search for src="http:// and href="http://. Watch for protocol-relative URLs written as //example.com/asset.js, which can also resolve to HTTP depending on how they are used.
4. Pay attention to pages with embeds. Iframes, video players, chat widgets and map embeds are active mixed content, and they are the ones most likely to break your page outright.

Fixing your own assets: update the URLs, not the redirects

Your server may redirect HTTP requests to HTTPS, but do not count on redirects as the fix. Change the URLs in your pages so the browser requests the secure version directly. Google’s guidance is to change insecure content requests to secure content to ensure that your page keeps loading correctly.

• Update image, script and stylesheet URLs in your templates, theme files and page content to use https://.
• Search your CMS database for hardcoded http:// links to your own domain, since old content often holds them.
• Confirm each asset actually loads over HTTPS before you change the reference. If a file has no HTTPS version, the request will fail without falling back to HTTP.

For sites with a large backlog of legacy URLs, the Content Security Policy directive upgrade-insecure-requests tells the browser to rewrite insecure resource URLs to HTTPS before any request is made. It is a reasonable stopgap, but the right fix is still updating the URLs themselves, and the directive does not replace other protections such as the HSTS header.

Third-party scripts, fonts and iframes

Not every HTTP asset is yours. Analytics snippets, hosted fonts, ad code, booking widgets and iframe embeds can all reference HTTP. For each one, get an updated embed code from the provider; reputable services supply HTTPS code by default. If a provider offers no HTTPS version, remove that embed, because browsers will block it anyway and your visitors will just see a gap or a broken widget.

Common mistake: An HTTP iframe is treated as active mixed content and will be blocked entirely. If a form or map inside an iframe stops rendering on your HTTPS pages, the parent page’s embed URL is the first thing to check.

Keeping it clean

Mixed content usually comes back through routine edits: a pasted embed code, a plugin update, a migration that copied over old markup. After any content, theme or plugin change, load the affected pages and glance at the address bar and console. If you have moved your whole site to HTTPS, updating every internal reference is part of a proper migration, not an optional cleanup; see redirects and site migrations.

Mixing HTTP and HTTPS undermines the reason you bought a certificate in the first place. If you are still early in the process, start with HTTPS and site security, and for the images you are re-pointing to HTTPS, image optimization will keep them fast once they load securely.

FAQ

Is mixed content bad for SEO?

Google recommends changing insecure requests to secure ones so your page keeps loading correctly, since browsers now block mixed content for security reasons. The direct ranking effects matter less than the broken pages and visitor trust issues that blocking creates.

Why do images trigger a warning but scripts disappear entirely?

Browsers auto-upgrade image, video and audio requests from HTTP to HTTPS and show a warning, while they block requests for other resource types outright. That is why an HTTP image may still appear but an HTTP script never runs.

Can I just redirect the HTTP asset URLs to HTTPS?

The dependable fix is to update the URLs themselves in your HTML, database and templates so the browser never requests the insecure version. Google recommends changing insecure requests to secure ones so your page keeps loading correctly.

What if a third-party script has no HTTPS version?

Then it will be blocked on your HTTPS pages and you should remove it. Look for an HTTPS version or a replacement from another provider, because there is no safe way to load it.

Search engines update their systems and documentation often. This guide reflects Google’s published guidance at the time of writing; check Google Search Central for current details, and test changes on a staging copy of your site before making them live.