How to Fix Mixed Content After Enabling SSL

After enabling SSL, it is common for a website to stay partly loaded over HTTP instead of HTTPS. This usually creates browser warnings such as “mixed content,” broken padlock icons, missing images, blocked scripts, or layout problems. In a hosting or control panel environment such as Plesk, the issue is usually not the certificate itself, but the fact that some page resources still point to the old non-secure address.

Mixed content happens when the main page is loaded securely over HTTPS, but some files are still requested over HTTP. Modern browsers may block these files or reduce the security level of the page. For website owners, this often appears right after SSL activation, a migration, a cache reset, or a cleanup after a hacked website. The good news is that in most cases the issue can be fixed by updating URLs, adjusting application settings, and clearing cached references.

What mixed content means after SSL is enabled

When SSL is active, the browser expects every resource on the page to be delivered through HTTPS. If any element still loads through HTTP, the browser treats it as mixed content. There are two common types:

  • Passive mixed content - images, videos, audio files, and some downloadable resources. These may display warnings or be blocked in some browsers.
  • Active mixed content - JavaScript, CSS, fonts, AJAX calls, frames, and form actions. These are much more serious because they can change how the page behaves or expose sensitive data.

For hosting users, the issue often comes from old links stored inside the site database, hardcoded URLs in theme files, or settings that were not updated after SSL was turned on. In managed hosting environments, this can also happen after moving a site to a new domain, restoring a backup, or cleaning up malicious code.

Common signs of mixed content problems

You may be dealing with mixed content if you notice one or more of the following:

  • The padlock in the browser is missing, grey, or shows a warning.
  • Some images, icons, or fonts do not appear.
  • JavaScript features stop working after SSL is enabled.
  • Forms, sliders, popups, or menus behave incorrectly.
  • The browser console shows “mixed content” warnings.
  • Some pages redirect to HTTPS, but specific pages or assets still use HTTP.

If the issue appeared right after SSL activation, the cause is often a site-wide URL mismatch rather than a server-level problem.

Why mixed content appears on hosting platforms

There are several typical reasons for mixed content in a hosting and control panel setup:

Old absolute URLs in site content

Many websites store full URLs in the database, for example http://example.com/image.jpg. After SSL is enabled, those entries still point to HTTP until they are updated.

Theme, plugin, or template files

Some CMS themes and plugins contain hardcoded references to HTTP resources in CSS, JavaScript, or image paths.

Incorrect base URL or site address settings

Applications such as WordPress, Joomla, Drupal, and other CMS platforms often have a primary site URL setting. If this still uses HTTP, internal links may continue to generate insecure addresses.

CDN or external asset references

If the website loads fonts, scripts, analytics files, or widgets from third-party services over HTTP, the browser may block them even if your own server is configured correctly.

Cached pages and browser cache

After a migration or SSL change, cached versions of pages may still contain old HTTP links. This can happen in application cache, server cache, CDN cache, or the visitor’s browser.

Cleanup after malware or hacked website incidents

When a site has been compromised, malicious code may inject insecure redirects, external scripts, or invisible content. After cleanup, some old references may remain in files or database records and still trigger mixed content warnings.

How to fix mixed content after enabling SSL

The best approach is to work from the most common causes first. Start with the website settings, then update content URLs, then check files and cache. If you use a control panel such as Plesk, you can complete many of these steps without direct server access.

1. Confirm that SSL is installed and the site loads over HTTPS

Open the website using https:// and verify that the certificate is valid. If the certificate is missing, expired, or installed for the wrong hostname, mixed content is not the main issue yet. Fix the SSL installation first.

In a hosting panel, check that:

  • The certificate is assigned to the correct domain and subdomain.
  • The site is accessible on port 443.
  • There are no certificate chain errors.
  • Redirection from HTTP to HTTPS is enabled only after the certificate is working properly.

2. Update the site URL in the application settings

Make sure the website’s main address uses HTTPS. This is important because many CMS platforms generate internal links based on the configured base URL.

