How to find redirect chains on your website

Redirect chains show up in SEO by Zaweba in two places. Every page the app fetches has its full redirect chain recorded, hop by hop, so you can see exactly how an address reached its final page. And when you crawl your own site, the site checks flag every redirect chain they find, together with error pages and other site problems.

So for one address you look at the page details, and for the whole site you look at the site problems after a crawl.

What a redirect chain is

A redirect sends a browser or crawler from one address to another. A chain is when that new address redirects again, and perhaps again, before the real page appears. A typical example is an old http address that goes to https, then to the www version, then to a newer slug. Each hop costs time, and every extra step is another place for something to break. Internal links that point at the start of a chain are the usual cause, and they are easy to fix once you know where they are.

Checking a single address

Give step 2 of the guided audit the address you want to check. The single page crawler fetches it straight away with an honest user agent and records the redirect chain along with the status code, time to first byte, total time, size and the main headers. If the address you typed is not the address that finally answers, the chain shows every hop between them.

This is also a quick way to confirm a redirect you have just set up behaves as you meant it to, and that it lands on a page that returns a success code rather than an error.

Checking the whole site

For a site-wide view, ask step 4 to crawl your own site. The crawler reads robots.txt and your sitemaps, then follows internal links breadth first up to your page limit (500 by default, changeable in Settings under Limits). Redirect chains are one of the site problems it reports, next to 4xx and 5xx pages, orphan pages, duplicate titles, canonical conflicts and noindexed pages in the sitemap.

Because the crawler builds the internal link graph as it goes, it knows which pages link to each address. That turns a list of chains into a list of links to update.

Fixing chains properly

There are two parts to the fix. First, change your internal links so they point straight at the final address. That removes the chain for visitors and crawlers following your own links. Second, where outside sites or old bookmarks still use the first address, change the redirect itself so it goes to the final page in one hop rather than through the middle steps.

Watch for chains that end in an error, and for loops where a redirect eventually points back at itself. Both are worse than a long chain and should go to the top of your list. Look also at the sitemap: it should list final addresses, never ones that redirect.

Confirming the result

Run the audit again after the changes. The History page keeps every scan, and its compare two scans view sorts the differences into improved, fixed, regressed and new, so a cleared chain shows up as fixed. If you track the work on the To-do list, tasks marked done are verified at the next scan and reopened if the check still fails. For a long list, File, Export table as CSV saves the table you are looking at, which is handy when someone else maintains the redirects.