Blog

Page with redirect is not an error, it is a description.

Of all the Search Console statuses that cause unnecessary work, this is the most literal. It means the URL redirects somewhere else, so Google indexed the destination instead of the URL you submitted. That is what a redirect is for. It sits in the not indexed section, which is the only reason anybody worries about it.

Usually nothing to doThree exceptionsTwo minute check

Why it is listed as "not indexed"

Because the URL itself is not indexed, and that is correct. The content is indexed at the destination. A redirect is you telling Google "not here, there", and this status is Google confirming it listened. After any migration or tidy-up you should expect this number to be large, and a large number is not a symptom.

The mistake is treating the report as a to-do list where every row must reach zero. Some statuses genuinely need work. This one usually needs reading and closing.

The three cases worth a look

Chains. A redirects to B redirects to C. Each hop dilutes the signal and slows the crawl, and chains accumulate quietly over years of small changes. Every redirect should reach its final destination in one step. This is the single most common finding here and it is mechanical to fix.

Redirects to somewhere irrelevant. Retiring two hundred product pages by pointing them all at the homepage clears the list without preserving anything. Google may treat a mass redirect to a non-equivalent page as a soft 404, so you get the status back anyway, having thrown away the signal in the process.

URLs you are still actively promoting. If a redirecting URL is in your sitemap, your navigation or your ad landing pages, something is out of step. Sitemaps should list destinations, not redirects, and internal links should point at the final URL rather than hop through one.

The check

Follow the redirect and count the hops. One hop to a relevant 200 is a healthy redirect and needs nothing.

# show every hop and the final destination
curl -sIL https://example.com/old-page/ | grep -i '^HTTP\|^location'

The related trap is a canonical tag pointing at a URL that then redirects, which is quietly damaging in a way this status will not show you, and which we found holding down a DR 72 page that was ranking for nothing. That one is covered in alternate page with proper canonical tag.

If you are seeing thousands of these after a move, the redirect map is the thing to check rather than the report, and the order that protects rankings is set out in migrating without losing rankings.

Book me

Thousands of these after a migration?

Send us the old and new URL patterns. We will tell you whether the redirect map is doing its job or quietly costing you the rankings the old pages had.

Reply within one working day No obligation Your details stay with us

Takes about 60 seconds. No newsletter and no CRM sequence. Your details are used to reply to this enquiry and nothing else. See the privacy notice.