Redirect checker for every hop, and every crawler

What a redirect checker does

When you click a link, your browser follows redirects without telling you. It asks for a URL, the server answers with a 3xx status code and a Location header, and the browser quietly asks for that location instead. Two or three of those can happen before a page appears, and you would never know.

A redirect checker turns that automatic behaviour off. It makes each request by hand, writes down what the server said, and only then moves to the next URL. For every hop you get the status code, the exact Location value, how long the server took, and the headers that matter for crawling: server, cache-control, x-robots-tag and any canonical declared in a Link header.

This one does three things the usual checkers skip. It reads the start of the final page for a meta refresh or a script redirect, which a status code cannot show. It names the problem in plain words with a fix. And in single mode it runs the same URL again as four crawlers, because a page that works for you can still fail for the bots that decide whether AI answers mention you.

Sources: Google^[2]; Vercel^[4]. Vercel’s figures are a vendor study of traffic on its own network over one month.

301 vs 302 vs 307 vs 308

There are five redirect codes in everyday use. They differ on two questions: is the move permanent, and may the client change the request method when it follows? For pages people and crawlers read with GET, only the first question matters in practice^[5][6].

Google treats 301 and 308 as permanent: the target becomes the canonical URL and shows in results. It treats 302, 303 and 307 as temporary and keeps the original URL indexed^[1]. Its crawler documentation calls a 301 a strong signal and a 302 a weak one^[2]. For when a temporary redirect is the right choice, and how long-lived ones are treated, see what a 302 status code means.

Redirect chains, and why to collapse them

A chain is two or more redirects in a row. The most common one is accidental. A site adds an http to https rule, then a www rule, then a trailing-slash rule, each written at a different time. An old link to http://example.com/pricing now takes three hops to reach https://www.example.com/pricing/.

Each hop is a full round trip before any content arrives. On a slow server that is seconds of waiting for a person. For a crawler it is extra work for no content. Google’s guide for large sites says it plainly: avoid long redirect chains, which have a negative effect on crawling^[3]. And every hop is one more chance for a timeout, a misconfigured rule or a firewall to break the path.

The fix is to point every old URL straight at its final destination in one redirect, and to update internal links, canonicals and sitemap entries to the final URL so nobody needs the redirect at all. When the checker finds a chain, its fix names the exact source and destination to connect.

Redirect loops and “too many redirects”

A loop is a chain that comes back to a URL it already visited. Browsers give up and show an error such as ERR_TOO_MANY_REDIRECTS. The HTTP specification asks clients to detect cycles like this and stop^[6], so crawlers give up too.

Loops nearly always come from two rules that disagree. A CDN set to talk to your server over http while the server forces https. A plugin that adds a trailing slash while the server removes it. A www rule in the host’s panel and the opposite rule in .htaccess. This checker stops before requesting a URL it has already seen, shows you the pair, and flags a slash that is added and then removed. Every common cause and its fix is in our guide to fixing ERR_TOO_MANY_REDIRECTS.

A chain does not need to loop to fail. Past 10 hops, Google’s crawlers stop following by default^[2], and so does this tool, so a very long chain is reported the same way a loop is.

Meta refresh and JavaScript redirects

Not every redirect is a status code. A page can answer 200 and then move the visitor with a <meta http-equiv="refresh"> tag or with a script that sets window.location. Server-side checkers that stop at the status code miss both, which is why this one reads the first 100 KB of the final page.

Sources: Google^[1]; Vercel^[4].

Why redirects matter more for AI crawlers

Start with what is not known. OpenAI, Anthropic and Perplexity do not publish how many redirects their crawlers follow, how long they wait, or whether they follow a meta refresh. Anyone who tells you a number is guessing. What can be measured points one way: keep the path short and on the server.

Vercel’s study of its own network found that 14.36% of the ChatGPT crawler’s fetches were spent following redirects, and 34.82% hit 404 pages, with Claude’s crawler close behind at 34.16% on 404s^[4]. Those are fetches that delivered no content. The same study found that none of the major AI crawlers render JavaScript, so a JavaScript redirect is a dead end for them.

The bigger risk is often not the chain but the treatment. Bot protection, rate limits and CDN rules that are tuned against scrapers often match on the word “bot”. A browser sails through while GPTBot gets a 403 or a challenge page. That is why single-URL checks here repeat the chain with each crawler’s user agent and say plainly when the result differs.

How to fix redirects on your server

The goal is the same everywhere: one permanent redirect from each old URL to its final URL, and the protocol and host fixed in the same hop. Pick your platform.

# One page, permanently
Redirect 301 /old-page https://www.example.com/new-page

# http and non-www to https://www in ONE hop
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

# Every http request, and the bare domain, to https://www in one hop
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# Inside the https server block for www.example.com
location = /old-page {
    return 301 /new-page;
}

{
  "redirects": [
    { "source": "/old-page", "destination": "/new-page", "permanent": true },
    { "source": "/blog/:slug", "destination": "/articles/:slug", "statusCode": 301 }
  ]
}

module.exports = {
  async redirects() {
    return [
      { source: "/old-blog/:slug", destination: "/blog/:slug", permanent: true },
    ];
  },
};

add_action( 'template_redirect', function () {
    if ( is_page( 'old-page' ) ) {
        wp_safe_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

If incoming requests match:   Hostname equals "example.com"
Then:                          Dynamic redirect
  Expression:                  concat("https://www.example.com", http.request.uri.path)
  Status code:                 301
  Preserve query string:       on

Redirect checklist

Run through this after a migration, a redesign or a change of CMS. Your ticks are saved in this browser only.

Check every URL on your site

This page checks up to 10 URLs at a time, and only the ones you think of. The redirects that hurt are usually the ones nobody remembers: an internal link from 2019, a sitemap entry pointing at an old slug. The GEO Audit crawls your site and runs 31 checks on every page, including whether it answers with a clean 200 or only after a redirect.

The free account audits 10 pages with an email address and no card. Paid plans audit more and re-run on a schedule; every limit is on the pricing page. If you only need one page checked in depth, the AI SEO checker runs the same 31 checks on a single URL for free.

Redirects are one part of being reachable. Your robots.txt is the other; build or test one with the robots.txt generator and tester.

Questions people ask

Sources