Redirect Errors

About this error category

# Redirect Errors

Redirect errors happen when a request is sent from one URL to another but never reaches a final page, or when it passes through more redirects than necessary. Typical symptoms include ERR_TOO_MANY_REDIRECTS, repeated changes in the address bar, alternating HTTP and HTTPS URLs, or a page that fails to load after several redirects.

Redirects are normally used for valid purposes: enforcing HTTPS, selecting a preferred hostname, moving an old URL, or routing a request to a new path. An error usually appears when redirect decisions conflict between layers or when cached state causes a browser to repeat an outdated result.

Main types of redirect errors

Redirect loops

A redirect loop occurs when the sequence eventually returns to a URL that has already been requested. For example, one rule may redirect HTTP to HTTPS while another treats the HTTPS request as insecure and sends it back to HTTP. The browser follows the cycle until it stops and reports too many redirects.

Loops can also alternate between hostnames, trailing-slash variants, paths, or an application URL and a proxy URL. On WordPress, a loop may begin after an HTTPS migration when the WordPress Address, Site Address, force-SSL setting, proxy handling, and server redirect do not describe the same public URL. See [Too Many Redirects After Moving WordPress to HTTPS](/wordpress-too-many-redirects-https) for that focused case.

Long redirect chains

A redirect chain contains several successive redirects before the request reaches its final destination. An old URL might first redirect to a changed path, then to a preferred hostname, and finally to HTTPS. Chains can be left behind by multiple migrations or overlapping rules.

A chain is different from a loop because it eventually reaches a final response. However, it can make navigation slower and can obscure which rule is responsible for the final destination. The useful diagnostic question is whether each intermediate redirect is still necessary.

Conflicting redirect rules

Redirect behavior may be controlled by a reverse proxy or CDN, hosting platform, web server, content management system, application code, or plugin. These layers can disagree about:

• Whether the original request used HTTP or HTTPS
• Which hostname is canonical
• Whether a path should include a trailing slash
• Whether an old path should be rewritten or redirected
• Which URL should be considered the final application address

A proxy may receive HTTPS from the visitor and forward a different connection scheme to the origin. If the application is not configured to interpret the forwarded scheme correctly, it may issue another HTTPS redirect even though the visitor is already using HTTPS.

Cached redirect or cookie-related behavior

A private browsing test can help separate browser-specific state from a shared configuration problem. Cookies, cached responses, or application session state may preserve an older domain, login flow, or protocol decision. This does not prove that the server configuration is correct; it only shows that the result may depend on stored client state.

If the same URL loops in multiple browsers and on different devices, prioritize the redirect responses and shared configuration rather than repeatedly clearing local data.

How to diagnose a redirect error

1. Record the starting URL and exact symptom. Note the scheme, hostname, path, trailing slash, browser message, and whether the address changes repeatedly.
2. Test a fresh browser session. Use a private window or clear the affected site’s cookies and cached data. Compare the result with another browser or device when possible.
3. Trace the redirect history. Browser developer tools or an HTTP header inspection tool can show each response and its Location target. Identify the status returned at every step and look for a repeated URL, alternating scheme, changing hostname, or unnecessary intermediate address.
4. Classify the pattern. A repeated address indicates a loop. A sequence that ends at a page indicates a chain. A switch between HTTP and HTTPS points toward protocol handling; a switch between hostnames or paths points toward canonicalization or migration rules.
5. Check the public URL settings. Confirm that the application’s configured site URL matches the scheme and hostname visitors are intended to use. On WordPress, compare the WordPress Address and Site Address instead of changing only one value.
6. Review redirect layers from the outside inward. Check the CDN or reverse proxy, hosting settings, web-server rules, application configuration, and redirect or SSL plugins. Look first at the layer that generated the unexpected Location response.
7. Isolate recent changes carefully. If the problem began after enabling HTTPS, changing a domain, migrating a site, editing permalinks, or installing a plugin, compare those changes with the redirect sequence. Disable or alter a rule only when you have authorization and a way to restore the previous configuration.
8. Retest the original and final URLs. Use a fresh session after each controlled change. Confirm that the original URL reaches the intended destination and that the final URL no longer redirects unnecessarily.

What to check first

The error began after enabling HTTPS

Start with protocol handling. Check where HTTPS is terminated, whether the application receives the expected secure-request information, and whether more than one layer is enforcing HTTPS. Look for a rule that redirects an already-secure request back to HTTP or causes the application to issue a second HTTPS redirect.

The error began after a domain or migration change

Compare the old and new hostnames, scheme, path, and trailing-slash behavior. Review migration redirects and application URL settings together. A partially updated hostname or a redirect that still targets the old domain can create a loop or a long chain.

Only one browser or user is affected

Test without the affected site’s cookies and cached data. If the problem disappears, investigate stored session or redirect state before changing shared server rules. If it persists across browsers and devices, focus on the response headers and common proxy, server, or application configuration.

The redirect chain reaches the page but is unusually long

List every intermediate URL and determine which rule introduced it. Consolidate outdated migration rules where appropriate, while preserving intentional redirects and checking that old URLs still reach the correct final destination.

Vendor documentation to consult

For implementation-specific details, consult the documentation for the web server, reverse proxy or CDN, hosting platform, content management system, and redirect or SSL plugin involved in the request. Search those documents for HTTPS termination, forwarded protocol headers, canonical host redirects, redirect precedence, and cache invalidation. The correct setting depends on which layer receives the original request and which layer generates each redirect.