A WordPress too many redirects error means the browser keeps receiving another destination instead of reaching the page. You might see ERR_TOO_MANY_REDIRECTS, or a message that the page is not redirecting properly. The safest first step is to identify the repeating request, not change both WordPress addresses or switch off every plugin.
This guide separates a whole-site HTTPS loop from a login-only problem, a conflicting domain rule and an old browser response. You can collect the first evidence without editing the live site. Then you can choose the person or setting that actually owns the repair.
First, decide whether this is a redirect loop
A page can redirect once and work normally. For example, an old public address may send a visitor to the current HTTPS address. A loop is different: the browser never arrives at a usable final page. It may alternate between two addresses or repeatedly request what looks like the same address.
If the browser shows a certificate privacy warning before opening the page, use the SSL certificate recovery guide instead. Do not bypass that warning. If the page opens but images, fonts or scripts fail because they use HTTP, start with the WordPress mixed-content guide. Neither symptom alone proves a redirect loop.
Also distinguish a redirect to an unfamiliar spam site. That requires a different investigation from a loop between your own addresses. Preserve evidence and follow the hacked redirect guidance; do not assume this article’s configuration checks will remove malware.
Use the loop pattern to choose the next check
This is an owner decision table, not a diagnosis of your site. Record the pattern before changing anything. More than one layer can produce the same visible symptom.
| What repeats | What to investigate | First safe action |
|---|---|---|
| HTTP and HTTPS versions of the same page | Conflicting HTTPS enforcement or proxy-to-origin configuration | Ask the host to confirm origin HTTPS and identify the rule sending requests back to HTTP. |
| www and non-www addresses, or old and new domains | Two layers choosing different final hostnames | Write down the intended public hostname and compare the competing redirect destinations. |
| The same HTTPS address appears repeatedly | The application may not recognize a secure request behind a proxy | Ask the host to verify how the trusted proxy communicates the original request scheme. |
| Only wp-admin or the login page loops | Login cookies, authentication redirects, site addresses or HTTPS recognition | Test one private window, then record whether public pages still load. |
| One old page loops while other pages work | A route-specific redirect or canonical rule | Inspect that route’s redirect entry and its destination, not every plugin. |
| Only one existing browser session fails | Stored cookies, a cached redirect or a browser-specific condition | Compare a fresh session on the same URL before editing production. |
A private window is a comparison, not proof that the server is correct. Browser security policies, network conditions and extensions can still affect results. If an ordinary public page fails in fresh sessions on more than one device, treat it as a site-side investigation until the evidence says otherwise.
Collect a small redirect record before making changes
Start with one ordinary public page. Avoid account, payment, password-reset and signed download links when collecting or sharing evidence. Those addresses can contain sensitive information.
- Record the start. Note the public address you entered, the time and timezone, and the last known successful visit.
- Record the scope. Check the homepage, one article and the login screen without repeatedly submitting credentials. Note which pages fail.
- Record the last change. Examples include a domain move, SSL change, new CDN, redirect edit or authentication plugin update. Timing is a lead, not proof.
- Capture the first repeat. In browser developer tools, open Network, enable Preserve log and reload the public page. Look at document requests and their redirect destinations.
- Stop collecting when the pattern is clear. A short redacted sequence is more useful than a large unreviewed browser export.
Chrome documents the Network panel, including preserving requests across page loads and inspecting request details. If that interface is unfamiliar, send your host the failing public URL and ask for the redirect sequence. You do not need to learn server administration to request the right evidence.
A simple worksheet for the host or developer
| Record | What to provide | What to leave out |
|---|---|---|
| Affected route | A public page and the intended final hostname | Reset tokens, private account links and checkout session URLs |
| Repeating steps | Request address, response status and next destination for the first few document requests | Cookies, authorization headers and an unredacted HAR export |
| Scope comparison | Public pages versus login, fresh session versus existing session | Customer details or passwords |
| Change record | Time of the last SSL, hosting, domain or redirect change | API keys and hosting login details |
| Recovery boundary | Who can reverse the identified change and whether a current backup exists | An instruction to reset every setting without diagnosis |
For example, a redacted sequence might read: https://example.com/page/ sends to the www version, and that version sends straight back. This is an illustrative pattern, not a Webless incident or a test result. It tells the investigator to compare hostname rules before changing content.
If Cloudflare was added or SSL settings changed
Cloudflare’s redirect-loop documentation identifies encryption-mode conflicts and competing redirect rules as possible causes. In Flexible mode, the connection from Cloudflare to the origin uses HTTP. If the origin insists on redirecting that request to HTTPS, the request can keep repeating.
Do not randomly cycle through SSL modes until the homepage opens. First have the host confirm that the origin serves HTTPS correctly. Cloudflare’s Full (strict) requirements include an unexpired certificate, a matching hostname and a trusted issuer or Cloudflare Origin CA. A mode change made without those prerequisites can replace one failure with another.
Keep the intended public URL on HTTPS. Do not turn off certificate validation, remove security protections, pause the CDN or expose the origin as a routine shortcut. Ask the responsible administrator to align the proxy connection and origin rules, with a rollback for the exact setting changed.
A response that passed through Cloudflare does not prove Cloudflare created the redirect. The origin, a WordPress plugin or the hosting configuration may have generated it. Ask which layer emitted the redirect and what evidence identifies that layer.
If WordPress cannot recognize HTTPS behind a proxy
The public browser can use HTTPS while WordPress sees a different connection from an upstream proxy. WordPress’s HTTPS administration handbook warns that this mismatch can create an infinite redirect loop when SSL enforcement is enabled.
This is configuration work for the host or developer who knows the actual proxy path. They must verify the trusted proxy and how secure-request information reaches WordPress. Do not paste a forwarded-header snippet from an unrelated installation into your configuration. Accepting untrusted client headers can create a separate security problem.
Likewise, do not automatically make WordPress Address and Site Address identical. Some installations deliberately keep WordPress in a different directory from the public site. The correct values depend on the installation, not on a generic repair checklist. Record current values and ask the host to compare them with the intended topology.
If only the WordPress login keeps redirecting
When public pages work, protect that working path. Do not disable caching, commerce plugins or the whole security stack merely because wp-admin is unavailable. WordPress’s login troubleshooting guidance identifies cookies, address settings, HTTPS and proxy configuration as relevant checks.
Try a fresh browser session once. If it works, compare site-specific cookies and the original session before clearing data for every website. Clearing this site’s cookies will sign you out. If the fresh session also loops, give your host the login route, exact error and public-page comparison.
For a recent authentication or membership change, ask the maintainer to reproduce it on staging and inspect the responsible redirect. Preserve access controls and working customer sessions. A successful administrator login is not proof that customer login, logout and protected pages still behave correctly.
Fix one owner, then clear the relevant caches
Assign the repair to the layer supported by the evidence: the host for origin HTTPS and server rules, the CDN administrator for an edge rule, or the WordPress developer for an application redirect. One person should coordinate the changes if those roles belong to different providers.
Before a material edit, save the exact rule or record and a current recoverable backup. Avoid replacing the entire database or server configuration for one identified conflict. Revert or correct the smallest responsible change, then test the same public route again.
Only after the source behavior is correct should you purge relevant object, page-optimization, host and CDN caches. Not every site uses every layer. Rebuild page caches where appropriate and compare a fresh browser visit with the normal clean URL. A harmless cache-busting query can be supporting evidence, but it is not guaranteed to bypass every cache.
Never restore an old production database just to undo a redirect without assessing newer orders, leads and content. Our backup restore test guide explains why a usable recovery path matters before a risky change.
When to stop and get professional help
Stop changing settings when the next step requires unknown proxy configuration, a live database edit, loss of administrator access or an untested rollback. Also escalate when checkout, customer accounts or several domains are involved. Record the failing path and preserve the current evidence rather than experimenting on transactions.
You do not need a paid repair if a site-specific browser-session reset resolves the issue and fresh visits remain healthy. Professional help becomes useful when the loop spans multiple layers, you cannot identify its owner, or the business cannot safely tolerate another configuration experiment.
Prove the loop is gone before closing the incident
- The affected clean URL reaches the intended HTTPS page without repeating destinations.
- The intended www or non-www variant resolves consistently on a fresh session.
- The homepage and representative content pages load, not just the administrator dashboard.
- Login, logout and any affected customer journey work using an authorized test process.
- Mobile menus, images and forms render correctly after caches rebuild.
- The canonical points to the intended public URL and no temporary noindex setting remains.
- The change record identifies the cause, the exact repair and the rollback owner.
Use staging, sandbox payments or a separately authorized production test for transactional checks. Do not create an unintended order or submit real customer information as part of diagnosis.
For prevention, keep a simple register of who owns domain redirects, HTTPS enforcement, hosting and WordPress changes. Include those routes in post-update checks. Webless WordPress maintenance is the ongoing-care conversation; an active outage needs its own assessment and agreed repair scope.
The practical answer: capture the first repeat, find the responsible layer, make one reversible correction and verify the business paths that matter. Clearing every cache or weakening HTTPS without that evidence can hide the cause rather than fix it.