Can’t Access WordPress Admin After Enabling HTTPS? A Complete Fix Guide

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.

If WordPress admin stopped working immediately after you enabled HTTPS, the problem is usually a mismatch between the URL WordPress expects and the way your web server or proxy reports the request. Check the TLS certificate first, then align WP_HOME, WP_SITEURL, and the database values. If HTTPS ends at a proxy, make WordPress recognize the original request as secure. Clear the site’s cookies, isolate plugins, and only then replace old HTTP URLs in the database.

The order matters. Changing several settings at once can hide the cause or make recovery harder, so take a database and file backup and work through the layers below.

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

Identify the failing layer before changing settings

The visible error normally points to the layer that needs attention. Use this table as a starting point, then follow the detailed procedure in order.

Do not interpret a successful redirect from the HTTP homepage as proof that HTTPS is correctly configured. The login path, admin path, static assets, and proxy headers can fail independently.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

Prepare a safe recovery

1. Back up the database and the files containing wp-config.php, plugins, and themes. A redirect loop usually does not damage data, but URL replacements and manual edits can.
2. Write down the current values of WP_HOME, WP_SITEURL, the database options named home and siteurl, and the public hostname you intend to keep. Decide whether the canonical host includes www; HTTPS does not make two hostnames equivalent.
3. Have an alternate access method ready: SSH with WP-CLI, a hosting file manager, SFTP, or a database console. You may need one of these if the dashboard remains unreachable.
4. Make one logical change at a time. After each change, test both /wp-login.php and /wp-admin/ in a private browser window.

1. Confirm that HTTPS works at the server layer

WordPress’s HTTPS guidance states: “WordPress is fully compatible with HTTPS when an TLS / SSL certificate is installed and available for the web server to use.” In practical terms, the certificate must be installed on the server or TLS-terminating proxy that receives the request, and the HTTPS virtual host must point to the WordPress installation.

Check the public certificate

1. Open the exact hostname you use for WordPress with https://, not a bookmarked HTTP address. Confirm that the certificate covers that hostname, is not expired, and is presented with a complete trust chain.
2. Check both the bare domain and the www form if both resolve. Choose one canonical hostname and make the other perform a single redirect to it.
3. Verify that port 443 reaches the intended web server and document root. A certificate installed on one virtual host does not fix a different virtual host serving the site.
4. From a shell, inspect the response headers with curl -I https://example.com/wp-login.php, replacing the example hostname with yours. A normal result may be a direct 200 or one deliberate redirect to the canonical HTTPS URL. Repeatedly alternating Location: headers indicate a loop.

Do not add WordPress URL changes until a direct HTTPS request succeeds. If the browser still shows a certificate error, fix DNS, the certificate, the certificate chain, or the HTTPS virtual-host configuration with your server administrator or hosting provider first.

2. Make WordPress’s canonical URLs agree

WordPress builds login links, redirects, cookie paths, and many asset URLs from two values: the site URL (where WordPress core is installed) and the home URL (the public site address). They can be supplied by constants in wp-config.php or by the home and siteurl rows in the options table. A disagreement between those sources is a common cause of an HTTPS redirect loop.

Inspect and, if necessary, set the constants

Open wp-config.php and look for definitions before the line that says “That’s all, stop editing.” If these constants are present, both should use the same intended HTTPS hostname and should not end with a slash:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Replace the example hostname with the canonical address you selected. Do not define a second copy elsewhere in the file. Constants take precedence at runtime, so changing the database while leaving incorrect constants in place will not solve the request that WordPress receives.

If you do not need hard-coded values, remove the definitions only after recording them and use the database options instead. Hard-coding can be useful during recovery, but it can also hide a database value that remains wrong for command-line tools, migrations, or another environment.

Read the database values without the dashboard

From the WordPress document root, WP-CLI can read the current options even when the login screen is unavailable:

