How to detect redirect loops on simple websites

A simple website can hide surprisingly complicated behaviour behind a single “Click here” link. The visible page may contain almost no information, yet the link can send a visitor through several HTTP responses, append a tracking parameter, or return the browser to the same address repeatedly. When that happens, the page may appear to load forever, flash briefly, or produce a browser message about too many redirects.

Redirect loops are especially easy to miss when testing only one browser or clicking the link once. A cached response, an existing cookie, or a mobile network can change the result. A reliable check therefore needs to examine the full redirect chain, compare URLs carefully, and distinguish a genuine loop from an intentional tracking redirect.

For an Australian audience, this matters across small business landing pages, campaign microsites, affiliate links, and temporary promotional domains. A visitor in Sydney using a phone on a commuter train may experience the problem differently from someone on a home NBN connection in Perth. Slow or unstable connections can make a chain feel broken before the browser displays a clear error.

The site described here offers too little evidence to establish its purpose or services. Its basic link appears to redirect visitors within the same domain using a tracking-style query parameter, so the safest approach is to test observable behaviour rather than guess what the site is meant to do. The methods below apply to similarly minimal websites.

Understand what a redirect loop looks like

A redirect is a server instruction telling the browser to request another address. Common status codes include 301 and 308 for permanent moves, and 302, 303, and 307 for temporary or method-preserving moves. A normal chain may go from an old page to a secure version, then to a preferred hostname, and finally to the destination. A loop occurs when the chain returns to a URL already visited or cycles between two or more addresses.

The loop may be obvious, such as page A sending the browser to page B while page B sends it back to page A. It can also be concealed by query parameters. For example, /go might redirect to /go?ref=abc, which then redirects to /go?ref=abc&ref=abc, with each request creating another variation. A browser may stop after a limit, while command-line tools reveal the repeated pattern more clearly.

Record the full redirect chain

Start with browser developer tools. Open the Network panel, enable preservation of requests, and activate the link. Look for entries marked 301, 302, 303, 307, or 308. Select each response and inspect its Location header, which identifies the next address. Record the scheme, hostname, path, query string, and fragment separately rather than relying on the shortened display.

The command line provides a cleaner repeatable test. A command such as curl -I https://example.com/path requests headers, while curl -IL --max-redirs 20 https://example.com/path follows redirects and limits the number of hops. Replace the example address with the tested URL. If the output repeats the same Location values, or reaches the maximum redirect count without returning a final response, the chain deserves investigation.

Do not test only the link’s visible label. Copy the actual target from the page source or inspect the click event in developer tools. A JavaScript handler may construct a destination dynamically, add a campaign identifier, or make a second request after the initial page loads. This distinction helps separate an HTTP redirect loop from a client-side navigation loop.

Compare URLs beyond their appearance

Two addresses can look almost identical while behaving differently. Compare http and https, www and the bare domain, uppercase and lowercase paths, trailing slashes, URL-encoded characters, and the order of query parameters. A server may treat /click and /click/ as different resources, while an application assumes they are equivalent and redirects between them.

Query strings require particular attention on tracking-style links. Parameters such as utm_source, ref, clickid, or a generated token may be added on every request. If the destination redirects back to a URL that causes the same parameter to be added again, the chain can grow indefinitely. Copy several successive addresses into a text editor and mark what changes at each step.

A useful diagnostic is to remove one parameter at a time and repeat the request, provided the test does not affect a real transaction. If the clean path works but the tracked path loops, the issue probably lies in parameter handling, campaign middleware, or a destination rule. Never remove security or authentication values from a live account workflow simply to make a test pass.

Check browser state and caching

Cookies and local storage can create conditions that are absent in a private window. A site may send one version of a redirect to a first-time visitor and another after a cookie has been set. Test in a normal window, a private window, and a second browser, then compare the chains. Clearing cookies for the domain can show whether an old session or malformed preference is influencing navigation.

Caching can produce the opposite problem: an old 301 response may continue directing visitors long after a rule has been corrected. Use a cache-disabled Network-panel setting during testing, and check response headers such as Cache-Control, Age, ETag, and Via. A content delivery network may also retain a redirect at an edge location even after the origin server has changed.

