WordPress SSL Redirect Loop: 7 Safe Checks Before Changing .htaccess

A WordPress SSL redirect loop happens when the browser is sent repeatedly between HTTP and HTTPS, or between two HTTPS URLs. The usual cause is not the certificate itself: WordPress, the web server, a reverse proxy, or a CDN has conflicting ideas about the connection’s security.

Start by confirming the exact redirect chain, then check the site URLs and the HTTPS information passed to WordPress. Avoid repeatedly editing .htaccess or adding SSL constants until you know which layer is issuing the redirect. Those changes can make a production site harder to recover.

This guide focuses on diagnosing an SSL-related loop at the WordPress origin. If the browser specifically shows ERR_TOO_MANY_REDIRECTS after a CDN configuration change, also review the related WordPress redirect-loop troubleshooting guide.

What a WordPress SSL redirect loop looks like

Common symptoms include a browser warning that the page redirected too many times, a login page that never opens, or a site that works in a private window but not in a normal browser session. You may also see different behavior between the homepage and the dashboard.

First test the site in a private browser window and on a different network. This rules out an old redirect cached by the browser or a stale cookie. It does not prove the server is healthy, because browsers can cache redirects independently of WordPress.

Record the redirect chain

Use a redirect-checking tool or inspect the request in your browser’s developer tools. Record:

• The first URL requested, including http or https.
• Every Location destination.
• Whether the host changes between www and the non-www version.
• Whether the path changes, such as a redirect to /wp-login.php.
• Which response starts the cycle.

A simple HTTP-to-HTTPS redirect is normal. A loop usually alternates between two URLs, or repeatedly sends an already-HTTPS request back to the same HTTPS address.

Before changing anything: protect access and identify the redirect owner

Make a current backup of the files and database, and confirm that you can reach hosting file management, SFTP, or a hosting control panel. If the dashboard is inaccessible, you need a recovery route before changing configuration files.

Do not begin by deleting the SSL certificate, disabling all security controls, or replacing the entire .htaccess file. Those actions can hide the cause or break unrelated rewrite rules.

Check whether the redirect comes from WordPress

Temporarily disable page caching at the host or CDN if you have a safe, documented way to do so. Then compare the response for a static file, such as an existing image, with the response for the homepage. If both are redirected, the web server, proxy, or CDN is likely involved. If only WordPress URLs loop, WordPress or a plugin becomes more likely.

Hosting logs can identify the layer more precisely. Ask your host which server or proxy generated the redirect if the response headers are unclear.

1. Confirm WordPress Address and Site Address

In the dashboard, go to Settings → General and inspect WordPress Address (URL) and Site Address (URL). Exact labels can vary slightly by WordPress version or hosting setup. Both should normally use the intended HTTPS hostname, for example:

https://example.com

Do not include a trailing slash, and do not mix www.example.com with example.com unless your redirect plan deliberately uses one as the canonical host.

If you cannot open the dashboard, these values may be defined in wp-config.php or stored in the database. Do not edit the database directly unless you have a verified backup and know the correct table prefix. A safer first step is to ask your host or WordPress administrator to confirm the values.

Check for hard-coded URL constants

Open wp-config.php only through SFTP or your host’s file manager, and look for existing definitions such as:

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

Do not add duplicate definitions. If these constants use an old hostname, HTTP, or a different subdomain, they can override the dashboard values. Save a copy before changing them, edit only the incorrect value, and test immediately.

2. Check whether a proxy is hiding HTTPS from WordPress

This is one of the most common causes when SSL terminates at a load balancer, hosting proxy, or CDN. The visitor connects using HTTPS, but the proxy connects to the origin using HTTP. If the origin does not receive a trusted HTTPS signal, WordPress may keep redirecting the visitor to HTTPS even though the visitor is already there.

Ask your host or proxy provider whether SSL terminates before the WordPress server and which header communicates the original protocol. Common environments include managed WordPress hosting, load balancers, reverse proxies, and CDN proxy services.

Do not blindly copy a $_SERVER snippet from a forum into wp-config.php. The correct trusted-header configuration depends on the proxy, and accepting a spoofable header can create security problems. Use your host’s documented configuration or have the host confirm it.

After the origin correctly recognizes HTTPS, clear the relevant cache and test both the homepage and /wp-admin/. A redirect response should no longer repeat when the requested URL is already HTTPS.

3. Inspect SSL and redirect rules at the server

There should be one clear policy for upgrading HTTP to HTTPS. Problems occur when several layers each try to enforce a different rule, or when a rule redirects HTTPS back to HTTP before another rule upgrades it again.

Review the web server, hosting panel, and any redirect plugin for rules that:

• Force HTTPS and also force a different hostname.
• Redirect HTTPS requests to HTTP.
• Use a hard-coded old domain or staging domain.
• Apply a rule differently to the homepage, login page, or admin area.

