Page With Redirect in Search Console: When to Fix It

"Page with redirect" means the URL sends visitors and Googlebot to a different URL, so Google leaves the redirecting address out of the index and deals with the destination instead. In the great majority of cases that is correct and needs no action. It deserves attention in four situations: the redirect was not intended, it points to the wrong page, the redirecting URLs are in your sitemap, or the redirect is chained or broken.

Why this status is normal

Google's description is that this is a non-canonical URL that redirects to another page and as such will not be indexed. The destination may or may not be indexed, and you check that separately.

Every healthy site produces these:

• http:// to https://
• non-www to www (or the reverse)
• /page to /page/ (or the reverse)
• Old URLs after a redesign, a slug change or a migration
• Retired products redirected to their successor or category
• Short links and campaign URLs

Google learns about these URLs from old links around the web, from its own crawl history and from your past sitemaps. It will keep them in this list for a long time, and it keeps rechecking them occasionally. A count in the hundreds or thousands on an older site is ordinary.

One consequence that confuses people: pressing Validate fix on intentional redirects will end in "Failed", because Google checks whether the URLs still redirect, and they do. Nothing is wrong. Do not start validation for redirects you mean to keep.

The four cases that need work

1. Redirecting URLs in your sitemap

In Indexing > Pages, switch the filter from "All known pages" to All submitted pages and look at the "Page with redirect" row again. Anything left is a URL you are actively telling Google to index while your server sends it elsewhere.

Typical reasons: the sitemap still lists http:// or non-www URLs, slugs were changed without regenerating the sitemap, or the sitemap and the server disagree on trailing slashes.

Fix: list only final URLs that return 200. You can pull every URL from the sitemap with the sitemap URL extractor and run them through the bulk HTTP status checker to find the ones answering 301, 302, 307 or 308.

2. Redirects you did not intend

A page you want indexed should not redirect at all. When it does, look for:

• Geo or language redirects by IP address. Googlebot crawls mostly from US IP addresses and sends no Accept-Language header, so it is pushed to the US or default version and may never see the others. Google recommends against automatic redirection based on location. Offer a banner or a language switcher, and use hreflang.
• Login or paywall redirects for pages meant to be public (302 to /login).
• Age gates and cookie consent gates implemented as redirects.
• Device redirects to a separate mobile site that are misconfigured.
• Slash or case normalisation rules that conflict with your canonical and internal links, so the URL you link to everywhere is the redirecting one.
• Plugin leftovers. Redirect managers keep old rules forever. A rule created years ago for /services can swallow the new page you publish at the same path.
• Out of stock rules that redirect product pages to a category even when the product is coming back.
• Hacked sites. Conditional redirects that only fire for search visitors or crawlers. Check Security & Manual actions > Security issues.

How to confirm: inspect the URL and run Test live URL. If the page works in your browser but the live test reports a redirect, the redirect is conditional, and the condition (location, headers, cookies, user agent) is your lead.

3. Redirects to the wrong target

A redirect carries value when the destination is an equivalent of the old page. It does not when:

• Everything goes to the homepage. After a migration, mass-redirecting old URLs to / is tempting. Google has said it commonly treats such redirects as soft 404s, because the homepage does not replace the specific page. Map old URLs one to one, and let pages without an equivalent return 404 or 410. See soft 404 errors.
• The destination is itself not indexable: it returns 404, carries noindex, is blocked in robots.txt, or canonicalises somewhere else. Always inspect the final URL. That is where indexing is decided.
• The destination is irrelevant, such as an old article redirected to an unrelated product.

4. Chains, loops and the wrong redirect type

Chains. http://example.com/a to https://example.com/a to https://www.example.com/a to https://www.example.com/a/ is three hops where one would do. Google's documentation says Googlebot follows up to 10 redirect hops, and its guidance for site moves is to keep chains short, ideally no more than three hops and preferably a single one. Each hop adds latency for users and cost for crawlers. Trace the full path with the redirect checker or:

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

Loops and failures. A redirects to B and B back to A, or the chain is too long, or a Location header is empty or malformed. These show up under a different status, "Redirect error", and those always need fixing.

Type. Use a server-side permanent redirect (301 or 308) for permanent moves. Google treats it as a strong signal that the target should be canonical. Temporary redirects (302, 307) are a weak signal, so Google may keep the old URL indexed for longer. That is appropriate when the move really is temporary. More in 301 vs 302 redirects.

Method	How Google treats it	Use it?
301 / 308 server-side	Permanent, strong canonical signal	Yes, default for moves
302 / 307 server-side	Temporary, weak signal	Only for real temporary moves
Meta refresh, 0 seconds	Interpreted as permanent	Only if you cannot set server redirects
Meta refresh with delay	Interpreted as temporary	Avoid
JavaScript location redirect	Followed only if rendering succeeds	Last resort

Example rules for a single-hop normalisation and a moved page:

# Nginx: send the bare domain (http and https) to https + www in one hop
server {
    listen 80;
    listen 443 ssl;   # keep your ssl_certificate lines in this block
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

# a moved page
location = /old-pricing { return 301 /pricing; }

# Apache .htaccess
Redirect 301 /old-pricing https://www.example.com/pricing

How to review the list efficiently

1. Open Indexing > Pages > Page with redirect and export the examples (the list shows up to 1,000).
2. Check final destinations and hop counts in bulk with a crawler in list mode, or in batches with a status checker.
3. Sort into groups:

Group	Action
Protocol, host, slash normalisation	None
Old URLs with a relevant 200 destination in one hop	None
In the sitemap	Replace with the destination URL
Internal links still point to it	Update the links to the final URL
Chain of two or more hops	Point the first URL straight to the final one
Destination is 404, noindex or irrelevant	Fix the target, or return 404 or 410
Should not redirect at all	Remove the rule, then test live and request indexing

Internal links deserve a special mention. Redirects are for old links you cannot control. Your own navigation, body links, canonical tags and hreflang annotations should all use final URLs. Linking to redirecting URLs works, but it adds a hop for every visitor and makes Google recrawl URLs that lead nowhere new.

After removing an unintended redirect

1. Confirm the URL now returns 200: run Test live URL and check for "URL is available to Google".
2. Make sure its canonical tag points to itself and not to the old redirect target.
3. Click Request indexing.
4. If a whole group was affected, this is the moment to use Validate fix. Google says validation typically takes up to about two weeks and sometimes much longer.
5. Clear caches. Browsers cache 301s aggressively, so test in a private window or with curl. CDNs can cache redirects too.

How long should redirects stay?

Google's site move guidance is to keep redirects for as long as possible, and generally for at least a year, so that all signals have time to transfer to the new URLs. If other sites still link to the old URLs, keep the redirects indefinitely for the sake of users. During a bigger move, follow the site migration indexing checklist.

Summary

You see	Meaning	Do
Page with redirect, URL is an old or alternate address	Working as designed	Nothing
Page with redirect, URL is in your sitemap	Sitemap is out of date	Update the sitemap
Page with redirect on a page you want indexed	Unintended or conditional redirect	Find the rule and remove it
Redirect error	Chain too long, loop, or bad URL	Fix immediately
Validation failed	Redirects still exist	Expected for intentional redirects

The redirecting URL is never the one to worry about. The destination is. If the destination is indexed, the redirect is doing its job. If it is not, take the destination URL through why is my page not indexed.