Redirect Checker: 301 and Chain Test

Enter the old address, the one people and links actually use, not the page you expect to land on. The checker requests it and records the status code. If the answer is a 3xx with a Location header, it requests that location next, and keeps going until a page answers with something other than a redirect, a URL repeats, or it has made 10 requests.

Each request is a HEAD first, because a redirect only needs headers. If the server refuses HEAD with 403, 405 or 501, or fails to answer it, the checker sends a GET instead. When it reaches a page that is not a redirect, it sends a GET anyway and reads up to 120,000 bytes of the HTML, looking for two more kinds of redirect: a meta refresh tag, which it follows like an HTTP redirect, and a script that sends visitors elsewhere as the page loads, which it reports but does not follow. Every request gets 8 seconds.

Only a plain case counts as a JavaScript redirect: a statement at the top level of a script in the page that sets location or location.href to a fixed address, or calls location.replace or location.assign with one. A redirect inside a function, a condition or a click handler may never run, and an address built while the page runs cannot be read without running it, so neither is reported. A page can still redirect that way; check the page source if the report and the browser disagree.

The Type column labels every hop. As of October 2026, Google’s redirect documentation splits them into permanent ones, which are a strong signal that the target should be the canonical URL, and temporary ones, which Google follows without treating the target as the replacement.

Googlebot follows up to 10 hops in one chain. Past that, Search Console reports a Redirect error for the URL. The checker’s limit is the same 10 requests, so a chain it cannot finish is one Google would not finish either.

Final URL is the last address in the chain. When it is not the page you meant to send people to, the rest of the report explains where the route went wrong.

Final status is the code that last address returned. A dash means it never answered: the hop was refused, timed out or failed DNS, and the reason is printed in red under that row in the Hops table.

Redirects counts the hops before the final page, including a meta refresh or JavaScript hop. One is ideal for an old URL. Zero means the address you entered is itself a page and nothing redirected.

Chain complete says Yes when the walk reached a page. Otherwise it says why it stopped: No, the chain loops when a URL came back a second time; No, hop limit reached when the URL was still redirecting after 10 requests; No, the last request failed when a hop never answered; and No, the last redirect has no usable target when a redirect came without a Location the checker could follow.

The Hops table lists each request in order with its status code, its type and the URL that was requested. A hop typed JavaScript shows the page that runs the script, with the address the script sends visitors to underneath. The checker does not follow it, so the chain ends there; run that address as a new check to see where it goes.

Errors make the verdict Redirect chain has problems. Warnings alone make it Redirect chain has warnings. With neither, it reads Redirect chain looks healthy.

When the protocol and hostname warning appears, the more-than-two-redirects warning is held back even if the chain is long, because merging those two hops is the first fix and may be the only one needed.

A 3xx response with no Location header ends the chain too. The checker treats that hop as the final one and prints Redirect status with no Location header under it, which is a server bug rather than a rule to edit.

Illustrative values. A blog moved to HTTPS on the www hostname some years ago, and last month a post was renamed from old-post to new-post. A newsletter still links to http://example.com/old-post/. The checker reported a Redirects count of 3, a Final status of 200 and two warnings: The protocol change and the hostname change are handled as two separate hops, and One hop uses a temporary redirect.

Getting to a single hop would mean moving the post’s redirect into the CDN as well, which is rarely worth it for one URL. What is worth doing is updating your own internal links and the sitemap to point straight at new-post/, so that every click from inside the site skips the chain entirely.

A request to a WordPress site can be redirected by up to four layers before WordPress itself sees it, and each keeps its own rules. Fixing a chain starts with knowing which layer answered at every hop.

The CDN answers first. On Cloudflare, check SSL/TLS → Edge Certificates for Always Use HTTPS, the Rules section for Redirect Rules and Page Rules, and Bulk Redirects at the account level. Then the host: managed WordPress hosts such as Kinsta and WP Engine have redirect rules and HTTPS settings in their dashboards. Then the web server: .htaccess on Apache and LiteSpeed, or the site configuration on Nginx, which ignores .htaccess entirely.

Then WordPress core, which redirects more than most people expect, all with 301s: to the hostname in Settings → General when only the www differs, to add or remove a trailing slash to match your permalink structure, from ?p=123 style links to the pretty permalink, from a post’s old slug to its current one, and from a mistyped URL to its best guess at the post you meant. The old-slug redirect covers posts but not pages, so a renamed page needs a rule of its own. Core does not redirect http to https by itself; that comes from one of the other layers.

Finally the plugins: a redirect manager, an SEO plugin’s redirect module, an SSL plugin, a multilingual plugin or a maintenance-mode plugin.

The fastest way to tell them apart is the X-Redirect-By response header. Open DevTools, check Preserve log on the Network tab, load the old URL and click each redirect; or run curl -sI against each hop’s URL. WordPress sends X-Redirect-By: WordPress, the Redirection plugin sends redirection, and many other plugins send their own name. No header usually means the server, the host or the CDN.

Edit the rule in the layer that sent the hop. Adding a new rule somewhere else to cover a bad one is how most long chains are built.

Automatic slug-change redirects are useful, but they build chains when a post is renamed twice: A redirects to B, then a new rule sends B to C. Edit the first rule so A goes straight to C, and keep the B rule for anyone who saved the middle address.

Loops have three common causes on WordPress. The Site Address says one hostname while a server rule forces the other. Cloudflare’s Flexible SSL mode talks to the server over http while WordPress or the server redirects to https, so every request bounces; switch the mode to Full (strict) once the server has a certificate. Or a trailing slash is added in one layer and removed in another. The checker shows the URLs repeating, which tells you which pair to compare.

What the report shows, the cause that comes up most often on WordPress, and the fix.

In Search Console, inspect the old URL. Page with redirect under Page indexing means Google followed it and left the old URL out of the index, so only the target can be indexed; that is the outcome you want for an old address, not an error. Inspect the target too, and check that its Google-selected canonical is the target itself rather than the old URL, which can happen for a while after a 302 is corrected.

Indexing → Pages groups problem URLs under Redirect error. Google uses that status for a chain that is too long, a loop, a redirect URL that grows past the maximum URL length, and a bad or empty URL in the chain. After you fix the rules, re-run each example URL here, then open the status and click Validate fix.

For the URLs that matter most, run URL Inspection’s live test on the old address and use Request indexing on the target. Old URLs often stay in Google’s records long after you change them, so a recrawl is quicker than waiting.

On a WordPress site connected to RankHive, redirects are one of the fixes it can draft from its weekly read of your Search Console data. Nothing goes live until you approve it, its plugin then serves the redirect, and reverting it in the Change Log turns it off.

One or two permanent hops ending on a 200 do not need work. A visitor on an old link barely notices, and Google follows both. Spend the time on chains that end in errors, loop, or carry a 302 for a move that is permanent.

Some temporary redirects are correct. Logged-out visits to /wp-admin/ get a 302 to wp-login.php, and that is how WordPress is supposed to work. A seasonal sale page that points to a holding page between campaigns, or a product that is briefly out of stock and points to its category, should stay 302 so the original URL keeps its place.

A warning on a URL nobody uses is not urgent either. If the old address has no links pointing at it and no traffic in Search Console, the redirect is a courtesy, and its shape does not matter much. Check the internal link side with the Broken Link Checker, which follows redirects and only reports links that end on an error.