WordPress Too Many Redirects? Fix URL and HTTPS Loops

You change a WordPress address, enable HTTPS or move hosting. Instead of opening the site, your browser says ERR_TOO_MANY_REDIRECTS, redirected you too many times or the page is not redirecting properly. The useful question is not which plugin promises a quick fix. It is: which addresses keep sending the browser back to each other?

This guide is for a site you own or administer. Keep hosting or SFTP access available before editing an address that could lock you out. Record current settings and confirm a usable backup. On a live store, prefer a targeted configuration rollback: restoring an old database can overwrite newer orders, enquiries and customer accounts.

What the redirect error actually means

A normal redirect tells the browser to request another address. The MDN redirect guide describes the HTTP status and Location header used for that instruction. A loop happens when those instructions repeat without reaching a usable destination. A long, non-repeating chain can also exhaust a client's redirect limit, so count the hops instead of assuming every case is a two-page loop.

• HTTP → HTTPS → HTTP: inspect conflicting HTTPS enforcement or a proxy that hides the original scheme from WordPress.
• Non-www → www → non-www: inspect host forwarding, WordPress addresses and canonical-host rules.
• Old domain → new domain → old domain: inspect migration settings and any rule still sending visitors back.
• Only login/admin repeats: inspect authentication cookies, membership/login rules and HTTPS detection; it may not be a site-wide routing failure.
• Only one page repeats: start with that page's redirect rules rather than changing the site's global address.

These patterns narrow the investigation; they do not prove which product caused it. A certificate warning, a missing-page 404 and a redirect loop are different failures. Use the HTTPS warning guide for certificate problems or the WordPress permalink guide when inner pages return 404 instead of redirecting.

1. Check whether everyone sees the loop

Open the exact affected URL in a private window and, if possible, a second browser or device. Compare the homepage, one ordinary inner page and the login page. Note whether the problem began immediately after a domain edit, SSL change, migration or new redirect rule. A short change history is more useful than randomly toggling settings.

• Only your usual browser fails: investigate that site's stored cookies, cached redirects or an extension before changing the server.
• Several devices fail on the same URL: investigate the shared WordPress, hosting or proxy configuration.
• Only authenticated visitors fail: reproduce with an authorised test account; avoid experimenting with real customers' sessions.

Chrome's site-cookie instructions let you remove data for one site instead of every website. This can sign you out and clear preferences or carts. Treat a private-window success as a clue, not conclusive proof: extensions, cache and session state differ too. If the public site works but wp-admin does not, the login troubleshooting guide covers the access-recovery branch.

2. Record the repeating URLs before changing settings

For a public page, your browser can show each redirect without an extra WordPress plugin. The Chrome Network reference explains request logging and response headers. Labels vary slightly by browser version, but the evidence you need stays the same.

1. 1Open Developer Tools, choose Network and turn on Preserve log before reproducing the failure.
2. 2Load the affected public URL. Inspect its document requests and the Status column rather than unrelated image or analytics requests.
3. 3Select a redirect request and inspect Headers. Record the request URL, response status and Location destination.
4. 4Follow the destinations until you see an address repeat, or note that the chain is simply long. Compare scheme, hostname, path and any non-sensitive parameters.
5. 5Match each instruction to the host redirect panel, CDN rules, WordPress settings or redirect plugin. Response headers may offer clues, but confirm ownership in the actual configuration.

Illustrative trace — not a measurement of a customer's site
1. https://example.com/services/
   301 Location: https://www.example.com/services/
2. https://www.example.com/services/
   302 Location: https://example.com/services/
Result: the original address repeats; two host rules disagree.

In this example, clearing a cache alone does not remove either instruction. The repair is to choose the intended hostname and correct the rule pointing away from it. Do not assume the 302 is automatically wrong: its destination and purpose determine the conflict, not just whether it is temporary.

3. Verify WordPress addresses after a URL change

On a standard single-site installation, check Settings → General. The WordPress settings documentation distinguishes WordPress Address, where the core application lives, from Site Address, the public-facing website. Compare the intended scheme, domain, www choice and any subdirectory with your hosting arrangement.

If the fields are greyed out or your edits appear ineffective, check whether configuration constants control them. The official configuration reference maps WP_SITEURL to WordPress Address and WP_HOME to Site Address. Those constants override database values; they do not rewrite them. Removing an override can reveal the old value again.

• Accidental address edit: restore the confirmed correct setting using an available, authorised access path. Do not perform a whole migration to undo one mistaken field.
• Intentional domain move: verify the new domain, HTTPS certificate and hosting destination first; then align the WordPress addresses and old-to-new redirects.
• Dashboard inaccessible: ask the host or developer to inspect the exact configuration and stored options with a backup. Do not add duplicate constants or guess a database table prefix.

WordPress's migration handbook separates changing an address from moving a complete installation. It also warns about serialized data: a blind SQL text replacement can damage stored settings. Repair the address conflict first; use a migration-aware procedure for any wider content URL replacements.

4. Align HTTPS and proxy settings

A reverse proxy sits between the visitor and WordPress. It may receive HTTPS from the browser and use a different connection to the origin server. If WordPress incorrectly believes an already-secure visitor arrived over HTTP, it can keep redirecting that visitor to the HTTPS URL they already requested.

The WordPress HTTPS handbook describes this reverse-proxy case. Have the host configure HTTPS detection for the actual trusted proxy path. Do not copy a snippet that trusts any incoming X-Forwarded-Proto value: direct-origin requests and client-supplied headers must be handled safely. Forcing the HTTPS flag for every request can conceal an insecure configuration rather than repair it.

