--- title: "How to fix ERR_TOO_MANY_REDIRECTS in WordPress | WP Ministry" url: https://wpministry.co/errors/err-too-many-redirects/ description: "The site keeps sending the browser between addresses and never to a page. Two parts of the setup disagree about the site's address, usually over https or www." lang: en-US --- Skip to content # How to fix ERR_TOO_MANY_REDIRECTS in WordPress ERR_TOO_MANY_REDIRECTS means the site keeps sending the browser from one address to another and never to a page. Two parts of the setup disagree about the site's address, usually over https or www. Find the addresses the loop runs between, then make WordPress and the server agree. By WP Ministry Published October 7, 2026 Tested on WordPress 7.1.4, PHP 8.3.36 ## In short - Your content is untouched. Two parts of the setup disagree about the site's address and pass visitors back and forth. - Test in a private window first. A browser can keep following a redirect the site no longer sends. - A redirect checker shows each hop. How the looping addresses differ, by www or by https, points at the cause. - WordPress sends visitors to the www or non-www form in its Site Address. The server must not send them to the other. - Behind a CDN or proxy that connects to your server over plain http, WordPress has to be told the visitor is on https. - If the addresses agree, look for a redirect rule in .htaccess, then for a redirect or SSL plugin. `ERR_TOO_MANY_REDIRECTS` means the browser asked for a page, was sent on to another address, then another, and gave up because the chain never reached a page. Chrome heads it "This page isn't working" and says your domain "redirected you too many times." Firefox heads it "The page isn't redirecting properly". Two parts of the setup disagree about the site's address, and each keeps sending the visitor to the other. Nothing has been lost. Your posts, pages and uploads are as they were, and every fix below changes a setting, not your content. ## See which addresses the loop runs between Put your site's address into the redirect checker (https://wpministry.co/tools/redirect-checker/). It shows what an address answers and every redirect on the way: each hop, its status code and where it sends you next. In a loop, the last hop leads back to an address already in the list. Look at how the addresses in the circle differ. - **One has `www` and the other does not.** WordPress and the server each insist on a different form of the domain. Use the second fix. - **One is `http` and the other `https`, or an `https` address redirects to itself.** Something forces https and never sees it arrive. If a CDN or proxy sits in front of the site, use the third and fourth fixes. If none does, use the fifth. - **Neither.** Use the fifth fix, then the sixth. If the login page loads and comes back empty after you press Log In, that is a different fault: see the login page that keeps refreshing or redirecting (https://wpministry.co/errors/login-page-refreshing-and-redirecting/). ## Where it goes wrong A page request passes through each of these in turn. This one comes from **the web server**. 1. Browser 2. DNS 3. HTTPS 4. CDN or firewall 5. Web server (this error comes from here) 6. PHP 7. WordPress 8. Database and files ## What causes it - ### WordPress and the server want different forms of the domain Common WordPress sends every visitor to the form of the domain in its Site Address, with www or without. If the host, a CDN or a server rule sends visitors to the other form, each hands the visitor back to the other. Fix: Give WordPress the form of the address the server uses - ### A CDN or proxy connects to your server over plain http Common The visitor's https connection ends at the proxy, which asks your server for the page over http. WordPress, or a rule on the server, answers by redirecting to https. The proxy asks over http again. Fix: Tell WordPress the visitor is on https, or Have the CDN or proxy connect to your server over https - ### A redirect rule in .htaccess contradicts WordPress or the proxy Sometimes A rule that forces https or one form of the domain loops when WordPress's address names the other form, or when the rule tests for https behind a proxy that has already removed it. Fix: Replace .htaccess with WordPress's standard one - ### A redirect or SSL plugin sends visitors in a circle Sometimes A redirect plugin can hold a rule that points an address back at itself. A plugin that forces https or www can contradict what the server does. Fix: Switch off the redirect or SSL plugin - ### The browser is following a stored redirect or a bad cookie Sometimes A browser may store a 301 and follow it again without asking the server. Chrome and Firefox both name cookies as a cause of this error. The site can be fixed and one browser still loop. Fix: Try a private window, then delete the site's cookies ## How to fix it ### Try a private window, then delete the site's cookies - Easy - No risk - About 5 minutes A browser may store a 301 redirect and follow it again without asking the server. Chrome and Firefox both name cookies as a cause of this error. So test in a private window, now and after each fix below. 1. #### Step 1: Open the site in a private window In Chrome this is an Incognito window. Chrome removes an Incognito session's cookies and site data when the session ends, so each one starts clean. 2. #### Step 2: If the site loads there, delete its cookies in your usual browser Chrome's own help for this error says to try deleting your cookies. Delete the cookies and cached files stored for your site's address, then reload. 3. #### Step 3: If it fails there too The loop is on the site. Go to the next fix. ### Give WordPress the form of the address the server uses - Takes care - Back up first - About 15 minutes - Steps tested on WordPress 7.1.4 WordPress stores two addresses, "WordPress Address (URL)" and "Site Address (URL)". It redirects a visitor who arrives at the `www` form of the domain to the form without, or the other way round, to match the Site Address. If your host or CDN redirects to the opposite form, the two never agree. The checker's hops show both forms. Give WordPress the one your host or CDN is set up for. 1. #### Step 1: Open wp-config.php It is in the site's main folder, beside the `wp-content` folder. 2. #### Step 2: Add these two lines above "That's all, stop editing" Replace `https://example.com` with the address the server uses: the same `https`, the same `www` or none, and no slash at the end. wp-config.php Copy ``` define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' ); ``` 3. #### Step 3: Reload the site If it loads, the saved addresses were the cause. The two lines overrule the addresses in the database without changing them. With WP-CLI, read the saved addresses: bash ``` wp option get home wp option get siteurl ``` And correct them: bash ``` wp option update home 'https://example.com' wp option update siteurl 'https://example.com' ``` How to change your WordPress URL (https://wpministry.co/blog/change-wordpress-url/) covers the dashboard and the database as well, and replacing an old address stored in your content. **To undo it:** Remove the two lines from wp-config.php, or set the old values again. ### Tell WordPress the visitor is on https - Takes care - Back up first - About 10 minutes - Steps tested on WordPress 7.1.4 This applies when a CDN, a load balancer or another proxy takes the visitor's https connection and asks your server for the page over plain http. When the WordPress Address begins with `https`, WordPress insists on https for the login page and the dashboard. A request for either that arrives over http is redirected to its https address. Behind such a proxy every request arrives over http, so those two loop while the rest of the site loads. If every page loops, a rule in `.htaccess` or a plugin is forcing https as well: do this fix, then the last two. A proxy can say what the visitor used in a header named `X-Forwarded-Proto`. These lines make WordPress count such a request as https. 1. #### Step 1: Add these lines to wp-config.php, above "That's all, stop editing" wp-config.php Copy ``` if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) { $_SERVER['HTTPS'] = 'on'; } ``` 2. #### Step 2: Open the login page in a private window If the login form appears at `/wp-login.php`, WordPress's own loop is gone. If nothing has changed, your proxy does not send that header. Ask its support which header says the visitor used https. **To undo it:** Remove the three lines from wp-config.php. ### Have the CDN or proxy connect to your server over https - Takes care - Low risk - About 15 minutes The lasting arrangement is https all the way to your server. WordPress and the server's rules then see https for themselves. On Cloudflare the setting is the SSL/TLS encryption mode. Its documentation says that in Flexible mode it sends requests to your server over HTTP, and that redirect loops occur if the server redirects all HTTP requests to HTTPS. It gives two ways out: remove the https redirects from your server, or change the mode to Full or higher, which needs a certificate on your server. 1. #### Step 1: Check that your server has a certificate of its own Ask your host if you are not sure. A mode that connects to your server over https requires one. 2. #### Step 2: Change the mode in the CDN's or proxy's settings Other services name the setting differently. Look for how the service connects to your server, which it may call the origin. 3. #### Step 3: Reload the site in a private window If it loads, the plain http connection was the cause. **To undo it:** Set the proxy's mode back to what it was. ### Replace .htaccess with WordPress's standard one - Easy - Back up first - About 5 minutes - Steps tested on WordPress 7.1.4 This applies to sites on Apache or LiteSpeed. nginx has no `.htaccess`: its rules are in the server's own configuration, so ask the host to look there for a redirect. 1. #### Step 1: Download a copy of .htaccess It sits in the site's main folder, beside `wp-config.php`. Its name begins with a dot, so turn on "Show hidden files" if you cannot see it. 2. #### Step 2: Replace everything in it with this This is what WordPress itself writes for a site at the root of its domain. .htaccess Copy ``` # BEGIN WordPress RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress ``` 3. #### Step 3: Reload the site If it loads, a rule in the old file was the cause. Put your other rules back one section at a time from the copy. Leave out the ones that force https or `www`, and let one place decide each: WordPress's address for `www`, the CDN or the host for https. If WordPress is installed in a subfolder, such as `example.com/blog`, two lines carry the folder's name: `RewriteBase /blog/` and `RewriteRule . /blog/index.php [L]`. How to set up redirects in WordPress (https://wpministry.co/blog/set-up-wordpress-redirections/) explains how these rules are written and how loops and chains start. **To undo it:** Put your copy of the old .htaccess back. ### Switch off the redirect or SSL plugin - Takes care - Low risk - About 15 minutes - Steps tested on WordPress 7.1.4 1. #### Step 1: Rename the plugin's folder In your host's file manager or over SFTP, open `wp-content/plugins` and add `-off` to the name of the plugin's folder. The plugin can no longer load. If you cannot tell which plugin it is, rename the whole `plugins` folder instead. 2. #### Step 2: Reload the site If it loads, that plugin was sending visitors round. 3. #### Step 3: Open the Plugins screen, then rename the folder back Renaming alone does not switch a plugin off: named back, it loads again at once. Opening the Plugins screen while the folder is renamed makes WordPress deactivate what it cannot find. After that the plugin stays off, with its settings kept, until you activate it. Over SSH, the rename is one command from the site's main folder. Use the plugin's folder name in place of `plugin-name`, here and below. bash ``` mv wp-content/plugins/plugin-name wp-content/plugins/plugin-name-off ``` WP-CLI deactivates a plugin with its folder left as it is: bash ``` wp plugin deactivate plugin-name ``` Before you switch the plugin on again, decide what it should do. A redirect list must not hold an address that points back at itself. An option that forces https or `www` must match what the server and WordPress's address already do. **To undo it:** Rename the folder back, or activate the plugin again. ## When to get help If a private window still loops when the addresses agree, .htaccess is the standard one and every plugin is off, the redirect is added outside WordPress. It can be the host's own server configuration or a redirect rule at the CDN. Finding it takes access to those accounts and reading what every hop answers. ## Common questions Why did it start when I moved to https or added a CDN? A likely reason is that a CDN or proxy now takes the https connection and asks your server over plain http. Whatever on the server redirects http to https then does so on every request, and the visitor never arrives. The third and fourth fixes deal with it. With no CDN or proxy in front of the site, look at the fifth and sixth. The site loads for other people and loops for me. Why? Your browser is following something it stored: a redirect the site used to send, or a cookie. The first fix clears it. Why do only the login page and the dashboard loop? WordPress insists on https for those two when the WordPress Address begins with `https`. Behind a CDN or proxy that asks your server over http, they loop even while the rest of the site loads. The third fix covers it. ## More on this subject - WordPress errors and troubleshooting: https://wpministry.co/topics/wordpress-troubleshooting/ - Guide WordPress uptime monitoring: what a check sees and what it misses: https://wpministry.co/blog/wordpress-uptime-monitoring/ - Guide How to update the PHP version of a WordPress site: https://wpministry.co/blog/update-php-version-wordpress/ - Glossary term .htaccess: https://wpministry.co/glossary/htaccess/ - Guide Locked out of WordPress admin: find which lockout you have and get back in: https://wpministry.co/blog/locked-out-of-wordpress-admin/ - Glossary term Must-use plugin (mu-plugin): https://wpministry.co/glossary/must-use-plugin/ - Glossary term Permalink: https://wpministry.co/glossary/permalink/ ## Would you rather we fixed it? Emergency Fix is $99. Site down or checkout broken. Goes to the front of the queue. No fix, no fee. 30-day warranty. More about this work: Emergency WordPress support (https://wpministry.co/services/emergency-support/) May we measure how this site is used? A yes notes the pages of this visit and loads Google Analytics. A no keeps and loads nothing. See the cookies page (https://wpministry.co/legal/cookies/). If you say yes, we note the pages you look at during this visit and load Google Analytics. If you say no, nothing is kept and nothing is loaded. The site works the same either way. The cookies page (https://wpministry.co/legal/cookies/) has the details. ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://wpministry.co/#organization", "name": "WP Ministry", "url": "https://wpministry.co/", "logo": "https://wpministry.co/brand/logo.png", "address": { "@type": "PostalAddress", "streetAddress": "1309 Coffeen Ave STE 1200", "addressLocality": "Sheridan", "addressRegion": "WY", "postalCode": "82801", "addressCountry": "US" }, "sameAs": [ "https://www.linkedin.com/company/wp-ministry/", "https://x.com/wpministryco", "https://www.instagram.com/wpministryco/", "https://www.facebook.com/wpministryco", "https://www.tiktok.com/@wpministryco", "https://www.pinterest.com/wpministryco/", "https://www.youtube.com/channel/UCOZRuAukk5QSTRPG6BaHl3Q" ] }, { "@type": "WebSite", "@id": "https://wpministry.co/#website", "name": "WP Ministry", "url": "https://wpministry.co/", "inLanguage": "en-US", "publisher": { "@id": "https://wpministry.co/#organization" } }, { "@type": "TechArticle", "@id": "https://wpministry.co/errors/err-too-many-redirects/#article", "headline": "How to fix ERR_TOO_MANY_REDIRECTS in WordPress", "description": "The site keeps sending the browser between addresses and never to a page. Two parts of the setup disagree about the site's address, usually over https or www.", "url": "https://wpministry.co/errors/err-too-many-redirects/", "mainEntityOfPage": "https://wpministry.co/errors/err-too-many-redirects/", "inLanguage": "en-US", "image": "https://wpministry.co/og/errors/err-too-many-redirects.png", "author": { "@id": "https://wpministry.co/#organization" }, "publisher": { "@id": "https://wpministry.co/#organization" }, "datePublished": "2026-10-07T00:00:00.000Z", "dateModified": "2026-10-07T00:00:00.000Z" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://wpministry.co/" }, { "@type": "ListItem", "position": 2, "name": "Error fixes", "item": "https://wpministry.co/errors/" }, { "@type": "ListItem", "position": 3, "name": "How to fix ERR_TOO_MANY_REDIRECTS in WordPress" } ] } ] } ```