Installing an SSL certificate secures the connection between a visitor’s browser and your WordPress site, but it does not update every URL stored in WordPress. Older images, scripts, stylesheets, fonts, embeds, or background images may still load over http://. When that happens, browsers can display mixed content warnings or block resources altogether.
The result may be a broken layout, missing icons, JavaScript errors, or problems with forms and checkout. This guide covers a careful fix: update the site URLs, replace old links safely, identify remaining HTTP assets, verify redirects, and test important workflows. Create a complete backup first, and use a staging site if one is available.
What causes mixed content in WordPress?
Mixed content occurs when the main page loads over HTTPS but requests another resource over insecure HTTP. Common sources include:
- Images added before the SSL certificate was installed
- Hard-coded stylesheet or JavaScript URLs in a theme
- Old media links saved in posts, widgets, or reusable blocks
- Page builder background images
- External fonts, videos, tracking tools, or embeds
- Custom plugin or theme code that builds URLs manually
The problem may also involve a CDN, reverse proxy, cache, or server configuration that does not correctly detect HTTPS. Updating the homepage address alone will not necessarily repair those references.
1. Update the WordPress site URLs
In the WordPress dashboard, open Settings > General. Change both fields below to the HTTPS version of your domain:
- WordPress Address (URL)
- Site Address (URL)
For example, change http://example.com to https://example.com. Use the same domain format in both fields, including or excluding www consistently. Do not change other URL details unless your hosting setup requires it.
Save the settings, log in again if WordPress ends your session, and clear your browser and site caches before testing.
If you cannot access the dashboard
You can temporarily define the URLs in wp-config.php:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Place these lines above the comment that says, “That’s all, stop editing!” Replace the example domain with your own. These constants can restore access while you investigate the underlying configuration. Document temporary changes and remove them when they are no longer needed.
2. Replace old HTTP links in the database
WordPress stores URLs in posts, pages, widgets, theme settings, plugin options, and page builder data. A search-and-replace operation can update those references, but it should support serialized data. Serialized values can become corrupted if they are edited with a basic database tool.
A reputable search-and-replace plugin can handle this from the dashboard. Search for your old site URL:
http://example.comReplace it with:
https://example.comRun a dry run first when the tool supports one. Check the match count, confirm both URLs are correct, and make a database backup before applying the change. Do not replace http:// globally: that could modify unrelated external URLs or ordinary text.
WP-CLI example
With SSH access, WP-CLI provides another option:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-runReview the dry-run output before removing --dry-run. WP-CLI is designed to account for WordPress serialized data, but a backup and staging test remain sensible precautions. For related PHP and WordPress development utilities, see this guide to PHP development tools for WordPress.
3. Find remaining HTTP assets
Open an affected page in a browser and inspect the developer tools. In Chrome-based browsers, select Inspect, open the Console tab, and look for messages naming blocked HTTP resources. The Network tab can help you identify requests that still use http://.
You can also view the page source and search for:
http://Check image, CSS, JavaScript, font, iframe, and background-image URLs. If only one page is affected, inspect its content, widget, reusable block, or page builder module rather than changing the whole site again.
Places worth checking
- Theme files with hard-coded URLs
- Custom CSS containing
url(http://...) - Header and footer injection settings
- Page builder templates and global settings
- WooCommerce checkout and payment integrations
- Plugin settings containing asset or API URLs
- CDN and image optimization settings
For theme and plugin code, use WordPress functions instead of manually writing the site URL:
$logo_url = get_theme_file_uri( 'assets/images/logo.svg' );
$api_url = home_url( '/wp-json/example/v1/status' );These functions allow WordPress to generate URLs that match the site configuration. If a third-party service is available only over HTTP, replacing it with an HTTPS-compatible service is generally safer than relying on browser upgrades.
4. Verify HTTPS redirects
Once the asset URLs are corrected, test whether important HTTP addresses redirect to their HTTPS equivalents. Check the homepage, key landing pages, login page, media URLs, and WooCommerce pages in a private browser window.
Look for the following:
http://example.comredirects tohttps://example.comhttp://www.example.comredirects to the chosen HTTPS version- The HTTPS page opens without certificate errors
- No redirect loop occurs
- Canonical URLs and XML sitemaps use HTTPS
Redirect rules depend on your hosting platform and web server. Do not copy Apache rules into an Nginx configuration, and avoid enabling several redirect plugins without checking the existing server setup. If a CDN or proxy sits in front of the site, confirm that its SSL mode and origin connection settings match the hosting configuration.
5. Clear caches and test real workflows
Clear WordPress page caches, object caches, server caches, CDN caches, and your browser cache. Then test more than the homepage. Review forms, search, logged-in pages, mobile layouts, product pages, cart, checkout, account pages, and payment-related flows.
Some mixed content appears only after an interaction or on a page that is not included in the main cache. If the WordPress dashboard is also slow or cache purges are failing, troubleshoot that separately with this guide to fixing a slow WordPress admin dashboard.
When to involve a WordPress developer
Professional help is worth considering when the site uses custom code, many page builder templates, WordPress multisite, a complex CDN, or WooCommerce checkout. An unsafe database replacement can damage serialized settings, while incorrect redirect rules can make the site inaccessible.
For custom plugin and theme debugging, SSL migrations, database URL repairs, WooCommerce troubleshooting, and server configuration, see what a WordPress backend developer can handle. When requesting help, provide the affected URL, hosting setup, recent changes, and browser error messages.
Frequently asked questions
Is mixed content the same as an invalid SSL certificate?
No. An invalid certificate prevents the browser from trusting the HTTPS connection. Mixed content means an HTTPS page is still requesting one or more resources over HTTP. The two problems can occur together, but they need different fixes.
Can an SSL plugin fix every mixed content warning?
Some plugins can rewrite requests or identify insecure URLs, but they may not repair database values, third-party resources, or custom code. Correcting the source URL is usually more reliable than depending on a rewrite.
Should I replace every HTTP link in the database?
No. Carefully replace your old site URL, but do not blindly replace every occurrence of http://. External URLs may be intentional, and serialized plugin data requires a compatible search-and-replace tool.
Why is the warning still present after changing the site URL?
Old references may remain in page builder data, widgets, theme files, custom CSS, cached HTML, or third-party integrations. Use the browser Console and Network panel to identify the specific resource still loading over HTTP.
Conclusion
Fixing WordPress mixed content after an SSL installation involves more than activating the certificate. Update both WordPress URLs, replace old database links carefully, locate remaining HTTP assets, verify redirects, clear caches, and test the workflows visitors actually use. If custom code or hosting rules are involved, a qualified developer can help complete the migration without putting the database, content, or checkout at unnecessary risk.