wp option get home --skip-plugins --skip-themes
wp option get siteurl --skip-plugins --skip-themes

The WP-CLI documentation describes wp search-replace as: “Searches/replaces strings in the database.” For reading and updating individual options, use the option commands so you can see exactly what changes.

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

If WP-CLI is unavailable, query the options table with a database tool. The table may not be named wp_options if the installation uses a different prefix:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('home', 'siteurl');

Update only the rows that are wrong, and keep a backup before issuing an UPDATE. The values should match the chosen scheme and hostname. A trailing slash is normally omitted from these URL values.

Use one source of truth

Choose one of these arrangements and keep it consistent:

• Constants define both URLs, and the database contains the same values for future tools and migrations.
• No URL constants are defined, and the database’s home and siteurl values are authoritative.

A mixed arrangement—one constant still using HTTP, one constant using HTTPS, or constants pointing to a different hostname—can make the front end appear correct while the login endpoint continually redirects.

3. Tell WordPress when a reverse proxy terminated HTTPS

With a CDN, load balancer, or other reverse proxy, the browser may use HTTPS while the connection from the proxy to the origin web server is plain HTTP. Unless the proxy forwards the original scheme and WordPress trusts it, PHP sees an HTTP request and WordPress tries to “upgrade” it to HTTPS on every request. The browser then returns to the proxy, producing an infinite loop.

Verify the proxy’s forwarded scheme

Ask the proxy or load-balancer administrator which header carries the original scheme. WordPress’s documented pattern uses HTTP_X_FORWARDED_PROTO. The proxy must set it to https for requests that arrived over HTTPS, and the origin must be configured to trust that header only from the proxy.

A commonly used normalization in wp-config.php is:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Place this before WordPress loads. Use the exact header and value your infrastructure sends, and restrict trust to known proxy addresses when your server setup permits it. Do not blindly treat a client-controlled header as proof of HTTPS on a server that is also reachable directly from the internet; an attacker could forge it.

If the proxy does not send the header, configure it to do so rather than guessing in WordPress. Also ensure that the proxy forwards the original host name, because a correct scheme paired with the wrong host can create a different redirect loop.

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

Run WP-CLI commands behind the proxy

WP-CLI provides the global --assume-https option for commands operating behind an HTTPS proxy. For example:

wp --assume-https option get home
wp --assume-https option get siteurl

This option affects the command’s interpretation of the request; it does not replace the server-side proxy configuration. Fix the forwarded scheme for normal browser traffic as well.

4. Clear cookies and test the two login endpoints

After correcting URL and proxy settings, remove cookies for the affected domain. A cookie issued before the scheme or hostname changed can keep sending the browser through an old login state.

1. Delete cookies and site data for the WordPress hostname only, so unrelated sessions are not lost.
2. Close old tabs for the site, open a private window, and visit https://example.com/wp-login.php directly.
3. After signing in, open https://example.com/wp-admin/. Test both paths because a rewrite rule or plugin can affect one but not the other.
4. If the private window works while the normal window does not, the server-side fix is probably complete; clear the regular browser’s stale cookies and cache.

Do not use repeated refreshes as a diagnosis. A browser can cache redirects, and the resulting behavior can obscure whether the server is now returning a single canonical response.

5. Isolate a plugin that changes login or redirects

If the certificate, URL values, proxy handling, and cookies are correct but login still reloads, temporarily disable plugins. WordPress’s troubleshooting guidance recommends renaming the plugins directory when the dashboard is inaccessible.

1. Using SFTP, a file manager, or SSH, rename wp-content/plugins to a temporary name such as plugins.hold.
2. Open the login URL in a private window. If it works, the core installation and basic URL handling are functioning without normal plugins.
3. Rename the directory back to plugins. Reactivate plugins one at a time, testing the login after each activation, until the conflicting plugin is identified.
4. Update, reconfigure, or replace the conflicting plugin before reactivating it. Redirect, security, cookie, and URL-rewriting plugins deserve particular scrutiny because they run during authentication.

