~/search-console/page-with-redirect

§ page indexing report

usually fine

"Page with redirect" in Search Console

Usually not a problem. Google is telling you the redirect worked and it indexed the destination instead. Here is how to tell the harmless case from the one worth fixing.

Normally Google working as intended. Worth a look, rarely worth a fix.

check a url →

§ check your url

Is it still happening?

Paste the URL Search Console flagged. We follow the chain as Googlebot and show you every hop, so you can confirm the destination is the page you actually want indexed.

what this proves

Where this URL ends up, how many hops it takes, and whether the destination returns a working page.

what it cannot prove

We cannot tell you whether the destination is the right page. That is a judgement about your content, and a redirect to the homepage looks identical to a correct one from the outside. We also request from one location with no cookies, so a redirect that fires only for certain visitors will not appear.

§ what google is telling you

What this error actually means.

This URL redirects, Google followed it, and it indexed the destination rather than this address. That is the entire message. It is a status, not a fault, and it is the single most over-reacted-to row in the Page indexing report.

If you moved a page and pointed the old URL at the new one, this row is your redirect working exactly as designed. The correct response is to do nothing.

It becomes worth investigating in three cases: the destination is not the page you meant, the URL redirecting is one you expected to rank on its own, or a large number of URLs appear here that you never redirected. The last one usually means a normalisation rule is redirecting traffic you did not intend to move.

§ causes

5 things that produce this error.

Ordered by how often they turn out to be the cause, not by how obvious they look.

A deliberate move, working correctly

You changed a URL and redirected the old one. The old address appears here forever, or until Google stops checking it. Nothing is broken and there is nothing to fix.

Trailing slash or www normalisation counted as a redirect

Your server enforces one canonical form and redirects the other. Both forms exist in Google's memory, so the non-preferred one is reported here. Harmless, but it doubles the number of URLs Google has to check, and it is why this row is often much larger than the number of pages you actually moved.

text

GET /about   -> 301 /about/   (reported here)
GET /about/  -> 200          (indexed)

The destination is not what you intended

The common expensive version: a bulk redirect rule that sends every old URL to the homepage. Google indexes the homepage, the specific pages disappear, and the report calls it a success because technically the redirect resolved.

A page you wanted indexed is redirecting for reasons you did not set

Locale detection, a mobile redirect, an A/B test, or a login wall that bounces anonymous visitors. Nobody wrote this as an SEO decision and it does not show up in a browser that already has a session.

A sitemap still listing the pre-redirect URLs

Your sitemap advertises URLs that immediately redirect. Google keeps checking them because you keep telling it they matter, which is why this row can stay large indefinitely on a migrated site.

§ the fix

How to clear it.

step 1

First decide whether it needs fixing at all

Export the affected URLs and check where each one lands. If the destination is the page you want ranking, close the report. Chasing this row to zero is not a goal, and on a site with any history it is not achievable.

step 2

Point redirects at the equivalent page, not the homepage

A redirect to the homepage tells Google the old page has no successor, and it is treated much like a soft 404. Map each old URL to its closest replacement, and use 404 or 410 for content that genuinely has no successor.

step 3

Stop advertising URLs that redirect

Update your sitemap to list only final destination URLs, and update internal links to point at the destination rather than relying on the redirect. Both cut the work Google spends re-confirming a move you finished months ago.

bash

# Any 3xx here is a URL your sitemap should not still be listing
curl -sI https://example.com/old-page | head -1

step 4

Make sure no redirect is conditional on the visitor

Request the URL with no cookies and no locale hints. If it redirects for a crawler and not for you, a personalisation rule is deciding what Google can index, and that rule needs an exception for crawler traffic.

§ related

Next to check.

blockingRedirect errorGoogle followed a redirect from this URL and never arrived anywhere usable. Here is what breaks a redirect chain, and how to see the whole chain the way a crawler does.usually fineAlternate page with proper canonical tagThe clearest good news in the Page indexing report. Google found your canonical tag, agreed with it, and indexed the page you nominated. Here is when it is worth a second look anyway.blockingSoft 404Your server says 200 and your page says the content is gone. Google believes the page, not the status code, and refuses to index either.toolRedirect CheckerTrace the full redirect chain for any URL — every 301, 302, and hop.

→ Redirect Chains and SEO: The Ranking Signal Leaking Out of Your 302s

LintPage rules covering this: canonical-url, meta-refresh-redirect

§ faq

Questions, answered.

Is "Page with redirect" an error?

No. Search Console groups it under "Page is not indexed", which makes it look like a failure, but it is a status report: this URL redirects and Google indexed the destination instead. If you moved the page on purpose, the row is confirmation that your redirect works. It only needs attention when the destination is wrong or you did not intend the redirect.

Should I try to get this number to zero?

No, and on most sites you cannot. Every URL you have ever moved, every trailing-slash variant, and every www duplicate can appear here. The number reflects the history of your URLs, not the health of your site. Look at which URLs are listed rather than how many.

Why do so many of my URLs show as redirects when I never moved them?

Almost always a normalisation rule: HTTP to HTTPS, non-www to www, or trailing-slash enforcement. Each one creates a second address for every page on the site, and the non-preferred address gets reported here. Consolidating to a single canonical form in one layer of your stack, rather than several, keeps this under control.

Do redirects pass ranking signals?

A 301 passes signals to the destination, and Google has said it does so without meaningful loss. What does cost you is chaining several redirects together, or redirecting to a page that is not a genuine equivalent. A redirect to the homepage passes very little, because Google treats it as the old page having no real successor.

Should the redirected URL be in my sitemap?

No. A sitemap should list only URLs that return 200 and that you want indexed. Listing a URL that redirects tells Google to keep re-checking a decision you already made, which wastes crawl budget and keeps this report row inflated long after the migration finished.

§ before the next deploy

Catch this one before Search Console does.

Search Console tells you weeks after the fact. LintPage runs 60 checks against a URL in about 30 seconds. Free, no signup.

run a full scan →