The page with redirect Google Search Console status appears under “Not indexed” in the Page indexing report, and it is the one most often mistaken for a fault. Owners see hundreds of URLs listed as not indexed and assume something is broken. Usually nothing is. These are addresses that point somewhere else, and Google is indexing the somewhere else. The useful question is not “how do I get these indexed” but “is each one pointing at the right place, and why is Google still finding it?”
What page with redirect means
Google’s Page indexing report documentation defines it in two sentences: “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed.” The redirecting URL is not the version Google wants to show, so it stays out and the destination takes its place.
It helps to see where this status sits among its neighbours in the report, because several of them involve the same URLs at different stages.
| Status | Google’s description | Usually needs action? |
|---|---|---|
| Page with redirect | “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed.” | Rarely |
| Redirect error | A redirect chain that was too long, a loop, a URL over the maximum length, or a bad or empty URL in the chain | Yes |
| Alternate page with proper canonical tag | “This page correctly points to the canonical page, which is indexed.” | Rarely |
| Not found (404) | “This page returned a 404 error when requested.” | Only if the page should exist |
The difference between the first two rows is the whole story. Page with redirect means the redirect worked. A redirect error means it did not, and that one deserves your time first.
Why the list is usually the report working
Most sites redirect far more URLs than their owners realise. Each of these patterns generates entries under this status, and each is correct behaviour:
- Protocol. Every
http://address redirecting to itshttps://version. - Hostname.
example.comredirecting towww.example.com, or the reverse. - Trailing slashes.
/guideredirecting to/guide/so only one version is served. - Retired content. Old posts merged into newer ones, renamed categories, discontinued products pointed at a replacement.
- Migrations. A whole URL structure moved to a new one, which can add thousands of rows at once.
Google keeps finding these old addresses through external links, old sitemaps and its own memory of URLs it has seen before. That is fine. The redirect passes the visitor and the crawler on, and the indexed page is the destination.
The received wisdom says to get the “not indexed” count down. For this status that instinct is wrong. Removing a redirect to clear a row from the report would turn a working redirect into a 404 or a duplicate, both worse outcomes. A large page with redirect count on a site that has moved to HTTPS and been through a migration is normal.
When the page with redirect Google Search Console status needs action
There are three situations where a URL in this list is telling you something you need to fix.
- The destination is wrong. A redirect that sends a specific product page to the homepage, or an article to an unrelated category, is technically working and practically a loss. Check that each group lands on the closest equivalent page.
- An important page is redirecting by mistake. If a URL you expect to rank appears here, something is redirecting it: a plugin rule, a server rewrite or a CMS setting that changed the slug. That page is not being indexed under the address you think it is.
- Your own site still lists the old URLs. If internal links and the XML sitemap still point at redirecting addresses, you are sending Google through a redirect on every crawl for no reason.
The third is the most common and the easiest to fix. Semrush’s advice on Search Console errors puts it plainly: “update internal links on your site to point directly to the new URLs, reducing the need for redirects.” A sitemap should list only final, indexable URLs; our guide to XML sitemaps for SEO covers what belongs in one.
How to clean up the list
- Export and group the URLs. Sort by path. Protocol, hostname and trailing-slash variants form obvious blocks you can mark as intended and move past.
- Check the destinations of what remains. Use URL Inspection or any header checker to confirm where each one ends up and with which status code. Permanent moves should use a 301; our comparison of 301 and 302 redirects explains why the choice matters.
- Look for chains. A URL that redirects to another redirect wastes a hop each time. Point the first URL straight at the final one. Google’s crawlers “follow up to 10 redirect hops”, but you should not need more than one. See redirect chains for how to find and flatten them.
- Update internal links and the sitemap. Replace every old address with its final destination.
- Leave the redirects in place. External links and bookmarks still use the old URLs, and the redirect is what carries them across.
After a migration this list is also a useful audit. Compare it against your redirect map: every old URL should appear here eventually, pointing at its planned destination. Our site migration guide covers building that map before the move rather than after.
What the report cannot tell you
The limitation is that this status confirms a redirect exists, not that it is the right one. Search Console will list a product page redirecting to your homepage under the same heading as a clean HTTPS redirect. It cannot judge intent. Only a comparison with your own redirect map, or a manual check of the destinations, will separate the two.
It also does not tell you how Google found each URL. An old address can keep appearing for years because an external site links to it, and that is not something you control or need to. What you do control is your own internal links and sitemap, and those should never be the reason a redirecting URL is crawled. If the list keeps growing after you have cleaned both, look for a template or plugin generating links to old addresses.
Using Validate fix on this status is rarely worthwhile, because there is usually nothing to fix: the URLs are meant to redirect and will stay listed. Save validation for statuses that represent real faults, such as redirect errors or a server error (5xx). For pages that are excluded on purpose by a directive rather than a redirect, see excluded by noindex tag.
Frequently asked questions
Is page with redirect bad for SEO?
No. Google describes it as a non-canonical URL that redirects to another page and will not be indexed. The destination is indexed instead, which is what the redirect is for.
Should I remove redirects to clear the report?
No. Removing a working redirect turns the old URL into a 404 or a duplicate and drops anyone following an old link. Keep the redirect and update your own links instead.
Why does Google still crawl URLs I redirected long ago?
It finds them through external links, old sitemaps and URLs it has seen before. Remove them from your sitemap and internal links; the rest is outside your control and harmless.
What is the difference between page with redirect and redirect error?
Page with redirect means the redirect worked. Redirect error means Google could not complete it, because of a loop, a chain that was too long, an over-long URL or a bad URL in the chain.
The takeaway Treat this status as an inventory of working redirects. Check the destinations, flatten any chains, and remove old URLs from your internal links and sitemap. Leave the redirects themselves alone.
