Page with Redirect in Google Search Console
“Page with redirect” is one of the most common statuses in the Google Search Console Pages (Index Coverage) report, and it is also one of the most misunderstood. It appears under the “Not indexed” section, which makes people panic. In reality it is usually completely normal: it simply means the URL Google tried to crawl returned a redirect to a different address, so Google indexed the destination instead of that URL. Below is exactly what triggers it, when you can ignore it, and the few cases where it points to a real problem worth fixing.
What “Page with Redirect” Actually Means
When Googlebot requests a URL and the server responds with a 3xx redirect (most often a 301 permanent or 302 temporary), Google follows the redirect to the target page. The original URL is recorded as “Page with redirect” because there is nothing to index there — it is just a signpost pointing somewhere else. Google indexes the destination URL, not the redirecting one. So this status is reporting a fact about the URL, not necessarily an error.
This is fundamentally different from statuses like “Crawled — currently not indexed” or “Discovered — currently not indexed,” where Google is making a quality or scheduling decision about real content. With “Page with redirect,” Google is doing exactly what you asked: respecting your redirect and consolidating signals onto the target page. In the vast majority of cases, the correct response is to do nothing.
When It Is Completely Normal
Most “Page with redirect” entries are expected and healthy. You will see this status fill up legitimately in these situations:
HTTP to HTTPS redirects
Every http:// version of your pages redirects to the https:// version. Google still knows about the old HTTP URLs, so they sit in this report permanently. This is correct and you should leave it alone.
www and non-www consolidation
If you redirect www.example.com to example.com (or the reverse), the non-preferred version shows up here. Again, this is the redirect doing its job. See our www vs non-www redirect guide for how to set this up cleanly.
Trailing slash and case normalization
Redirecting /page/ to /page, or uppercase URLs to lowercase, generates redirect entries for every variant Google has discovered. This is good hygiene that prevents duplicate content.
Old URLs from a past migration
After a site migration or a URL restructure, your old paths 301 to their new equivalents. Google keeps those old URLs in its memory and reports them here for a long time — sometimes years. As long as each one points to the right new page, this is exactly what you want.
When It Is a Real Problem
The status only deserves attention when a URL you actually want indexed lands here. That means a page you expect to rank is redirecting away instead of serving content. Watch for these cases:
Redirected URLs sitting in your sitemap
Your XML sitemap should only ever list final, canonical, 200-status URLs. If a redirecting URL appears in your sitemap, you are telling Google “please index this” while your server says “go somewhere else.” That contradiction wastes crawl budget and can show up as “Page with redirect” against a sitemap-submitted URL. Remove redirected URLs from the sitemap and list only the destinations. This is one of the most common sitemap errors we see, and you can scan for it automatically with the SitemapFixer tool.
A page you want indexed redirects by mistake
A misconfigured plugin, a stale rewrite rule, or a CMS setting can silently redirect a live page. If a money page or a key article suddenly appears under “Page with redirect” and disappears from search, your content is no longer reachable at that URL. Use the URL Inspection tool to confirm the redirect target, then remove the unintended redirect so the page returns a 200 again.
Redirect chains and loops
If URL A redirects to B, which redirects to C, Google may flag the intermediate hops here and will eventually stop following long chains. Redirect loops (A points to B, B points back to A) break crawling entirely. Collapse every chain to a single hop — A should redirect straight to the final destination. Our redirect chains guide walks through finding and flattening them.
Internal links pointing to redirected URLs
Even when a redirect is correct, your own internal links should point to the final URL, not the old one. Linking through redirects leaks a little link equity and makes Google crawl the hop every time. Update internal links to the destination so the redirect only ever fires for external traffic and bookmarks.
How to Diagnose It in Search Console
Open Google Search Console, go to Indexing → Pages, and click the “Page with redirect” row. You will get the list of affected URLs. For each one, run it through the URL Inspection tool — it shows the exact redirect target Google followed. Ask one question per URL: do I want this URL indexed? If the answer is no (it is an old, alternate, or normalized version), the status is correct and you can move on. If the answer is yes, you have found a genuine problem to fix.
A fast filter: cross-reference the affected URLs against your sitemap. Any redirecting URL that is also in your sitemap is a contradiction worth resolving immediately, because that is where the status is most likely to hurt you.
How to Fix “Page with Redirect”
Once you have separated the harmless entries from the real ones, the fixes are straightforward:
1. Clean your sitemap. Remove every redirecting URL and keep only final 200-status destinations. This single step resolves most of the cases where the status actually matters. Run a free SitemapFixer scan to catch redirected and non-canonical URLs in seconds rather than checking them by hand.
2. Remove unintended redirects. For any page that should serve content, delete the rogue redirect rule so the URL returns a 200. Then request indexing on that URL in Search Console.
3. Flatten chains. Edit your redirect rules so each old URL points directly to the final destination in one hop, and remove any loops.
4. Fix internal links. Update on-site links to point at the destination URL instead of the redirecting one.
5. Leave the rest alone. HTTP-to-HTTPS, www normalization, trailing-slash redirects, and old migrated URLs will stay in this report indefinitely, and that is fine. You do not need to validate the fix or chase the count down to zero — a healthy site of any size will always have entries here.
301 vs 302: Does It Matter Here?
For permanent moves, use a 301. It tells Google the change is permanent and to pass ranking signals to the destination, and it is the cleanest signal for consolidating a redirected URL. A 302 (temporary) tells Google the original URL may return, so Google may keep the source URL around longer and treat the move as provisional. If you accidentally used a 302 for a permanent move, switch it to a 301. For a deeper comparison, see our 301 vs 302 redirects guide.
Frequently Asked Questions
Is “Page with redirect” bad for SEO?
Not by itself. In most cases it is the expected result of redirects you set up on purpose, and Google indexes the destination page normally. It only hurts SEO when a URL you want indexed is redirecting away, or when redirected URLs clutter your sitemap and waste crawl budget.
Will the count ever reach zero?
Almost never, and that is fine. Google remembers old URLs for a long time, so HTTP versions, www variants, and migrated paths keep this report populated indefinitely. Focus on whether the right pages are indexed, not on the raw number.
Should redirected URLs be in my sitemap?
No. A sitemap should list only final, indexable, 200-status URLs. Listing a redirecting URL sends Google a mixed signal and is one of the few situations where this status genuinely matters. Remove them and keep only destinations.
How do I know which redirects to fix?
For each affected URL, ask whether you want it indexed. If yes, the redirect is a mistake — remove it. If no, the status is correct and you can ignore it. Cross-referencing the list against your sitemap quickly surfaces the entries that need action.