A WordPress redirect loop is the browser telling you that two parts of your site disagree about what the correct URL is, and neither will back down. Chrome calls it ERR_TOO_MANY_REDIRECTS. Firefox says the page is not redirecting properly. Underneath both messages is the same thing: URL A sends the browser to URL B, and URL B sends it back to URL A, forever.
Every guide on this covers the fix. Almost none cover the part that costs money, which is what Google does with a looping URL while you work out which plugin caused it. This post does both.
Why does my WordPress site keep redirecting?
Because there is more than one place in a WordPress stack that can issue a redirect, and they do not know about each other. Six places, and the loop is nearly always two of them arguing: the Site Address and WordPress Address fields in Settings, General; WP_HOME and WP_SITEURL in wp-config.php, which override those fields; rules in .htaccess or the nginx server block; a redirect plugin with a rule someone added and forgot; an SSL plugin forcing https; and the host or CDN forcing https or www at the edge, before WordPress runs at all.
The classic version: your host forces https://example.com at the edge while your Site Address says http://www.example.com. Each rewrites to what it believes is correct, and together they describe a circle. RFC 9110, the HTTP specification, has a line worth keeping in mind while you debug: “A client SHOULD detect and intervene in cyclical redirections.” The browser stopping is the browser doing its job.
Why does only wp-admin loop?
If the front end loads and /wp-admin/ or wp-login.php bounces you forever, you almost certainly have FORCE_SSL_ADMIN set behind a proxy. WordPress documents that constant plainly: it “can be set to true in the wp-config.php file to force all logins and all admin sessions to happen over SSL.”
It then documents the loop by name, which is the sentence I wish more SSL plugin authors had read: “If WordPress is hosted behind a reverse proxy that provides SSL, but is hosted itself without SSL, these options will initially send any requests into an infinite redirect loop.”
That is the whole login loop. A CDN, load balancer or managed host terminates https at the edge and passes plain http to PHP. WordPress checks $_SERVER['HTTPS'], sees nothing, decides the admin session is insecure and redirects to https, and the edge sends the same request straight back. The documented fix teaches WordPress to read the header the proxy sets:
define( 'FORCE_SSL_ADMIN', true );
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false )
$_SERVER['HTTPS'] = 'on';That belongs above the “stop editing” line in wp-config.php, and only if your proxy actually sets that header, because trusting a header nothing sets is its own problem.
Redirect loops after a migration
Different cause, same symptom. You import the database to a new domain and the siteurl and home rows in wp_options still hold the old one, so every request gets sent to a domain that sends it back. WordPress’s migration handbook is explicit that both live in wp_options, and adds that “if you had any kind of rewrites (permalinks) setup you must disable .htaccess and reconfigure permalinks when it goes live.”
If you cannot reach the admin to fix them, WordPress ships a way in. Add define('RELOCATE', true); to wp-config.php and log in at wp-login.php on the new domain, which updates siteurl for you. Then delete the line, because leaving it there hands anyone who can reach your login page a way to move your site.
How do I find which rule is causing it?
Most likely to least, and the early steps cost nothing.
1. Log the hops. curl -sIL https://example.com prints every hop with its status and Location header, and the pattern names the culprit faster than any plugin audit. A chain alternating example.com and www.example.com is a host mismatch. One alternating http and https is an SSL rule fighting the edge. One flipping between /page and /page/ is a trailing slash rule.
2. Check the two address fields. Site Address and WordPress Address must match each other and what your host serves, scheme and www included. Check wp-config.php too, because WP_SITEURL and WP_HOME win: each “overrides the wp_options table value” but “will not change the database stored value”, and reverts “if this line is ever removed”. A correct constant can be hiding a wrong database row, so pulling the constant out later reintroduces the loop long after anyone remembers why.
3. Deactivate plugins. Rename the plugins folder over SFTP if you are locked out. SSL and redirect plugins first, caching second, security third.
4. Regenerate .htaccess. Rename it, let WordPress write a default, then add your custom rules back one block at a time.
5. Clear every cache. Plugin, host, CDN. A 301 is cacheable and browsers keep it, so retest in a private window or you will debug a loop you already fixed.
Change one thing, retest, change it back if it was not the cause. Two at once and you no longer know what worked, which matters because this recurs.
What does a redirect loop do to my Google rankings?
It depends entirely on how long the loop lives, and Google documents a hard limit: “By default, Google’s crawlers follow up to 10 redirect hops.” It also says “Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn’t follow redirects.” A loop burns that budget in five round trips and Googlebot gives up.
The URL then shows in the Page indexing report as Redirect error, and Google lists a redirect loop among its four causes, alongside a chain that was too long, a URL over the maximum length, and a bad or empty URL in the chain. Redirect error in Search Console works through all four.
That Inspection Tools clause deserves its own warning. The report says Redirect error, you inspect the URL, and you get something that looks nothing like a loop, because the tool stopped at hop one. The live test behaves differently again: “The live URL Inspection test follows redirects and then tests the final URL, although the live test doesn’t indicate that it is following a redirect.” The two disagree by design and neither is broken. The report and the live test answer different questions covers that trap.
Meanwhile no crawl means no index. If the URL was never indexed it stays out. If it was, it can drop out of the index once Google recrawls and finds nothing. A loop on a homepage or a category template takes a large block of the site with it, because those templates are how Googlebot reaches everything below them.
Is “Page with redirect” the same problem?
No, and mixing them up sends people fixing something that works. Page with redirect means the URL redirects successfully somewhere else: “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed.” Healthy. Your old post pointing at your new one belongs there, and Page with redirect in Search Console covers the rare cases when it is not fine. Redirect error is the failure, and a loop belongs in that bucket.
While you are in there, check whether your rules are 301 or 302. A loop built from 302s looks identical in the browser and says something different to Google about permanence, and the 301 versus 308 decision is the same family.
To confirm a fix, count hops on curl -sIL again, then use Test live URL rather than the stored result, because the report shows the last crawl and will keep showing the error for days. Then wait: Google says validation “typically takes up to about two weeks, but in some cases can take much longer, so please be patient.”
What I see in audits
The version I run into most is not a site that is down. It is a loop on one URL pattern nobody noticed, because the homepage loads and nobody on the team visits a paginated category page or an author archive on their own site. It surfaces in the Page indexing report weeks later as a growing Redirect error count, and by the time someone asks me the pattern has been uncrawlable long enough to have dropped out. The fix takes twenty minutes. Getting the URLs back takes considerably longer, and that gap is the real cost of the delay.
So the habit worth taking: after you change anything about hosts, https, www or permalinks, run curl -sIL on a URL from three templates. A post, an archive, and a paginated page. It catches the loop the day it is made rather than in the report six weeks later. The other WordPress URL traps, attachment pages and category and tag archives, belong in the same check.
Sources
- Google Search Central, how HTTP status codes affect Google’s crawlers, the
3xx (redirection)row, for the ten hop limit and the statement that Google Inspection Tools does not follow redirects, checked 4 September 2026 - Google Search Central, redirects and Google Search, for permanent redirects being a strong canonical signal and temporary ones a weak signal, checked 4 September 2026
- Google Search Console Help, Page indexing report, for the four Redirect error causes including a redirect loop, the definition of Page with redirect, the note that the live URL Inspection test follows redirects without indicating it, and the validation timeframe, checked 4 September 2026
- Google Search Console Help, URL Inspection tool, for the difference between the indexed result and the live test, checked 4 September 2026
- WordPress Advanced Administration Handbook, HTTPS, for
FORCE_SSL_ADMINforcing all logins and admin sessions over SSL, the reverse proxy infinite redirect loop, and theHTTP_X_FORWARDED_PROTOfix, checked 4 September 2026 - WordPress Advanced Administration Handbook, migrating WordPress, for
siteurlandhomeliving inwp_options, the permalink and.htaccessstep, and theRELOCATEmethod with its instruction to remove the line afterwards, checked 4 September 2026 - WordPress Advanced Administration Handbook, editing wp-config.php, for
WP_SITEURLandWP_HOMEoverriding thewp_optionsvalues without changing them in the database, and the URL reverting if the line is removed, checked 4 September 2026 - IETF, RFC 9110, HTTP Semantics, section 15.4 on redirection and the requirement that a client should detect and intervene in cyclical redirections, checked 4 September 2026