Page with redirect

Page with redirect means Google requested a URL, received a redirect instead of a page, followed it, and indexed the destination — then filed the original URL under this status. It is a statement of fact about that URL, not a fault report. For the redirects most sites have, nothing needs fixing, and Search Console’s Validate fix button can never pass.

Four situations are genuine problems, and “there are too many URLs in this report” is not one of them: a redirecting URL sitting in your sitemap, internal links pointing at the redirecting version, a redirect that goes somewhere unhelpful, and a redirect you did not intend at all.

The trap: a validation that cannot pass

Search Console files this under Why pages aren’t indexed, in the same list as server errors and soft 404s. There is a Validate fix button next to it, and pressing it feels like the responsible thing to do.

It will fail.

Google re-crawls the sample URLs, finds they still redirect, and marks the validation failed — usually a day or two later, so the disappointment arrives after you have forgotten about it. Nothing went wrong. For the validation to pass, the URL would have to stop redirecting, and for the URLs that normally appear here that would mean breaking the thing that is working correctly.

The two that turn up most often are:

http://yoursite.com/          301 → https://yoursite.com/
https://www.yoursite.com/     301 → https://yoursite.com/

Both of those must redirect. Both will keep reporting this status for as long as your site exists. Pressing Validate fix again will not change that, and the only cost is a few days of expecting news that never comes.

When it is genuinely nothing

The URL	Why it is fine
http:// version of an https:// page	You forced HTTPS. Correct.
www when you serve the bare domain, or the reverse	You picked one canonical host. Correct.
A URL with a trailing slash your site normalises away	One URL per page. Correct.
An old URL from a migration, pointing at its replacement	This is what a redirect is for.
A URL with tracking parameters stripped by a redirect	Fewer duplicate URLs, deliberately.

In every row the destination is the page you want indexed, and it is indexed. The report is telling you the plumbing worked.

There is also nothing to gain here. A redirecting URL is not competing with your real page, not diluting it, and not costing you rankings. Reducing the count in this report is not an objective.

When it is a real problem

Four cases, and they have nothing to do with the number of URLs in the report.

1. The redirecting URL is in your sitemap

A sitemap should list destinations only. If a URL in your sitemap redirects, you are asking Google to crawl a URL and then telling it to go somewhere else — on every fetch, for every URL, indefinitely. It also signals that the sitemap is generated from stale data, which is a reason to trust the rest of it less.

This is the one case worth actively hunting for. Pull the URLs out of your sitemap and check each one for a 200 with no redirect. The sitemap URL extractor will turn the XML into a plain list to work from.

2. Your internal links point at the redirecting version

Every internal link should go straight to the final URL. Linking to http:// or to a pre-migration path still works for a human, and still costs a redirect on every crawl. Search-and-replace in your templates is a one-off job that keeps paying.

3. The redirect goes somewhere unhelpful

Redirecting a removed page to the homepage — or to a category listing that does not mention it — is a common cleanup after a migration and it does not work the way people expect. Google treats an irrelevant redirect as a soft 404: it recognises that the destination is not a replacement for what was requested, and declines to pass anything along.

A redirect is a claim that this content moved here. If nothing moved, a 404 or 410 is the honest answer and Google handles it better.

4. You did not intend the redirect at all

This is the one worth checking properly, because it is invisible from a browser. A page you expected to be indexed now returns a 301 because a plugin rule, a CMS setting, or a stray rewrite caught it. It still loads for you — you land on the destination and see a working page — so nothing looks wrong until the original URL quietly leaves the index.

If a URL you care about appears in this report and you cannot say which rule put it there, that is the thing to investigate.

Chains, and the difference between 301 and 302

Chains. http://www.yoursite.com should reach https://yoursite.com in one hop, not by way of https://www.yoursite.com. Googlebot will follow a chain, but each hop is a separate fetch and Google’s own guidance is to keep it to three at most. Two hops is not a crisis; five is a server configuration nobody has looked at in a while.

301 versus 302. A 301 says the move is permanent and the destination should be indexed in place of the original. A 302 says the original will be back, so Google may keep the original URL in the index and treat the destination as temporary. Google usually reinterprets a long-lived 302 as permanent eventually, but “eventually” is doing real work in that sentence. If the move is permanent, say so with a 301.

How to tell which situation you are in

The report gives you sample URLs, not all of them, so reading the list is not a complete answer. Work from your own side instead:

1. Take the URLs from your sitemap.
2. Check each one for a 200 with zero redirects. Any that redirect are the sitemap problem, and are worth fixing.
3. Take the URLs you actually care about ranking — the ones in your navigation and your best internal links — and check the same thing. Any that redirect are either an internal link pointing at the old URL, or a redirect you did not intend.
4. Ignore everything else in the report.

Anything left over is your canonical-host redirects doing their job, and the right response is to close the tab.

When the answer is a different status

If a URL is not in this report and still is not indexed, the reason is elsewhere and the advice here does not apply. Start with why is my page not indexed for the mechanical causes, then crawled – currently not indexed if Google fetched the page and declined it, discovered – currently not indexed if it never came to fetch it at all, or submitted URL marked ‘noindex’ if the page is telling Google to stay away while your sitemap asks it in.

Doing this for more than a handful of URLs

Checking a sitemap’s URLs and your best internal links for redirects is a loop over a list, and Search Console will not run it for you. URL Inspection answers one URL at a time against a daily quota, and it only covers property you own — which rules out the case that prompts this most often, a migration where you need to know whether the URLs other people link to still resolve to something indexed.

Checking a redirect is a request you can make yourself. Checking whether the destination actually ended up in Google is the part that needs asking Google, once per URL — our free index checker does ten of them with no account, and how to check if a page is indexed covers the four ways to do it and which of them tell you the truth.