To fix WordPress mixed content errors, find the insecure HTTP requests, update their source URLs, and clear every caching layer. Installing an SSL certificate secures HTTPS connections, but it doesn’t rewrite old links in your content, settings, or theme files.
You usually don’t need another certificate. You need to locate the original HTTP reference and correct it. Start with the browser’s error message before changing WordPress settings.
Key Takeaways
- Copy the exact insecure URL from your browser’s developer tools before choosing a fix.
- Back up your site before replacing database URLs, and use a tool that handles serialized data safely.
- HTTPS redirects and fixer plugins can help, but stored URLs, generated files, and caches may still need attention.
Why Mixed Content Appears After SSL Installation
Mixed content occurs when your HTTPS page requests a resource over HTTP. Your page connection is encrypted, but that resource’s connection isn’t.
Browsers block active mixed content, including scripts, stylesheets, iframes, fonts, and AJAX requests. Insecure form submissions can also trigger warnings or blocking.
Images, audio, and video receive different treatment. Modern browsers automatically upgrade many requests to HTTPS, then block them if the secure version fails. Older browsers may display insecure images with warnings. MDN’s mixed content documentation explains these browser behaviors.
Your certificate can therefore work correctly while parts of your page remain broken.
1. Find the Exact Insecure URL
Inspect the Console and Network tabs
Open the affected HTTPS page, right-click, choose Inspect, and select Console. Refresh the page, then find messages mentioning “Mixed Content” or an insecure resource.
Copy the complete http:// address, including its path. Record the affected page too.
If the message is vague, open Network, refresh again, and inspect failed or blocked requests. The Initiator column can identify the stylesheet or script responsible. Google’s mixed content guidance provides further browser troubleshooting context.
Why No Padlock can also scan a public page for insecure resources. Its yellow warnings indicate insecure content affecting the padlock; red warnings identify blocked content. Browser security indicators vary, so use the reported URLs as your evidence.
Test HTTPS and identify the source
Paste the resource URL into a new tab and change only http:// to https://.
If it loads, update its original reference. If HTTPS fails, replace or remove the resource, or choose a secure provider. Don’t disable browser protection.
Use the request path to narrow your next step:
| Request points to | Start with |
|---|---|
| Your uploads directory | Content and database URLs |
| Builder-generated CSS | Builder settings and regenerated files |
| An external domain | Embed code or provider |
| A CDN hostname | CDN URL and TLS settings |
The hostname and path usually tell you where to investigate first.
2. Update Your WordPress Site Addresses
Go to Settings > General. Both WordPress Address (URL) and Site Address (URL) should use https://.
Keep the correct hostname, including your chosen www or non-www version. Preserve any intentional installation subdirectory. The two fields don’t always have identical paths.
Save your changes and sign in again if prompted. However, changing these fields doesn’t replace old URLs inside existing content.
If the fields are locked, WP_HOME or WP_SITEURL may define them in wp-config.php. Our WordPress configuration guide explains how those settings work. Back up the file before editing it.
3. Replace Stored HTTP URLs Safely
Back up before changing the database
Take a full backup of your database and WordPress files before running a database search and replace operation. Keep a downloadable copy outside your hosting account.
Then match the exact old site address, such as http://example.com, with its HTTPS replacement, https://example.com. Don’t replace every occurrence of http:// indiscriminately. External addresses may require different fixes.
Avoid raw SQL replacement across WordPress settings. Plugins and builders often store serialized data, which includes string-length information. An ordinary replacement can corrupt those values.
Leave post GUIDs unchanged during the migration.
Use Better Search Replace or WP-CLI
With Better Search Replace, enter the old and new URLs, select this site’s relevant tables, and run a dry run first. Review the affected tables before applying changes. Keep GUID replacement disabled.
With SSH access, export your database using wp db export, then preview:
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
After reviewing the results, run the same command without --dry-run.
The official WP-CLI search-replace documentation confirms that the command handles PHP serialized data. Its dry-run option previews changes without writing them.
4. Repair Builder Output and Hard-Coded Links
Fix generated page-builder resources
If a background image in a page builder such as Elementor still requests HTTP, inspect its initiating stylesheet. A corrected database can coexist with an old generated CSS file.
Use Elementor’s URL replacement tool when needed, then run its CSS/data regeneration or cache-clearing tool. Re-save the affected page and inspect the request again.
Also look for malformed schemes such as httpss://. These are URL typos, rather than ordinary mixed content. Auto-generated image URLs from block plugins, including Spectra, can contain such mistakes.
Correct the originating block setting, plugin configuration, or copied embed code. Repeated database replacement won’t help if the plugin keeps generating the wrong address.
Fix theme files, CSS, and embeds
Search custom code for the exact failing hostname. Hardcoded HTTP references can appear in header.php, footer.php, functions.php, or custom CSS background declarations.
For custom scripts and styles, use wp_enqueue_script() and wp_enqueue_style() with HTTPS URLs. Protocol-relative // addresses inherit the page protocol, but explicit HTTPS is clearer.
Keep theme customizations in a child theme so updates don’t overwrite them. For plugin files, prefer a setting or maintained update over a direct edit.
External maps, videos, and widgets need secure embed URLs too. Our WordPress iframe troubleshooting guide covers blocked embeds. If the source supports only HTTP, remove it or choose another service.
5. Use a Mixed Content Plugin for Temporary Relief
Really Simple SSL, now called Really Simple Security, and SSL Insecure Content Fixer can rewrite insecure URLs while WordPress generates a page.
This helps when your own resources already work over HTTPS. However, these plugins don’t necessarily repair the database or every dynamically generated request.
For SSL Insecure Content Fixer, open Settings > SSL Insecure Content. Start with Simple. If warnings remain, test stronger levels, including Capture, and retest forms and interactive features.
A database replacement repairs stored references. A fixer plugin changes output. A server redirect routes incoming requests. Choose the method that matches the source.
Once you’ve repaired the underlying URLs, disable temporary rewriting and retest before removing the plugin.
6. Check CDN and Server HTTPS Settings
Check the resource’s CDN address
If the failing hostname belongs to your CDN, open that exact resource over HTTPS. Your main site’s certificate doesn’t automatically cover a separate CDN hostname.
Update the CDN asset URL in your caching or CDN plugin. Confirm that its HTTPS response loads successfully, then purge that cache.
Behind a reverse proxy, WordPress also needs to recognize the visitor’s original HTTPS connection. Incorrect forwarded-protocol handling can generate HTTP URLs even when visitors use HTTPS.
Keep one HTTPS redirect system
An HTTP-to-HTTPS redirect is useful, but it doesn’t remove insecure references from your pages.
On a direct Apache setup, a typical rule uses RewriteCond %{HTTPS} off with a 301 rule such as RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L].
Back up .htaccess first and keep custom rules outside WordPress’s generated markers. Our WordPress .htaccess guide includes redirect guidance.
Don’t stack host, CDN, and plugin HTTPS redirects. Proxy setups need appropriate conditions; otherwise, redirect loops can result.
7. Clear Caches and Retest the Original Failure
After correcting the source, purge your WordPress caching plugin, host cache, and CDN cache. Also clear generated or combined CSS and JavaScript files.
Then clear your browser cache and open a fresh incognito window. For closer testing, keep DevTools open and enable Disable cache in Network.
Repeat the original failing action. Test the affected page, another content page, login, and any forms or checkout flows. Scroll down to trigger lazy-loaded resources.
If a deleted resource is still requested, inspect Initiator again. A cached stylesheet, saved block, or script may still reference it.
Clearing caches removes old output. It can’t repair an HTTP URL that your theme or plugin generates again.
8. Add HTTPS Safeguards After Cleanup
The response header Content-Security-Policy: upgrade-insecure-requests tells browsers to upgrade insecure resource requests. It can provide a safety net for missed URLs.
However, the upgraded request still fails if the destination doesn’t support HTTPS. MDN’s upgrade-insecure-requests reference explains this behavior.
HSTS tells browsers to use HTTPS for future connections. A policy such as Strict-Transport-Security: max-age=31536000; includeSubDomains; preload requires care: every covered subdomain must support HTTPS.
The preload token doesn’t automatically add your domain to browser preload lists. Neither HSTS nor CSP rewrites database URLs. Apply these safeguards after cleanup, not as substitutes for it.
Frequently Asked Questions
Why does your site still say “Not Secure”?
Your page may contain mixed content, but certificate problems can produce security warnings too. An expired certificate, hostname mismatch, or incomplete certificate chain requires a separate fix.
Check the browser’s security details and Console rather than assuming every warning has the same cause.
Can visitors fix WordPress mixed content errors?
As a visitor, you can reload the page, try a private window, and report the affected page and Console message.
You can’t repair the site’s database, theme, or CDN configuration. Don’t enable insecure content or bypass certificate warnings to use a form. Those changes weaken your protection.
Keep the Fix at the Source
A lasting WordPress mixed content fix starts with the exact insecure request. Correct its source, regenerate affected files, and clear the caches that preserve old output.
Keep a recoverable backup before bulk edits. Then repeat the original failure test so you know the page works without temporary rewriting or disabled browser protection.
