Your Padlock Says Secure. One Image Breaks That Promise.

“Why does my site have HTTPS if the browser still says something is not secure?”

That question usually appears after a fast launch. The page has a certificate. The URL starts with https://. The padlock looked correct yesterday.

Then one old image, font, script, iframe, or form action quietly points to http://.

That is mixed content. It means the main page is encrypted, but part of the page still asks the browser to use an insecure connection. The result can be a browser warning, blocked content, broken styling, an unsafe form submission, or a page that feels less trustworthy than it looks.

This is especially common on AI-built, no-code, and vibe-coded websites. Templates, copied sections, old CMS records, embedded widgets, and database URLs can survive long after the site moves to HTTPS.

What mixed content does to your website

An HTTPS page should load its resources through HTTPS or through relative paths such as /images/logo.png.

These patterns create problems:

An image loads from http://cdn.example.com/photo.jpg
A font loads from http://fonts.example.com/font.woff2
A JavaScript file loads from http://old-domain.com/app.js
A form sends customer details to http://example.com/submit
An iframe or API request still uses http://
A database contains old image URLs from before the hosting move

Modern browsers treat active content such as scripts, fonts, stylesheets, fetch requests, and iframes aggressively. They can block it completely. Images and other passive content may be upgraded automatically, but that does not mean the original problem is fixed.

Depending on the browser and resource, visitors may see:

A Not secure warning
A changed or broken padlock state
Missing images or fonts
Broken buttons or page interactions
Console warnings
A form that fails to submit
A form that submits data over an insecure connection

The page may appear normal to you while failing for another visitor, browser, or network.

Why this affects security, SEO, and AEO

Security: HTTP is an opening

HTTP does not encrypt traffic. Someone positioned between the visitor and the server may be able to read or modify the request.

A changed image may mislead a visitor. A changed stylesheet may distort a page. A changed script can do much more damage, including altering forms or capturing information.

An insecure form action is particularly serious. If your page contains:

<form action="http://example.com/contact" method="post">

the page may look secure while the submitted name, email address, message, or other fields travel to an HTTP endpoint. Modern browsers may block the submission, but you should never rely on that protection. Fix the destination.

SEO: HTTPS is a baseline trust signal

HTTPS is a confirmed Google ranking signal and a basic expectation for a modern website. Mixed content does not automatically create a ranking penalty for every page, but it weakens the practical value of your HTTPS setup.

A warning can reduce trust. Blocked assets can damage usability. Broken scripts can stop navigation, forms, and content from working. Those problems can affect how people interact with your site and whether they return.

Treat mixed content as a technical SEO defect, not just a design issue.

AEO: answer engines need a reliable page

Answer engines and AI search systems need to crawl, render, understand, and assess your content. A page that fails to load important resources, displays warnings, or contains broken interactions gives weaker quality signals.

This does not mean fixing one image guarantees a citation. No website audit can guarantee that ChatGPT, Perplexity, Google AI Overviews, or another system will cite a page.

It does mean you should remove avoidable technical problems. A clean HTTPS page is a stronger foundation for traditional search and Answer Engine Optimization.

Find the problem without a developer

1. Check the padlock and console

Open the published page using its full HTTPS URL.

Click the padlock or site information icon. Look for security warnings. Then open browser DevTools:

Right-click the page and choose Inspect.
Open the Console tab.
Reload the page.
Search for Mixed Content, blocked, or insecure.
Open the Network tab and reload again.
Filter requests by http or inspect requests marked as blocked.

The console often identifies the exact file causing the issue.

2. Search the page source

Open the page source with:

view-source:https://yourdomain.com/page

Press Ctrl + F or Command + F and search for:

http://

Check every result. Focus on:

src
href
action
url()
srcset
data-src
Inline CSS
Embedded widgets
Font declarations

An HTTP link that simply points to another website is not always mixed content. An HTTP image, script, font, stylesheet, iframe, API request, or form action is more important.

3. Use the console to list insecure elements

You can paste this into DevTools Console:

[...document.querySelectorAll('[src], [href], [action]')]
  .map(el => ({
    tag: el.tagName,
    attribute: el.getAttribute('src') ||
               el.getAttribute('href') ||
               el.getAttribute('action')
  }))
  .filter(item => item.attribute && item.attribute.startsWith('http://'))

This lists common insecure references on the rendered page.

Also search the source and CSS files manually. A font inside an @font-face rule may not appear in the first console check.

Broken patterns versus correct patterns

