Page with redirect in Search Console: when to ignore it or fix it
Page with redirect means the URL redirects, so Google indexes its target instead. Ignore it unless your sitemap or internal links still use the old URL.
LLaunchScaler·Published ·8 min read
Page with redirect means the URL listed in the report redirects to another URL, so Google indexes the target instead, and most of the time that is exactly what you want. It needs a fix only when your own sitemap or internal links still point at the redirecting URL, or when the target the URL redirects to is not indexed either.
So the job is to look at the example URLs, confirm their targets are healthy, and then check whether you are the one still sending Google to the old addresses.
What does "Page with redirect" mean in Search Console?
It means Google crawled the URL, got a redirect, and will not index that URL. Search Console's help says: "This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL."
A redirect tells Google the content now lives somewhere else. With a permanent redirect (301 or 308), Google's documentation says "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." The redirecting URL drops out, the target takes its place, and the old URL is reported here so you can see what happened to it.
The help adds one exception: "A canonical URL with a redirect can be indexed." That covers the rarer case where Google still treats the redirecting URL as canonical, for example when other signals point strongly at it. For the other statuses in the same report, see the page indexing report guide.
When can you ignore Page with redirect?
Ignore it when every example URL is an old version you retired on purpose and every target is indexed. Moving to HTTPS, choosing www or non-www, settling on a trailing-slash style and renaming slugs all leave redirecting URLs behind, and Google keeps finding them through old links and bookmarks. Those rows are the report confirming your redirects work.
Variant
Listed URL
Questions, answered
What people ask about this
01
What does page with redirect mean in Google Search Console?
It means the URL in the report redirects to another URL, so Google does not index it and considers the redirect target instead. Google's help calls it a non-canonical URL that redirects to another page.
Trailing-slash redirects are often added by the framework itself. Next.js, for example, "will redirect URLs with trailing slashes to their counterpart without a trailing slash" by default, so /about/ goes to /about. The trailing slash guide and the www vs non-www guide cover choosing one form and redirecting the rest.
The last row is the one to read carefully. A page that redirects signed-out visitors to a login screen, or redirects by country, also lands here, and if that page was meant to rank, the redirect is the bug.
When is Page with redirect a real problem?
It is a problem in two common cases: your sitemap lists redirecting URLs, or your own pages link to them. Both mean you are asking Google to crawl an address you have already abandoned, which costs an extra request per URL and sends mixed signals about which URL you want indexed. A third case is a target that is not indexable, which leaves the content out of Google entirely.
Your sitemap lists redirecting URLs
In the Page indexing report, change the sitemap filter above the chart from "All known pages" to "All submitted pages". If the Page with redirect row still shows URLs, your sitemap is submitting them. Google's sitemap guidance says to "include the URLs in your sitemap that you want to see in Google's search results," which means the final canonical URLs, never the ones that redirect.
Open your sitemap and search it for the listed URLs.
Replace each one with its final URL, the one that returns 200.
If the sitemap is generated, fix the generator: it is usually building URLs from an old base URL, the wrong protocol, or a slug field that no longer matches the route.
Resubmit the sitemap in Search Console's Sitemaps report.
Your own pages link to redirecting URLs
Internal links that go through a redirect make every crawler request two URLs to reach one page. The Crawl Stats report shows this: "If a URL has a server-side redirect, each request in the redirect chain is counted as a separate request."
The usual sources are navigation and footer links written before a URL change, hard-coded http:// links in old posts, links missing the trailing slash your site now adds, and canonical or hreflang tags that still name the old URL. Update each link to the final URL. In URL Inspection, the Referring page field on the indexed result shows a page Google may have used to find the redirecting URL, which is a good place to start looking.
How do you check where a URL redirects?
Run curl against the listed URL. It prints each hop's status code and Location header, so you see the whole path from the old URL to the final page in one command. Browser address bars hide intermediate hops, and URL Inspection's live test follows redirects without saying so, which makes curl the quickest honest view.
HTTP/1.1 301 Moved Permanently
Location: https://example.com/pricing
HTTP/2 200
-I requests headers only, -L follows each redirect, and -s hides the progress meter. Two or more Location lines mean a chain. A 302 or 307 on a move you meant to be permanent means the redirect type is wrong.
URL Inspection is useful too, with one catch. Google's help says that when a URL redirects, "the results reflect the tested URL in the index, not the redirect target." To see the indexed target, click the INSPECT button in the Page indexing section of the result. The live test "follows redirects and then tests the final URL," but "doesn't indicate that it is following a redirect," so a clean live test tells you the target is healthy, not the URL you typed.
How do you confirm the redirect target is indexable?
Inspect the final URL, not the redirecting one. It should say "URL is on Google", fetch with a 200, allow indexing, and name itself as canonical. If any of those fail, the redirect is doing its job and the content is still missing from Google, which is a real problem worth fixing today.
Paste the final URL into URL Inspection.
If it says "URL is on Google", you are done with this URL.
If not, read the Page indexing section. Page fetch should say Successful, and Indexing allowed should say Yes.
Compare the User-declared canonical with the Google-selected canonical. Both should be the final URL. If Google picked another URL, the target is being treated as a duplicate.
Click Test live URL to confirm the current version, then Request indexing if you changed anything.
A target that is noindexed, blocked by robots.txt, returns 404, or redirects again is the worst version of this status: the old URL leaves the index and nothing replaces it.
How many redirect hops are too many?
More than one. Google's crawlers "follow up to 10 redirect hops" by default, but every extra hop is another request, and chains tend to grow as rules stack up: http to https, then to www, then to a trailing slash. Aim for a single permanent hop from any old URL straight to the final one.
For permanent moves, use 301 or 308. Google treats both as strong signals, while 302, 303 and 307 are weaker and tell Google the move is temporary. Its redirect guide puts the difference plainly: permanent redirects "show the new redirect target in search results," temporary ones "show the source page." The 301 vs 302 guide covers choosing between them, and the redirect chains and loops guide shows how to collapse stacked rules into one hop.
When you collapse a chain, fix the rule order at the layer that runs first. If your CDN upgrades to HTTPS and your app then adds www, write one rule that sends http://example.com/x straight to https://www.example.com/x.
Where should old URLs redirect, and for how long?
Each old URL should redirect to the page that replaced it, and the redirect should stay for at least a year. Google's site move guide says: "Keep the redirects for as long as possible, generally at least 1 year," because that time "allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs."
The destination matters as much as the duration. The same guide warns: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error." A mass redirect to the homepage can therefore turn a tidy Page with redirect row into a Soft 404 row. Map each old URL to its closest equivalent. If several old pages were merged into one new page, redirecting all of them to that consolidated page is fine; Google names that case as the exception.
Removing redirects too early brings the old URLs back as 404s, and links other sites still point at them lead to a dead page instead of the new one. When you do retire a redirect, update your own links first, so nothing on your site depends on it.
Check your redirects and links in one pass
To see what your pages send right now, run the free scan on LaunchScaler. Give it the URL, no account needed, and it runs 156 checks across 6 of its 7 categories at no cost. Its checks for this status include redirect chains longer than one hop, redirect loops, internal links that resolve through a redirect, sitemap entries that redirect or fail to return 200, a canonical that points at a redirected URL, and whether plain HTTP sends visitors to HTTPS on the same host in the first hop. It reads your live site, so fix the sitemap and the links it flags, then filter the Page indexing report to All submitted pages to confirm the row is clean.
Usually not. If the listed URLs are old http, www, trailing-slash or retired-slug versions and their targets are indexed, the report is working as intended. Fix it when your sitemap or your own internal links still list the redirecting URLs, or when the target is not indexed.
03
Why is my page with redirect not indexed?
The redirecting URL is never indexed by design; only its target can be. Inspect the target URL: it must return 200, allow indexing, and not be judged a duplicate of another page.
04
How do I remove redirected URLs from my sitemap?
Regenerate the sitemap so it lists only final URLs that return 200 and are canonical, then resubmit it in Search Console's Sitemaps report. Filter the Page indexing report to All submitted pages afterwards to confirm no submitted URL still sits under Page with redirect.
05
How many redirects will Googlebot follow?
Google's crawlers follow up to 10 redirect hops by default. Keep every redirect to a single hop from the old URL to the final one.
Redirect error means Googlebot hit a loop, a chain that was too long, an overlong URL or a bad URL. Trace every hop with curl, then redirect in one step.
Request indexing lives in URL Inspection and has an unpublished daily quota. Repeat requests don't help; a rejection means the live test found a blocker.
Six robots.txt and noindex checkers compared: LaunchScaler, Search Console's report and URL Inspection, Bing's tester, an extension and Google's parser.
