WordPress Says Not Secure After SSL? Fix Mixed Content

SSL is installed, but WordPress still looks insecure

A WordPress mixed content warning can appear after you install SSL, move a site, change domains, enable Cloudflare, or replace an old theme. The page opens with https://, yet the browser still reports an insecure connection. Images, fonts, forms, or page-builder styling may also disappear.

The important first step is to identify the warning correctly. A certificate problem and a mixed content problem can look similar to a site owner, but they need different fixes. Changing WordPress URLs or running a database replacement before you know which one you have can create redirect loops, broken links, or an inaccessible dashboard.

This guide gives you a safe diagnosis order. It shows what you can check without changing the live site, how to locate the old HTTP request, and when the repair needs a backup, staging copy, or developer.

First, identify which security problem you have

If the browser blocks the entire visit, do not start with a mixed content plugin. Fix the certificate, DNS, or hosting issue first. Mixed content diagnosis starts when the main document already loads over HTTPS but one or more resources do not.

What mixed content means on a WordPress site

A secure page becomes mixed when its HTML arrives over HTTPS but requests another resource over plain HTTP. That resource could be an image in an old post, a font in generated CSS, a script added by a plugin, a video embed, a form endpoint, or a hardcoded theme asset.

Browsers treat resource types differently. Some requests may be upgraded automatically, while riskier requests can be blocked. The result is not always a visible warning alone. A blocked stylesheet can make a page look unformatted, a blocked script can stop a menu or form, and a missing font or image can create layout movement.

Mozilla’s mixed content explanation distinguishes content that browsers can upgrade from content they block. Cloudflare also documents how mixed content can appear after HTTPS or proxy changes. These references help explain the browser behavior, but the actual repair still depends on where WordPress stored or generated the old URL.

A safe 15-minute diagnostic order

1. Check the exact public URL and certificate

Open the affected URL directly, including its www or non-www form. Confirm the final address begins with HTTPS and does not bounce between domains. Then use the browser’s site or connection details to inspect the certificate.

The certificate should cover the final hostname and remain within its valid dates. If the certificate is wrong, expired, or missing, stop here. WordPress content changes will not repair a certificate issued for another domain.

2. Reload with the browser console open

Open the browser’s developer tools, select the Console, and reload the page. Search for messages containing Mixed Content or an http:// resource. Record the complete affected URL and its type: image, font, stylesheet, script, frame, or form action.

Do not install a repair plugin before capturing this evidence. A temporary rewrite can hide the original source while leaving the old value in the database, theme, or third-party service.

3. Decide whether the problem affects one page or the whole site

Check the home page, one ordinary blog post, and one important form or sales page. When only one page fails, inspect that page’s content, featured image, page-builder widgets, and assigned template first. When every page fails, inspect global settings, headers, footers, fonts, theme files, and CDN or proxy configuration.

This distinction prevents a risky site-wide database replacement for a URL that exists in only one widget.

4. Inspect WordPress Address and Site Address

In WordPress, open Settings > General and check both address fields. They should represent the intended public HTTPS installation. Some hosts or managed setups lock these values in configuration, so do not force a change when the fields are unavailable or when you are unsure how the site is routed.

WordPress documents the implications of changing a site URL during a migration. An incorrect change can disconnect media, alter serialized settings, or block dashboard access. Capture the current values before editing them.

5. Search page source and generated CSS

View the public page source and search for the insecure hostname or http://. If the URL appears in HTML, it may come from post content, a widget, a custom field, a template, or a plugin setting. If it appears only in a stylesheet, check page-builder CSS, theme options, local font declarations, or an optimization plugin’s generated files.

When the page source already contains HTTPS but visitors still receive old HTTP links, compare a private window and a harmless cache-busted query. The Webless guide to WordPress changes not showing explains how to separate current origin content from a stale page, host, or CDN copy.

Fix the source, not only the warning

An old URL is stored in one page or widget

Edit that page, reusable block, header, footer, popup, or template and replace the old resource with its verified HTTPS version. Save the correct content record, purge only the affected page, and retest anonymously.

If the remote service does not support HTTPS, remove or replace it. Do not assume that adding an s creates a working secure resource.

Old HTTP URLs are stored across the database