Examples of settings to review:

  • WordPress: WordPress Address (URL) and Site Address (URL)
  • Joomla: global configuration site URL and SSL-related settings
  • Drupal or custom applications: base URL, trusted host configuration, or environment variables

If the application still thinks the site uses HTTP, it may continue to print insecure links in menus, media, and templates.

3. Replace old HTTP links in content and the database

This is one of the most effective fixes. Search for http:// references inside posts, pages, product descriptions, widgets, and custom fields. Replace them with https://.

In many CMS platforms, a search-and-replace tool or migration plugin can update database records safely. Be careful with serialized data if your application stores settings in a special format. A simple find-and-replace in raw database tables can break the site if done incorrectly.

Focus on these content areas:

  • Page content and blog posts
  • Menus and navigation links
  • Widget text blocks
  • Footer and header content
  • Product images and media attachments
  • Custom field values

4. Check theme and template files for hardcoded HTTP references

Look inside the theme, template, and custom code files for references to insecure URLs. Common files include CSS, JavaScript, header templates, and footer templates.

Search for:

  • http://yourdomain.example
  • http:// external assets
  • Absolute links to images, fonts, or scripts

If possible, use protocol-relative or HTTPS-only URLs for local assets. For external services, verify that the provider supports HTTPS. If not, replace the resource or host it locally on your own server.

5. Review plugins, modules, and third-party integrations

Mixed content often comes from plugins or add-ons that insert their own scripts. Analytics tools, chat widgets, payment modules, font loaders, embedded maps, and social media widgets are frequent sources.

Disable suspicious plugins one by one if you cannot identify the source. After each change, clear cache and reload the page in a private browser window. When the warning disappears, you have found the component that needs an HTTPS update.

6. Fix redirects and canonical URLs

Ensure that all HTTP requests are redirected to HTTPS consistently. However, do not rely on redirects alone to solve mixed content. The browser may still request insecure resources if the page source contains HTTP links.

Also verify:

  • Canonical tags use HTTPS
  • Open Graph and social metadata use HTTPS
  • Sitemap URLs use HTTPS
  • Internal links in structured data use HTTPS

These details are important for both browser security and SEO.

7. Clear caches at every layer

After updating URLs, clear all caches so the browser and server stop serving old versions of the page.

Check the following cache layers:

  • CMS cache
  • Plugin cache
  • Server cache
  • CDN cache
  • Browser cache

If your hosting platform includes a cache manager, flush it after the HTTPS changes. If you use a reverse proxy or external CDN, purge that as well. Then test in an incognito window or another browser.

8. Use developer tools to find the exact insecure resource

Open the browser developer console and reload the page. Mixed content warnings usually list the exact file that is still loaded over HTTP. This is the fastest way to identify the source when the issue is not obvious.

Look for:

  • Stylesheets loaded over HTTP
  • JavaScript files loaded over HTTP
  • Images inserted with hardcoded HTTP paths
  • Font files blocked by the browser
  • AJAX requests sent to old HTTP endpoints

Once you know the exact URL, you can trace it back to content, a plugin, a template file, or a configuration value.

How to fix mixed content in Plesk or similar hosting control panels

In Plesk and similar environments, a lot of the cleanup can be done from the control panel or with file manager access.

Update the domain’s preferred address

Check that the domain is configured to use HTTPS as the primary URL in the application settings. If the control panel offers SSL/TLS settings, make sure the certificate is assigned and the site is allowed to use secure connections.

Check file manager and application files

You can inspect theme files, configuration files, and uploaded content for absolute HTTP links. If SSH access is available, use it to search the document root efficiently. If not, use the file manager and application editor tools provided by the panel.

Confirm redirection rules

If you use Apache or a web server rule set, confirm that the HTTP to HTTPS redirect is correct and does not create loops. A typical setup should redirect visitors smoothly to the secure version while leaving internal resource links unchanged only if they already use HTTPS.

Review security and cleanup results after malware removal

