Too Many Redirects After Moving WordPress to HTTPS

What this error means & how to recognize it

• The site worked over HTTP before the HTTPS migration, then began showing “too many redirects.”
• The browser repeatedly switches between HTTP and HTTPS or requests the same HTTPS address repeatedly.
• The whole site may fail, or only /wp-admin, the login page, or selected paths may loop.
• Opening the HTTP address may produce one expected HTTPS redirect followed by repeated redirects instead of a normal response.
• Private browsing or another device may behave differently because of cached redirects, cookies, or site data.

Root causes, ordered by likelihood

1. WordPress URL settings still use HTTP. If either WordPress Address (URL) or Site Address (URL) remains HTTP while another layer requires HTTPS, WordPress can redirect to a scheme that conflicts with the server’s policy.
2. HTTPS enforcement exists in multiple layers. A security plugin, wp-config.php logic, .htaccess or Nginx rule, hosting setting, and proxy rule may overlap or make different assumptions about the request scheme.
3. A CDN or reverse proxy terminates TLS. The visitor connects over HTTPS while the origin connection is HTTP. If the original protocol is missing, incorrect, or not safely trusted, WordPress may repeatedly believe the request is insecure.
4. A plugin or theme redirects a specific path. Login, admin, canonical-URL, security, and membership plugins can affect only /wp-login.php, /wp-admin, or selected pages.
5. A stale cached redirect or browser cookie masks the correction. This is less likely to be the original cause, but it can make a fixed configuration appear broken.
6. Old HTTP references remain in content or configuration. These normally cause mixed-content warnings or an additional redirect, not a site-wide redirect loop; investigate them after the main chain is fixed.

How to fix it

1. Inspect the redirect chain

Use a private browsing window for an initial check. If you have shell access, set a shell variable to the affected site’s actual HTTPS address and run this read-only request:

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

Record every status code and Location: header. Alternating HTTP and HTTPS usually indicates a scheme-detection or redirect-rule conflict. Repeating the same HTTPS address points more toward a canonical, plugin, proxy, or cached redirect. Do not include credentials, cookies, or authorization headers.

2. Check both WordPress URL settings

If the dashboard is available, open Settings → General and verify that WordPress Address (URL) and Site Address (URL) use the same intended HTTPS origin, including any required subdirectory.

If the loop blocks the dashboard, an authorized administrator with SFTP or database access can temporarily define the values in wp-config.php:

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

Back up the file first and make one controlled change. These constants override the corresponding dashboard fields while they are defined, so remove or manage them deliberately after testing.

3. Determine where TLS terminates

Establish whether the browser connects directly to the web server or through a CDN, load balancer, or reverse proxy. When a proxy terminates TLS, the origin may receive an HTTP connection even though the visitor used HTTPS.

Ask the hosting or proxy administrator to confirm that the original protocol is forwarded consistently and that WordPress is configured to recognize it only from the intended trusted proxy. Do not blindly trust X-Forwarded-Proto from arbitrary clients; an unvalidated forwarded header can create security problems.

4. Reduce HTTPS enforcement to one deliberate layer

List every place that may redirect HTTP to HTTPS:

• CDN or load-balancer rules
• Hosting-panel SSL settings
• Apache .htaccess or Nginx configuration
• Security or SSL plugins
• Custom wp-config.php or theme code

Keep enforcement at the layer that fits the hosting architecture, commonly the edge or web server, and disable conflicting application-level redirects. Back up configuration and obtain administrator approval before changing server rules. Validate configuration before any approved reload or restart; do not restart a production web server as a first diagnostic step.

5. Test login and admin paths separately

If the front end works but /wp-admin or login loops, review recently changed security, login, canonical-URL, and caching plugins using an approved maintenance procedure. A plugin conflict is more likely when only one path loops. If a plugin must be disabled for testing, record the change, preserve access controls, and re-enable or replace it after the test.

6. Purge caches and retest

After recording the original behavior and making a controlled correction, clear browser site data and purge WordPress page or object caches plus hosting and CDN caches. Retest the HTTP address, HTTPS home page, login page, and a representative internal page. A cached 301 or 302 can persist after the live configuration is corrected.

7. Update remaining HTTP references

Once the redirect chain is fixed, back up the database before changing stored URLs. Use a reputable WordPress migration tool or WP-CLI search-and-replace with a dry run first, and use a tool that handles serialized WordPress data. Replace only the old site origin with the HTTPS origin; do not broadly replace every http:// value because third-party URLs and intentionally external resources may not belong to the site.

Prevention & how to verify the fix

• Record the site’s canonical HTTPS origin and update both WordPress URL settings during the migration.
• Choose one documented location for the HTTP-to-HTTPS redirect and review other layers before enabling a force-SSL plugin.
• Document whether a CDN or reverse proxy terminates TLS and how the origin learns the original protocol.
• Test the home page, an internal page, login, and the dashboard after each HTTPS configuration change.
• Back up configuration and the database before editing wp-config.php, rewrite rules, or stored URLs.
• After redirects work, run a targeted HTTPS URL migration and check for mixed-content references.

Frequently asked questions