Page with Redirect: Error or Normal? (Search Console)

In Google Search Console's Page Indexing report, "Page with redirect" isn't a defect to fix. It's the opposite: the listed URL points to another one, and Google indexes the destination — exactly what a redirect is supposed to do.

The status only gets interesting when the redirect doesn't do what you think. What if the chain keeps growing, A to B to C? What if a strategic page redirects to the homepage instead of its real equivalent? What if your internal links still point, by the hundreds, to old redirected URLs?

Three cases where a redirect that looks perfectly normal quietly costs you crawl budget and rankings.

What does "Page with redirect" mean?

It means the listed URL points to another address (an HTTP 3xx response). Google therefore doesn't index it under that URL: it follows the redirect and indexes the destination page. In the vast majority of cases, that's expected behavior, not an anomaly.

It's actually a sign your redirect works. When you move a page, consolidate it into another, or switch to HTTPS, the old URL should point to the new one. Google sees it, marks it "Page with redirect," and indexes the target instead.

So the only useful question isn't "how do I make this status disappear," but "does the redirect lead where it should, and cleanly?"

When it's normal: nothing to do

Most URLs in this report are there for good reasons. These redirects are healthy and need no action:

The common thread: the redirect leads to the right page, in a single hop. As long as that holds, there's nothing to fix.

When the redirect is a problem

The status deserves attention in four situations. None is visible from the "Page with redirect" label alone: you have to look at where the redirect leads, and how.

Understanding redirect codes: 301, 302, 303, 307, 308

Not all 3xx statuses are equal, and the code you choose changes how Google treats the page. Direct answer: signal a permanent move with a 301 (or 308); a temporary move with a 302 (or 307).

One case often causes confusion: the "internal 307" tied to HSTS. When your site enforces HTTPS via HSTS, the browser itself forces http:// to https:// through a locally generated 307 — it's not a real server redirect. It shows up in developer tools, but there's nothing to fix: don't confuse it with a redirect to clean up.

The hidden cost: redirected URLs still linked

Here's the point almost no one covers, and it weighs on large sites. A redirect can be perfectly clean and still cost you, if you keep pointing to the old URL.

Every internal link to a redirected address forces Google and your visitors through a needless hop. On crawling, that's budget spent reaching a page that only exists to redirect. And a sitemap still listing old redirected URLs sends Google a contradictory signal: you're submitting pages you're also asking it to leave.

The rule is simple: once a redirect is in place, update your internal links and sitemap to point straight to the final URL. The redirect stays as a safety net for external links you don't control, but your own site should no longer route through it.

Now that you can tell a healthy redirect from a real problem, you still have to spot the latter among the former — across all your URLs.

Identify the affected pages across the list you analyze

This is where Search Console hits its limit: its URL Inspection tool handles one URL at a time. To know, page by page, which target it redirects to, whether it forms a chain, and whether you still link it, you inspect, read, move to the next. Fine for a handful of pages. Across hundreds, spotting the growing chain or the misredirected strategic page becomes impractical.

That's the wall IndexProbe breaks. IndexProbe is the bulk version of Google's URL Inspection tool: it queries the official Search Console API to inspect, in a single analysis, the list of URLs you give it (CSV import, sitemap, paste). For each page, it shows the indexing status, the redirect's destination URL, the segment, and the internal links it receives.

Example data. Source URL, redirect target and chains, per URL | IndexProbe view.

What you get out of it depends on the list you bring in. IndexProbe doesn't crawl your site to discover URLs: it inspects the ones you give it, and only those.

Example data. Share of redirects among HTTP codes | IndexProbe view.

How to fix it, by case

Once your pages are triaged, the fix depends on the problem. Most redirects need none; focus on the four cases below.

  1. Redirect chain. Replace the cascade with a direct redirect from the starting URL to the final one. A should no longer go through B and C: A points straight to D.
  2. Redirect loop. Identify the two rules pointing at each other and fix the redundant one, so the chain ends on a real 200 page.
  3. Irrelevant target. Point the redirect to the page's real equivalent (the replacing product, the closest category), not to the homepage by default. It's also the right way to handle a deleted page that deserved a 301 rather than a 404: see when to redirect a removed page in Fix 404 errors in Google Search Console.
  4. Linking and sitemap. Update your internal links and sitemap to target the final URL, without routing through the redirect. And check the code: a permanent move should be a 301 (or 308), not a 302/307.

Confirm the fix worked

After your fixes, confirm at scale. Re-inspect your URLs and compare two analyses over time: chains should be resolved (a single hop), misredirected strategic pages should now point to the right target — or be reindexed if they shouldn't have redirected at all.

Example data. Change between two analyses, after resolving chains and fixing targets | IndexProbe view.

That's the full loop: understanding the redirect is usually normal, spotting chains, loops and irrelevant targets, fixing them directly, verifying.