The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →If WordPress admin stopped opening immediately after you enabled HTTPS, work from the outside in: verify the TLS certificate and port-443 virtual host, make WP_HOME, WP_SITEURL, home and siteurl agree, tell WordPress when a reverse proxy terminated SSL, then clear cookies, isolate plugins and replace old database URLs. That order fixes the common causes without locking you into another redirect loop.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What the HTTPS failure is actually telling you
Enabling HTTPS changes more than the padlock in a browser. WordPress must know the canonical scheme for the site, the web server must present a valid certificate, and every proxy between the browser and PHP must preserve the original request scheme. If one layer says http:// while another says https://, the browser can be sent around in a circle.
As an Amazon Associate I earn from qualifying purchases.
The visible symptom usually narrows the search:
- “Too many redirects” or an endless redirect: suspect conflicting URL values or a reverse proxy that is not passing the original HTTPS scheme.
- The login form reloads after you submit it: check cookies, canonical URLs and plugins after the server and proxy checks.
- The front end loads securely but images, scripts or styles fail: old
http://URLs remain in stored content or settings, creating mixed content. - Nothing responds on HTTPS: start with the certificate and the HTTPS virtual host; WordPress cannot repair a TLS service that the web server has not configured.
WordPress’ official HTTPS guidance describes the prerequisite this way: “WordPress is fully compatible with HTTPS when an TLS / SSL certificate is installed and available for the web server to use.” The troubleshooting sequence below follows that dependency order.
Prepare a safe recovery path
Do not begin by changing several URL values at once. A wrong edit can make both the front end and /wp-admin/ unavailable, while a backup gives you a way back.
#1 Best Overall
- Take a database backup and keep a copy of the current
wp-config.php. - Record the exact public URL, including whether it uses
wwwor the bare domain. Treathttps://example.comandhttps://www.example.comas different canonical choices. - Keep an alternate access method ready: hosting file manager, SFTP, SSH, or a database console. You may need one of these if the login page loops.
- Make one category of change at a time and test both
/wp-login.phpand/wp-admin/after each category.
1. Verify HTTPS at the server layer
Check the certificate in a browser
Open the site’s HTTPS address directly, not through a cached bookmark. Inspect the certificate details in the browser and confirm that it covers the exact hostname you are using, is within its validity period and is trusted by the browser. A certificate for a different hostname, an incomplete certificate chain or an expired certificate must be corrected at the web-server or hosting level before WordPress settings can help.
Confirm that the HTTPS virtual host serves the site
The server needs a listener for port 443 (or the HTTPS equivalent on your platform) mapped to the same WordPress installation. If HTTPS displays a default server page, a different site or a connection error, fix the virtual-host configuration and certificate attachment first. WordPress only receives a usable HTTPS request after the web server has completed the TLS handshake.
Use a header check when the browser view is ambiguous
From a shell, request the public URL and inspect the response headers:
curl -I https://example.com/A normal response should come from your WordPress site (often with a 200, 301 or 302 status that you understand). Repeated alternating Location: headers between HTTP and HTTPS indicate a redirect policy problem; a certificate or connection error points to the server layer instead.
2. Make WordPress’ canonical URLs agree
Inspect WP_HOME and WP_SITEURL
Open wp-config.php through SFTP, SSH or the host file manager and look for definitions such as:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );If these constants exist, both must use the intended HTTPS hostname. Do not add a second definition elsewhere in the file. Keep the choice of www versus non-www identical in both values, and avoid a trailing slash in the value unless your existing configuration explicitly requires one.
Hard-coded constants override values that you might try to change in the WordPress Settings screen. If the dashboard is inaccessible, editing these constants is a temporary way to establish one canonical URL; once access is restored, document the decision so a later migration does not create a second source of truth.
Check the database’s home and siteurl options
In the table whose prefix is defined by $table_prefix in wp-config.php, inspect the options named home and siteurl. They should contain the same HTTPS URL you chose for the constants. In a database console, a read-only check can look like:
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('home', 'siteurl');Replace wp_options with your actual table name; custom prefixes are common. If the values disagree, back up the database and update them deliberately rather than running a broad replacement. For a one-site installation, the corrected values are typically:
UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name IN ('home', 'siteurl');Use your real hostname and table prefix. If constants remain in wp-config.php, they must match the database values or the conflict will return when another component reads a different source.
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 problemsAccount for multisite
Multisite stores network and site-specific URL data in additional tables, and domain mapping can add another redirect layer. Do not apply a single-site SQL update to a multisite network without identifying the relevant site and network rows. Check the network’s HTTPS and domain settings, then test a subsite’s front end and login separately. If only one subsite loops, its mapped domain or site-specific values are more likely than the network-wide certificate.
3. Tell WordPress when a reverse proxy terminated SSL
Understand the proxy failure
With a CDN, load balancer or other reverse proxy, the browser may use HTTPS while the connection from the proxy to PHP is plain HTTP. Without a trusted indication of the original scheme, WordPress sees HTTP and issues an HTTPS redirect; the proxy then sends the request back over its HTTP-to-origin connection, producing an infinite loop.
The proxy must forward the original scheme, commonly in the X-Forwarded-Proto header. WordPress’ HTTPS documentation shows handling for HTTP_X_FORWARDED_PROTO. A typical guarded pattern in wp-config.php, placed before the line that says to stop editing, is:
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
&& 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}Only trust this header when it is supplied by your own proxy or load balancer. If visitors can send an unchecked header directly to the origin, they could make WordPress believe an insecure request is secure. Restrict origin access to the proxy where possible and configure the proxy to overwrite, not merely append, the scheme header.
Recommended Free Tools
Test the complete proxy path
After the proxy setting is corrected, request the public HTTPS URL and verify that the origin no longer generates a second HTTPS redirect. Test an uncached browser window as well as the proxy’s normal path; a cached redirect can hide a successful fix.
Use WP-CLI’s proxy option when appropriate
WP-CLI includes --assume-https for commands operating behind an HTTPS proxy. It affects how that command interprets the request scheme; it does not replace correct proxy headers for normal browser traffic. Check the command’s help output and use the option only for a site that is genuinely being accessed through an HTTPS-terminating proxy.
4. Clear cookies and test the two critical URLs
WordPress login cookies are issued for the site’s domain and scheme. Cookies created before the URL change can cause a login form to reload even after the server configuration is correct.
- Delete cookies and site data for the affected domain, or open a private/incognito window.
- Visit
https://example.com/wp-login.phpdirectly. - Sign in once, then open
https://example.com/wp-admin/. - Repeat the test with the exact canonical hostname, including the same
wwwchoice used inWP_HOMEandWP_SITEURL.
If a private window works but your normal window does not, stale cookies or browser cache are the likely cause. If both windows loop, continue with the URL, proxy and plugin checks rather than repeatedly deleting cookies.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
5. Temporarily isolate plugins
A plugin can force an old login URL, issue its own redirect or assume that the origin connection is HTTPS. WordPress’ login guidance recommends disabling plugins when the login page keeps reloading.
- Using SFTP, SSH or the hosting file manager, go to
wp-content. - Rename
pluginsto a temporary name such asplugins.disabled. Renaming prevents WordPress from loading the standard plugins without requiring dashboard access. - Test
/wp-login.phpand/wp-admin/in a private window. - If access returns, restore the folder name and reactivate plugins one at a time, testing after each activation. The plugin activated immediately before the loop returns is the leading suspect.
Do not delete plugin files during this test. A temporary rename preserves settings and makes the change reversible. If the problem remains with ordinary plugins disabled, inspect must-use plugins, server redirects and the proxy path; must-use plugins are loaded from a separate directory and are not disabled by renaming the standard folder.
6. Replace old HTTP URLs without damaging the database
Find the remaining HTTP references
Once login works, a secure page with blocked images, scripts or styles usually means that content still contains the old HTTP address. References can exist in post content, widget settings, theme options, menus and plugin data. Not every http:// string should be changed blindly: external services, code examples and GUID fields may have a different purpose.
Run a WP-CLI dry run first
The WP-CLI project describes wp search-replace as: “Searches/replaces strings in the database.” Run a dry run from the WordPress directory before making changes:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-runReview the reported tables and replacement count. The command handles serialized data intelligently, which is important for PHP arrays stored by WordPress and plugins. If the scope is correct, repeat without --dry-run:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefixUse the exact old and new hostnames, including the www choice. Keep a database backup, and inspect the command’s help for options appropriate to your installation. Migration guidance cautions against unsafe blanket replacements and recommends care around GUID columns; do not rewrite GUIDs merely to remove a mixed-content warning. If a plugin stores URLs in a table outside the normal WordPress prefix, identify that table and handle it separately rather than widening the command indiscriminately.
Best Value
Check the result in the browser
After the replacement, purge relevant page or CDN caches, reload a secure page and inspect the browser’s developer console for mixed-content errors. A page that is visually secure but still requests HTTP assets has a remaining stored reference or a script-generated URL that needs to be traced to its setting.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Match the symptom to the most likely fix
| Visible symptom | Where HTTPS terminates | Most likely first check | Site scope | What to do next |
|---|---|---|---|---|
| Browser reports too many redirects | Directly on the web server | WP_HOME, WP_SITEURL, home and siteurl disagree |
Single-site or multisite | Align every canonical URL, then retest in a private window. |
| Browser reports too many redirects | At a proxy or load balancer | Original HTTPS scheme is not forwarded | Usually affects the whole site | Configure the forwarded-proto header and trusted server handling. |
| Login form reloads after submission | Either | Stale cookies, URL mismatch or a login-related plugin | Often one site or one hostname | Clear cookies, verify canonical URLs and isolate plugins. |
| Front end is secure but assets are blocked | Either | Stored http:// content |
Pages, widgets or theme/plugin settings | Run a reviewed WP-CLI dry run, then replace safe references. |
| HTTPS does not load at all | Web server | Certificate, port 443 or virtual-host configuration | Whole domain | Fix TLS availability before changing WordPress URLs. |
When the dashboard is still unavailable
Work through the layers in this order so each test eliminates a class of causes:
- Open the HTTPS URL and confirm the certificate and server response.
- Read
wp-config.phpand record any URL constants and proxy logic. - Check the database’s
homeandsiteurlvalues using the actual table prefix. - Test the public URL with the proxy path and, where available, the origin path restricted to administrators.
- Clear cookies and test both login endpoints in a private window.
- Rename the standard plugins directory and test again.
- After access is restored, use a WP-CLI dry run to locate and replace safe stored HTTP URLs.
If a change makes the site worse, restore the backed-up wp-config.php and database values, then repeat one step at a time. Hosting or server logs can show whether the redirect is generated by the web server, a proxy, WordPress core or a plugin; the component issuing the first unexpected Location header is the one to correct.
Configuration details that commonly get overlooked
Hostname consistency
HTTPS alone does not choose between the bare domain and its www variant. Pick one hostname and use it consistently in the certificate, proxy configuration, WordPress constants, database values, cookies and any server redirect. Alternating between both hostnames can look like an SSL problem even when the certificate is valid.
Hard-coded constants versus editable settings
When WP_HOME or WP_SITEURL is defined in wp-config.php, changing the Settings screen does not change those constants. Conversely, removing a temporary constant without correcting the database can expose the original HTTP values again. Treat the file and database as a pair.
Proxy caching
A proxy or browser may cache a 301 redirect from before the correction. Use a private window, purge the relevant cache and retest the canonical URL before deciding that a configuration change failed. Do not keep adding redirect rules to compensate for a cached response.
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 reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteQuick Recap
What a successful repair looks like
- The certificate is valid for the exact canonical hostname and the HTTPS virtual host serves the WordPress installation.
WP_HOME,WP_SITEURL,homeandsiteurlall use one HTTPS URL.- A proxy, if present, forwards the original HTTPS scheme and the origin trusts that information only from the proxy.
- A fresh browser session can submit
/wp-login.phpand reach/wp-admin/without a redirect loop. - Plugins are re-enabled after isolation, and the offending plugin is updated, reconfigured or replaced if it recreates the loop.
- Stored internal URLs use HTTPS where appropriate, while GUIDs and unrelated external URLs have not been changed blindly.
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.
