Redirect checker

The tool requests the address and, instead of letting the browser follow, reads the answer: the status and, when it is a redirect, the Location header. Then it requests the destination, and so on, up to ten hops, timing each one. Each hop is named by what it changes: the scheme (http to https), the host (www to the bare domain or the reverse), a trailing slash, the letter case, or the path. When the chain ends, the final page is fetched and read for a meta refresh tag and for a script that sets the location, the two redirects a server never shows and search engines follow late or not at all. From the first address and the last, it writes the one rule that would replace the chain, for nginx and for a Next.js config.

A redirect is a page telling the world it moved. Done with a 301 or a 308, the old address hands its standing to the new one and the links people wrote to it keep counting. Done with a 302 or a 307, it says the move is temporary, and search engines are entitled to keep the old address in the index and treat the new one as a stand-in. Most 302s on product sites are moves that were never meant to be temporary; the framework picked the code.

Chains cost more than they look. Each hop is a request, a wait and a chance to fail; Googlebot follows a handful and gives up. The common case is a site that moved to https, then to www, then to a new path: three hops on every old link, when one rule could send the old address straight to the last one.

• The verdict counts the hops, adds the time, and says whether the chain can be one rule. Two redirects that change the scheme and then the host are the common case, and one server rule does both.
• The table is one row a hop: the address, its status (permanent or temporary), the kind of hop, the milliseconds it took, and where it sent the request. The last row is where the request landed.
• Permanent (301, 308) hands the old address's standing to the new one. Temporary (302, 303, 307) keeps it on the old one; a move meant to last should not be temporary.
• Crosses hosts means the chain moves between domains, each of which needs its own certificate and its own rule.
• In the final page reports a meta refresh or a script redirect. Both work in a browser; make them a server redirect so every crawler follows.
• One rule in place of the chain is the nginx location and the Next.js redirect entry from the first address straight to the last, to copy.

1. 1

   Find where the rules live

   A host's settings, a framework's config, an .htaccess or an nginx block. Chains happen when two of these each add a hop.

2. 2

   Send the first address to the last

   Rewrite the rule so http://old goes to https://www.new/page in one hop, with a 301 or 308.

3. 3

   Keep the middle addresses answering

   Links may point at them. Each should redirect straight to the end too, not to the next hop.

4. 4

   Redirect to the closest live page

   Never to the home page by default. A visitor who followed a link to a specific page and lands on the home page leaves; so does the standing of the old link.

5. 5

   Check the whole family

   A redirect on one old path usually means a family of them: run the sitemap checker on the old sitemap, or the broken link checker on a page that links to the old paths.

The tool sends a HEAD request and falls back to a small GET when a server refuses it. A server that answers bots differently from browsers, or a redirect that depends on a cookie, a country or a device, shows the bot's path here and another in your browser. Script redirects are read by pattern from the first sixty kilobytes of the page; a redirect built at runtime from pieces is not seen. Ten hops at most, which is about where Googlebot stops too.