If the website was recently cleaned after a compromise, verify that no injected JavaScript or hidden iframes remain. Hacked sites can continue to load insecure external resources even after obvious malware is removed. A full scan of templates, uploads, and database content is recommended.

Example fixes for common website types

WordPress

  • Update the site URL to HTTPS in general settings.
  • Replace old HTTP links in posts and pages.
  • Check theme header, footer, and custom CSS/JS.
  • Review plugin settings for external scripts and embeds.
  • Clear cache from caching plugins and any server cache.

Custom PHP application

  • Update configuration files where the base URL is defined.
  • Search templates for hardcoded HTTP references.
  • Verify asset loading paths in JavaScript and CSS.
  • Check database records for stored links.

Joomla or similar CMS platforms

  • Review global configuration and SSL-related settings.
  • Update menu items, module content, and media references.
  • Check templates and extensions for insecure assets.
  • Clear application and browser cache after changes.

How to prevent mixed content from coming back

Once the issue is resolved, a few preventive steps can help avoid a repeat problem after future updates, migrations, or SSL renewals:

  • Always use HTTPS when adding new internal links.
  • Prefer relative or HTTPS-only asset URLs in templates.
  • Review third-party scripts before installing them.
  • Keep CMS core, plugins, and themes updated.
  • Test the site after migrations, backups, and restores.
  • Check the browser console when adding new features.
  • Re-run a site-wide search for HTTP references after major content changes.

For hosted websites, it is also a good practice to include HTTPS checks in your deployment or maintenance routine. This is especially useful if multiple people edit the site or if external agencies manage parts of the design.

When the problem is not mixed content

Sometimes the symptoms look similar, but the real issue is different. For example:

  • The SSL certificate is expired or not installed correctly.
  • The domain points to the wrong virtual host or document root.
  • A redirect rule is forcing a loop between HTTP and HTTPS.
  • The browser cache is showing an old version of the page.
  • A security plugin is blocking scripts or assets.
  • Malware has altered page output or injected redirects.

If you have already updated all links and the browser still reports mixed content, inspect the site source and console output carefully. The browser error usually identifies the exact file or request causing the issue.

FAQ

Why does my site still show a warning after SSL is enabled?

Because SSL only secures the connection to the page itself. If the page loads images, scripts, styles, fonts, or other files over HTTP, the browser will still warn about mixed content.

Can mixed content affect SEO?

Yes. While the effect is usually indirect, mixed content can hurt user trust, reduce page performance, and cause browsers to mark the site as not fully secure. Search engines also expect clean HTTPS implementation.

Is it enough to redirect HTTP to HTTPS?

No. Redirects help visitors reach the secure version, but embedded resources inside the page must also be updated to HTTPS. Otherwise the browser will continue to request insecure files.

Should I use search and replace in the database?

Yes, but only with a tool that understands your application’s data format. If your CMS uses serialized or structured data, a basic raw database replace can break settings or page content.

What if the mixed content comes from a third-party service?

Check whether the service offers HTTPS. If it does not, try to replace it with a secure alternative or host the resource locally. Browsers are increasingly strict about blocking insecure external content.

Can a hacked website cause mixed content warnings?

Yes. Malware can inject insecure scripts, hidden iframes, or external assets. After cleaning a hacked site, review files, templates, and the database to remove remaining HTTP references.

Conclusion

Mixed content after enabling SSL usually means the website is partly updated, not fully migrated to HTTPS. The fix is to make every resource match the secure version of the site: update application settings, replace old HTTP links, inspect templates and plugins, clean cache, and verify that no malicious or outdated references remain. In a hosting control panel environment, this process is often straightforward once you identify the exact file or setting that still points to HTTP.

If the problem persists after these checks, review the browser console, application logs, and recent changes such as migrations, restores, plugin updates, or malware cleanup. A careful HTTPS cleanup usually restores the secure padlock, removes browser warnings, and brings the website fully in line with modern security requirements.

  • 0 Users Found This Useful
Was this answer helpful?