Page With Redirect in Google Search Console: When to Ignore It (And When to Fix It)

If the Page Indexing report lists a batch of your URLs under Page with redirect, the short answer is that most of them need no action. Google's own definition is: "This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed." The redirect worked, Google followed it, and the destination page is the one that can be indexed.

The longer answer is that this status sits right next to a few real problems — sitemaps full of old URLs, internal links that never got updated, and redirects that land on the wrong page. This guide covers how to separate the harmless entries from the ones worth fixing.

What "Page With Redirect" Actually Means

When Googlebot requests a URL and gets a redirect back (a 301, 302, 307, 308, or a meta refresh), it doesn't index the URL it asked for. It records that URL as a pointer to somewhere else, follows the redirect, and evaluates the target instead. Search Console reports the original URL as "Page with redirect" so you know why it isn't in the index.

That's the expected outcome of almost every redirect you set up on purpose. If you moved /old-post to /new-post with a 301, you want /old-post to show up here — it means Google saw the move and stopped treating the old address as a page of its own.

One detail is worth knowing: the status only describes the redirecting URL. Google's documentation notes that the target "might or might not be indexed," depending on how Google assesses that target page. So the useful question is never "why is this URL here?" but "is the page it points to indexed?"

Common Reasons Blog URLs Land in This Report

On a typical blog, the entries usually come from a handful of predictable sources:

| Source | Example | Action needed? | |---|---|---| | HTTP → HTTPS | http://yourblog.com/post → https://yourblog.com/post | No | | www ↔ non-www | www.yourblog.com → yourblog.com | No | | Trailing slash rule | /post → /post/ | No, if consistent | | Changed slug | /2023/my-post → /my-post | No, if the target is right | | Merged or pruned post | Old post 301'd into a newer, fuller one | No, if the target covers the same topic | | Old URL still in your sitemap | Sitemap lists a URL that now redirects | Yes — update the sitemap | | Internal link to an old URL | A post still links to /old-post | Yes — update the link | | Redirect to an unrelated page | Deleted post sent to the homepage | Yes — reconsider the target |

The first five rows are housekeeping that Google handles on its own. The last three are where this report turns into a to-do list.

When It's Fine to Ignore

You can leave a "Page with redirect" entry alone when all three of these are true:

1. You meant to redirect that URL. It's an old slug, a protocol or hostname variant, or a post you merged during a content pruning pass.
2. The redirect is permanent. Google's redirect documentation says that with a permanent redirect (301 or 308), "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." With a temporary one (302, 303, 307), it doesn't use the redirect as that signal. If a move is permanent, the status code should say so.
3. The target is indexed. Run the destination URL through the URL Inspection tool. If it shows as indexed, the redirect has done its job.

A large or growing count on its own isn't a warning sign. A site that switched to HTTPS or changed its permalink structure can easily have more redirecting URLs than real posts, and that's normal.

When "Page With Redirect" Points to a Real Problem

Your sitemap still lists the old URLs

A sitemap is supposed to tell Google which URLs you want indexed. If it's full of addresses that redirect, you're sending mixed signals: "index this," followed by "actually, go over there." Google's guidance on canonicalization recommends listing canonical URLs in your sitemap. Check whether the URLs in the report also appear in your submitted sitemap — if they do, regenerate the sitemap so it only contains final destination URLs. On most CMSs this means clearing a sitemap plugin's cache or fixing a hard-coded entry.

Your own internal links point at the old address

Every internal link that points at a redirecting URL makes Googlebot (and readers) take an extra hop. One hop is harmless; but links rarely get updated once, and after a couple of restructures you end up with chains. Google's crawlers follow up to 10 redirect hops by default, and a chain that runs past the limit or loops back on itself gets reported as Redirect error instead — a status that does need fixing. An internal linking audit finds the links still pointing at old URLs, and a redirect chain checker shows how many hops each one takes.

The redirect goes to the wrong place

Redirecting a deleted post to your homepage, or to a loosely related category page, is a common shortcut. It technically resolves, so it shows up as "Page with redirect" rather than as an error. But if the target doesn't cover what the old page covered, it's not a real replacement. Google may treat a redirect like that as a soft 404 — a page that exists but doesn't deliver what the URL promised. If there's no true replacement, a 404 or 410 is the more honest response.

A page you want indexed is redirecting

Occasionally a URL you expect to rank shows up in this report. That usually means a plugin, server rule, or CDN setting is redirecting something it shouldn't — a trailing-slash rule that conflicts with your canonical tags, a language redirect based on visitor location, or an old rule matching more paths than intended. Treat any surprise entry as a bug: open the URL in a private window and run curl -IL against it to see every hop and status code.

How to Check Your Report in Five Minutes

1. In Search Console, go to Indexing → Pages and open Page with redirect.
2. Export the list and sort it. Scan for patterns: http://, www., missing trailing slashes, and old date-based slugs are expected. Anything else deserves a second look.
3. Pick a few URLs and check where they land with curl -IL https://yourblog.com/old-url. Confirm each ends on a 200 page with a single permanent redirect, not a chain or a 302.
4. Search your sitemap for the same URLs and remove any that redirect.
5. Inspect the destination URLs, not the redirecting ones. If a destination isn't indexed, that's the page to work on — the redirect itself is fine.

If any of your URLs land under Blocked due to access forbidden (403) or Excluded by 'noindex' tag instead, those are different problems with different fixes — the 403 guide and the noindex breakdown cover each.

Should You Ever Remove Old Redirects?

Generally, no. Google's site-move guidance says to keep redirects "for as long as possible, generally at least 1 year," so it has time to recrawl old URLs and move their signals — including backlinks from other sites — to the new ones. Removing a redirect too early turns a working "Page with redirect" entry into a 404 and throws away whatever links pointed at the old URL. The only redirects worth deleting are ones that send visitors somewhere wrong.

How Do You Know a Redirect Cost You Traffic?

Search Console's indexing report tells you a URL redirects. It doesn't tell you whether the move hurt. The clearest sign is in your performance data: if the destination post doesn't pick up the clicks the old URL used to earn, something went wrong — the new page may not be indexed yet, it may target a different query, or the redirect may point at the wrong page.

That's a comparison worth watching for a few weeks after any URL change. Traffic Monitor pulls your Search Console clicks and impressions every day and sends an alert when a post's traffic drops past the threshold you set, so a redirect that quietly lost traffic shows up as a change to investigate instead of something you notice months later.