How to Fix “Page with Redirect” in Google Search Console

“Page with redirect” is not an error. It means Googlebot requested a URL, followed the redirect you put there, and is indexing the destination instead of the source, which is exactly what a redirect is supposed to do. The status appears under “Why pages aren’t indexed” in the Page indexing report, but the redirecting URL is not meant to be indexed; the final URL is. So the report line is informational by default. The reason it shows up after a migration and the reason its count can climb are two different things, and only the second is a problem worth your time.

The real question is never “how do I fix the redirect” but “why is Google still discovering the old URLs at all.” If the count is stable, that is normal post-migration cleanup and you leave it alone. If the count is growing, something live is still feeding Google old URLs, and that source, not the redirect, is what you fix.

What the status actually means

When Google crawls a URL that returns a 301 or 302, it does not index that URL; it follows the redirect and considers the destination for indexing and ranking. The original URL lands in the Page indexing report as “Page with redirect” to explain why it itself is not indexed. This is expected and correct for HTTP-to-HTTPS moves, www normalization, restructured paths, and consolidated product URLs. URL-inspect one of the entries and you will typically see Google has indexed the destination, which is the proof the redirect is doing its job.

So before touching anything, confirm the destination is the URL you want indexed and that it is in fact indexed. If it is, the entry is reporting noise, not damage. The one exception worth catching early: if a URL you actually want indexed is sitting in this report, your own redirect is pointing the wrong way, and that is a routing bug to fix at the source, not a Search Console problem.

Stable count versus growing count

This single read ends most of the panic. A migration produces a one-time batch of old URLs that Google rediscovers and reclassifies; that batch is finite, so the count rises once and then plateaus. A plateaued count is the system working as intended, and there is no action to take. A count that keeps climbing weeks or months after the migration means a live source is still minting references to the old URLs, and Google keeps finding them. Your job is to locate and cut that source.

Use URL Inspection’s “discovered via” information on a sample of the newer entries to learn where Google found them. The answer is usually one of a small set: a sitemap still listing old URLs, internal links still pointing at old paths, or an external feed. Fix the source and the bleeding stops; the historical entries then age out on their own.

Cutting the discovery sources

Work through the supply chain that hands Google URLs.

The sitemap is first because it is the strongest discovery signal you control. It should list only final, canonical, 200-status URLs. A sitemap that still contains redirecting URLs is actively telling Google to crawl them, so regenerate it to emit destinations only.

Internal links are second. Old hrefs scattered through templates, navigation, and body content keep re-surfacing the source URLs. Fixing these at the template level propagates across the whole site at once and is far more efficient than editing pages individually. The win is double: you stop feeding old URLs to Google and you stop sending users and link equity through an unnecessary hop.

The sneaky, often-missed third source is automated feeds and generators: a product feed to Merchant Center, a catalog export, or programmatic emails and invoices still emitting old URLs. The classic cause is a cached base URL inside a feed plugin or export config that never got updated after the migration, so it regenerates old links on every refresh. If your “Page with redirect” count is the one that keeps growing, check the feeds first; that is usually where it lives.

External backlinks and UTM or other parameter variants are low priority. You do not control other sites’ links, the redirect handles those visitors correctly, and the entries age out. Do not spend effort chasing them.

Redirect chains are the one real equity problem

Everything above is about reporting cleanup. The one issue in this area that genuinely costs you is a redirect chain: A redirects to B, which redirects to C. Each hop adds latency, and long chains risk Google not following them all and risk diluting the signal that should reach the final URL. This is worth fixing on its own merits regardless of the report.

Flatten chains to single hops. Export your redirect rules, then programmatically find any redirect destination that is itself the source of another redirect, and rewrite the first rule to point straight at the final URL (A to C). After flattening, every redirect should resolve to a 200-status page in one step. This is mechanical and scriptable on any reasonable rule set.

Keep the working redirects, and stop chasing history

Keep your redirect rules in place indefinitely for any URL that ever had links or traffic. Removing a redirect to “clean up” the report turns the old URL into a 404, breaks the backlinks pointing at it, and discards the equity the redirect was preserving. The report entry is harmless; a 404 is not.

There is no way to force the historical “Page with redirect” entries to clear faster, and no reason to want to. They are Google’s record of redirects it has correctly processed. Focus entirely on stopping new ones: fix the sitemap, fix internal links at the template level, fix the feed emitting old URLs, and flatten any chains. Once no live source is producing old URLs, the count stabilizes, the destinations stay indexed, and the report goes back to being a passive log.

Use the right redirect type and method

While the report status itself is harmless, two implementation details determine whether your redirects preserve value correctly. The first is choosing the right status code for the situation. A 301 signals a permanent move and is the right choice for migrations, consolidations, and restructured paths, because it tells Google to transfer ranking signals to the destination and to index the new URL. A 302 signals a temporary move and is appropriate only when the original URL will genuinely return. Using a 302 for what is actually a permanent change can leave Google indexing the old URL longer than you want, so confirm permanent moves emit 301s.

The second is preferring server-side redirects over client-side ones. A redirect issued in the HTTP response, at the server or CDN level, is unambiguous and fast. A redirect performed in the browser with JavaScript or a meta refresh depends on rendering and is slower and less reliable for crawlers. Where you control the server or platform redirect rules, implement the redirect there rather than in client-side code.

A quick diagnostic checklist

When the “Page with redirect” count draws your attention, work through it in order. Confirm whether the count is stable or growing; a stable count is normal and needs nothing. If it is growing, use “discovered via” on recent entries to find the live source, then fix it: regenerate the sitemap to list only final URLs, update internal links at the template level, and correct any feed emitting old paths. Separately, flatten any multi-hop redirect to a single hop landing on a 200-status page, and verify permanent moves use 301s. Once those are clean, leave the historical entries to age out.

Frequently Asked Questions

Is “Page with redirect” hurting my rankings?

No, not in itself. The redirecting URL is not supposed to be indexed; the destination is, and if the destination is indexed and ranking, the redirect is working. The only ranking-relevant variants are a redirect chain adding latency and signal loss, or a redirect accidentally pointing away from a page you wanted indexed.

Why does my count keep growing after the migration finished?

A growing count means a live source is still emitting old URLs. Check, in order, your sitemap, internal links, and any product feed or programmatic generator. A feed plugin with a cached old base URL is the most common culprit. Fix the source and new entries stop appearing.

Should I remove the redirects to clear the report?

No. Removing a redirect creates a 404 for that old URL and breaks any backlinks or bookmarks pointing to it, discarding preserved equity. Keep redirects indefinitely for any URL that had traffic or links. The report entries are harmless and will age out.

Sources

Page indexing report – Search Console Help: https://support.google.com/webmasters/answer/7440203
Redirects and Google Search – Google Search Central: https://developers.google.com/search/docs/crawling-indexing/301-redirects