Event website says “too many redirects” after a domain change: trace the loop

Keep a verified attendee route available

Download the redirect-loop trace and repair sheet (Markdown, English)

Confirm whether the public event page, registration and ticket links are affected. If a direct ticket destination still works, use a verified owned channel to point attendees there while the website owner repairs the loop. Keep event date, venue and support contact available through an approved route. Do not ask visitors to bypass browser warnings or keep retrying an unusable checkout.

Record one failing URL and one clean comparison

Save the hostname, path, language, safe query-parameter names, browser message, time and device. Redact tokens, ticket codes and personal values in the shared sheet; keep full URLs only in the owner’s restricted diagnostic system. Try the same public GET page in a fresh browser or another approved device, without submitting attendee or payment data. If only one browser fails, record its cookie or cache difference before touching shared rules. If both fail, ask the site owner for a short trace of the exact URL in that restricted system.

Trace the redirect chain

HTTP redirects return a 3xx status and a Location destination. In a browser network log or a limited GET trace, record each safe URL shape, status and Location for a short, bounded number of hops. Stop at the first repeated URL or the last observed hop if no URL repeats. Redact token-bearing values before copying the chain into a shared sheet. Include the first working or failing response, not just the final browser error. Compare `http`/`https`, `www`/apex, old/new domain, locale and trailing slash. A DNS record points traffic to a service; it does not by itself explain which web rule emitted a Location header.[1]

Avoid tracing a checkout submission with a command that could repeat a purchase or form action. Use public page GETs and ask the ticketing provider for its own safe diagnostic path if the loop begins after checkout.

Identify the layer that owns the conflicting rule

List recent domain, edge/CDN, hosting, CMS, application and language-routing changes. Match the first repeated hop to its rule owner instead of deleting every redirect. For example, an edge forcing HTTPS while an origin sends HTTPS back to HTTP can loop; Cloudflare documents this for particular encryption-mode and origin combinations. Its settings are provider-specific. Do not weaken TLS, disable HSTS or choose an encryption mode from a generic checklist without the host and certificate owner verifying the architecture.[2]

Make one reviewed correction with a reversal path

Have the responsible owner record the current rule, intended final URL and rollback method. Correct only the confirmed conflict, then publish through that provider’s normal change path. A browser cache or cookie clear may help a single stale client, but it cannot repair a repeated server-side Location chain. If the trace crosses two vendors, hand both the same timestamped chain and agree which layer owns the final redirect before either changes settings.

Retest the links attendees actually use

Check the old announcement URL, new event page, each language route and the published ticket button on phone and desktop. Each should reach the intended event edition and date without cycling; test the attendee task up to the provider’s safe pre-purchase point. Re-run the redirect trace for the originally failing URL and log its final destination, status, owner and time. Then update controlled emails, QR destinations and partner links that still point at the broken route. Keep monitoring reports for a short agreed window.