When Chrome shows "This page isn't working, the site redirected you too many times" with the code ERR_TOO_MANY_REDIRECTS, the site's redirect rules contradict each other. One rule sends the browser from HTTP to HTTPS, another sends it back, and the loop never ends, so after a few dozen hops the browser gives up. Firefox calls the same thing "the page isn't redirecting properly". The cause is almost always a configuration you can see directly.
Trace the redirect chain
Before guessing, look at where the server actually sends you. curl prints each response and its next location:
curl -sIL --max-redirs 10 http://example.uz | grep -iE "^HTTP|^location"If two addresses alternate, such as https://example.uz/ and http://example.uz/, those two rules form the loop. If www.example.uz and example.uz alternate, the www rules are fighting. This one command often reveals the cause immediately.
HTTPS redirects behind a proxy
The most common case involves a proxy like Cloudflare in "Flexible" SSL mode. The visitor connects to the proxy over HTTPS, but the proxy talks to your server over plain HTTP. The server sees HTTP and replies "go to HTTPS", the proxy passes that back, the browser returns over HTTPS, and the cycle repeats. Switch the proxy to "Full (strict)", which requires a valid certificate on the server; a free Let's Encrypt certificate on the hosting is enough. If the proxy must stay as it is, a server rule can detect the original scheme from the X-Forwarded-Proto header, but only trust that header behind a proxy you control.
Duplicate or conflicting .htaccess rules
Site owners often add an HTTPS rule to .htaccess, then install a plugin doing the same, then enable a redirect in the panel too. If one sends to www and another away from it, you get a loop. Define the scheme and canonical host once, in one rule, at the top of the file:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.uz%{REQUEST_URI} [L,R=301]This sends everything to the non-www HTTPS address. If your site should use www, invert the condition, but never keep both variants.
WordPress address settings
WordPress stores siteurl and home in the database. If they say http://www.example.uz while the server forces https://example.uz, WordPress keeps sending the browser back to "its" address. Without admin access, force the values in wp-config.php:
define('WP_HOME', 'https://example.uz');
define('WP_SITEURL', 'https://example.uz');With SSH and WP-CLI you can check and fix the database directly:
wp option get siteurl
wp option get home
wp option update siteurl 'https://example.uz'
wp option update home 'https://example.uz'Also check plugins that force HTTPS or manage redirects; renaming a plugin folder quickly shows whether it is involved.
A real-world example
After a private school in Tashkent moved its site to a new domain, the homepage stopped loading. curl showed the server sending http to https, WordPress redirecting to the old domain, and the old domain redirecting back to the new one. A stale home value in the database was to blame. Updating it to the new HTTPS address and clearing the cache fixed the site at once. Most post-migration redirect loops come from old addresses left in the database.
Clear caches and cookies
Browsers remember 301 redirects for a long time, so the error may persist for you after the server is fixed. Test in a private window or with curl, clear the browser cache and site cookies, and purge any page cache plugin. If everything looks correct and the loop remains, contact support from the sayt.uz cabinet and include the curl output.