A normal plugins-directory rename does not disable must-use plugins in wp-content/mu-plugins. If the problem remains with the regular directory disabled, inspect that directory and any server-level redirect rules. Restore the original directory name when testing is complete.

6. Replace stored HTTP URLs without damaging the database

Changing the canonical URL settings does not rewrite links already stored in posts, page builders, widget settings, theme options, or plugin tables. Those old links can create mixed-content warnings, blocked scripts, broken images, or secondary redirects. They usually explain a secure page with broken assets rather than a pure login loop, so perform this step after the server and login checks.

Back up and scope the replacement

Back up the database, identify the exact old and new origins, and account for variants such as HTTP versus HTTPS and the presence or absence of www. Replace only your own old origin; do not run a broad replacement for every http:// string, because external URLs may intentionally remain unchanged.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

Run a dry run first

From the WordPress directory, a typical scoped dry run is:

wp search-replace 'http://example.com' 'https://example.com' 
  --all-tables-with-prefix --dry-run --skip-columns=guid

Review the reported tables and counts. The WP-CLI command understands serialized data, so structured values are updated without the common length-calculation errors caused by a raw SQL replacement. The --skip-columns=guid safeguard leaves post GUID columns untouched; GUIDs are identifiers, not a general-purpose way to change the public URL.

Apply the reviewed change

If the dry-run scope is correct, repeat the command without --dry-run:

wp search-replace 'http://example.com' 'https://example.com' 
  --all-tables-with-prefix --skip-columns=guid

Use the correct table scope for your installation. A multisite network may have separate tables for each site, and unrelated tables sharing the same database prefix should not be altered casually. If a plugin stores URLs outside the normal prefixed tables, inspect that plugin’s documented migration procedure rather than guessing.

Find what remains

Load a representative page and use the browser’s developer tools to identify blocked HTTP resources. Search your own content and configuration for the old origin. Hard-coded URLs in theme or plugin code may require a code change, while URLs generated from the options table should be corrected by the database migration. Clear page, object, and proxy caches only after the replacement is complete so cached HTTP markup is not mistaken for a failed migration.

Special cases: multisite and hard-coded environments

Multisite networks

In multisite, the network’s domain and path constants determine how requests are routed, while each site can have its own home and siteurl options. A network administrator should verify:

• DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE in wp-config.php use the intended host and path.
• The proxy forwards the original HTTPS scheme for every mapped host.
• The affected site’s options are queried with its URL rather than assuming the main site’s values apply.
• Search-and-replace covers the appropriate site tables and does not rewrite unrelated network data.

When using WP-CLI against a particular site, supply its URL with the command’s --url parameter so you do not read or update the wrong site’s options.

Environment-specific constants

Deployment systems sometimes define URL constants through environment variables or include files rather than editing wp-config.php directly. Search those files for a leftover HTTP value or a staging hostname. Correct the source that generates the constant; otherwise the next deployment can restore the broken setting.

Verify the repair and prevent a repeat

1. Request the HTTP version of the homepage and login URL and confirm each makes at most one intentional redirect to the chosen HTTPS hostname.
2. Request the HTTPS versions directly and confirm the login page no longer reloads continuously.
3. Sign in, open the dashboard, and load a page containing images, styles, and JavaScript. Confirm that the browser reports no blocked HTTP resources for your own domain.
4. Check the final values with wp option get home and wp option get siteurl, or with a database query if constants are not being used.
5. Restore plugins, if they were disabled, one at a time and test authentication after each restoration.
6. Keep the backup until normal front-end and administrator activity has been verified. Record the final canonical hostname and proxy behavior for the next deployment.

The fix is complete when the certificate is valid, WordPress has one consistent HTTPS identity, the origin knows when a proxy received HTTPS, the login cookie is issued for that identity, and stored content no longer points your own pages and assets back to HTTP.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

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.