If you use Apache, inspect .htaccess carefully and preserve a downloadable backup. WordPress’s standard rewrite section should not be replaced casually. If you use Nginx or a managed host, there may be no .htaccess file controlling the redirect; ask the host to inspect the virtual host or edge configuration.

For background on safely understanding WordPress rewrite rules, see this guide to WordPress .htaccess. A malformed rewrite file can also cause broader failures, so keep changes minimal.

4. Temporarily isolate redirect plugins and theme code

Redirect, security, caching, and SEO plugins can each enforce HTTPS or a preferred hostname. A theme or custom snippet can also call a redirect when it detects an insecure request.

Before disabling anything, record the active plugins and take a backup. Then use one of these safer approaches:

1. Disable the plugin most likely to control redirects or SSL, then test in a private window.
2. If the dashboard is unavailable, use SFTP to rename only that plugin’s directory temporarily. Rename it back as soon as testing is complete.
3. If the loop remains, restore the plugin and test the next likely source rather than disabling everything permanently.

Do not leave security or caching plugins disabled on a production site. If the loop stops, inspect that plugin’s HTTPS, canonical-domain, or redirect settings and re-enable it after correcting the conflict.

To test whether the theme is involved, temporarily switch to a default WordPress theme from the dashboard if access is available. If changing the theme fixes the loop, inspect custom functions and redirect hooks rather than editing random template files.

5. Clear the right caches and cookies

Once the configuration is corrected, clear caches in this order:

1. Any redirect or page cache in the WordPress plugin.
2. The hosting or server cache.
3. The CDN or proxy cache, if applicable.
4. The browser’s site data or cookies.

Test in a private window first. A persistent wordpress_logged_in cookie can make login behavior appear different from public-page behavior. Clearing cookies is useful for verification, but it will not fix a server-side loop by itself.

Be careful when purging a full site cache during busy periods. If the host offers a targeted purge, use it for the affected hostname or URLs.

6. Check certificate coverage and the canonical hostname

An expired or mismatched certificate usually produces a certificate warning rather than a redirect loop, but certificate and hostname changes often trigger conflicting redirect rules.

Confirm that the certificate covers the exact hostname WordPress uses, including whether it is the www or non-www version. Then confirm that DNS points the intended hostname to the correct hosting or proxy service. Do not change DNS simply to test a redirect; DNS changes can take time to propagate and may disconnect email or other services.

If the site recently moved hosts, check that the old host is not still applying redirects and that the new origin is not configured with the old site URL. Migration-related URL problems may also affect canonical tags; for a separate diagnostic process, see how to fix broken canonical tags and duplicate URL issues.

7. Verify the repair without creating a second problem

After each meaningful change, test from a private window and at least one normal browser. Check:

• The HTTP homepage redirects once to the intended HTTPS hostname.
• The HTTPS homepage loads without another redirect.
• The login page and dashboard load correctly.
• A representative post, page, and media URL behave normally.
• Internal links do not send visitors to the old hostname.
• Forms, embedded content, and administrative requests still work.

Use a redirect checker or browser network panel to confirm that the chain has ended. Also review the site’s Tools → Site Health screen, although exact labels can vary by version, and look for HTTPS or loopback warnings. The official WordPress Documentation is useful when a setting or screen differs in your installation.

Quick decision guide

• HTTP redirects to HTTPS, then HTTPS redirects to HTTPS repeatedly: check proxy HTTPS detection, WordPress URL constants, and duplicate force-SSL rules.
• Only one hostname loops: compare the www and non-www settings in WordPress, DNS, the certificate, and the server redirect rule.
• Only logged-in pages loop: inspect cookies, login/security plugins, and proxy rules affecting authenticated requests.
• The loop began after migration: verify WP_HOME, WP_SITEURL, database URL values, old host redirects, and caching.
• Static files work but WordPress pages loop: isolate plugins, theme code, WordPress URL settings, and HTTPS detection.

Questions to answer before escalating

Can I fix the loop by changing both URLs to HTTPS?

Sometimes, but only if HTTPS is correctly available at the origin and the hostname is correct. If a proxy hides the original protocol, changing the URLs alone can leave the loop unchanged.

Should I force SSL in wp-config.php?

Not as a first step. A hard-coded SSL directive may help in a known hosting configuration, but the correct setting depends on how HTTPS reaches WordPress. Confirm the proxy behavior first and back up the file before editing it.

Why does the site work in a private window?

Old cookies or cached redirects may be involved, particularly after changing domains or SSL settings. Compare the redirect chain in both windows; if only the normal window fails, clear that site’s data after confirming the server configuration.

What if I cannot access wp-admin or hosting files?

Contact the host and request the redirect chain, origin HTTPS-detection setting, WordPress URL values, and relevant server redirect rules. If you need an administrator to make controlled changes, WordPress Site Repair can be considered after access and backups are established.

The safest fix is the smallest change that makes every layer agree: one canonical hostname, HTTPS recognized correctly at the origin, and one deliberate HTTP-to-HTTPS redirect. Verify the chain after each change instead of stacking more redirects on top of the original conflict.