❌ Broken pattern	✅ Correct pattern
`<img src="http://example.com/photo.jpg">`	`<img src="https://example.com/photo.jpg">`
`<script src="http://cdn.example.com/app.js">`	`<script src="https://cdn.example.com/app.js">`
`url(http://example.com/font.woff2)`	`url(https://example.com/font.woff2)`
`<form action="http://example.com/send">`	`<form action="https://example.com/send">`
`<img src="//cdn.example.com/photo.jpg">`	`<img src="https://cdn.example.com/photo.jpg">`
Old database URL: `http://oldsite.com/uploads/logo.png`	New secure URL: `https://newsite.com/uploads/logo.png`
Third-party script with no HTTPS endpoint	Remove it or replace it with an HTTPS-compatible service
Fix one page only	Search templates, CMS content, CSS, database fields, and embedded code

Protocol-relative URLs beginning with // usually follow the current page protocol. On an HTTPS page, they typically load over HTTPS. However, they are harder to audit and can become insecure if the same code runs on an HTTP page. Replace them with explicit HTTPS URLs or relative paths.

Your 10-minute mixed-content repair playbook

Follow this sequence after every launch, template change, or hosting move.

Open the live HTTPS page. Do not test only inside your site builder preview.
Reload with DevTools open. Read every mixed-content warning in the Console.
Inspect Network requests. Find blocked or downgraded files.
Search the page source for http://. Record each asset, form, and embedded URL.
Replace hardcoded HTTP asset URLs. Use https:// or a same-site relative path.
Fix protocol-relative URLs. Change //cdn.example.com/file to https://cdn.example.com/file.
Inspect every form. Change HTTP actions to HTTPS or use a relative action such as /contact.
Check your CMS or database. Search old image, file, and media URLs after any domain or hosting move.
Reload in a private window. Clear caching issues and confirm images, fonts, scripts, and forms work.
Test again on mobile. Check the padlock, console, form submission, and key interactions.

If an external resource does not support HTTPS, do not keep using it just because the page looks acceptable. Replace it, remove it, or host an equivalent file securely.

Do not forget old database URLs

A hosting move often changes the domain without changing every stored asset URL.

For example:

http://old-domain.com/uploads/hero.jpg

may remain inside:

CMS media fields
Blog content
Page builder blocks
Product descriptions
Theme settings
CSS files
Custom code snippets
Email or form integrations

Search your content database or builder for the old domain and http://. Replace each URL with the current HTTPS version. Then open pages that contain older images, forms, and downloads.

A global find-and-replace can save time, but create a backup first and review the results. Do not blindly replace every http:// string because some external links are intentional navigation links.

Final HTTPS checklist

Before you call the site finished, confirm:

✅ The page loads at https://
✅ The browser shows no mixed-content warning
✅ The Console contains no mixed-content errors
✅ Images use HTTPS or relative paths
✅ Fonts use HTTPS or relative paths
✅ Scripts and stylesheets use HTTPS
✅ Iframes and API requests use HTTPS
✅ Forms submit only to HTTPS endpoints
✅ Old domain and database URLs have been updated
✅ Third-party services support HTTPS
✅ The page works after cache clearing
✅ Key pages work on mobile
✅ The site has been checked after every major template or hosting change

A padlock is not proof that every line of a website is safe. It is a promise that the page and its important connections are protected. One forgotten HTTP reference can weaken that promise.

For a broader check, use the free SEO and AEO analyzer to review HTTPS and other ranking factors. Then visit the Free Tools page for the Meta Tag Generator, Schema Markup Generator, Robots.txt Generator, llms.txt Generator, and Search Console Regex Library.

You can also run the free Vulnerability Check for additional website security issues. Everything is free, with no login, email, or paywall required.

Frequently asked questions

Can one HTTP image really make an HTTPS page unsafe?

Yes. An HTTP image creates mixed content. Browsers may upgrade or block it, but the original insecure reference still needs to be fixed. Other resources, especially scripts, fonts, stylesheets, and forms, can create more serious failures.

Is mixed content a direct Google penalty?

Not every mixed-content issue causes a direct penalty. However, HTTPS is a ranking signal, and warnings, broken assets, failed forms, and poor user experience can weaken a page’s performance. Fix mixed content as part of technical SEO maintenance.

Are protocol-relative URLs safe?

On an HTTPS page, a URL beginning with // normally follows HTTPS. It is still better to use explicit HTTPS or a relative path because that makes the intended security level clear and prevents problems when the same code appears on an HTTP page.

Can an HTTP form action expose leads?

Yes. If a form submits to an HTTP endpoint and the browser allows the request, submitted data can travel without encryption. Change the action to an HTTPS endpoint or use a relative form action.