Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Installing an SSL/TLS certificate does not, by itself, switch every part of a WordPress site to HTTPS. The certificate must cover the exact hostname visitors use and be installed where encrypted connections terminate; WordPress must store HTTPS site URLs; old database values and theme or plugin assets must stop requesting HTTP; and any proxy, web server, and WordPress redirect rules must agree about the request protocol.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Diagnose the failure in that order. A certificate or hostname problem is fixed at the hosting or proxy layer, mixed content is fixed at the resource’s source, and redirect loops are fixed by making one layer authoritative for HTTPS detection and redirects.
As an Amazon Associate I earn from qualifying purchases.
What changes when you install SSL—and what does not
SSL is now generally implemented as TLS, but WordPress documentation and hosting panels still use both terms. A certificate authenticates a hostname and encrypts traffic after a browser connects to the TLS termination point. That point may be the origin web server, a load balancer, or a reverse proxy. WordPress describes itself as fully compatible with HTTPS when a TLS/SSL certificate is installed and available for the web server to use.
The certificate does not rewrite WordPress Address (URL), Site Address (URL), image links, serialized options, menus, widgets, theme files, plugin settings, or embedded content. Those values can continue to emit http:// even while the page itself is delivered through https://. HTTPS troubleshooting therefore has four separate layers:
#1 Best Overall
- Certificate and hostname: whether the browser can establish a trusted connection for the exact name requested.
- WordPress URL data: the canonical address stored in settings, configuration constants, and database content.
- Resources: images, scripts, stylesheets, embeds, and third-party calls loaded by each page.
- Request routing: redirects and proxy headers that tell WordPress whether the original request was HTTP or HTTPS.
Fixing one layer does not automatically repair another. For example, replacing a certificate cannot change an old image URL, and changing WordPress URLs cannot make a certificate valid for a different hostname.
1. Confirm that the certificate serves the hostname you actually visit
Check the exact name, not just the domain
Open the final HTTPS address directly and inspect the browser’s certificate details. Confirm that the certificate covers the exact apex hostname or exact www hostname in the address bar. A certificate for www does not automatically cover the bare domain, and a certificate for the bare domain does not automatically cover www unless both names are included.
- Verify the certificate is not expired.
- Verify the certificate chain is complete and trusted by the browser.
- Verify DNS sends the hostname to the service where TLS is terminated.
- Verify the certificate is installed on that termination point, whether it is the origin server or a proxy.
If the browser reports a name mismatch, an incomplete chain, or an expired certificate, stop changing WordPress settings. Correct the certificate, DNS, or hosting configuration first.
Handle a pending certificate carefully
A hosting dashboard may show that an SSL certificate is “pending” while the provider validates DNS and provisions the certificate. Check that the required DNS records point to the correct service before waiting for issuance. A DNS CAA record can restrict which certificate authorities may issue certificates; WordPress.com documents that CAA records can prevent Let’s Encrypt from issuing a certificate. Remove or adjust a conflicting CAA policy only when you understand which certificate authority your provider uses.
Do not force HTTPS redirects while the certificate is still unavailable. Visitors will receive certificate errors, and a redirect cannot compensate for a certificate that has not been provisioned at the endpoint accepting the connection.
2. Set both WordPress URLs to the final HTTPS hostname
Change the two General Settings fields
In the dashboard, go to Settings → General. Set both WordPress Address (URL) and Site Address (URL) to the same intended canonical hostname using https://. Keep the chosen www or non-www form consistent with the certificate, DNS, and redirect policy.
These fields serve different purposes: the WordPress Address identifies where the WordPress files and administration operate, while the Site Address is the public address visitors use. In a standard installation they normally match. A mismatch can send login links, canonical tags, feeds, or front-end navigation to another scheme or hostname.
When the fields are locked or revert
If the fields cannot be edited or immediately revert, inspect wp-config.php for hard-coded WP_HOME or WP_SITEURL constants. Those constants override the database values. Make sure both constants use the same final HTTPS hostname, or remove them only if your deployment process does not require them. A typo, trailing path, or different www choice can keep WordPress generating the wrong links even after the dashboard appears correct.
Migrate old database URLs with a backup and a recovery path
Existing content can retain absolute HTTP URLs after the settings change. Before replacing anything, create and verify a database backup and ensure you have a way to restore it. Search for the old http:// form in ordinary content and serialized data, then perform a serialization-aware replacement. Blind text replacement can corrupt serialized values when string lengths change.
- Record the exact old hostname and the exact new HTTPS hostname, including whether each uses www.
- Back up the database and confirm that the backup can be downloaded or restored.
- Search posts, pages, widgets, theme options, plugin options, and menus for the old HTTP URL.
- Use a migration method that understands serialized WordPress data rather than editing serialized strings manually.
- Clear any page, object, or server cache used by the site.
- Check both logged-out pages and
wp-adminfor remaining HTTP links.
WordPress core guidance identifies hard-coded HTTP URLs in existing database content as a major source of mixed-content warnings. Changing only the two General Settings fields leaves those historical references untouched.
Recommended Free Tools
3. Find and remove mixed content
Understand why the padlock can be missing on only some pages
Mixed content occurs when the main document is loaded over HTTPS but one or more subresources are requested over HTTP. Typical examples are an old image URL, a theme stylesheet, a JavaScript file, an embedded frame, a web font, or a third-party script. Because resources differ from page to page, one URL can show a secure padlock while another displays a warning.
Mixed content is a resource-level problem, not proof that the certificate failed. Reinstalling the certificate does not alter the URL embedded in an image, stylesheet, script, or post.
Use the browser to identify the exact request
- Open the affected page in a private or clean browser window.
- Open Developer Tools and select the Console and Network panels.
- Reload the page and look for mixed-content messages or requests whose URL begins with
http://. - Inspect page source when the request is not obvious in the Network panel; search for
http://and note the full resource URL. - Trace that URL back to its origin: a post, widget, theme file, plugin setting, customizer field, or external service.
- Change the originating value to the HTTPS version, update the component, or remove the resource if its provider does not support HTTPS.
Test the public page while logged out and test the administration area separately. A cached or authenticated view can hide a problem that visitors still receive.
Match the resource to its fix
| HTTP resource found | Likely origin | Fix |
|---|---|---|
| Image or media URL | Post content, widget, or old attachment metadata | Update the stored URL with a serialization-safe database migration or edit the originating content. |
| Theme CSS or JavaScript | Theme option, hard-coded template path, or outdated theme asset | Change the theme setting or template reference and update the theme through a supported release. |
| Plugin asset | Plugin setting or plugin-generated markup | Update the setting, update the plugin, or ask its maintainer for an HTTPS-compatible release. |
| Embed or third-party script | External provider URL | Use that provider’s HTTPS endpoint or remove the embed if no secure endpoint exists. |
4. Stop “too many redirects” errors
What the error means
A redirect loop means that two or more layers disagree about the scheme or canonical hostname. Common patterns include an HTTP request redirected to HTTPS, followed by a proxy that tells the origin the request was HTTP, causing WordPress to redirect again. Another pattern alternates between www and non-www addresses.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
WordPress specifically warns that forcing HTTPS while SSL is supplied by a reverse proxy, with the origin itself running without SSL, can initially create an infinite loop. The browser sees HTTPS at the proxy, while WordPress at the origin sees an HTTP connection unless the proxy communicates the original scheme.
Make proxy HTTPS detection accurate
Configure the proxy or load balancer to pass the original protocol, commonly through HTTP_X_FORWARDED_PROTO: https or the platform’s equivalent. Configure WordPress to trust and recognize that header before forcing secure administration. The header must be set by your trusted proxy, not accepted blindly from arbitrary clients.
Do not assume the proxy’s SSL mode matches the origin’s mode. Verify where TLS terminates, whether the origin connection is encrypted, and which header reaches PHP. If WordPress never detects the forwarded HTTPS request, its HTTPS checks can remain false even though the browser connection is secure.
Use one authoritative redirect layer
Choose the layer responsible for canonical redirects wherever possible: the CDN or reverse proxy, the web server, or WordPress. Duplicating equivalent rules in all three layers makes diagnosis harder and can create contradictory www and scheme changes.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors| Test | Expected result | What a failure suggests |
|---|---|---|
| HTTP, non-www | One redirect to the chosen HTTPS hostname | Missing or conflicting HTTP redirect policy. |
| HTTP, www | One redirect to the same chosen HTTPS hostname | Separate www rule or certificate coverage problem. |
| HTTPS, non-www | Final page or one canonical-host redirect | Hostname inconsistency between DNS, WordPress, and redirect rules. |
| HTTPS, www | Final page or one canonical-host redirect | Proxy or origin disagreeing about the requested host. |
Run these tests in a clean browser session so cached redirects do not obscure the current chain. Inspect every hop and identify which layer generated it before changing a rule.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.5. Keep administration SSL aligned
FORCE_SSL_ADMIN belongs in wp-config.php, not in a plugin file. It also assumes the server’s SSL virtual host and proxy detection are already correct. Enabling it before the origin can recognize HTTPS may lock you out of wp-admin or produce a loop.
Recovery if wp-admin becomes inaccessible
- Use file access or a database access method to reach
wp-config.phpand the relevant URL values. - Temporarily correct
WP_HOME,WP_SITEURL, and forwarded-protocol handling so WordPress sees the request scheme accurately. - If necessary, temporarily disable the forced-admin setting while correcting the proxy and origin chain.
- Test a clean login session, then re-enable
FORCE_SSL_ADMINonly after secure detection and canonical URLs are consistent.
Do not try to solve an administration lockout by repeatedly changing browser cookies or reinstalling the certificate; those actions do not correct the server-side scheme disagreement.
Diagnose by the failing layer
| Observed symptom | Most likely layer | First corrective action |
|---|---|---|
| Certificate warning or hostname mismatch before WordPress loads | Certificate, DNS, or TLS termination | Check exact hostname, expiry, chain, provisioning, and endpoint installation. |
| Secure page with HTTP images, scripts, or styles | Database, theme, plugin, or embed resource | Use the browser console to locate the exact HTTP request and update its source. |
| “Too many redirects” after enabling HTTPS | Proxy headers, origin detection, or duplicate redirect rules | Verify forwarded protocol and make one layer authoritative for redirects. |
| Dashboard URLs revert to HTTP | wp-config.php constants or deployment configuration |
Align or remove conflicting WP_HOME and WP_SITEURL definitions. |
| Only some pages show a warning | Page-specific mixed content | Inspect each affected page’s resources; do not treat the site as uniformly fixed. |
Final verification checklist
After each layer is corrected, retest rather than assuming the previous result still applies.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Open the exact canonical HTTPS hostname and inspect certificate name, expiry, and trust chain.
- Confirm both WordPress URL fields and any configuration constants use that hostname and scheme.
- Check representative pages, media-heavy pages, checkout or form pages, and
wp-admin. - Use Developer Tools to confirm that images, scripts, stylesheets, embeds, and fonts no longer request HTTP.
- Test HTTP and HTTPS for both www and non-www forms and record every redirect hop.
- Repeat the tests logged out and in a clean browser session after clearing relevant caches.
- Keep the database backup until the site has passed all checks and normal visitors are receiving the intended canonical URL.
The reliable fix is the one that makes the certificate, WordPress URL data, page resources, and proxy or server routing agree on the same HTTPS hostname. Treating those as separate checks prevents a certificate change from being mistaken for a complete WordPress migration.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
