How to Fix the ERR_TOO_MANY_REDIRECTS Error on Your WordPress Site

Encountering an error message on a production website disrupts revenue operations, harms SEO indexation metrics, and degrades user trust. Among the diagnostic hurdles website administrators and DevOps engineers face, the ERR_TOO_MANY_REDIRECTS error—commonly designated as an HTTP redirect loop—represents a particularly frustrating challenge. When this condition manifests, browsers trap the execution thread in a continuous cycle of HTTP status code exchanges (typically 301 Moved Permanently, 302 Found, or 307 Temporary Redirect). The browser exhausts its maximum redirect threshold, aborts the request connection, and displays an unrecoverable failure state to the end user.

Resolving this infrastructure anomaly requires a systematic dissection of the HTTP request lifecycle, the underlying web server configuration blocks, database-level options storage, proxy termination rules, and application-level routing logic. This guide provides a comprehensive, engineering-level methodology for diagnosing, isolating, and permanently mitigating infinite redirect loops within modern WordPress environments running on Nginx, Apache, or enterprise cloud platforms.

Problem Statement & Impact

The ERR_TOO_MANY_REDIRECTS exception occurs when an inbound HTTP client request triggers a circular chain of server responses. For example, a request to http://example.com/ instructs the client to redirect to https://example.com/ via web server rules. Upon receiving the secure connection, application-level logic (such as WordPress core or a security plugin) interprets the request as insecure or mismatched against stored parameters, issuing a secondary instruction to redirect the client back to http://example.com/. This initiates an infinite loop.

This failure pattern impacts various environments across the WordPress ecosystem, including:

• Core WordPress Core Installations: Misaligned application constants or database entries concerning URL schemes.
• Plugin & Theme Layers: Hardcoded SSL enforcement logic, geoblocking extensions, multilingual redirection controllers, or caching engines with stale edge configurations.
• Web Server Stacks: Conflicting rewrite rules inside Apache .htaccess files, Nginx server block blocks, or upstream reverse-proxy configurations.
• Cloud Edges & CDNs: SSL termination mismatches between origin servers and edge proxies (e.g., Cloudflare Flexible SSL mode paired with a strict HTTPS origin).

The business consequences of unmitigated redirect loops are severe. Search engine crawlers (such as Googlebot) encountering redirect loops will rapidly drop crawling frequency, demote page rank, and eventually remove the affected URLs from the index. Simultaneously, user acquisition funnels break entirely, resulting in immediate conversion loss and operational friction.

Root Cause Analysis & Architecture

To understand why redirect loops occur, examine the WordPress HTTP request lifecycle. When an HTTP request hits the infrastructure edge, it traverses several layers before rendering HTML:

1. Edge Proxy / CDN Layer: Intercepts public traffic, handles TLS termination, and forwards requests to the origin server.
2. Web Server Layer (Nginx/Apache): Evaluates configuration files, virtual host directives, and directory-level override rules.
3. PHP-FPM & WordPress Bootstrap: Executes wp-load.php, initializes database connections, and loads active plugins.
4. Application Routing & Canonicalization: WordPress core checks whether the requested URL matches the values stored in the database for siteurl and home. If a mismatch occurs, or if functions like force_ssl_admin() evaluate to true on an unproxied HTTP connection, WordPress issues a redirect header.

If any single component in this execution chain enforces HTTPS while a downstream component assumes HTTP, an infinite loop is generated. For instance, if Nginx passes requests to PHP-FPM without setting the HTTP_X_FORWARDED_PROTO header, WordPress views every incoming secure connection as an unencrypted HTTP request. If the WordPress installation is configured to force SSL, it responds with a 301 redirect back to HTTPS. Nginx receives the HTTPS request, forwards it to PHP via HTTP, and the loop repeats indefinitely.

Step-by-Step Implementation & Remediation Guide

Resolving this error requires isolating each layer of the web stack. Execute the following remediation steps systematically.

1. Diagnostic Verification via cURL

Before modifying configurations, inspect the exact HTTP headers and redirect path using the command line. This eliminates browser cache interference and reveals the exact URL targets driving the loop.

curl -I -L https://yourwebsite.com

Analyze the output for repeating sequences of status codes:

HTTP/1.1 301 Moved Permanently
Location: http://yourwebsite.com/
HTTP/1.1 301 Moved Permanently
Location: https://yourwebsite.com/
HTTP/1.1 301 Moved Permanently
Location: http://yourwebsite.com/

This output confirms an explicit schema mismatch between the web server and the application layer.

2. Correcting WordPress Application URLs

The most common root cause is a mismatch between the WordPress Address and Site Address configurations. If you have database access, query the options table directly using the MySQL CLI:

mysql -u db_user -p db_name -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');"

If the values show http:// while your site requires https://, update them immediately via SQL or force them inside the wp-config.php file.

To enforce correct URLs at the application level, inject the following constants directly above the “That’s all, stop editing!” line in your wp-config.php file:

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

