Mixed Content Errors After Installing Let's Encrypt: Causes and Fixes

Overview

Installing a certificate is only one part of moving a site to HTTPS. The certificate secures the connection between the browser and your server, but your pages also need to load every asset over HTTPS. If the HTML document is secure and one or more resources still load over plain HTTP, the browser flags the page as mixed content.

That is why a site can look “partly fixed” after SSL setup. You may have completed the certificate installation correctly and still end up with a broken layout, missing images, blocked scripts, or warnings in the browser console. In practical terms, mixed content errors usually mean one of five things:

• Your site still contains hard-coded http:// URLs in templates, posts, stylesheets, or configuration files.
• Your application still thinks the canonical site URL is HTTP instead of HTTPS.
• A proxy, CDN, or cache layer is serving old content.
• Third-party assets are requested over HTTP and the remote service does not support HTTPS.
• A redirect or server configuration is incomplete, so parts of the stack disagree about the correct scheme.

Browsers treat mixed content differently depending on the resource type. Insecure scripts, stylesheets, iframes, and XHR or fetch requests are commonly blocked because they can affect page behavior and security. Images, audio, or video may sometimes still load with warnings depending on browser behavior, but you should not rely on that. The durable fix is simple in principle: every page, asset, script, API call, and embedded resource should resolve over HTTPS.

For site owners, the most important point is this: mixed content is usually not a certificate problem. It is a content, configuration, or application path problem introduced during deployment, migration, theme changes, plugin updates, CDN changes, or copy-and-paste embeds. That distinction matters because many people start by reinstalling the certificate when they actually need to inspect URLs and responses.

If you are still completing the basic certificate setup, the supporting guides on Let's Encrypt on Ubuntu, Let's Encrypt for Nginx, and Let's Encrypt for Apache cover the server side. This article focuses on what happens after SSL is installed but the website is still not fully clean over HTTPS.

Topic map

This section gives you a practical map of where mixed content usually comes from and how to approach each source.

1. Start with the browser console

The fastest way to identify the issue is to open developer tools and reload the page. Mixed content messages usually tell you exactly which secure page tried to load which insecure resource. That message is often enough to classify the problem:

• Image URL over HTTP: usually content or media library data.
• Script or stylesheet over HTTP: theme, plugin, template, or third-party integration.
• XHR, fetch, or API endpoint over HTTP: JavaScript configuration, environment variables, reverse proxy headers, or application base URL settings.
• Iframe over HTTP: embedded forms, videos, maps, widgets, or legacy integrations.

Do not stop at the first warning. One insecure asset often points to a broader pattern in the codebase or CMS database.

2. Check whether the site URL is configured for HTTPS

Many mixed content issues happen because the application still generates absolute HTTP URLs. In WordPress, this usually means the site address or home URL is wrong, or content was imported before the HTTPS switch. In custom apps, the base URL may be stored in an environment file, application config, database setting, or framework-level URL helper.

Common places to inspect:

• CMS general settings
• Environment variables
• Framework config files
• Template helpers that build asset URLs
• Admin panels for e-commerce, forums, or static site generators

If your application thinks the site is HTTP, it will continue producing HTTP links even if the server has a valid certificate.

3. Audit hard-coded asset references

This is one of the most common causes after redesigns and site migrations. A theme file, page builder block, old blog post, CSS file, or navigation template may contain explicit http://example.com/... paths. Search your codebase and exported database content for http:// references, especially those pointing to your own domain.

Places where hard-coded insecure resources often hide:

• Header and footer templates
• Custom JavaScript snippets
• Inline CSS background images
• Theme options panels
• Widget HTML blocks
• Old landing pages
• Email signup forms and embedded scripts
• CDN or asset host settings

If the insecure URL belongs to your own site, the fix is usually straightforward: update the reference to HTTPS or use a relative or root-relative path where appropriate.

4. Review redirects and reverse proxy behavior

