“Page with redirect” is one of the most common rows in the Page indexing report, and it is the one people most often try to fix when nothing is broken. Most of the time it is Search Console confirming that a redirect you set up is doing its job. Sometimes it is hiding a real mistake. The difference is not in the status, it is in which URLs are sitting under it.
What “page with redirect” means
Google’s page indexing report documentation is unusually plain about it:
This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL.
Two things follow from that sentence, and both get missed.
First, the status is about the URL in the list, not the page a visitor ends up on. Google is telling you that /old-page is not indexed. It is saying nothing at all about /new-page. That is why the count under this status going up is not, by itself, a traffic story.
Second, the same documentation adds a line people find contradictory:
A canonical URL with a redirect can be indexed.
So a redirecting URL is not automatically un-indexable. The reason these URLs are not indexed is that Google picked a different URL as the canonical for the content, not the redirect itself.
When it is completely fine
Four cases account for most of what sits under this status on a healthy site.
HTTP and www variants. If http://example.com, http://www.example.com and https://www.example.com all redirect to https://example.com, that is three URLs per page filed under “page with redirect”, forever, by design. On a domain property you are seeing every variant Google has ever known about.
Trailing slash normalisation. A host that redirects /page to /page/ doubles the same way.
Old URLs you deliberately retired. A migration done properly produces exactly this row. The redirects working is what the status is reporting.
Campaign and tracking URLs. Anything with a parameter that redirects to the clean URL.
In all four, the count is large and stable, the destinations are indexed, and there is nothing to do. Chasing this number to zero is not a goal; on most sites zero is not even reachable.
When it is actually a problem
Three shapes are worth your attention, and you find them by reading the URLs rather than the total.
A page you did not intend to redirect. Something in the CMS or a plugin is sending a live page somewhere else. This is the one that costs traffic, and it is invisible if you only look at the count.
Redirects into the wrong destination. The classic is a bulk rule that sends every retired URL to the homepage. Each of those redirects “works” in the HTTP sense, so it never appears as an error, and every one of them is a page whose relevance you threw away. If you cannot name the page that best replaces the old one, that redirect is doing less than you think.
Chains. Google files a genuine failure under a different status, redirect error, which its documentation defines as a chain that was too long, a loop, a URL that grew past the maximum length, or a bad or empty URL in the chain. If you see redirect errors alongside a growing “page with redirect” count, the chain is the thing to fix, and you fix it by pointing the first URL straight at the last one.
How to check yours in five minutes
- Open the Page indexing report and click into “Page with redirect”. You are reading the sample list, not the number above it. Note that Google caps the example list at 1,000 URLs and does not guarantee it shows everything in a status.
- Sort mentally into the two piles above: variants and retired URLs in one, anything you recognise as a live page in the other. The second pile is your work.
- Take one URL from the second pile and inspect it. Google’s documentation has a trap here worth quoting: if you inspect a redirecting URL, “the indexed information applies to the tested URL (ignoring any redirects)”. To see the state of the page people actually land on, click INSPECT again inside the Page indexing section on the Google-selected canonical.
- Check the destination is indexed. If it is not, you have been debugging the wrong URL, and the answer is in URL is not on Google or whichever status the destination is sitting in.
- Run the chain by hand. Request the old URL and follow every hop, counting them. One hop is right. Two is tolerable. Three or more is a bug you introduced over time by redirecting redirects.
What that check found on this site
I ran step 5 against my own domain on 28 August 2026 rather than describing it in the abstract, and it found the chain I just told you to look for:
http://shahidali.co/ 308 ->
https://shahidali.co/ 308 ->
https://www.shahidali.co/ 200Two hops to reach the homepage from the plain HTTP apex. The 308s themselves are not a finding: I went through why in 301 vs 308 redirect, and Google scores both as the same permanent move. The canonical host here is www.shahidali.co, and it is consistent everywhere it should be: the canonical tag, the og:url, and all 131 entries in the sitemap use it. So nothing is broken, and no page is at risk. But the HTTP apex takes the scenic route, upgrading the protocol first and moving to the www host second, when one hop would do.
That is the honest scale of it. Two hops is not a problem worth a migration, and I am not going to dress it up as one. It is worth knowing because it is how three-hop chains start: each hop was reasonable when it was added, nobody counted them together, and by the time it matters the rule that created the first one is four years old and nobody remembers writing it. Counting hops takes a minute. Do it before the number grows.
The confusion with the other statuses
This status gets mixed up with two neighbours, and the distinction is worth holding.
Duplicate without user-selected canonical is about two URLs that both serve content, where Google picked one. “Page with redirect” is about a URL that serves no content at all, because it points elsewhere. Different problem, different fix.
“Alternate page with proper canonical tag” is the other neighbour, and there the URL also serves content but declares another page as canonical. All three are Google saying “this URL is not the one I index”, for three different reasons, and all three are usually fine.
The general rule I use on audits, and the one behind the umbrella guide to every indexing status, is that a status is only a problem when the URLs under it are pages you wanted indexed. Everything else is bookkeeping. Search Console is not scoring you, it is describing what it did.
The status this gets confused with most is Redirect error, which is the failure rather than the healthy case. If yours is looping rather than resolving, and the site runs on WordPress, the WordPress redirect loop post covers where the two conflicting rules usually live.
Sources
- Google Search Console Help, page indexing report, definitions of “page with redirect” and “redirect error”, checked 28 August 2026
- Google Search Central, what is canonicalization, on how Google clusters duplicates and selects a canonical URL
- Google Search Console Help, URL Inspection tool, on inspecting the tested URL versus the Google-selected canonical
- First-hand: redirect hops followed on shahidali.co on 28 August 2026, and the 131 URL entries in the site’s sitemap, all on the www host