If you see the too many redirects wordpress error, the browser is caught in a redirect loop: it keeps being told to request another URL and never reaches a final page. The safest fix is to identify which layer is sending the repeated redirect before adding or changing another rule.
Start by finding out how wide the failure is. Test the same address in a private window, another browser, or another network, then check wp-login.php and wp-admin separately. If only one browser fails, start with cookies and cached responses. If only the login or admin area fails, focus on login security, cache, URL, and proxy handling. If the whole site fails for every client, trace the public redirect chain before editing WordPress, server files, or the database. This split gives the rest of the article a safe order: diagnose first, then change one reversible layer at a time.
TL;DR: Test the site in a private window and inspect the redirect path before changing settings. Then make WordPress, the server, and any CDN agree on one HTTP/HTTPS choice, domain name, optional connection number, and path. Backup your site before editing files or the database. If the redirects are unexpected or return after you’ve fixed the configuration, scan your WordPress site for malware to rule out malicious redirects.
If the site redirects to an unfamiliar domain, spam page, or unexpected mobile destination, treat it as a possible WordPress security incident. Preserve a backup and evidence before trying to clean it up.
Start with the safest checks
Begin with checks that do not change the site. First find out whether the problem is local or site-wide.
Refresh the page and test another client
- Test the same address in a private window: Open the page in a private window, another browser, or another network. If it works everywhere except your usual browser, stale WordPress session cookies or a saved redirect are plausible causes.
- Clear only the affected site’s browser data: Remove the site’s cookies and cached files, then test again. Clearing browser data can remove stale information, but it cannot repair a loop that every visitor receives.
- Compare the failure across visitors: If the homepage fails everywhere, record the address, destination, and last change. Common triggers include an HTTPS change, migration, plugin or theme update, cache setting, CDN change, or server rule.
Clear the relevant caches, not every layer at once
- Purge the cache that matches the symptom: Clear browser data for a browser-only failure, follow a guide to clear WordPress cache for a plugin-generated response, purge a CDN cache for an edge-wide failure, or use the host cache when your host controls it. A cache is a saved response that may keep serving an old redirect. If optimization settings create other side effects, Airlift’s safe WordPress performance optimization guide recommends changing one major setting at a time and retesting.
- Retest after each purge: Change one layer at a time. A permanent redirect, also called a 301, may remain cached after its rule is fixed. A purge can also hide an active rule until the next request, so a temporary improvement is not proof of a repair.
Trace the redirect loop before changing settings
The browser message tells you that the chain did not settle. The Location response header, which tells the browser where to go next, shows which addresses are taking turns. Browser developer tools can show the same sequence under the Network panel, so use them if a terminal is not available.
Inspect the public address with a redirect limit: Run this diagnostic command from a terminal. It reads the response headers and follows no more than 10 redirects.
curl -I -L --max-redirs 10 https://example.com/Look for a repeated pattern: Watch for:
- http and https switching;
- www and non-www switching; or
- two paths sending visitors back to each other.
Stop before an unfamiliar destination: Do not follow a suspicious domain just to collect more output; if the first Location points somewhere unexpected, rerun the check without -L. Redact private addresses before sharing headers. The goal is not zero redirects. A normal redirect can send an old address to one final HTTPS address. The goal is a stable final response with the intended HTTP/HTTPS choice, domain name, connection number if used, and path.
Check WordPress URL settings
WordPress uses two important addresses. WP_SITEURL identifies where the WordPress core files are installed. WP_HOME is the public address visitors use. A standard installation usually uses the same HTTPS domain name for both, but a deliberate subdirectory setup may use different paths.
Compare every part of both addresses: Check each of these values:
- the HTTP/HTTPS choice;
- the domain name;
- the connection number, if shown; and
- the path.
Do not replace a valid subdirectory path with the root domain.
Check the dashboard fields when access works: Open Settings > General and compare WordPress Address (URL) with Site Address (URL). A clean WordPress 6.9.4 installation running PHP 8.3 and MySQL 8.0 used the same HTTPS domain in both fields. Its homepage returned HTTP 200, the normal success response, and Site Health reported Good with four recommended improvements.
🧭 Note: Site Health is useful evidence, not proof that every redirect rule is correct.
Inspect the configuration file when an incorrect WordPress URL leaves the dashboard unavailable: Look in wp-config.php for WP_HOME and WP_SITEURL. Use the exact public address, including a required subdirectory. These fixed settings override matching database values but do not update them. If the file also contains FORCE_SSL_ADMIN, check that its behavior matches the site’s HTTPS and proxy setup. Remove temporary changes after access returns.
Handle migration changes with a backup and preview: Check the database’s home and siteurl values, then look for old domains, HTTP/HTTPS choices, ports, or paths in plugin settings and content. Use a serialization-aware tool, which preserves saved WordPress settings, and preview replacements first. Do not use broad SQL on an unfamiliar database. Old http links may need updating, but mixed content alone does not prove a redirect loop.
For a WP-CLI replacement, preview the result before writing anything:
wp search-replace 'http://old.example.com' 'https://example.com' --dry-runThe correct replacement depends on the site’s table prefix, path, host, and stored data. Take a backup and remove temporary wp-config.php constants after access returns so they do not hide the database values during later troubleshooting.
Isolate plugins and themes safely
A redirect, security, membership, or caching plugin can enforce HTTPS, a preferred domain, a login route, or a preferred path. If the problem began after a plugin or theme change, test that component before editing the database.
Deactivate the suspected component from the dashboard: Use a clean browser session and test again. If the dashboard is unavailable, use a file manager or SFTP, a secure way to manage site files, to rename wp-content/plugins temporarily. This stops WordPress from loading the plugins without deleting them.
Restore and narrow the test immediately:
- Rename the folder back after testing.
- If the loop stops, reactivate plugins one at a time and check each redirect, cache, login, and HTTPS setting.
- Treat renaming the whole folder as an isolation test, not proof that every plugin is faulty.
- Use the same reversible approach for a recently changed theme.
⚠️ Note: Take a full backup before disabling production components. Do not leave the site running with its security, cache, or login plugins disabled.
Inspect server redirects
Apache .htaccess, a per-site file that controls web-server rules, and Nginx, another web server, can redirect a request before WordPress runs. A WordPress rule, host rule, and plugin rule can each look reasonable alone and still form a loop together.
Back up and rename .htaccess temporarily: Do not delete it. Renaming it can affect page addresses, access restrictions, and security rules. Test briefly, then restore the file and inspect the conflicting conditions.
After access is restored, regenerate WordPress rewrite rules only after the conflicting rule is understood. Regenerating them without identifying the conflict can put the same loop back in place.
Review server rules before adding another HTTPS rule: Do not paste a new HTTP-to-HTTPS redirect over unknown rules. If the repeated response comes from Nginx, a load balancer, a service that spreads traffic across servers, or another managed service, the rule may not be inside WordPress at all. Ask the host which layer emits each Location header instead of continuing to edit WordPress files.
Make HTTPS and third-party settings agree
HTTPS must be enforced through one coherent path. A common conflict occurs when a CDN, a network that serves cached copies to visitors, accepts HTTPS but sends HTTP to the hosting server, while the server sends HTTP back to HTTPS.
Check the CDN and hosting server as one system: Review these settings together:
- the CDN’s connection setting, edge redirects, and cache or optimization rules;
- the server’s force-HTTPS rules; and
- the HTTP/HTTPS choice WordPress receives.
Change one setting, purge its cache, and test from a clean client.
Correct a Cloudflare Flexible conflict carefully: Flexible mode uses HTTP between Cloudflare and the origin, which is the hosting server. If the origin forces HTTP to HTTPS, the two layers can loop. Remove the conflicting origin redirect or use Full or Full (strict) when the origin has a valid certificate installed on the hosting server. Full (strict) can still loop if the origin sends HTTPS back to HTTP or another edge rule conflicts.
Verify the proxy’s original-protocol signal: A load balancer or reverse proxy may handle HTTPS before passing the request to WordPress. WordPress needs a trustworthy X-Forwarded-Proto value, a server message recording whether the visitor used HTTP or HTTPS. The value must come from the trusted proxy, not from an arbitrary visitor. Do not add proxy code to a site that connects directly to its host.
🔌 Note: The clean WordPress site used for the baseline had no CDN or reverse proxy, so these cases depend on the site’s architecture. If you cannot inspect that architecture, the host or CDN provider should identify the redirecting rule.
Fix an admin-only redirect loop
When the public site works, focus on the login and admin addresses instead of changing the homepage settings blindly. Test wp-login.php and wp-admin separately.
Separate normal login behavior from a loop: A logged-out request to wp-admin normally sends you to wp-login.php with a return address. On a fresh WordPress 6.9.4 site, opening /wp-admin/ produced a redirect to /wp-login.php?redirect_to=...&reauth=1; after browser login, the same session returned to /wp-admin/. That is a working login flow, not an error.
Check cookies and private-session behavior: If the login form keeps returning after valid credentials, check the login path independently from the public homepage:
- cookies and cache exclusions for login and admin addresses;
- HTTPS enforcement and the two WordPress URLs;
- proxy settings; and
- recently changed authentication or membership plugins.
Treat API failures as a separate signal: A WordPress API, a way for another tool to communicate with the site, returned 200 for its public index and 401, meaning not authenticated, for the current-user check, while browser login worked. A separate content-creation request returned “Sorry, you are not allowed to create posts as this user.” No content was created. Do not mistake an API authentication or permission error for proof that the browser redirect has the same cause.
Investigate server errors separately: If wp-admin returns a server error or permission response instead of redirecting, inspect hosting settings and which account controls the files. Never set permissions to 777 as a generic fix. Unexpected permission changes may require security review.
When a redirect may indicate malware
An ordinary HTTPS loop does not mean the site was hacked. Investigate suspicious redirects when they lead to an unrelated domain, spam page, or unexpected mobile destination, or return after the URL, plugin, server, and proxy settings are correct.
Preserve evidence before cleaning:
- Keep a known-good backup.
- Avoid deleting files or database rows that may show how the redirect was added.
- Check recently changed files, scheduled tasks, WordPress user activity, administrator accounts, saved database values, and server rules.
Use a WordPress malware scanner plugin for suspicious or recurring redirects: MalCare’s scanner can inspect files, database tables, and scheduled tasks from its own infrastructure. It can help find injected redirects, but it does not repair Cloudflare settings, Nginx rules, Apache rules, or mistaken WordPress URLs.
Escalate a clearly malicious redirect: If the site serves spam, sends visitors to a dangerous domain, or becomes infected again after cleanup, follow a hacked website repair process or involve the host or a WordPress security professional. Keep the site controlled while you investigate instead of changing unrelated settings repeatedly.
Verify the repair and prevent a repeat
Make one change at a time and record the previous value. After each change, test the paths that matter to visitors and administrators.
- Test the preferred HTTPS homepage and both domain versions: Check the preferred address, then test the www and non-www versions if both exist.
- Test a real internal page and the login path: Confirm that a representative page, wp-login.php, and wp-admin behave as expected while logged out and after login.
- Inspect the final response from a clean browser and terminal: Confirm that the headers end at the intended address and do not alternate between HTTP/HTTPS choices, domains, or paths.
To prevent another loop, keep full backups before migrations and major updates, test plugin and theme changes on a staging copy, document one preferred address, review CDN and hosting-server rules together, and preview URL replacements. For a broader prevention pass, use a WordPress security checklist. Keep WordPress, plugins, and themes current, then review unexpected administrator accounts, scheduled tasks, and file changes.
Contact the host when the chain points to a managed server rule, load balancer, visitor filter, or proxy header you cannot inspect. Contact the CDN provider when its edge rule or connection setting is outside your access. If the layer remains unclear, stop changing settings and provide the host with the address, response headers, timestamps, and last known-good change.
Conclusion
The safest fix for ERR_TOO_MANY_REDIRECTS is to find the layer sending the repeated address, then correct one setting at a time. Start with a private-window test and the Location chain. Compare WordPress URLs with server, CDN, and proxy behavior before editing files or the database.
Back up first and keep changes reversible. For ongoing prevention, use a WordPress security maintenance checklist. Escalate managed infrastructure or suspicious redirects when the cause remains unclear. A clear chain usually turns the outage into a specific configuration problem.