Some applications sit behind Cloudflare, a load balancer, a hosting proxy, or a container ingress. In those setups, the browser may connect over HTTPS while the origin application thinks the request is HTTP unless forwarded headers are handled correctly. The result can be mixed URLs generated by the app.

Look for these symptoms:

• The homepage loads over HTTPS, but some internal pages generate HTTP links.
• Admin pages or login forms redirect unexpectedly between HTTP and HTTPS.
• Asset URLs change scheme depending on cache state.
• The application works correctly when accessed directly on the origin but not behind a proxy.

If you use Cloudflare, review your SSL mode and origin setup carefully. The related guide on using Let's Encrypt with Cloudflare is useful when proxy settings complicate validation or HTTPS behavior.

5. Identify third-party resources that do not support HTTPS

Not every mixed content problem comes from your own server. Older ad tags, analytics snippets, embedded widgets, font hosts, tracking pixels, and media services may still call HTTP endpoints. If the third-party provider supports HTTPS, update the URL. If it does not, the practical choices are to remove the integration, replace the provider, or self-host the asset when licensing and maintenance make sense.

This is especially common after old CMS themes or purchased templates are reused. The page may contain legacy external calls that nobody noticed until HTTPS enforcement was enabled.

6. Purge caches before deciding a fix failed

Full-page caches, CDN caches, browser caches, and optimization plugins can all preserve insecure markup after you update settings. If you correct URLs and still see mixed content, clear the application cache, CDN cache, proxy cache, and browser cache before assuming the change did not work.

A reliable testing order is:

1. Open developer tools and disable cache for the session if available.
2. Purge server or application caches.
3. Purge CDN or edge caches.
4. Reload the affected page and review the console again.

Related subtopics

Mixed content is rarely isolated. It usually sits next to broader HTTPS and deployment issues. These adjacent topics are worth checking as part of a complete fix.

WordPress-specific mixed content

WordPress commonly stores absolute URLs in the database, so HTTPS transitions can leave old media, theme settings, and post content pointing to HTTP. A search-and-replace operation may be needed, but it should be done carefully and with a backup. Serialized data adds another layer of caution, which is why purpose-built tools are better than manual SQL edits in many cases.

Also inspect:

• siteurl and home values
• Theme customizer settings
• Page builder content blocks
• Plugin-generated assets
• Hard-coded links in menus or widgets

For a broader platform guide, see Let's Encrypt for WordPress.

Nginx and Apache HTTPS redirects

A clean redirect strategy matters because users, crawlers, and old bookmarks may still request HTTP URLs. Redirecting all HTTP traffic to HTTPS does not by itself solve mixed content inside the page, but it prevents duplicate scheme access and reduces the number of places where insecure links persist.

If redirects are incomplete, pages may be reachable over both protocols, causing confusion during testing. The server-specific setup guides for Nginx and Apache cover the underlying configuration patterns.

Certificate validity versus content errors

Users often describe any HTTPS problem as an SSL issue. In practice, a valid certificate, a broken redirect, and mixed content are separate layers. If the certificate is expired, missing, or misissued, fix that first. If the certificate is valid and the browser still warns only on certain pages or resources, mixed content becomes the likely path.

That is also why monitoring matters. Once the mixed content issue is fixed, certificate renewal should remain automatic and observable. See how to renew Let's Encrypt certificates automatically and Let's Encrypt expiry monitoring tools for the maintenance side.

Content Security Policy and upgrade strategies

For some sites, security headers can help control or expose mixed content more clearly. A Content Security Policy can block insecure requests or instruct browsers to upgrade some requests automatically. These controls can be useful, but they are not a substitute for fixing the underlying URLs. They work best after you understand what is loading and why.

Use these mechanisms as guardrails, not as a way to avoid cleaning up templates and application settings.

Migrations and staging-to-production mistakes

