A mixed content warning means the page loads over HTTPS, but at least one image, script, stylesheet, font, iframe, or tracking URL still uses http://. The safest fix is to identify the exact insecure URL first, then correct it where it is stored: WordPress settings, the editor, a page builder, a plugin setting, a CDN rule, theme code, or the database.
Do not start with a broad search-and-replace. One old logo URL in a widget does not need the same repair as thousands of old image URLs left behind after an HTTPS migration.
Confirm the site URL uses HTTPS
In the WordPress dashboard, go to Settings > General.
Check both fields:
- WordPress Address (URL)
- Site Address (URL)
Both should start with https://.
If either field still uses http://, change it to the correct HTTPS address only if the SSL certificate is already working. Save the change, then sign back in if WordPress asks you to. WordPress documents HTTPS configuration in its guide to Administration Over SSL.
If the fields are greyed out, they may be defined in wp-config.php. In that case, use your hosting file manager, SFTP, or ask your host to check whether WP_HOME or WP_SITEURL still contains the old HTTP address.
Find the insecure URL
Open the affected page in your browser and use the developer console.
In Chrome or Edge, right-click the page, choose Inspect, then open the Console tab. Firefox and Safari have similar developer tools. Reload the page and look for a mixed content message. The warning usually names the insecure URL.
It may be something like:
http://example.com/wp-content/uploads/old-image.jpgor an external URL from a script, iframe, font, ad network, analytics tool, or embedded media provider.
Keep that exact URL visible while you troubleshoot. It tells you where to look next.
Fix editable content first
If the insecure URL points to an image, button, background, or link you can edit in WordPress, update it there.
Check the most common places:
- The post or page editor
- Featured images and image blocks
- Page builder modules
- Header and footer builders
- Custom HTML blocks
- Widgets
- Navigation menus
- Reusable blocks or synced patterns
- Theme options for logos, icons, and backgrounds
Change the URL from http:// to https://, or reselect the image from the Media Library so WordPress saves the current secure URL.
For a small number of mixed content warnings, this is usually better than touching the database.
Check plugin, theme, CDN, and cache settings
If the insecure URL does not appear in the page editor, check the feature that outputs it.
A form plugin, slider, analytics plugin, ad plugin, cookie banner, popup builder, or social embed plugin may store its own asset or endpoint URL. Open the plugin settings and look for fields that still contain http://.
If the URL comes from a theme option, check Appearance > Customize, the theme settings panel, or the site editor, depending on your theme.
If you use a CDN, reverse proxy, or security service, confirm that it is set to serve assets over HTTPS. Also check cache plugin settings for old CDN URLs or hard-coded asset domains.
After changing a plugin, theme, or CDN setting, clear that tool’s cache before testing again.
Fix hard-coded URLs in theme or plugin files
If the insecure URL is coming from a child theme or custom plugin, update the code instead of masking the warning with a plugin.
Look for manually printed tags such as:
<script src="http://example.com/script.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">
<img src="http://example.com/image.jpg" alt="">Use HTTPS URLs, protocol-relative URLs only when appropriate, or WordPress functions that generate the correct URL. For enqueued assets, WordPress provides wp_enqueue_script() and wp_enqueue_style().
Before editing theme or plugin files, download a copy or use version control if available. A small typo in PHP can break the site.
Use database replacement only for widespread old site URLs
A database replacement makes sense when the site was moved from http://example.com to https://example.com and old internal URLs remain across many posts, pages, options, or metadata records.
Back up the database first from your hosting panel or backup plugin. Then use a trusted search-and-replace tool that supports serialized WordPress data. Many hosts provide this in their control panel, and some WordPress migration plugins include a safe replacement feature.
Search only for the old full site URL, such as:
http://example.comReplace it with the matching HTTPS URL:
https://example.comDo not replace every http:// string with https://. That can damage external links, webhook URLs, old embeds, tracking URLs, or plugin settings that should not be changed.
Review the results carefully before applying the change. Stop if the tool shows unexpected domains, unrelated tables, or replacement counts that do not match the size of the site.
Optional WP-CLI check for SSH users
If you have SSH access and are comfortable with WP-CLI, you can run a dry run before making a database replacement:
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-runReview the tables and replacement counts. If they match the HTTPS migration you intend to make, run the same command without --dry-run:
wp search-replace 'http://example.com' 'https://example.com' --all-tablesWP-CLI’s official search-replace documentation explains dry runs, table selection, and other options. Use this method only after a current database backup.
Clear caches and test again
After fixing the source, clear every cache layer that could still serve the old page or asset URL:
- WordPress cache plugin
- Page builder cache
- Object cache
- Hosting cache
- CDN cache
- Browser cache
Open the affected page in a private window and check the browser console again. The warning is fixed when the page no longer requests assets from http://.
When to ask for help
Contact your host or developer if the insecure URL is injected by a reverse proxy, load balancer, managed CDN, security plugin, or server rule you cannot edit.
Also pause before changing the database if the search results include unexpected tables, unusually high replacement counts, or URLs outside the domain you meant to migrate.