Additionally, if your site sits behind a load balancer or reverse proxy that handles SSL termination, you must instruct WordPress to recognize the proxy headers to prevent internal loop generation. Add this snippet to wp-config.php:

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

3. Debugging and Resetting Apache .htaccess Files

On Apache-based hosting environments, malformed rewrite rules or conflicting HTTPS enforcement blocks inside the .htaccess file frequently trigger redirect loops.

Access your server via SSH or SFTP, navigate to your web root, and temporarily rename the file:

mv .htaccess .htaccess_backup

Test your website. If the error disappears, your rewrite rules were corrupted. A standard, clean WordPress .htaccess file should strictly adhere to the following structure:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Once this file is in place, log into your WordPress administrative dashboard and navigate to Settings > Permalinks, then click Save Changes to flush and regenerate the rewrite rules cleanly.

4. Verifying and Hardening Nginx Server Blocks

If your WordPress infrastructure runs on Nginx, ensure your server block properly handles HTTPS termination and passes appropriate headers to PHP-FPM. A misconfigured Nginx SSL block often looks like this:

server {
    listen 80;
    server_name yourwebsite.com www.yourwebsite.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourwebsite.com www.yourwebsite.com;

    root /var/www/html;
    index index.php index.html;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        # CRITICAL: Prevent proxy redirect loops by setting HTTPS param
        fastcgi_param HTTPS on;
    }
}

Verify that fastcgi_param HTTPS on; is explicitly defined within your PHP execution block. Omitting this directive when enforcing SSL at the Nginx level is a primary driver of redirect loops in LEMP stack configurations.

5. Resolving CDN and Cloud Proxy Mismatches

When routing traffic through edge proxies such as Cloudflare, Akamai, or enterprise firewalls, SSL encryption modes must match origin server configurations precisely.

• Flexible SSL Mode Issue: If your CDN is configured to use “Flexible” SSL mode (where traffic between the CDN edge and your origin server is sent unencrypted over HTTP), but your WordPress installation forces HTTPS, an infinite loop occurs. The visitor connects via HTTPS to the edge, the edge connects via HTTP to your server, WordPress sees HTTP and redirects to HTTPS, and the loop begins.
• Remediation: Log into your CDN dashboard, navigate to the SSL/TLS settings tab, and upgrade your encryption mode from Flexible to Full or Full (Strict). Ensure a valid origin certificate is installed on your web server.

6. Isolating Rogue Plugins and Themes

Security plugins, SSL enforcement extensions, multilingual routers, and caching layers often implement custom redirect rules that conflict with server configurations. If you are locked out of the WordPress administrative dashboard, disable all plugins via WP-CLI or SFTP.

Using WP-CLI via SSH, execute:

wp plugin deactivate --all --path=/var/www/html

If WP-CLI is unavailable, rename the plugins directory via SFTP or SSH:

cd /var/www/html/wp-content
mv plugins plugins_backup
mkdir plugins
chown www-data:www-data plugins

Check if the site loads. If the redirect loop ceases, restore the original directory name (`mv plugins_backup plugins`) and reactivate your extensions individually through the WordPress dashboard to isolate the offending component.

Production Hardening & Edge Cases

Preventing future iterations of the ERR_TOO_MANY_REDIRECTS error requires implementing defensive infrastructure patterns and maintaining strict configuration controls.

• Avoid Hardcoded Redirects in Theme Functions: Developers frequently write custom redirect loops inside functions.php using conditional checks like if (!is_ssl()) { wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']); exit(); }. Avoid writing raw PHP redirection blocks without checking if a request is already secure or originating from a trusted load balancer, as this bypasses native WordPress canonicalization routines.
• Object Caching and Edge Cache Purging: When modifying site URLs or SSL settings, clear all upstream object caches (Redis, Memcached) and edge CDN caches immediately. Stale edge nodes may continue serving cached 301 responses long after the origin server configuration has been corrected.
• Staging-to-Production URL Migration Safety: When pushing a staging environment to production, database serialization issues frequently occur. If URLs are replaced using raw SQL string replacements instead of a search-and-replace tool that respects serialized data structures (such as WP-CLI’s `wp search-replace`), option arrays containing site URLs become corrupted, causing administrative lockouts and redirect loops. Always use proper serialization-aware commands:

wp search-replace 'https://staging.yourwebsite.com' 'https://yourwebsite.com' --all-tables --path=/var/www/html

Diagnostic Verification & Checklist

Use the following verification matrix to ensure complete remediation across all infrastructure layers before marking the incident resolved.

Monitor your web server access logs in real-time during verification to confirm that incoming requests resolve with an HTTP 200 OK status code rather than repeating 301 or 302 sequences:

tail -f /var/log/nginx/yourwebsite.access.log

By executing this rigorous diagnostic and remediation framework, you ensure complete eradication of redirect loops, maintain strict search engine indexing health, and secure the operational integrity of your WordPress infrastructure.