iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Installing an SSL/TLS certificate secures the connection to a server, but it does not automatically change WordPress’s saved URLs, rewrite old database content, update theme and plugin assets, or reconcile settings at a reverse proxy. HTTPS can therefore fail at several different layers.
Find the failing layer first: certificate and hostname, WordPress URL settings, stored content and assets, server redirects, or proxy HTTPS detection. Correct that layer, then test the complete redirect and resource chain again.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match
What “HTTPS isn’t working” can mean
Several different symptoms are commonly described as an HTTPS problem. A browser may report that the certificate is invalid, show a missing padlock, load a page that contains HTTP images or scripts, or fail with a “too many redirects” message. These are not the same fault and should not be fixed in the same way.
| Symptom | Likely failing layer | First check |
|---|---|---|
| Certificate warning or hostname mismatch | Certificate, DNS, hosting, or TLS termination | Inspect the certificate served for the exact URL you opened |
| WordPress still displays an HTTP URL | WordPress settings or hard-coded constants | Settings → General and wp-config.php |
| Padlock is missing only on some pages | Mixed content in resources | Browser developer console and page source |
| “Too many redirects” | Conflicting proxy, server, WordPress, or www rules | Trace both HTTP/HTTPS and www/non-www requests |
| Dashboard becomes inaccessible after forcing SSL | Admin SSL setting or incorrect proxy HTTPS detection | Temporarily restore file/database access and correct detection |
WordPress is compatible with HTTPS when a TLS/SSL certificate is installed and available for the web server. That statement describes the prerequisite, not an automatic migration of every URL and resource on an existing site.
#1 Best Overall
1. Verify the certificate and the hostname first
Open the final HTTPS address directly, without relying on a redirect. Use the browser’s certificate viewer to check the certificate’s subject or subject-alternative names, expiration date, and trust chain. The certificate must cover the exact hostname being visited. A certificate for www.example.com does not necessarily cover example.com, and the reverse is also true unless both names are included.
Check the TLS termination point
Confirm where encrypted traffic is terminated. It may be the origin web server, a load balancer, a content-delivery network, or another reverse proxy. The certificate must be installed and active at the device that accepts the browser’s TLS connection. Installing a certificate only on the origin does not help if a proxy terminates HTTPS before the request reaches it.
- Verify that the certificate is not expired or revoked.
- Verify that the intermediate certificates form a complete chain trusted by ordinary browsers.
- Test both the apex and
wwwhostnames if both are publicly reachable. - Check that DNS for each hostname points to the service where the certificate was provisioned.
When a certificate is still pending
A hosting dashboard that says “SSL certificate pending” usually means issuance or deployment has not completed. Check DNS records before repeatedly requesting a new certificate. Certification authorities can be prevented from issuing a certificate by restrictive CAA DNS records; WordPress.com documents CAA records as one cause of a pending Let’s Encrypt certificate. Correct the DNS policy or use an authorized certificate issuer, then wait for provisioning to complete before changing WordPress URLs.
2. Set both WordPress URLs to the final HTTPS address
Once the certificate works for the intended hostname, change the two WordPress URL fields. In the dashboard, go to Settings → General and set both WordPress Address (URL) and Site Address (URL) to the same canonical HTTPS hostname, for example https://example.com. Do not leave one field on HTTP or point one field at www while your canonical address is the non-www version.
Rank #2
If the URL fields are disabled or keep reverting
Look in wp-config.php for hard-coded constants. A host or migration may define them as follows:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Those constants override the values stored in the database. Change them to the chosen canonical hostname, or remove them only when you deliberately want WordPress to read the database values. Make a copy of the file before editing it, and preserve the original formatting and quotation marks.
Free tools Windows power users keep installed
One-click scans. No signup required.
Keep the hostname decision consistent
Choose one public form—apex or www—and redirect the other form to it. Inconsistency can produce a redirect loop even when every individual certificate is valid. The same choice must be reflected in WordPress’s two URL fields, any constants, server rules, canonical tags, sitemap settings, and links generated by themes or plugins.
3. Migrate old HTTP URLs in the database safely
Changing the two settings does not rewrite URLs already saved in posts, widgets, menus, theme options, custom fields, or plugin settings. An image may still be stored as http://example.com/uploads/photo.jpg, and a stylesheet or embedded frame may still reference an HTTP address. Those old values can trigger mixed-content warnings after the page itself is delivered over HTTPS.
Back up before replacing anything
Create a tested database backup before a search-and-replace operation. Also keep a copy of the files and a way to reach the database if the dashboard becomes unavailable. A replacement that is interrupted or aimed at the wrong domain can damage links throughout the site.
Preserve serialized data
WordPress and many extensions store arrays and objects in serialized form. A raw SQL replacement can change string lengths without updating serialization metadata, causing broken options or widgets. Use a migration utility that understands serialized data, or have an administrator run a serialization-safe replacement. Replace only the old site URL and protocol, not every occurrence of the text “http” across unrelated data.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →After the migration, search for the old hostname in ordinary content and in theme and plugin configuration. Check attachment URLs, menus, CSS files, JavaScript settings, feeds, XML sitemaps, and any hard-coded API endpoints. A database migration fixes the source value; it does not repair an external service that still publishes an HTTP URL.
4. Diagnose and remove mixed content
Mixed content occurs when the main document uses HTTPS but the browser is instructed to fetch a resource over HTTP. The affected resource may be an image, font, stylesheet, JavaScript file, video, iframe, tracking endpoint, or web-font provider. A page can therefore show a secure padlock while another page displays a warning, because each page requests a different set of resources.
Rank #4
Find the exact HTTP request
- Open the affected page in a private or logged-out browser window.
- Open Developer Tools and select the Console and Network panels.
- Reload the page and filter requests for
http://, “Mixed Content,” or blocked resources. - View the page source and search for
http://to catch URLs that may not appear in the initial console output. - Record the file or setting that generated each URL before changing it.
Fix the source, not just the symptom
Update the originating image field, menu, widget, theme stylesheet, plugin setting, or database value to use HTTPS. If the resource belongs to another site, verify that the provider supports HTTPS and update the embed to its secure URL. If it does not, replace or remove the resource; a certificate on your own domain cannot make a third-party HTTP server secure.
Test front-end pages while logged out and test the dashboard separately. Logged-in administrators may receive different scripts, previews, or toolbar resources, so a clean public session is necessary to confirm what visitors receive.
Recommended Free Tools
5. Resolve “too many redirects” errors
A redirect loop means two layers disagree about the request’s scheme or hostname. A common arrangement is a reverse proxy that accepts HTTPS and forwards plain HTTP to an origin server. If the origin does not know that the original request was secure, WordPress or the server may redirect to HTTPS again. The proxy repeats the same request, producing an infinite loop.
Make HTTPS detection trustworthy
The proxy must pass a reliable forwarded-protocol indicator, commonly HTTP_X_FORWARDED_PROTO: https, when the visitor connected over HTTPS. WordPress must be configured to trust that indicator only when it comes from your own proxy or load balancer. A typical wp-config.php pattern is:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO']) {
$_SERVER['HTTPS'] = 'on';
}Use this pattern only when the upstream proxy controls the header and your hosting architecture requires it. Do not blindly trust a client-supplied header on a server that is directly exposed to the internet. Your host’s documented equivalent may use a different variable.
Choose one authoritative redirect layer
Put the HTTP-to-HTTPS and www-to-non-www (or the reverse) policy in one authoritative place whenever possible: the proxy, the web server, or WordPress. Duplicating equivalent-looking rules in all three layers makes the final behavior difficult to predict. After changing the policy, clear proxy and browser caches and test every variant:
| Request | Expected result |
|---|---|
http://example.com |
One redirect to the canonical HTTPS hostname |
http://www.example.com |
One redirect to the canonical HTTPS hostname |
https://example.com |
Loads directly if this is canonical |
https://www.example.com |
One redirect only if this is the non-canonical variant |
You can inspect response headers from a terminal with curl -I for each URL. Look for repeated alternating Location headers, a redirect from HTTPS back to HTTP, or a bounce between www and non-www.
6. Configure secure administration without locking yourself out
FORCE_SSL_ADMIN belongs in wp-config.php, not in a plugin file, and assumes that the server’s SSL virtual host is already configured. It tells WordPress to require HTTPS for dashboard and login requests; it does not provision a certificate or correct proxy detection.
Enable it only after the public HTTPS URL works and WordPress correctly recognizes secure requests. If enabling it causes a login loop or an inaccessible dashboard, use file access or database access to temporarily correct the URL constants and proxy detection, or remove the setting. Once the origin and proxy agree on the scheme, restore the setting and test a fresh login session.
7. A complete verification sequence
Run these checks in order after each change so that one fix does not hide another fault:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems- Open the canonical HTTPS URL and inspect certificate hostname, expiry, and chain.
- Confirm DNS points the hostname to the service that terminates TLS.
- Check Settings → General and any
WP_HOMEorWP_SITEURLconstants. - Back up the database, then migrate old site URLs with serialization-safe tooling.
- Use Developer Tools on representative public pages to eliminate HTTP resources.
- Test logged-out pages, login, and wp-admin in a clean browser session.
- Trace HTTP/HTTPS and www/non-www redirects and remove duplicate policies.
- Recheck sitemap, feed, canonical, media, and email links for the old protocol.
Do not reinstall the certificate as a response to a database URL or mixed-content error. Do not repeatedly change redirect rules without first identifying whether TLS ends at the origin or at a proxy. The durable fix is the one that makes every layer agree on the same certificate, hostname, scheme, and canonical URL.
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.
