Page with redirect in Search Console: what to do

"Page with redirect" in Search Console means Google crawled a URL, got a redirect, and left that URL out of the index because it points somewhere else. Most of the time that is exactly what you wanted. The status only matters when the target page is missing from the index too, or when your own sitemap and links keep sending Google to the old URLs. Check the target, clean up the references, and don't ask Google to validate a fix for redirects you meant to have.

What does page with redirect mean?

It is a report row for URLs that redirect, not an error. Google's Page indexing report help describes it as a non-canonical URL that redirects to another page, says the URL will not be indexed, and says the target "might or might not be indexed" depending on what Google thinks of the target itself.

So the row lists old addresses. The question is what happened to the new ones.

One trap in URL Inspection. When you inspect a redirecting URL, the indexed data shown applies to that URL and ignores the redirect. The live test does follow redirects and tests the final URL, but it doesn't tell you it did. Inspect the target URL directly to see its status.

Is page with redirect bad?

No, in the normal case. These URLs belong in this row and should stay there:

• http://example.com/ redirecting to https://example.com/
• https://www.example.com/pricing redirecting to https://example.com/pricing
• /blog/2019/old-slug redirecting to /blog/new-slug after a rename
• /pricing redirecting to /pricing/ because your server adds trailing slashes

A site that has been through an HTTPS move or a URL cleanup carries thousands of these for years, because Google keeps recrawling old URLs it learned from old links. A large count is history, not a penalty.

When page with redirect is a real problem

Page with redirect in Google Search Console is a problem when a URL you want in search results sits in the row, or when your own site keeps feeding Google redirecting URLs. Open the example list and look for these.

The target isn't indexed

Inspect a few targets. If they show as indexed, you're done. If they sit under "Crawled, currently not indexed", "Duplicate without user-selected canonical" or another excluded status, the redirect is doing its job and the target page has its own problem. Fix that page. Our post on duplicate without user-selected canonical covers the most common one.

A page that shouldn't redirect

Sometimes the listed URL is your real page, and a plugin, a language redirect or a misfiring rewrite rule bounces Googlebot away from it. Request it with curl:

curl -sIL https://example.com/pricing

If a page you want indexed answers with a 3xx, remove the rule that redirects it.

Redirecting URLs in your sitemap

A sitemap should list final URLs only. Google's sitemap guidelines ask you to list the canonical URLs you want in search results, and a URL that redirects is never the canonical. Filter the Page indexing report by sitemap. Any redirecting URL there means your sitemap generator is out of date. Our guide to checking an XML sitemap walks through the cleanup.

Internal links and canonical tags that point at redirects

Every internal link to an old URL sends Google back through the redirect. Update navigation, body links and rel="canonical" tags to the final URL. A canonical that points at a redirect contradicts itself.

Chains and host variants

http://www.example.com/old goes to https://www.example.com/old, then to https://example.com/old, then to /new. Point every old URL at the final destination in one hop, and make http, https, www and bare hosts all end on one HTTPS origin. The 301 vs 302 guide has the server rules. If the chain never ends, you have a loop, and Search Console files those under "Redirect error" instead. The ERR_TOO_MANY_REDIRECTS post shows how to find the two rules that disagree.

How to fix page with redirect

Work from the targets outward.

1. Inspect a sample of targets in URL Inspection. Indexed targets mean those redirects are fine.
2. Run curl -sIL on any URL you expected to load directly. Remove redirects that shouldn't exist.
3. Replace redirecting URLs in your sitemap with their final URLs.
4. Update internal links and canonical tags to the final URLs.
5. Collapse chains so each old URL takes one hop, with a permanent redirect if the move is permanent.

Leave the old URLs redirecting. Deleting a working redirect to clear the row turns those URLs into 404s and wastes their links.

Should you click validate fix?

Not for redirects you meant to have. Validation asks Google to confirm the issue is gone from every listed URL. An intended redirect is still a redirect when Google rechecks it, so validation fails.

Click Validate fix only when the row held URLs that should never have redirected and you have removed those redirects. Google's help page says validation typically takes up to about two weeks and asks you not to click it again until it has passed or failed.

Trace a redirect chain and check your host versions

Our redirects, headers and host checker follows a URL hop by hop, up to 10 redirects, and shows each hop's status code and target. It flags loops, chains of two or more redirects, HTTPS falling back to HTTP, temporary redirects that change host, and a final page that errors or isn't on HTTPS.

The same run requests the http and https versions of your bare domain and www and reports whether they all land on one HTTPS origin. It also flags response headers that block indexing, such as an X-Robots-Tag noindex. Each finding comes with the change to make. A run costs 10 credits. It follows HTTP redirects only, so a meta refresh or JavaScript redirect stops the trace at the 200 page.