[Resolved] Infinite redirect loop on multi-domain setup

# WPML Support Ticket — Infinite redirect loop on multi-domain setup

**Subject suggestion:** Infinite redirect loop on ~250 URLs in multi-domain setup (sloneek.com EN sibling) — sitewide impact, X-Redirect-By: WordPress confirmed

---

## Site setup

- **Primary install:** sloneek.cz (Czech)
- **Language siblings (multi-domain mode):** sloneek.com (EN), sloneek.sk (SK), sloneek.it (IT), sloneek.pl (PL)
- **Hosting:** Kinsta (managed WordPress + Nginx + Cloudflare in front)
- **WPML license:** Multilingual CMS / Lifetime (please verify in your records, account email: ondrej.lamcha@sloneek.com)
- **WPML features in use:** Multi-domain mode, "Auto sign-in and sign-out users from all domains" (suspected related)

## Issue summary

A sitewide infinite redirect loop on hidden link (EN sibling) is causing ~250 URLs to fail to load. Visitors get ERR_TOO_MANY_REDIRECTS, Googlebot logs them as "Redirect error" in GSC, and the issue started approximately 10 May 2026.

The hosting provider (Kinsta) has confirmed that the redirects are NOT happening at the Nginx layer. Response header `X-Redirect-By: WordPress` is present on the redirects, meaning a WordPress-level component (core or plugin) is calling `wp_redirect()` / `wp_safe_redirect()`. We are reaching out to WPML support first because:

1. The affected sibling site (sloneek.com EN) is part of WPML's multi-domain configuration
2. The loop reproduces in clean incognito with no cookies, suggesting server-side language detection logic rather than user session
3. The recent trigger correlates with cleanup of legacy redirects, which may have exposed a pre-existing WPML interaction

## Reproduction

Open any of the affected URLs in clean incognito (no cookies, no auth):

- hidden link
- hidden link
- hidden link

Expected: page loads with status 200
Actual: browser shows "Too many redirects" / ERR_TOO_MANY_REDIRECTS

Alternative reproduction in DevTools Console (any clean profile):

```js
fetch('hidden link', { redirect: 'follow', credentials: 'omit' })
.then(r => console.log(r.status, r.url))
.catch(e => console.error('Failed:', e.message));
```

Result: "Failed: Failed to fetch" (Chrome hits its internal redirect limit)

## Affected URLs (13 verified reproducible, ~250 per GSC total)

```
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
hidden link
```

Note: both `/url` and `/url/` variants loop, so trailing-slash normalization may be involved.

## What we've confirmed

- **Loop is server-side, plugin-level:** Confirmed by Kinsta hosting team via response header `X-Redirect-By: WordPress`
- **Not Nginx / hosting:** Kinsta has reviewed and ruled out their layer
- **Not session-dependent:** Reproduces in clean incognito with `credentials: 'omit'`
- **Affects only the EN sibling (sloneek.com):** sloneek.cz primary loads normally; other siblings not yet tested in detail
- **Reproducible across all 13 sampled URLs**, consistent with sitewide impact reported by GSC (~250 URLs)
- **Timing:** Started approximately 10 May 2026, coinciding with cleanup of legacy redirects (sloneek.com → sloneek.cz site-level redirect was removed; ~1,200 legacy /hc/* redirects on the primary)

## Our hypothesis (please validate or replace)

Suspected interaction between WPML language detection / multi-domain routing and one of:

- Recent change in language URL configuration
- "Auto sign-in and sign-out users from all domains" cross-domain session sync
- WPML's canonical URL handling on the EN sibling after the sloneek.com → sloneek.cz redirect was removed

## What we'd like from you

We do not have an internal WordPress developer and prefer not to toggle WPML settings on production without your guidance. Specifically:

1. **Server-side analysis:** Based on the symptoms, can you identify which WPML setting / code path is most likely generating the `wp_redirect()` call? Pointing us at a specific filter, hook, or config option would be ideal.
2. **Safe diagnostic steps:** If you need us to enable a debug option or share configuration, please specify exactly which one and how to revert if needed.
3. **Access:** We can provide temporary WP admin access (with WPML settings visible) and Kinsta hosting access for log review. Please confirm what you need.
4. **Recommended fix path:** Once root cause is identified, we'd appreciate a recommended config change or patch we can implement (with you watching) or a developer recommendation if it's beyond standard support scope.

## Supporting information we can share on request

- Full Screaming Frog response codes export (3,369 URLs crawled)
- GSC "Redirect error" list (~250 URLs)
- Hosting access logs from Kinsta for affected URLs
- WordPress plugin list with versions
- WPML configuration screenshots
- Timeline of recent infrastructure changes

## Business impact

This is high-severity for us:

- ~250 indexed URLs unreachable to users and Googlebot
- Direct traffic conversions effectively zero on .com (visitors can't reach landing pages)
- MQL pipeline impacted, potential revenue loss
- Paid campaign spend on affected URLs wasted

We've paused affected paid campaigns and would appreciate prompt attention. Happy to jump on a call or screenshare.

---

**Contact:**
Ondrej Lamcha
ondrej.lamcha@sloneek.com
Sloneek s.r.o.