Why WordPress SSL breaks and what it affects
Knowing how to fix WordPress SSL not working starts with understanding that SSL/TLS errors are usually caused by configuration mismatches rather than a single WordPress bug.
When HTTPS fails, browsers may show security warnings, redirect loops, broken admin access, or an insecure padlock state that affects trust, SEO, and conversions.
WordPress sites often depend on several layers working together: the domain, hosting server, certificate authority, web server configuration, and WordPress settings.
If one layer is incorrect, SSL can appear installed but still not function properly.
Check the SSL certificate first
The first step is to confirm that the certificate itself is valid, installed, and assigned to the correct domain.
A valid certificate should match the exact hostname users visit, such as example.com and www.example.com, if both are expected to work.
- Verify the certificate has not expired.
- Confirm it was issued for the right domain name.
- Check whether the certificate chain is complete.
- Make sure the hosting account has the certificate installed on the active site.
If you use Let’s Encrypt, renewals are usually automated, but cron issues, hosting restrictions, or DNS changes can interrupt renewal.
If the certificate shows as valid in your hosting panel but browsers still flag HTTPS as broken, the problem may be in web server routing or WordPress URL settings.
Confirm WordPress Address and Site Address settings
One of the most common reasons people search for how to fix WordPress SSL not working is that WordPress still thinks the site lives on HTTP.
In the WordPress admin area, go to Settings > General and inspect both the WordPress Address and Site Address fields.
Both values should normally use https:// if the site is fully migrated to SSL.
A mismatch between these URLs can trigger login issues, redirect loops, or pages loading over insecure HTTP even after the certificate is active.
If you cannot access the dashboard, you can define the URLs in wp-config.php with constants such as WP_HOME and WP_SITEURL.
This is especially useful after a failed migration or when SSL changes lock you out of wp-admin.
Fix mixed content errors on pages and assets
Mixed content occurs when a page loads over HTTPS but requests images, scripts, stylesheets, fonts, or iframes over HTTP.
Browsers may still show a padlock warning or mark the page as partially secure.
This issue is common on WordPress because older posts, page builder templates, theme files, and plugin settings may contain absolute HTTP URLs.
Common sources include:
- Image URLs inserted into posts or widgets
- Hard-coded links in theme files
- CSS files that reference fonts or background images over HTTP
- Plugin-generated scripts that still point to insecure resources
To fix mixed content, update internal links from HTTP to HTTPS and re-save plugin or theme settings that store absolute URLs.
Search-and-replace tools can help, but back up the database first and avoid replacing URLs inside serialized data unless the tool is serialization-safe.
Force HTTPS the right way
After the certificate is working, the site should redirect all HTTP traffic to HTTPS.
This is typically done at the server level, not only inside WordPress, because server-side redirects are faster and more reliable.
For Apache, HTTPS redirection is often implemented in .htaccess.
For Nginx, it is configured in the server block.
If your host uses a control panel such as cPanel, Plesk, or managed WordPress hosting, the platform may provide a simple toggle for force HTTPS.
Be careful not to create duplicate redirect rules.
Multiple redirect layers can cause endless loops, especially when a plugin, .htaccess rule, CDN, and host setting all try to enforce HTTPS at once.
Check for redirect loops and proxy issues
Redirect loops often happen when WordPress, a reverse proxy, or a CDN disagrees about whether the original request is HTTPS.
This is common with Cloudflare, load balancers, and some managed hosts that terminate SSL before the request reaches WordPress.
If the site keeps bouncing between HTTP and HTTPS, check whether the server correctly forwards the protocol header.
WordPress may need to recognize X-Forwarded-Proto or equivalent proxy headers so it knows the request was secure.
In proxy-based setups, make sure:
- The CDN SSL mode matches the origin server configuration
- The origin server has a valid certificate
- Only one system performs the final HTTPS redirect
- WordPress is receiving the correct scheme from the proxy
Regenerate permalinks and clear caches
After changing SSL settings, refresh WordPress permalinks by going to Settings > Permalinks and saving the settings again without changing anything.
This rebuilds rewrite rules and can resolve broken URL handling after migration.
Also clear every cache layer involved in the request path:
- WordPress caching plugins
- Server cache or object cache
- CDN cache such as Cloudflare
- Browser cache
Cached HTTP assets can make a correctly configured SSL site look broken for hours, so clearing cache is often a necessary final step.
Use a search and replace tool for database URLs
Many SSL problems persist because WordPress stores full URLs in the database, including page content, theme options, and builder metadata.
After moving to HTTPS, those stored links may still point to HTTP.
A reliable search-and-replace tool can update database content at scale.
Popular options include WP-CLI search-replace commands and trusted plugins designed for database URL replacement.
The goal is to replace http://example.com with https://example.com across all relevant tables while preserving data structure.
Back up the database before making bulk changes.
If a plugin stores serialized data and the replacement tool does not handle serialization correctly, the site can break more severely than the original SSL issue.
Inspect theme and plugin conflicts
Some WordPress themes and plugins hard-code insecure resource URLs or add redirects that interfere with SSL.
Security plugins, membership plugins, page builders, and legacy themes are common sources of conflicts.
To isolate the problem, temporarily disable nonessential plugins and switch to a default theme such as Twenty Twenty-Four.
If SSL works in a clean environment, reactivate components one at a time until the conflict returns.
When evaluating plugins, look for outdated code, deprecated URL handling, and scripts loaded from third-party endpoints that do not support HTTPS.
If a plugin has not been maintained, it may not be suitable for a secure site.
Verify certificate authority trust and chain problems
Sometimes SSL is technically installed but browsers still distrust the certificate chain.
This can happen when the intermediate certificate is missing or the hosting provider did not install the full chain correctly.
Browser developer tools, SSL test utilities, and hosting diagnostics can reveal whether the chain is incomplete.
If the chain is broken, ask the host to reinstall the certificate bundle or upload the correct full-chain file.
This is especially important for sites serving international traffic where browser trust behavior can vary.
Confirm DNS and hostname consistency
SSL only works properly when users visit the hostname covered by the certificate and pointed to the correct server.
If DNS records are stale, the domain may resolve to an old server with no valid certificate, producing warnings that look like SSL failures.
Check that A records, AAAA records, and CNAME records all point to the intended environment.
Also confirm whether the certificate includes both www and non-www versions if both are accessible.
Domain changes, staging to production migrations, and CDN setups often create hostname mismatches.
Keeping DNS, certificate SAN entries, and WordPress URLs aligned avoids many recurring problems.
Use the browser and server logs to pinpoint the issue
If basic checks do not solve the problem, use evidence from logs and browser tools.
The browser console can show mixed content warnings, failed resource loads, and redirect problems.
Server logs can reveal certificate errors, rewrite failures, or proxy header issues.
Look for patterns such as:
- HTTP requests still being generated after migration
- 301 chains that bounce between schemes
- 404s for CSS, JS, or image assets
- Certificate handshake failures in the server log
This diagnostic approach is often faster than making random changes, especially on larger sites with multiple plugins and cached pages.
When to contact your host or certificate provider
If you have verified WordPress settings, fixed mixed content, cleared caches, and still cannot solve the issue, the problem may be below the application layer.
Hosting support can confirm whether the certificate is installed correctly, whether the web server is reading the right virtual host, and whether SSL termination is configured properly.
Certificate providers can also help if renewal, domain validation, or issuance failed.
Provide them with the exact error message, affected hostname, and a summary of what you already checked so they can troubleshoot more efficiently.
Key checks to remember during an SSL repair
- Confirm the certificate is valid, installed, and matches the domain
- Set WordPress and site URLs to HTTPS
- Remove mixed content from posts, themes, and plugins
- Use one clean HTTPS redirect path
- Clear caches at every layer
- Check proxy, CDN, and DNS consistency
- Review logs before making large changes