A migration can leave the previous HTTP domain in posts, metadata, widgets, and builder settings. Before a broad replacement, create a current backup and prove it can be restored. A completed backup notification is not enough; a WordPress backup restore test confirms that both files and database can rebuild.

Use a serialization-aware WordPress tool and run a dry test first. WP-CLI’s official search-replace command supports a dry-run option and handles serialized data. Review the affected tables and replacement count before applying anything. Exclude GUID changes unless a migration specialist has a specific reason to include them.

A page builder or performance plugin generated old files

Use the builder’s supported action to regenerate CSS or data after correcting the source URL. Then purge the affected page and optimized assets. Avoid deleting random files from the uploads directory or clearing every cache before the origin version is correct.

If a cache-busted page works but the clean URL does not, purge in a controlled order: page or object layer when relevant, optimization cache and preload, then CDN. Retest after each meaningful layer so you know which one held the stale response.

A theme or plugin hardcodes the HTTP resource

Update the component when its vendor has fixed the URL. For custom code, change the source in a child theme or maintained custom plugin rather than editing WordPress core or a vendor file that the next update will overwrite.

When you cannot identify the code owner, record the resource URL and the file or response that requested it. That is enough evidence for a developer to trace the enqueue, template, shortcode, or API response without guessing.

Cloudflare or another proxy sits in front of WordPress

Confirm that the origin supports HTTPS and that WordPress recognizes secure requests through the proxy. Automatic HTTPS rewriting can help with compatible asset URLs, but it cannot create an HTTPS version on a server that does not offer one. It also should not replace correcting URLs you control.

Do not stack multiple force-HTTPS plugins, host redirects, CDN rules, and custom server redirects without mapping which layer owns the redirect. Competing rules can produce loops or make the dashboard unreachable.

Stop before the SSL repair creates a bigger outage

Pause the DIY work when any of these conditions appears:

• The browser blocks the whole site because the certificate is invalid or does not match the domain.
• Changing either WordPress address logs you out, creates a redirect loop, or removes dashboard access.
• The required replacement affects serialized builder data, multisite, multilingual content, orders, subscriptions, or custom tables.
• The insecure resource is a payment, login, form, analytics, or customer-data endpoint.
• You cannot create and verify a rollback before changing the database or server configuration.
• Different visitors receive different security behavior after cache or proxy changes.

At that point, collect the affected URL, browser message, insecure resource URLs, certificate hostname, recent migration or plugin changes, and the result from a private window. This evidence shortens the repair and reduces the risk of another change masking the cause.

Verify the repair beyond the home page

After correcting the source, test more than the page where you first noticed the warning:

1. Open the clean URL in a private window and confirm the final hostname and HTTPS address.
2. Reload with the Console open and confirm the recorded mixed content requests are gone.
3. Check the home page, a blog post, a form, and an important sales or checkout page.
4. Test both desktop and mobile layouts for missing fonts, images, menus, and scripts.
5. Compare a normal request with a cache-busted request after caches finish rebuilding.
6. Submit a form or test another affected function without using real customer data.

A clean browser icon is useful, but functionality matters too. A blanket rewrite can remove the visible warning while still breaking a script or sending a form to the wrong endpoint.

Prevent mixed content after the next migration

Use HTTPS on staging and production, avoid hardcoded domains in themes, and keep a migration checklist that covers serialized data, generated CSS, CDN configuration, redirects, and cache purge. Test a small set of representative pages after every domain, SSL, proxy, or deployment change.

Ongoing WordPress maintenance can combine update checks, backup verification, public-page testing, and cache review. When the cause sits in a custom template, plugin, API, proxy, or deployment path, WordPress development support is the safer route because the repair needs ownership tracing rather than another temporary plugin.

The practical answer

If WordPress still says Not Secure after SSL, first separate a certificate failure from a mixed content warning. When the main page loads over HTTPS, use the browser console to identify the exact HTTP resource. Then decide whether it comes from one page, the database, generated CSS, a component, or the CDN path.

Fix the original source, purge only after the origin is correct, and verify important pages and functions as an anonymous visitor. If the repair requires a database replacement, redirect changes, custom code, or work on a live sales site, send Webless the URL and warning evidence. We can trace the insecure request and repair it without turning an SSL warning into downtime.