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

“Page with redirect” isn’t an error. Google’s help for the Page indexing report describes it as a non-canonical URL that redirects to another page, and says that as such the URL won’t be indexed. That is what a redirect is for: the old URL steps aside, and the destination is the one Google considers. So the entry is informational by default. Why it appears after a migration and why its count can keep climbing are two different questions, and the second is the one to investigate first.

The question isn’t “how do I fix the redirect” but “why is Google still finding the old URLs?” If the count is stable, that is normal cleanup after a move, and you leave it alone. If the count keeps growing, something live may still be handing Google old URLs, and that source is what you fix.

What the status means

A non-canonical URL that returns a redirect isn’t indexed itself; Google follows it to the destination. The same help page adds that the target might or might not be indexed, depending on what Google thinks of that target. So the check is on the destination: confirm it is the URL you want and that it is indexed.

Run URL Inspection on the target URL itself. The help page says that when you view a redirecting URL in URL Inspection, the indexed information applies to the tested URL, ignoring any redirects. Inspecting the old URL tells you about the old URL, not about where it now sends people.

If a URL you want indexed shows up in this list, your own redirect points the wrong way. That is a routing bug to fix at the source, not a Search Console problem.

Stable count versus growing count

This reading answers the first question. A migration produces a one-time batch of old URLs that Google revisits and reclassifies; the batch is finite, so the count rises and then levels off. A level count needs no action. A count that keeps climbing weeks or months after the migration points to a live source still producing references to old URLs, and Google keeps finding them.

To find that source, inspect a sample of the newest entries and read the Discovery section of the indexed result. The URL Inspection tool documentation describes its fields: the sitemaps that list the URL, and a referring page that Google possibly used to discover it. Two cautions from the same page. The referring page might link to the URL directly, or it might be a grandparent or great-grandparent of a page that does. And the live test doesn’t check sitemaps or referring pages at all, so this information comes from the indexed result, not a live test.

Cutting the discovery sources

Work through everything that hands Google URLs.

The sitemap. It should list only final URLs that return 200. A sitemap that still contains redirecting URLs keeps pointing Google at them, so regenerate it to emit destinations only.

Internal links. Old links in templates, navigation and body copy keep resurfacing the source URLs. Fixing them at the template level updates the whole site at once, and it also stops sending visitors through an extra hop.

Feeds and generators. A product feed, a catalog export, or automated emails and invoices can keep emitting old URLs. One cause to check is a base URL stored inside a feed plugin or export setting that was never updated after the migration, so every refresh regenerates old links. If the growing count doesn’t trace to the sitemap or internal links, check these next.

External links and parameter variants are low priority. You don’t control other sites’ links, the redirect handles those visitors correctly, and the entries age out.

Redirect chains

The sitemap, link and feed work is report cleanup. An issue in this report that costs something on its own is a chain: A redirects to B, which redirects to C. Google’s site move guide advises redirecting to the final destination directly, and if that isn’t possible, keeping chains short, ideally no more than 3 hops and fewer than 5. It also notes that chains add latency for users and that not all user agents and browsers support long chains.

Flatten chains to single hops. Export your redirect rules, find any 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 land on a page that returns 200 in one step.

Keep the working redirects

The same site move guide says to keep redirects for as long as possible, generally at least 1 year. For URLs that had links or traffic, keep them longer. Removing a redirect to “clean up” the report turns the old URL into a 404 and breaks every link pointing at it. The report entry is harmless; the 404 isn’t.

You can’t make the historical entries clear faster, and there’s no reason to try. They are Google’s record of redirects it has processed. Put the effort into stopping new ones: the sitemap, template-level internal links, the feeds, and any chains. Once no live source produces old URLs, the count should level off and the report go back to being a passive log.

Use the right redirect type and method

Two implementation details decide whether a redirect says what you mean. Google’s redirects documentation explains the difference between types: with a permanent redirect (301 or 308), the indexing pipeline uses the redirect as a signal that the target should be canonical; with a temporary one (302, 303 or 307), it doesn’t. For migrations, consolidations and restructured paths, use a permanent redirect.

The same page recommends a permanent server-side redirect whenever possible, and advises using JavaScript redirects only if server-side or meta refresh redirects aren’t possible, because Google might never see a JavaScript redirect if rendering fails. Where you control the server, CDN or platform rules, set the redirect there.

A quick diagnostic checklist

1. Is the count stable or growing? Stable needs nothing.
2. If growing, inspect recent entries and read the Discovery section of the indexed result to find the source.
3. Regenerate the sitemap with final URLs only, fix internal links at the template level, and correct any feed emitting old paths.
4. Flatten chains to one hop that lands on a 200 page.
5. Confirm permanent moves use permanent, server-side redirects.
6. Leave the historical entries to age out.

Frequently asked questions

Is “Page with redirect” hurting my rankings?

Not in itself. The redirecting URL isn’t meant to be indexed. Inspect the destination: if it is indexed and is the page you want, the redirect is doing its job. The cases to act on are a long chain, or a redirect pointing away from a page you wanted indexed.

Why does my count keep growing after the migration finished?

Something live may still be producing old URLs. Check the sitemap, internal links, and any product feed or generator, using the Discovery section of URL Inspection on recent entries to see where Google found them. Fix the source and new entries should stop appearing.

Should I remove the redirects to clear the report?

No. Google’s site move guide says to keep redirects for as long as possible, generally at least a year. Removing one turns the old URL into a 404 and breaks the links pointing to it.