How to fix redirect problems

By Matt Kerr·Published 15 September 2026

Your audit came back with a section headed "Redirect problems" and a list of URLs, and you moved a site or renamed a directory recently, so of course there are redirects. The useful question is not how many. It is which of these shapes actually costs you something, and which is a redirect doing exactly the job you set it.

Docket's index.redirects check reports three of them, and they are three separate findings at three different severities because they are three different jobs:

• A redirect loop — index.redirect_loop, at CRITICAL. Nobody reaches the content. Ever.
• A chain — index.redirect_chain, at MEDIUM. A URL that redirects more than once before it resolves.
• An internal link pointing at a redirect — index.internal_link_to_redirect, at LOW. Your own templates linking to the old URL.

That ordering is the answer. If you only have time for one, it is the first, and the third is housekeeping you can schedule.

What this cannot tell you

Said first, because it changes how much weight the list deserves.

Docket does not read your server configuration. It has never seen your nginx file, your .htaccess, your CDN rules or your CMS redirect table. Everything it reports is a redirect its own crawler walked while fetching the pages it crawled, starting from your homepage and following links. A redirect rule that exists but that nothing on the site links to is invisible to it. So is one on a page the crawl did not reach.

And it does not record the status code of each hop. This is the one that matters most, because it is the opposite of what the phrase "redirect problems" suggests. The fetcher follows redirects by hand so the intermediate URLs survive, and its own comment says why: "the hops are the finding: a 302 where a 301 belongs, or a 4-hop chain burning crawl budget, are both invisible if you only see the destination". What it keeps is chain, a list of URLs. The statuses are not in it. So no finding under this check is about a temporary redirect used where a permanent one was meant — Docket cannot see the difference, and a page that told you otherwise would be describing a check that does not exist.

It follows that Docket also cannot tell a deliberate temporary redirect from a mistaken one. Nothing can, from the outside: the status code is a declaration of intent, and only you know whether the intent was real. Checking that is a job for the commands further down this page, not for a crawler.

One more, because it changes what a finding means rather than merely limiting it. When a redirect leaves your site, the crawler keeps the URL you own and discards the title and body at the far end — another site's words must not be attributed to yours. Those URLs still appear in the redirect findings, as your signposts pointing off your property, and no claim is made about what they point at.

The three findings, and what fires each

A loop: nothing gets through

The fetcher walks the chain itself, and when the next hop is a URL already in the chain it stops and records a redirect loop. The check picks those up and reports at CRITICAL, with a sentence that is not hedged: "These URLs redirect back to themselves, so no crawler or visitor ever reaches content." Its fix text is "Trace the redirect rules for these paths and break the cycle."

There is no threshold on this one. One is enough, because one is a page that cannot be reached by anybody, and a loop is almost always two rules written at different times that each look correct on their own — a trailing-slash rule and a lowercase rule, a CDN redirect and an application redirect, an old rule and its replacement.

RFC 9110 section 15.4 puts the obligation on the client rather than the server: "A client SHOULD detect and intervene in cyclical redirections (i.e., 'infinite' redirection loops)." That is why a loop is not a crash. Every client eventually gives up, quietly, and what the visitor sees is a browser that stops with an error page nobody reports to you.

A chain: more than one hop before it resolves

The rule is exactly as narrow as it sounds — a page whose recorded chain has two or more hops in it. One redirect is not a chain and is not reported here. The finding is MEDIUM, it prints one chain written out with arrows as its example, and its fix text is "Point the first URL in each chain straight at the final destination, in one hop."

Two bugs in that sentence are worth repeating, because they are the reason to trust the current version. The finding used to list the last URL of each chain — the destination, which redirects nowhere and needs no change — while its own fix asked you to change the first. And the example was built by slicing the first few hops, which silently dropped the destination once a chain got long enough. Both were measured on a real site, both are fixed, and both have tests named after them.

Chains come from history rather than carelessness: each rule was right when it was written. The site moved to HTTPS, then to a new URL structure, then a section was renamed, and each change added a hop to redirects that already existed. Collapsing them is the least glamorous and most reliable thing on this page — take the first URL, point it at the last, delete the middle.

An internal link pointing at a redirect

The narrowest of the three, and the one whose definition is worth reading before you act on it. It fires on a URL whose chain is exactly one hop long and which the crawl saw an internal link pointing at. Both halves are required. A single-hop redirect that nothing on your site links to is reported by none of these three findings, which is correct: it is a redirect working as intended, catching an old inbound link, and there is nothing to fix.

Reported at LOW, with the fix "Update these internal links to their destination URL." The URLs it lists are the redirecting ones, not the destinations — the same distinction the chain finding got wrong — because the redirecting URL is the string you have to find in your templates.

The claim this page will not make

You will have read that a permanent redirect passes some specific percentage of "link equity". No figure of that kind appears here. Google's redirect documentation does not state one, and a number repeated without a source is not evidence that it is true.

