Every redirect costs a round trip. One is usually harmless — a visitor types the old address, the server points them to the new one, and the page loads a fraction of a second later. The trouble starts when redirects start pointing at other redirects. Now the browser has to make two, three, or four requests before it sees a single byte of content, and search engines start losing patience with the page too.
This is a redirect chain, and it is one of the most common quiet performance leaks on WordPress sites. It rarely breaks anything outright, which is exactly why it survives for years: nobody notices until a speed audit or a Search Console report surfaces it. The good news is that chains are usually easy to fix once you find them, and the fix almost never requires touching code you do not understand.
What a redirect chain actually is
A redirect chain happens when URL A redirects to URL B, which redirects to URL C, which finally serves the page. Each hop is a separate HTTP request, and each one adds latency — especially on mobile connections, where every round trip is expensive.
A redirect loop is the broken version of the same idea: A redirects to B, B redirects back to A, and the browser gives up with an “ERR_TOO_MANY_REDIRECTS” error. Loops are loud and obvious. Chains are silent. Both usually come from the same handful of causes, so fixing one skill set covers both.
Why should you care about a delay of a few hundred milliseconds? Because chains stack on top of everything else your site already does. A page that already has a slow server response gets slower still, and Google treats redirect hops as a real cost: crawl budget gets wasted following chains instead of indexing pages, and link equity dilutes with every extra hop. If you have already worked through the big wins for server response time (our guide to WordPress TTFB fixes covers them in order of impact), redirect chains are one of the next clean-ups worth doing.
How to find redirect chains on your site
You cannot fix what you cannot see, so start with a crawl rather than guessing.
Check individual URLs first. For any URL you suspect — an old post you renamed, a page you moved during a redesign — paste it into a redirect checker tool (the free ones from Ahrefs, Screaming Frog’s redirect checker, or httpstatus.io all work). A healthy result shows one redirect at most, then a 200 response. Anything longer is a chain worth fixing.
Crawl the whole site. If you have Screaming Frog, run a crawl and open the Redirect Chains report. It lists every chain on your site, its length, and the final destination. The free version crawls up to 500 URLs, which covers most small and medium sites. Alternatives like Sitebulb or the redirect report in Rank Math Pro do the same job.
Use the terminal for a quick check. If you are comfortable with a command line, curl shows the full hop sequence in seconds:
curl -IL https://yoursite.com/old-page/Each “HTTP/2 301” line is one hop. Follow them down to the final “HTTP/2 200” and you can see exactly what the browser goes through.
Check Search Console. Google Search Console flags redirect errors under Pages, and its URL Inspection tool shows the redirect path Googlebot followed for a specific URL. If Google is reporting redirect problems, fix those URLs first — they are the ones already costing you visibility.
A useful habit: run a chain check after every migration, redesign, or bulk URL change. Chains are almost always created during changes, not during quiet periods.
The usual causes in WordPress
Most chains come from layers of redirects added at different times by different tools, each unaware of the others.
The www and HTTPS double hop. This is the most common chain on the internet. A visitor requests http://yoursite.com, which redirects to https://yoursite.com, which redirects to https://www.yoursite.com. Two hops before any content. The fix is to redirect straight from every variant to the single canonical version in one step — your server or CDN should handle http, www, and HTTPS in a single rule set, not as separate layers.
Trailing slash mismatches. WordPress treats /about and /about/ as different URLs and redirects one to the other. If your internal links, your sitemap, and your redirect plugin disagree about which version is canonical, you get chains — and sometimes loops, when two rules fight over the slash.
Plugin pile-up. A redirect plugin, an SEO plugin, a security plugin, and a migration plugin can each hold redirect rules. When a URL changes twice, you can end up with rule one pointing to the intermediate URL and rule two pointing to the final one. Nobody meant to build a chain; it just grew.
Migration leftovers. After moving from another platform or changing permalink structure, old redirect tables linger. A post that moved from /blog/old-slug to /old-slug to /new-slug often carries all three hops forever, because nobody cleaned up the middle step.
Changed slugs without updating links. When you rename a post, WordPress helpfully creates a redirect from the old slug. If you rename it again, you get a second redirect. Your own internal links may still point at the first slug, adding yet another hop for every visitor who follows them.
Fixing chains step by step
Work through chains one at a time, starting with the longest ones and the ones on your most-visited pages.
1. Point every chain at the final destination. Open your redirect rules — in the Redirection plugin, Rank Math’s redirections, or your .htaccess file — and find the chain. Change the first rule so it points directly at the final URL. If A redirects to B and B redirects to C, edit A’s rule to point at C. Then delete or disable the now-redundant middle rule if nothing else links to B.
2. Fix the source, not just the rule. Redirects should be a safety net for links you do not control — bookmarks, external sites, old search results. Links you do control should point at the final URL directly. Search your content for links to the old URLs and update them. A quick way to find them: in Screaming Frog’s chain report, look at the “inlinks” for chained URLs, or use the Search & Replace approach in your database for a bulk fix (back up first, always).
3. Consolidate www and HTTPS in one place. Decide your canonical version — https with www, or https without www — and make it the only target. In .htaccess on Apache, a single rule set handles both:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.yoursite.com/$1 [L,R=301]If you use a CDN like Cloudflare, set the same canonical target there and make sure your origin server is not adding its own www redirect on top. One layer does the redirecting; the other layers stay quiet.
4. Settle the trailing slash question. Pick one convention and enforce it everywhere: WordPress defaults to trailing slashes for posts and pages, so that is usually the path of least resistance. Make sure your redirect plugin, your SEO plugin’s settings, and your internal links all agree.
5. Clean up after migrations. If you migrated or restructured permalinks, audit the redirect table for entries whose target is itself the source of another redirect. Those are chains by definition. Rewrite them to the final destination and remove the middle steps.
6. Purge caches and re-test. After editing rules, clear your page cache and any CDN cache, then re-run the redirect checker on each fixed URL. You want to see exactly one redirect followed by a 200 response. If you still see two hops, another layer — often the CDN or the hosting panel — is adding one.
Fixing redirect loops
Loops feel scarier, but they usually have a small number of causes.
Conflicting plugin rules. Two plugins redirecting the same URL in opposite directions is the classic loop. Disable redirect-related plugins one at a time until the loop breaks, then reconcile the rules in a single place.
HTTPS detection behind a proxy or CDN. This is the most common WordPress loop of all. Your site sits behind Cloudflare or a load balancer that talks HTTPS to visitors but HTTP to your server. WordPress sees an HTTP request, redirects to HTTPS, the proxy passes it back as HTTP, and the loop repeats. The fix is to tell WordPress to trust the proxy’s forwarded protocol. In wp-config.php, above the “That’s all, stop editing!” line:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}Also check Cloudflare’s SSL mode: “Flexible” (HTTPS to visitors, HTTP to origin) combined with a WordPress HTTPS redirect is a loop waiting to happen. “Full” or “Full (Strict)” is the correct pairing when your origin supports HTTPS.
www versus non-www fighting. The same shape of problem: one rule forces www, another forces non-www. Pick one, delete the other, and clear caches before re-testing.
Cached redirects in the browser. Browsers cache 301 redirects aggressively. After fixing a loop, test in a private window or clear the browser cache — otherwise you can end up debugging a fix that already worked.
After the fix: verify properly
Fixing a chain is only half the job; the other half is confirming the fix stuck.
First, re-check each fixed URL with a redirect checker or curl and confirm a single hop to a 200. Second, re-crawl the site and confirm the chain report is empty or dramatically shorter. Third, update your XML sitemap if it lists any of the old intermediate URLs — sitemaps should only ever contain final, canonical URLs. Finally, keep an eye on Search Console over the following week: redirect errors should clear as Google re-crawls, and pages that were stuck behind long chains often get crawled more promptly.
This verification habit belongs in the same routine as your regular speed testing. If you do not already have one, our guide to testing WordPress speed the right way lays out a repeatable routine, and if the redirect cleanup reveals deeper slowness, the 15-minute diagnostic in why your WordPress site is slow is the right next step.
How to stop chains coming back
Redirects accumulate silently, so prevention is mostly about process:
- When you change a URL, update internal links to it in the same session. Do not rely on the redirect to carry your own links forever.
- Keep redirect rules in one place. If Rank Math handles your redirects, do not also maintain rules in a second plugin or in .htaccess for the same URLs.
- Before a migration or permalink change, export the existing redirect table so you can audit it afterwards instead of layering a new table on top.
- Add a redirect-chain check to your quarterly site maintenance, alongside cache and plugin audits. Ten minutes with a crawler catches chains before they grow long.
- Treat a redirect as temporary by default. If a redirect has been in place for a year and nothing external still links to the old URL, consider whether the old URL can simply be removed — or, more often, whether the content should live at the final URL permanently with links updated accordingly.
Redirect chains will never be the most exciting item on a speed audit, but they are one of the cheapest wins available. No new plugin, no hosting upgrade, no redesign — just a tidy set of rules that send every visitor and every search engine straight to the page they asked for, in a single hop. On a site where every millisecond of load time matters, that is exactly the kind of quiet improvement that adds up.