You type your own web address, the browser thinks for a second, and then gives up. In Chrome the page says “This page isn’t working. example.com redirected you too many times.” with the code ERR_TOO_MANY_REDIRECTS underneath. Firefox words it differently: “The page isn’t redirecting properly.” Safari says it cannot open the page because too many redirects occurred.
Whatever the wording, the site has not been deleted and your content is almost certainly still in the database. Something is sending the browser in a circle, and the browser has stopped following it. The job is to find which two settings are arguing with each other.
What a redirect loop actually is
A redirect is the server saying “not here, go there instead”. That is normal. WordPress redirects http:// to https://, or www to the bare domain, all day long, and nobody notices because each one happens once.
A loop happens when address A sends the browser to address B, and address B sends it straight back to A. Sometimes the loop has three or four steps rather than two, but the shape is the same. Browsers follow a limited number of hops before they stop and show the error, which is why you see a message instead of a page that spins forever.
The useful thing to know is that there are usually two layers involved, and they disagree. One layer might be WordPress itself, a plugin, the .htaccess file, the hosting control panel, or a CDN such as Cloudflare. Each one is trying to be helpful. Together they cancel each other out.
Where you see the loop tells you a lot
Before changing anything, write down exactly where the error appears:
- The whole site, every page. Usually an HTTPS or domain setting: the WordPress address, an SSL mode at the CDN, or a forced redirect at the host.
- Only wp-admin or the login page. Often cookies, a security or login plugin, or a mismatch between the two address fields in WordPress. That variant has its own write-up on the login page that keeps reloading.
- One page or one section. Usually a redirect rule someone added in a plugin, pointing a page at itself or at an address that redirects back.
- Only on one device or browser. Very likely stored cookies or a cached redirect in that browser, not the server at all.
The usual causes, most likely first
1. The CDN and WordPress disagree about HTTPS
This is the classic one for sites behind Cloudflare. If Cloudflare’s SSL mode is set to Flexible, Cloudflare talks to the visitor over HTTPS but talks to your server over plain HTTP. WordPress sees an HTTP request, decides it should be on HTTPS, and redirects. Cloudflare passes that redirect to the browser, the browser asks again over HTTPS, Cloudflare asks your server over HTTP again, and round it goes.
The fix is usually to install a proper certificate on the server (most hosts include one) and set Cloudflare’s SSL mode to Full (strict), so both legs of the journey use HTTPS.
2. The WordPress Address and Site Address don’t match reality
Under Settings → General WordPress keeps a pair of addresses, labelled WordPress Address (URL) and Site Address (URL). If they say http:// while the host forces https://, or they say www.example.com while the host forces the bare domain, you have two layers pulling in opposite directions. This often appears right after an SSL certificate is added or a domain is changed, which is why it shows up so often in the list of problems that follow a move to a new host or domain.
3. A reverse proxy hides the fact that the visitor used HTTPS
Some hosting setups put a load balancer or proxy in front of the server. The visitor connects over HTTPS, but PHP only sees the inner connection and thinks the request was plain HTTP. WordPress keeps “upgrading” a request that was already secure. The proxy normally passes the original scheme in a header called X-Forwarded-Proto, and WordPress needs to be told to read it.
4. A redirect, SSL or security plugin
Plugins that force HTTPS, redirect www, manage 301 rules, or hide the login page all issue redirects. Install two of them and they can fight. A redirect rule pointing /shop/ to /shop while WordPress adds the trailing slash back is a small example of the same thing.
5. Duplicate rules in .htaccess or the host panel
On Apache and LiteSpeed servers, the .htaccess file in your site’s root can contain hand-written redirect rules. Hosting panels often have their own “force HTTPS” or “preferred domain” switch as well. If an old rule sends traffic to www and the panel sends it away from www, that is a loop.
6. Browser cookies and cached redirects
Browsers remember permanent (301) redirects. If the site briefly had a bad redirect, the browser may keep replaying it even after the server is fixed. Stale login cookies can do the same to the admin area.
Fixing it, safest steps first
Work down this list in order. The first two change nothing on the server at all. Before you edit any file or setting further down, make a copy of what is there now: download the file, or screenshot the setting. If you have a hosting backup tool, take a fresh backup too, so a wrong edit can be undone in minutes.
Step 1: Rule out your own browser
Open the site in a private or incognito window, or try your phone with Wi-Fi switched off. If it loads there, clear cookies and cached files for your domain in your normal browser and try again. This alone fixes a surprising share of cases.
Step 2: Trace the hops
Put the address into our free redirect checker. It lists each hop and its status code, so you can see the pattern, for example https://www → https:// → https://www. Once you can see which two addresses are bouncing, you know which two layers to look at.
Step 3: Check the CDN’s SSL mode
If you use Cloudflare or a similar service, check the SSL/TLS setting before touching WordPress. Change Flexible to Full (strict) only once you have confirmed the server has a valid certificate. If you are unsure, pausing the CDN temporarily is a quick way to see whether it is involved.
Step 4: Correct the two WordPress addresses
If you can reach wp-admin, set both fields under Settings → General to the exact address you want visitors to use, scheme and www included. If you can’t reach the dashboard, you can pin them in wp-config.php. Place these two lines higher in the file than the “That’s all, stop editing!” comment:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
Use your real domain. These lines override the database values, and the fields in Settings → General become greyed out while they are present. Once the site works and you’ve corrected the values in the dashboard, you can remove them again or leave them in deliberately.
Step 5: Tell WordPress about the proxy, if there is one
If your host confirms the site sits behind a proxy or load balancer, a small addition near the top of wp-config.php lets WordPress recognise HTTPS requests:
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) { $_SERVER['HTTPS'] = 'on'; }
Only add this when you know a proxy is in front of the site. Ask the host first; it is a fix for one specific setup, not a general cure.
Step 6: Switch off plugins without the dashboard
Using your host’s file manager or FTP, go to wp-content and rename the plugins folder to something like plugins-off. WordPress then loads with every plugin deactivated. If the loop stops, rename the folder back to plugins (the plugins stay inactive) and reactivate them one by one from the dashboard, starting with anything related to SSL, redirects, caching, security or login. The one that brings the loop back is your culprit.
Step 7: Reset .htaccess
Rename .htaccess to .htaccess-old. If the loop disappears, the old file contained a conflicting rule. Go to Settings → Permalinks and press Save to let WordPress write a fresh default file, then re-add any genuine custom rules carefully, one at a time. Be aware that some security and caching plugins store rules in this file, so read the old copy before deciding what to keep.
Step 8: Check the hosting panel
Look for “force HTTPS”, “redirect to www” or “preferred domain” options in your hosting control panel. Keep one place in charge of each decision. If the host forces HTTPS, you don’t also need a plugin doing it.
When the redirect goes somewhere you don’t recognise
A loop between your own addresses is a configuration problem. A redirect that sends visitors to a different site, especially one selling pills or showing “you have won” pages, is not. That is usually injected code, and changing settings will not remove it. If that matches what you see, read about a site redirecting to spam pages before you touch anything else, because cleaning up the symptom alone tends to leave the way back in open.
Keeping it from coming back
- One owner per decision. Choose one layer to handle HTTPS (usually the host or the CDN) and one to handle www vs non-www. Remove the duplicates.
- Change domains and certificates on a copy first. Moving to HTTPS or a new domain is when most loops are born. Testing on staging catches them before visitors do.
- Keep redirect rules in one place. A single redirect plugin or a single section of
.htaccess, not both, with a note of why each rule exists. - Fix mixed content properly. People sometimes add HTTPS-forcing plugins to hide insecure images and scripts on an HTTPS page, and that extra plugin then becomes the loop. Fixing the underlying links is cleaner.
Knowing when to stop
Suppose you’ve worked through the browser checks, the two addresses and the plugins, and the loop is still there. Then the conflict is probably at the server, the proxy or the CDN, where a wrong edit can take the site offline for everyone. The same applies when the redirect points to a domain you don’t own. For a broader view of related problems, our guide to common WordPress errors groups them by symptom.
If the loop is keeping you out of your own dashboard, our help for WordPress login problems is the closest fit. Send the error and the address on WhatsApp or the contact form, and we’ll tell you honestly what we see before anything is changed.
Next in this series: WordPress Memory Exhausted Error: Causes and Fixes