Being precise about this cuts our own side too. The chain finding's detail text says an extra hop "dilutes the signal passed through the redirect" — a claim Docket's own source does not carry a citation for, and you should weigh it accordingly. The part of that sentence that survives scrutiny is the other half: each extra hop is another round trip before any content arrives, and that is measurable on your own connection.

What Google's redirect documentation does say, read on 15 September 2026, is about signals rather than percentages: for a permanent redirect, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical". For a temporary one, "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."

That is the real cost of the wrong status code, and it is a cost in canonicalisation rather than in leaked equity. A redirect is one of the signals that decides which URL gets indexed; what a canonical tag actually does covers the other declaration you can make about the same question, and the two can disagree.

Checking the status codes yourself

Since Docket does not keep them, get them directly. This prints every hop's status line and every Location header, in order:

curl -sIL https://example.com/old-url | grep -i '^HTTP/\|^location:'

Read it as pairs. A permanent move should show 301 and the new URL, once. Two or more pairs before the final 200 is the chain. The same URL appearing twice is the loop. A 302 where you meant a permanent move is the mistake nothing in your audit will catch for you.

Per RFC 9110 section 15.4.2, 301 means "the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs"; per section 15.4.3, 302 means only that "the target resource resides temporarily under a different URI". Both read at rfc-editor.org on 15 September 2026. The default in a lot of framework helpers and control panels is the temporary one, which is how sites end up declaring a permanent move in words and a temporary one in the header.

Fixing a chain rarely needs a new rule, only an edited one. On nginx, a permanent move written as a single directive rather than a block:

rewrite ^/old-url$ /new-url permanent;

On Apache, in the virtual host or an .htaccess file:

Redirect 301 /old-url /new-url

Point the first URL at the final destination in both cases. Leave the intermediate rules in place if other inbound links still use them; what you are removing is the hop, not the history.

Three neighbouring checks that are not this one

Docket reports redirects in more than one place, deliberately, and confusing them wastes your time:

• Client-side redirects — index.meta_refresh, at NOTICE. A page that answers 200 with a normal body and then moves the visitor with <meta http-equiv="refresh">. It has no chain and no redirect status, so everything on this page is blind to it; that is why it needed a check of its own. It is a notice rather than an error because static hosting frequently cannot issue a server-side redirect at all, and scolding somebody for using the only tool their host gives them is not advice.
• Redirect latency — perf.redirect_volume, in the performance lane. It fires on the share of crawled URLs that went through any redirect, one hop included, which is a question about cost rather than correctness.
• Canonical conflicts — the index.canonical check, whose findings include index.canonical_conflict. A redirect and a canonical tag are two ways of naming the real URL, and they can contradict each other.

The redirect that closes sixty-nine findings

The most expensive redirect defect Docket has measured was a missing one. A university department's audit carried a HIGH finding about pages with identical content across dozens of groups, and the remedy attached to it asked for a canonical decision per group. The crawl had already measured the cause: the site answered on both http:// and https://, with the same paths under both schemes, and the report said so separately as security.no_http_redirect. One server rule closed the lot. The reader had been handed sixty-nine decisions for a one-line fix, and the check that owned the remedy now reads the flag the crawl had recorded.

If your audit shows duplicate content and no HTTPS redirect, do the redirect first and re-run. How to redirect http:// to https:// covers the rule by host, including the certificate state that blocks the setting on GitHub Pages — which we found because Docket reported the same fault on this site.

What to do with the list you have

Loops first. Chains next, collapsed to one hop each, starting with the URLs you actually earned links to. Internal links pointing at redirects last, as a template edit rather than a URL-by-URL job. Then check the status codes by hand on the redirects that matter, because that is the one part of this no crawl report will do for you.

Download Docket

Common questions

Are all redirects bad for SEO?

No. A redirect that sends one old URL to one new URL in a single hop is the correct way to move a page, and Docket does not report it at all unless your own internal links still point at the old URL. What gets reported is a loop, a chain of two or more hops, and a template still linking to the redirecting URL.

Does Docket tell me which redirects are 301 and which are 302?

No. The crawler keeps the list of URLs it walked, not the status of each hop, so no finding under this check distinguishes a permanent redirect from a temporary one. Check that yourself with curl -sIL against the URL and read the status lines it prints.

How much link equity does a redirect lose?

This page does not give a figure, because Google's redirect documentation does not publish one and the percentages you see quoted elsewhere have no source. What Google's documentation does say is that a permanent redirect is used as a signal that the target should be canonical, and a temporary one is not.

Why does my audit list a redirect I do not have a rule for?

Docket reports the redirects its crawler actually walked from the pages it crawled, so a hop can come from your CDN, your host's trailing-slash handling, or a platform-level rule rather than from your own configuration file. It never reads that configuration, so the crawl is the evidence, not the rule list.

Does a redirect chain get shortened automatically by Google?

Googlebot follows redirects, but each hop is still a request a visitor's browser makes and your own links still point at the first URL. Collapsing the chain in your configuration is a one-line edit; leaving it means every visitor pays for the history of your URL structure.