Mixed content often appears after moving a site from staging to production. The typical causes are copied database values, old environment variables, asset hosts from the previous environment, or search-and-replace jobs that missed one content area. If your site was recently migrated, review the migration checklist before you assume the SSL deployment caused the issue.

A useful habit is to crawl a staging copy over HTTPS before launch and check the console on key templates: homepage, article page, product page, form page, account page, and landing page.

Choosing infrastructure that makes HTTPS easier

Some hosting platforms make certificate provisioning, renewals, redirects, and proxy awareness much easier than others. While mixed content is usually an application issue, better hosting support can reduce the number of moving parts. If you are reassessing your stack, Best Hosting for Let's Encrypt Support is a useful companion read.

If you are deciding whether a free certificate is enough for your use case, Let's Encrypt vs Paid SSL Certificates provides the broader context. It will not fix mixed content directly, but it helps separate certificate choice from implementation quality.

How to use this hub

Use this article as a repeatable checklist rather than a one-time read. Mixed content tends to return when something changes: a new theme, plugin, CDN rule, embed code, or migration can quietly reintroduce HTTP resources.

Here is a practical workflow that works for most small to mid-sized sites:

1. Confirm the certificate is valid. Load the site in a private browser window and verify that the main document is served over HTTPS.
2. Open developer tools. Check the console and network panel for blocked or insecure requests.
3. Classify each insecure URL. Decide whether it is local content, application-generated output, a proxy issue, or a third-party dependency.
4. Fix the source, not just the symptom. Update application settings, templates, database values, or integrations rather than applying temporary patches everywhere.
5. Clear all caches. Purge CMS, server, CDN, and browser caches.
6. Retest important page types. Do not test only the homepage. Check posts, category pages, checkout or contact forms, admin logins, and any pages with embeds.
7. Add a post-change check. After future redesigns or plugin updates, review the console again before considering the job done.

If your site runs on a modern deployment workflow, consider adding HTTPS checks to routine QA. A lightweight approach is enough: load core templates, watch the console, and inspect the network panel for any http:// requests. On a static site or app with CI, you can also lint for insecure absolute URLs in templates and content exports.

One caution: browser extensions and local overrides can create false signals during testing. If an error appears inconsistent, test in a clean browser profile or incognito window before making production changes.

Another caution is the temptation to rely only on auto-fix plugins. Some tools can help rewrite URLs, especially in WordPress, but they can also mask the real source of the problem. As a rule, use them carefully and prefer durable fixes in settings, templates, and stored content wherever possible.

If you are still in the certificate setup phase, these additional guides may help complete the foundation before you troubleshoot content-level issues: Let's Encrypt on Ubuntu and Certbot alternatives.

When to revisit

Revisit this hub whenever the inputs that affect asset loading change. Mixed content is not a problem you fix once forever. It is a class of issue that reappears when websites evolve.

The most common times to run through this checklist again are:

• After a site redesign or theme replacement
• After a CMS migration or domain change
• After moving from shared hosting to VPS or cloud hosting
• After enabling or reconfiguring Cloudflare or another CDN
• After adding marketing scripts, embeds, widgets, or third-party forms
• After changing image optimization, asset hosting, or caching plugins
• After restoring from backup or cloning staging to production
• After updating URL settings in a framework or admin panel

For the next time mixed content appears, keep a short action plan:

1. Inspect the console.
2. List every insecure URL.
3. Group them by source: local, generated, cached, proxied, or third-party.
4. Fix the generating source.
5. Purge caches.
6. Retest core page types.
7. Document what caused it so the same pattern is easier to catch later.

That last step matters more than it seems. A brief internal note such as “old page builder blocks stored absolute HTTP image paths” or “proxy headers were missing after load balancer change” can save hours during future migrations.

In short, if your site says “after installing SSL website broken,” do not assume the certificate failed. More often, HTTPS mixed content means the secure page is still pulling insecure resources from somewhere in your stack. Once you learn how to trace those requests back to their source, the fix becomes methodical instead of frustrating.