Page With Redirect in Search Console: What It Means and What to Do

You open the Page Indexing report, scroll down to the list of reasons that pages are not indexed, and see "Page with redirect". It sounds like a fault. In most cases it is not. The status tells you that Google found a URL, requested it, and was sent somewhere else. A URL that redirects is not itself indexed; the page it points to is the one Google considers.

This guide is for site owners and developers who want to know when "Page with redirect" is normal, when it points to a real problem, and what to change. You will learn how to separate healthy redirects from sloppy ones, how Google treats different redirect types, how to find the places on your own site that still link to old addresses, and how to confirm the redirect target is the page you want in the index. A tidy redirect setup removes confusion and wasted requests; it is not a promise of any change in rankings.

Before you begin

You need Search Console access for the property and a tool that shows redirect responses, such as curl or your browser's network panel. You also need the ability to change your redirect rules, your internal links and your XML sitemap. Save a copy of your current redirect configuration before editing it, whether it lives in a server file, a CMS plugin or a CDN rule.

Allow an hour to review the list. If you edit redirect rules, test on a copy of the site first. A mistaken rule can create a loop that makes a section unreachable. Google's help says validation of a Search Console issue typically takes up to about two weeks, sometimes much longer, so plan to check back later rather than expect an instant update.

What the status means

Google's Page Indexing help defines "Page with redirect" this way: the URL redirects elsewhere, so it is not indexed, and the redirect target may or may not be indexed. The help page gives no specific fix. The way to read it is that the status is informational. It becomes a task only if one of the following is true:

You did not intend the redirect.
The redirect target is not indexed and should be.
The redirect is the wrong type for the situation.
Your own site, sitemap or ads still send people and crawlers to the redirecting URL.
The redirect leads through several hops.

If you previously moved pages on purpose, such as an old blog URL sent to a new one, then seeing those old URLs in this list is expected.

How Google treats redirects

A few facts from Google's documentation shape every decision below.

Permanent versus temporary. Permanent redirects are HTTP 301 and 308. Google follows them and treats the target as the canonical URL, and Google recommends them only when you are sure the redirect will not be reverted. Temporary redirects are 302, 303 and 307, plus a delayed meta or HTTP refresh. Google follows them, but does not treat the target as the canonical, so the source URL may remain in results. In Google's crawling documentation, 301 and 308 are described as strong signals that the target should be processed, and 302, 303 and 307 as weak signals.

Server-side first. Google calls server-side redirects, configured in server files or scripts, the most reliable method and says to use them whenever possible for permanent moves. A meta refresh is a fallback: an instant refresh (0 seconds) is treated as permanent, a delayed one as temporary. A JavaScript location redirect should be used only if neither option is available, because Google must render the page to see it, and rendering can fail.

Hop limit. Google's crawlers follow up to 10 redirect hops by default, though some Google products have different limits. The content of the redirecting URL is ignored, and the target's content is processed.

For the choice of code in a given situation, see 301 vs 302 redirects.

Step-by-step instructions

Step 1: Export the URLs

In Search Console go to Indexing, then Pages, and open "Page with redirect". Use the example list and, if you can, export it. Sort the URLs into groups by pattern: old paths, http:// addresses, www versus non-www, trailing-slash variants, parameter URLs.

What success looks like: You have groups of URLs that redirect for the same reason.

Step 2: Test each group's redirect

Request one URL per group and follow the redirect manually:

curl -sI https://example.com/old-page

Read the HTTP status line and the Location header. Then request the Location URL and repeat. Write down each hop and its status. A healthy permanent move shows one hop, a 301 or 308, straight to a page that returns 200.

GET /old-page          -> 301 Location: /new-page
GET /new-page          -> 200 OK

A chain shows several:

GET http://example.com/old   -> 301 https://example.com/old
GET https://example.com/old  -> 301 https://example.com/old/
GET https://example.com/old/ -> 301 https://example.com/new/
GET https://example.com/new/ -> 200 OK

What success looks like: For every group you know the number of hops, the status code at each hop and the final status.

Step 3: Decide whether each redirect is intended

Compare each group with your plan.

Intended and correct. The old URL was retired, the target is the closest equivalent, and the redirect is one hop. Leave it.
Intended but the wrong type. A page moved for good but uses 302. Change it to 301 or 308.
Unintended. A URL you wanted indexed redirects, for example because of a plugin, a rewritten URL setting, or a case or trailing-slash rule. Remove or correct the rule.
Chain or loop. Replace the chain with one redirect straight to the final URL. Redirect Chains, Loops, and Incorrect HTTP Status Codes explains how to fix those.