This is relevant in Australia because visitors may be served by different points of presence around Sydney, Melbourne, Brisbane, Adelaide, or Perth. A regional edge cache can make a redirect fault appear intermittent. Testing from more than one network, such as home broadband and a mobile connection, helps identify whether the issue is global or limited to a cached or geographically selected response.

Separate server loops from script loops

A server-side loop appears in the Network panel as repeated HTTP responses, usually with a Location header. A script-driven loop may return successful 200 responses while JavaScript repeatedly assigns window.location, calls history.replaceState, or reloads the page. The browser may show a blank screen or a rapidly changing address without reporting a standard redirect error.

Disable JavaScript temporarily and load the target again. If the loop disappears, inspect the Console for exceptions and the Sources panel for navigation code. Look for code that adds a tracking parameter every time the page runs, checks a cookie that is never written, or redirects when a required referrer is missing. A content security policy report can also reveal blocked scripts that leave navigation logic in an incomplete state.

Single-page applications need an additional check. Their internal route changes may look like redirects but do not create ordinary HTTP hops. Watch whether the browser makes new document requests or only fetches API resources. A repeated API request is a separate fault from a document redirect loop, although both can leave visitors waiting indefinitely.

Use independent tools and clean test cases

A browser is useful for reproducing the visitor experience, but it can hide details. Header inspection services, command-line requests, and automated tests can expose each response in sequence. Run the same address with and without a user-agent string, because some websites send different routes to desktop browsers, mobile devices, crawlers, or social-media previews.

Keep a small test record containing the starting URL, timestamp, network, browser, status code, Location value, and final result. Include whether cookies, JavaScript, and cache were enabled. This makes a report actionable for a developer and helps identify a loop that happens only after a campaign parameter is present. A screenshot alone rarely proves the cause.

When reviewing a secure destination, verify that HTTP is upgraded once to HTTPS and that HTTPS does not redirect back to HTTP. Guidance on secure protocol use can provide useful background, although the redirect chain itself should still be checked directly. An HTTPS certificate warning is not the same as a redirect loop, but it can interrupt testing and should be recorded separately.

Interpret tracking and destination behaviour

A link that adds a query parameter is not automatically faulty. Tracking systems commonly redirect from a short path to an internal handler, register a click, and then send the visitor to a final page. The chain becomes problematic when the handler treats its own tracking URL as a fresh untracked request, or when the final page sends the visitor back to the handler.

Compare the first request with the final intended destination. A legitimate chain should converge on a stable address and stop with a 200 response or another expected result. If an interactive destination is involved, examine its canonical URL rather than assuming the redirect target explains the content; a link to an online slots page illustrates why destination identity and redirect mechanics should be assessed separately.

For a small Australian operator, test campaign links used in email, QR codes, social posts, and paid search independently. A URL copied into a printed flyer may include a stale parameter, while a Google Ads landing page may receive additional tracking values. Check whether the chain changes when the link is opened from a Brisbane office network, a Melbourne mobile device, or an overseas test point, while avoiding unnecessary clicks that could trigger a commercial action.

Fix and verify the navigation path

The cleanest fix is usually to define one canonical destination and make each rule point directly to it. Remove competing rules that separately force HTTPS, choose a hostname, add a slash, append tracking data, and select a campaign landing page. Several individually reasonable rules can form a cycle when their assumptions conflict.

Preserve tracking parameters deliberately. The redirect handler should recognise an existing parameter rather than append a new copy on every request. Validate destination URLs, prevent user-controlled open redirects, and ensure cookies are written with settings compatible with the site’s scheme and domain. If authentication is involved, check session and SameSite behaviour rather than weakening security settings.

After a change, retest with a clean browser, an existing-cookie session, JavaScript enabled and disabled, and at least two networks. Confirm that the chain ends consistently, that the final URL does not keep changing, and that status codes match the intended permanence. Repeat the check after cache expiry if a CDN or reverse proxy is involved. A simple site should produce a simple, finite path from click to destination.