Untangling redirect chains after three relaunches
Three migrations, three generations of rules, and none of them was cleaned up the next time round. The file works. It just works across four stops: http to https, www to non-www, old structure to middle one, middle one to new. Every hop costs its own request; Google does follow several of them but gives up after a handful and puts the rest off until later — and somewhere in the pile two rules are working against each other without anyone having noticed so far.
How to go about it in JMX
- Crawl. JMX follows every chain to its end, up to ten hops. In the Results the
Redirect targetcolumn shows where an address ends up; across how many stops is what the Redirects section in the Technical tab says — and in the CSV or Excel export theRedirect hopscolumn. - The Technical tab, Redirects section. Three numbers: how many addresses redirect, how many across more than one hop, how many go in circles. The chains stand in front with their length.
- The Issues tab.
SEO.STATUS.REDIRECT_LOOPis Critical and sits at the top,SEO.STATUS.REDIRECT_CHAINis a warning,SEO.STATUS.TEMPORARY_REDIRECTpicks out the 302s and 307s that should be 301s. The Evidence column shows the chain hop by hop. - Settings, thresholds. The permitted chain length is one redirect by default; under Settings → Thresholds it cannot be changed, though — only the title, description, word count and GEO thresholds live there. After a change, Refresh in the Issues view is enough; a new crawl is not needed.
- The Migration tab. The crawl only finds what is still linked today. You collect the addresses of the earlier relaunches there from Search Console, a
site:query, a sitemap and the Wayback Machine; the archive caps at 50,000 addresses and says so. Every old URL gets one of eleven verdicts, “Redirect chain” being one of them. - Generate redirects. From the matches JMX writes a finished
.htaccess, nginx.conforweb.config: status code selectable (301, 302, 307, 308), confidence threshold 90 % by default, everything below commented out rather than left out. Whatever already arrives at its destination with a single 301 gets no second rule. - The Tasks tab, then the command line. Impact in points and estimated effort stand side by side there;
jmx-cli --fail-on-change Criticalturns the nightly run red as soon as a new loop appears.
What to watch out for
JMX does not read your .htaccess. It only sees what the server answers to a request. A rule that no address has matched since the second relaunch appears in no finding. The list is not an inventory of the configuration but a list of the addresses that arrive by detour — deleting lines because JMX reports nothing about them is the wrong conclusion.
Hundreds of SEO.LINK.TO_REDIRECT findings look like a server problem. They are not one. The finding says that your own pages link to a redirecting address instead of to the target; what changes is the link, and the redirect stays in place so that external references and bookmarks keep working.
After ten hops the crawler gives up. And loops rarely arise inside one file but between the layers — CDN, web server, application, plugin, each with its own idea about the trailing slash — which is why the evidence tells you which address points back but not who wrote the rule.
The next relaunch is coming, and it will build on this file. Whether it then has one layer or gets a fourth is something you decide now.