Page With Redirect in Search Console: Error or Expected?

"Page with redirect" is almost always Search Console reporting that your redirects are working. Google's definition of the status is short and unambiguous: "This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed." A URL that sends visitors somewhere else is not supposed to be indexed. The destination is. When Google files a redirecting URL under this status, it has understood the redirect and moved on to the target.

It causes alarm anyway, for the same reason its neighbours do. Search Console groups it under the heading covering pages that are not indexed, so a site that just finished a clean migration opens the report and finds tens of thousands of URLs sitting under what reads like a list of failures. This article covers what the status means, the five situations where it does point at something worth fixing, and how to separate those from the ordinary case without spending a week on it.

What does "Page with redirect" mean in Search Console?

It means Google requested a URL, received a redirect response pointing at a different address, and therefore did not index the URL it asked for. Google evaluates the destination separately. In Google's own wording on the target, the URL a redirect points to may or may not be indexed depending on how Google evaluates that target page, which is the part people skip.

That distinction matters more than the status itself. "Page with redirect" tells you nothing about whether the destination made it into the index. It only tells you the source URL did not, which was never in question. If you are worried about a migration, the number to check is how many destination URLs are indexed, not how many source URLs landed in this bucket.

The last row is the one worth remembering. "Redirect error" and "Page with redirect" look similar in a list and mean opposite things. The first says Google could not follow your redirect. The second says it followed it fine.

Is "Page with redirect" an error?

No. It is an informational status, and on most sites the count should be large and growing. Every URL you have ever consolidated, every product that moved category, every http address on a site that went https, every non-www variant, every trailing-slash variant your server normalizes: each of those redirects, and each earns this status forever. A site with 3,000 live pages can easily carry 30,000 URLs in this report and be in perfect health.

The one thing you should not do is try to make the number go down. There is no way to remove a URL from this report other than to stop redirecting it, and un-redirecting an old URL means either resurrecting a dead page or serving a 404 where you currently serve a working handoff. Both are worse than the status you were trying to clean up. If a URL genuinely needs to leave Google's index rather than redirect, that is a different job with its own tooling, covered in removing a URL from Google.

When "Page with redirect" is actually a problem

There are five cases where the status is a symptom rather than a report. All five are worth ten minutes each.

Redirecting URLs are in your XML sitemap. A sitemap is a list of pages you want indexed, so a redirecting URL in it is a contradiction. Google follows the redirect, indexes the target if it merits it, and quietly discounts your sitemap as a signal of what you actually care about. After a migration this is the single most common leftover, because the sitemap gets regenerated from an old source or not regenerated at all. Every URL in your XML sitemap should return 200.

Your internal links still point at the old URLs. Redirects work, so nobody notices. But every internal link to a redirecting address spends a crawl request to learn something Google already knows, and passes its signals through an extra hop. On a small site this is noise. On a large one it is a measurable share of the crawl Google gives you. Update the links in your templates and content to point at the final destination.

Chains. A URL that redirects to a URL that redirects to a URL is a chain, and each hop costs a fetch. Google will follow a few hops but is explicit that it will not follow them indefinitely, and a chain long enough to exceed the limit turns into "Redirect error" and stops working entirely. Chains build up quietly over years as one migration is layered on the last. Point every old URL directly at the current live address rather than at whatever was current when it was retired.

Redirects to an unrelated page, usually the homepage. Sending a batch of retired URLs to the homepage feels tidier than serving 404s. Google generally treats an irrelevant redirect as a soft 404, so the signals you hoped to preserve are lost anyway, and a visitor who clicked a specific result gets dumped on a front page with no idea why. Redirect to a genuinely equivalent page or serve a clean 410. Do not use the homepage as a landfill.

The destination is not indexed. This is the one that actually costs traffic, and the status will never tell you about it. The source URL shows as handled, the redirect is correct, and the target sits in "Crawled, currently not indexed" where nobody thought to look. Check the destinations directly rather than inferring from the source report.

Does 301 or 302 matter for indexing?

Both land in the same Search Console status, and both get followed. The difference is what they signal about permanence. A 301 is a strong canonicalization signal telling Google the move is permanent and the destination should take over. A 302 says the move is temporary, so Google's default expectation is that the original URL comes back and keeps its place.

In practice Google will canonicalize to the target of a persistent 302 eventually, because a redirect that has been in place for months is not behaving like a temporary one. But "eventually" is doing real work in that sentence, and there is no reason to make Google guess. If the move is permanent, serve a 301. The most common cause of accidental 302s is a framework or CDN default, so check what your server actually returns rather than what the config file says it should. Redirect handling in a reverse proxy frequently overrides the application behind it.

Meta refresh and JavaScript redirects work differently again. Google treats them as weaker signals than an HTTP redirect and has to render the page to find them at all, which adds delay. Where you control the server, use a server-side redirect. Where you do not, a rel=canonical tag is a more reliable signal than a client-side redirect.

How long does it take for the redirect target to get indexed?

It depends entirely on how often Google crawls the old URL, and old URLs are typically crawled rarely. That is the frustrating part of a migration: the pages Google needs to revisit in order to learn about the move are the pages it has the least reason to visit. A high-traffic URL with lots of inbound links might be reprocessed in days. A deep page four clicks from the homepage can sit unchanged for months.

Three things genuinely speed it up. Make sure the new URLs are in a current sitemap, since that is how Google discovers the destinations without waiting to rediscover the sources. Update internal links so your own navigation points at the new addresses. And submit the destination URLs rather than the old ones, because submitting a URL that redirects just asks Google to re-learn the redirect.

Then watch it, because migrations fail quietly. The usual pattern is that most of the site transfers within weeks and a subset never does, and nobody notices until a quarterly traffic review. Keep an eye on whether the rankings actually moved across to the new URLs rather than assuming a clean redirect map guarantees it, and check index status on the destinations on a schedule. Watching coverage per URL over time is what the index monitoring side of Indexing is built for, and a migration is the case it earns its keep on.

How do I find redirect chains and loops?

Search Console will not list them for you. It reports the status of individual URLs, not the shape of the path between them, so a two-hop chain and a direct redirect look identical in the report. You need to walk the redirects yourself.

Take the URL list from the "Page with redirect" export, request each address without automatically following redirects, and record the destination and status code of every hop. Anything with more than one hop is a chain to flatten. Anything that returns to an address already in its own path is a loop, which is a genuine outage for that URL: Google gives up, the page is not indexed, and users see a browser error. Loops are almost always the result of two rules written by two people at two different layers, typically one in the application and one at the CDN, each undoing the other.

Once you have the map, the fix is mechanical. Rewrite every rule so the source points straight at the final live URL, delete the intermediate rules that nothing needs any more, and re-export the report in a few weeks to confirm the chains are gone rather than assuming the deploy worked.

The short version

"Page with redirect" means Google followed your redirect and correctly declined to index a URL that is not a real page. It is expected, it is permanent, and the count is supposed to grow. Do not try to shrink it. Spend your time on the five failure modes instead: redirects sitting in your sitemap, internal links pointing at old addresses, chains longer than one hop, redirects to an unrelated page, and destinations that never got indexed. The last of those is the only one that quietly costs traffic, and it is the one the status will never warn you about. If a page is missing from search, the page indexing report will name the status that explains it, and it will not be this one.

Migrating a site, or trying to work out whether a redirect map actually landed? Paste your destination URLs into the console at the top of this page. Indexing checks index status across Google and Bing, names the reason for every gap in plain English, and keeps watching so a migration that half-transferred does not go unnoticed for a quarter. You can also check Google index status for the old addresses to confirm they have dropped out.