If you use Cloudflare, its redirect-loop documentation identifies a specific conflict: Flexible mode uses HTTP to the origin, while the origin keeps redirecting that connection to HTTPS. Other cases involve an origin redirecting HTTPS back to HTTP or conflicting hostname rules. Cloudflare's presence alone does not identify the cause.

• Check the current encryption mode and the actual redirect direction before changing anything.
• Before enabling Full (strict), confirm the origin accepts HTTPS on port 443 and presents an unexpired, hostname-matching certificate from a trusted public CA or Cloudflare Origin CA.
• If validation fails, repair the origin certificate or routing with your host. Do not turn off certificate validation, disable the firewall or remove proxy protection as a generic workaround.

These prerequisites come from Cloudflare's Full (strict) reference. Changing the mode without a ready origin can replace the redirect loop with a certificate error. Keep one documented HTTPS policy across the layers, and remove only the rule that contradicts it.

5. Remove the conflicting rule, not every redirect

List where redirects can be set: hosting panel, CDN, server configuration, WordPress plugins and custom code. Start with the layer changed most recently or named by your trace. A rule forwarding an old page to its replacement is useful; another rule forwarding that replacement back is the problem.

• Redirect or SSL plugin: export its rules or record their current values. Disable the specific conflicting rule first, preferably on staging, then repeat the same trace.
• Login or membership plugin: preserve access controls and test with a suitable account. Do not disable authentication merely to make the redirect disappear.
• Apache rules: back up the configuration and review the relevant redirect with your host. Do not delete or rename the entire .htaccess file blindly; doing so can also remove security and access restrictions.
• Nginx or managed hosting: .htaccess edits may have no effect. Ask whoever controls the active server configuration to inspect its redirect rules.

Avoid deactivating every production plugin at once on a busy store. Payment, stock, forms and access controls can stop working, and the test changes several variables simultaneously. Use an isolated staging copy or a controlled host-assisted window. Keep transactional emails, live payments and fulfilment disconnected from staging tests.

After correcting the conflict, clear the relevant WordPress, host/CDN and browser cache so you are not testing an old redirect response. The cache-layer guide explains why clearing one cache may leave another copy untouched. Record the setting you changed so a future deployment does not quietly put the conflict back.

6. Test the repaired route and important journeys

A working homepage is only the first check. Repeat the original failing request and confirm that its redirects now terminate at the intended page, without revisiting an earlier address. There is no universal requirement for exactly one 301: a login flow or another intentional temporary redirect can be legitimate.

1. 1Check the intended HTTPS homepage and an affected inner page. Confirm the final address, expected content and valid certificate.
2. 2Check the old domain or alternate www form if they are supposed to redirect. Each should reach the correct destination without returning to the source.
3. 3Check login, logout and the relevant account area with an authorised test account. Compare signed-in and signed-out behaviour.
4. 4For stores or booking sites, verify the affected customer journey on isolated staging with sandbox payments and notifications disabled. Do not create real transactions as a casual redirect test.
5. 5Check a second browser or device, then document the final configuration and repeat the trace after any cache purge.

For a permanent URL move, Google recommends permanent server-side redirects. Align internal links, canonicals and sitemap URLs with the intended destinations. Restoring access does not mean Google has already recrawled the page or restored its search visibility. Inspect the affected URL in Search Console and check its latest crawl information; a repair is not a ranking guarantee.

When to involve your host or developer

Stop experimenting when you cannot identify the correct installation, several layers disagree, the origin certificate is invalid, or a fix would weaken customer access controls. Send a short incident note instead of a collection of passwords. The following blank template helps the next person continue from your evidence.

Affected public URL (remove private tokens):
First noticed, with timezone:
Last known configuration change:
Scope: everyone / one browser / login only / one page
Repeating hops: URL → status → Location
Expected final scheme, hostname and path:
Changes already tried and whether reversed:
Backup available and host access confirmed: yes / no
Evidence: redacted screenshots only; no cookies or credentials

For scoped recovery work, WordPress development and fixes can cover the address and application side; website maintenance can cover ongoing checks and change control. The maintenance cost guide distinguishes routine care from a one-off repair. Share the public URL and symptoms to discuss the work without sending account credentials.

Frequently asked questions

Why did WordPress start redirecting after I changed its URL?

A stored address, configuration override or existing host/plugin rule may still point to the previous destination. Compare the actual repeating hops with both WordPress address fields and any WP_HOME or WP_SITEURL overrides. Preserve a legitimate subdirectory arrangement instead of forcing both fields to match.

Will clearing cookies fix a redirect loop?

It can help when the problem is limited to browser or session state. It will not repair two server rules that send every visitor back and forth. Test a private window first and clear only the affected site's data where possible.

How can I fix wp-admin if I cannot log in?

Use an authorised hosting or SFTP recovery path to inspect the address and HTTPS configuration, or ask the host to do it. Keep the existing values and a backup. An admin-only loop can involve authentication or proxy settings; changing the entire site's URLs is not automatically the right fix.

Does a redirect loop hurt Google indexing?

A loop can prevent Google from fetching the intended page. Fix the route, check the final page's canonical and indexing settings, and review URL Inspection for the next crawl. Neither a successful browser test nor a sitemap submission guarantees indexing or a particular position.

Sources and review scope

Prepared on 24 October 2026 using the linked WordPress, browser, Cloudflare and Google documentation. The trace uses the reserved example.com domain and is a worked explanation, not a customer incident or measured repair. The photographs are contextual stock images, not WordPress screenshots. The evidence template is for your own observations; this article does not claim access to your hosting configuration or promise a recovery time.