§ page indexing report

blocking

"Redirect error" in Search Console

Google followed a redirect from this URL and never arrived anywhere usable. Here is what breaks a redirect chain, and how to see the whole chain the way a crawler does.

This URL is not indexed and it should be. Something is in the way.

check a url →

§ check your url

Is it still happening?

Paste the URL Search Console flagged. We follow the chain hop by hop without shortcuts and show you every status code and Location header along the way.

what this proves

The full redirect path for this URL, where it loops, how long it is, and what status it finally lands on.

what it cannot prove

We request from one location, with no cookies and no session. A redirect that only fires for certain countries, devices, or signed-in users will look clean here and still trap Googlebot.

§ what google is telling you

What this error actually means.

Google requested this URL, got a redirect, followed it, and the attempt failed. Not "the destination was disappointing". The chain itself did not resolve.

There are four ways that happens: the chain loops, it is longer than Google will follow, a hop points at something malformed or unreachable, or it ends on an error status. Google reports all four under one label, which is why the fix starts with seeing the chain rather than guessing.

A single clean redirect is not this error. If a URL 301s once to a working page, Google indexes the destination and reports the source as "Page with redirect", which is normal and needs no action.

§ causes

5 things that produce this error.

Ordered by how often they turn out to be the cause, not by how obvious they look.

Two normalisation rules fighting each other

The classic loop. One layer enforces a trailing slash and another strips it, or one forces www and another strips it. Each rule is correct on its own; together they bounce forever. This is especially easy to create when a CDN, a web server, and an application framework each hold an opinion.

text

GET /about   -> 301 /about/
GET /about/  -> 301 /about
GET /about   -> 301 /about/   ...

A chain that accumulated one hop at a time

HTTP to HTTPS, then non-www to www, then old path to new path, then a trailing-slash normalisation. Each was added by a different person solving a different problem, and none of them is wrong. Google follows a limited number of hops and gives up beyond that.

text

http://example.com/old
  -> https://example.com/old
  -> https://www.example.com/old
  -> https://www.example.com/new
  -> https://www.example.com/new/

The chain ends on a 404 or a 5xx

The redirect works perfectly and points at something that no longer exists. Common after a migration where redirect rules were written from an old sitemap and the new URLs changed again afterwards.

A redirect that depends on who is asking

Geo-based, language-based, device-based, or cookie-based redirects. Googlebot mostly crawls from US IP addresses with no cookies and no session, so a rule that redirects unknown visitors to a country selector can trap it in a loop that no human ever experiences. This is the hardest variant to reproduce, because the site works fine in your browser.

A malformed Location header

A relative path that resolves incorrectly, a missing protocol, an unencoded character, or a redirect to a URL that fails DNS. The redirect status is returned, but the destination cannot be requested.

§ the fix

How to clear it.

step 1

Look at the full chain first

Do not fix a redirect you have not traced end to end. Every hop, its status code, and its Location header. Most chains turn out to contain a hop nobody knew about, added at the CDN or by a platform default.

bash

curl -sIL https://example.com/page \
  | grep -iE '^(HTTP|location)'

step 2

Redirect to the final destination in one hop

Rewrite the rules so the original URL points straight at the URL you actually want indexed. When you move content, update the old redirect targets rather than chaining a new redirect onto the end of the previous one.

step 3

Resolve the conflict rather than adding another rule

For a loop, find the two rules fighting and delete one. Decide on a single canonical form for protocol, host, and trailing slash, enforce it in exactly one layer, and make every other layer pass through. A loop cannot be fixed by adding an exception; it is fixed by removing the second opinion.

step 4

Test as a crawler, not as yourself

If the chain looks clean in your browser but Google disagrees, the redirect is conditional. Request it with no cookies, from a plain client, and check whether a geo or locale rule fires. Personalisation rules should never apply to a crawler.

bash

curl -sIL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page | grep -iE '^(HTTP|location)'

§ related

Next to check.

usually finePage with redirectUsually not a problem. Google is telling you the redirect worked and it indexed the destination instead. Here is how to tell the harmless case from the one worth fixing.blockingServer error (5xx)Google asked for the page and your server failed to produce it. Often intermittent, often only under crawl load, and the most urgent of the indexing errors.blockingSoft 404Your server says 200 and your page says the content is gone. Google believes the page, not the status code, and refuses to index either.toolRedirect CheckerTrace the full redirect chain for any URL — every 301, 302, and hop.

→ Redirect Chains and SEO: The Ranking Signal Leaking Out of Your 302s

LintPage rules covering this: canonical-url, meta-refresh-redirect

§ faq

Questions, answered.

How many redirects will Google follow?

Google follows up to about five hops in a single crawl attempt, then queues the next URL in the chain for a later crawl. Chains do eventually resolve this way, but slowly, and every extra hop is another chance for something to break. Treat anything beyond one hop as technical debt rather than a working configuration.

What is the difference between 'Redirect error' and 'Page with redirect'?

"Page with redirect" means the redirect worked. Google followed it, indexed the destination instead of this URL, and is telling you so. That is normal and needs no action. "Redirect error" means the redirect failed to resolve at all: a loop, an over-long chain, a bad Location header, or an error status at the end.

Do 302 redirects cause indexing problems?

A single 302 to a working page does not cause this error. It does signal a temporary move, so Google may keep the original URL in the index and treat the destination as provisional. For a permanent move use 301. The status code matters for which URL ends up ranking, not for whether the chain resolves.

Can a JavaScript or meta refresh redirect cause this?

They can contribute. Google does follow meta refresh and some JavaScript redirects, but they are slower to process and easier to get wrong than an HTTP redirect, and they interact badly with a chain that already contains server-side hops. If a URL must redirect, do it with a 301 at the server.

Why does the redirect work in my browser but fail for Google?

Almost always because it is conditional. Your browser carries cookies, a session, a locale, and a local IP address. Googlebot has none of those and usually crawls from the United States. A rule that sends visitors without a country cookie to a region selector, which then redirects back, is invisible to you and an infinite loop to a crawler.

§ before the next deploy

Catch this one before Search Console does.

Search Console tells you weeks after the fact. LintPage runs 60 checks against a URL in about 30 seconds. Free, no signup.

run a full scan →