Be careful with temporary redirects for permanent moves. Google says a temporary redirect does not make the target the canonical URL, so the old address may stay in results.

What success looks like: Each group is marked leave, change type, remove or flatten.

Step 4: Check that the target is the page you want indexed

Take the final URL from each healthy redirect and inspect it in the URL Inspection tool. Look at whether it is on Google, whether indexing is allowed, and which canonical URL Google selected. If the target is not indexed, the redirect is not the issue. The cause is on the target page, and the Page Indexing report guide or the guides for Crawled - currently not indexed will help.

Also check that the target page is not redirecting back, is not blocked by robots.txt and carries a canonical that points to itself.

What success looks like: The final URL returns 200, is allowed to be indexed and declares itself as canonical.

Step 5: Stop linking to redirecting URLs

Redirects are a safety net for old links, not a navigation plan. Search your templates, menus, content and sitemap for the old addresses and replace them with the final URLs. Google's own advice on duplicate URLs is to link internally to the canonical URL, not to duplicates. Update internal links in your CMS content, canonical tags, structured data URLs, hreflang annotations and social sharing tags too, if they exist.

Your XML sitemap should list the final, indexable URLs only. A sitemap full of redirecting addresses wastes requests and sends mixed signals. If you rebuild it, see How to Create a Valid XML Sitemap. The broken links audit shows how to find internal links that still point at redirects.

What success looks like: A crawl of your own pages finds no internal links to redirecting URLs.

Step 6: Keep legitimate redirects

Do not remove a working permanent redirect to clear the report. Visitors may still hold bookmarks, other sites may still link to the old address, and removing the redirect will produce a 404. After a domain move, Google notes that old URLs can keep appearing as alternate names and fade over time without action. Google's documentation does not state how long to keep redirects, so base the decision on whether old addresses still receive requests, which your server logs can show.

What success looks like: Valid redirects stay in place until requests for the old addresses have stopped.

Step 7: Validate and re-check

When you have corrected the unintended cases, press "Validate fix" on the issue in Search Console once. Google says to wait until validation has succeeded or failed before pressing it again. For redirects you intend to keep, validation does not make sense, because the status will continue to describe them accurately. If a URL fails validation, open "See details", fix it and start a new validation.

What success looks like: Only URLs with intended, single-hop, permanent redirects remain in the list.

Final verification checklist

Every redirecting group has an owner and a reason.
Permanent moves use 301 or 308, and one hop reaches the final URL.
No redirect chain or loop remains in the groups you reviewed.
Each final URL returns 200 and is allowed to be indexed.
Final URLs declare themselves as canonical.
Internal links, menus and canonical tags point to final URLs.
The XML sitemap lists final URLs only.
Redirects that are still in use have not been removed.

Common mistakes to avoid

Treating the status as an error. If the redirect is intended, nothing needs fixing.
Using a temporary redirect for a permanent move. The old URL may stay in results. Use 301 or 308.
Leaving chains in place. Each extra hop adds a request. Redirect straight to the final URL.
Redirecting to an unrelated page. Visitors and crawlers expect the closest equivalent. If there is none, a 404 may be more honest.
Putting redirecting URLs in the sitemap. List the final URLs.
Using a JavaScript redirect when a server rule is possible. Rendering can fail. Use a server-side redirect.
Removing redirects too early. Keep them while old addresses still receive requests.
Pressing Validate fix for redirects you meant to keep. Validation is meant for problems you have fixed.

Frequently asked questions

Is "Page with redirect" bad for SEO?

No. It reports a URL that redirects, so Google indexes the target instead. It matters only when the redirect is unintended or the target is not indexed.

Why is a redirected URL not indexed?

Google follows the redirect and processes the target's content. Permanent redirects are a strong signal that the target is the canonical. The status says the redirecting URL itself is not indexed.

What is the difference between 301 and 302 for this status?

Both cause the status. A 301 or 308 is a strong signal that the target should be processed. A 302, 303 or 307 is a weaker signal, and the old URL may stay in results.

How many redirects in a row will Google follow?

Google's crawling documentation says its crawlers follow up to 10 hops by default. A chain that long is still wasteful, and a single redirect is better.

Can I fix the status by deleting the redirect?

You can, but visitors and links to the old URL will then reach a 404 page unless the page lives at that address again. Remove only unintended redirects.

Do I need to ask Google to reindex the target?

Usually not. If the target page is new or changed, you can inspect it and request indexing, but a request does not mean the page will be indexed. See Request Google Indexing the Right Way.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.