Page with Redirect in Search Console: Is It a Problem and When to Fix It?

So your first reaction should not be panic. First, open the example URLs in the report. Then check where each one goes. If the target is indexed and it is the page you expect, the row simply records a redirect that works. In this guide, Talha Aslan and team walk through the exact review order we use on client sites.

How does Google officially describe this status?

Google's Page indexing report help page describes it clearly. The URL is non-canonical, it redirects to another page, and therefore it will not be indexed. Also, the same page adds an important detail. The redirect target may or may not be indexed, depending on how Google evaluates that target.

In other words, the row tells you something about the source URL. It says nothing final about the target URL. The help page also notes that a canonical URL with a redirect can be indexed. That is why reading this status as an error on its own is a mistake. The real question is simple: did you want this redirect, or is it a side effect nobody noticed?

Many site owners assume a penalty the first time they see this row. In fact, the status shows that Google read the relationship between two addresses correctly. For example, if an old campaign URL points to a new page, Google noticed it and chose not to index both. So this row is often proof of a setup that reduces duplicate content risk.

When is a page with redirect status completely normal?

The most common picture we see is a healthy setup producing this row as a natural result. For example, if your site moved from HTTP to HTTPS, the old HTTP addresses can sit in this list for a long time. That is not a problem. Instead, it is a trace of history.

• HTTP addresses redirecting to the HTTPS version.
• The non-www host redirecting to the www host, or the other way around.
• A URL without a trailing slash going to the version with one.
• Old posts that moved or merged pointing permanently to new addresses.
• A retired campaign landing page pointing to the related category.

All of these share one thing: someone set up the redirect on purpose. Therefore, if the target is indexed, there is nothing to do. Also, the count can grow over time. Google recrawls old addresses now and then, so the report keeps showing them.

In addition, a big jump right after a launch or redesign is not surprising. Google remembers old addresses and revisits them. Each visit confirms the redirect again. As a result, a high count for a few months is no cause for concern when the redirects are correct.

When does page with redirect point to a real problem?

Trouble starts when a redirect appears by accident or when your signals conflict. If you tell Google an address matters while the server sends it elsewhere, you send a mixed message. That confusion wastes crawl resources and can delay how Google evaluates the target page.

• Your sitemap lists redirecting URLs.
• Internal links, menus and cards still point to old addresses.
• A canonical tag points to an address that redirects.
• The target page is not indexed or sits in another status.
• The redirect goes to an unrelated page, often the homepage.
• An important product or service page redirects unexpectedly.

If even one of these applies, the status deserves a closer look. The last item matters most. A traffic page that redirects because of a plugin setting is one of the quiet causes of ranking loss.

That said, some problems do not show up in the report right away. For instance, a product page that started redirecting by mistake may stay indexed until Google recrawls it. That is why we suggest keeping a list of your key pages and checking their response codes yourself on a regular schedule.

How do you tell a normal redirect from a problem one?

The table below sums up the quick triage our team uses in a first review. Match the rows to the example URLs in your report to see which group you are in.

In practice, the table is a starting point, not a final diagnosis. Still, on most sites one of these six rows explains what is going on.

How do you review the page with redirect list in the report?

Order matters here, because if you start from the wrong end, you lose hours on rows that are perfectly fine. We recommend this sequence:

1. Open the Page indexing report and click the Page with redirect row.
2. Export the list of example URLs.
3. Group the list by host version, folder and URL pattern.
4. Open a few examples from each group in the URL Inspection tool.
5. Note the target address and whether the target is indexed.
6. Separate intended groups and move suspicious groups to their own sheet.

Next, you work only on the suspicious groups. We covered the general logic of this step in our guide on how to find unindexed pages in Search Console. Here we focus only on the redirect side.

How do you check whether the target URL is indexed?

The row says nothing about the target, so you need to check it separately. Enter the final address, not the source, into URL Inspection. The tool shows whether the target is indexed and which canonical URL Google selected.

You will usually get one of three outcomes. First, the target is indexed and selected as canonical, which is the best case. Second, the target is not indexed, so you look at its own status, for example crawled but not indexed. Third, Google picked a different canonical, so you review your canonical signals.

For example, if you find a canonical mismatch, follow the steps in our post on canonical issues in Search Console.

Why is a redirecting URL in your sitemap a problem?

Google's sitemap documentation asks you to include the URLs you want to see in search results. It also says that when the same content lives at several URLs, you should choose your preferred one and list only that. A redirecting URL is, by definition, not your preferred address.

That makes a redirecting URL in your sitemap a conflicting signal. On one side you say this page matters. On the other side the server says the page lives elsewhere. Moreover, Google tries to crawl sitemap URLs exactly as listed, so it takes an extra hop every time.

So the fix is simple: build your sitemap only from final URLs that return a 200 response. For hand-made sitemaps, our XML sitemap generator helps you produce a clean list. For the basics, see our post on what an XML sitemap is.

Also, if your sitemap index contains several files, check whether an old child sitemap is still submitted. The Sitemaps section in Search Console shows which files you submitted and when Google last read them. Regenerating the list after every migration keeps old addresses from piling up.

How do internal links increase page with redirect counts?

Internal links are the most common reason Google keeps rediscovering redirecting addresses. Say you changed a post's URL and added a redirect. If older posts still link to the old address, Google visits the old address first on every crawl.

Still, that alone is not a disaster, but it is wasteful. It means an extra wait for visitors and an extra request for crawlers. If an old address stays in a component that repeats on every page, such as the menu, footer or category cards, the same redirect fires thousands of times.

• Check menu and footer links.
• Review hard-coded links in category and tag templates.
• Search in-content links in the database and update them in bulk.
• Make sure image and file links do not use an old host version either.

As a practical method, list every redirect rule on your site and search for where each source appears as a link. Then fix the most repeated old addresses first. This small cleanup improves the visitor experience and stops crawlers from taking pointless extra steps.

How does a redirect chain affect page with redirect status?

A chain is a setup where A goes to B and B goes to C. Google's help page lists overly long chains among the causes of the Redirect error status. In practice, a short chain shows up as page with redirect, while a longer one can turn into a separate error row.

That is why linking every source straight to the final URL is the cleanest path. To find chains, use our redirect checker. Our post on what a redirect chain is covers the details.

Most chains do not come from one big event. Instead, they build up from small changes over the years. First an HTTPS move, then a URL structure change, then a domain migration, and one old address now needs three hops. So after every major change, update old rules to point at the new final URL.

What is the difference between permanent and temporary redirects for Google?

Google's redirects and Google Search documentation says that with permanent redirects (301 and 308), Google treats the target as canonical. With temporary redirects (302, 303 and 307), the source can stay in search results. The document also recommends server-side redirects as the most reliable method.

A frequent mistake we see is handling a permanent move with a temporary redirect. Google may then hesitate over which address to show. On the other hand, JavaScript redirects may never register. According to the document, Google only sees that code after rendering, and rendering can fail.

For a deeper look at the codes, read our post on what a 302 redirect is.

How do you fix a page with redirect problem step by step?

Once you isolate the suspicious groups, you fix them in a set order. Order matters because new stale addresses keep appearing if you skip the root cause.

1. Decide whether the redirect is intentional.
2. Find and remove the rule or plugin setting behind any unwanted redirect.
3. Use a permanent code for intended redirects.
4. Break chains and point each source to the final URL.
5. Remove redirecting URLs from the sitemap.
6. Update internal links and canonical tags to the final URL.
7. Confirm with URL Inspection that the targets are indexed.
8. If it makes sense, notify Google with the validate fix option.

On a small site these steps take a few hours. On an ecommerce site with thousands of URLs, though, you work through the rules one by one. If you want us to handle this on your site, our SEO consulting covers both the fix and the follow-up monitoring.

When should you use the validate fix option?

According to the help page, after you fix all instances of an issue, you can ask Google to confirm your fixes. The same page notes that validation typically takes about two weeks and can take longer. It also stops if Google finds even one remaining instance.

However, page with redirect is usually not an error to fix. Your intended redirects will stay in the list. So instead of pressing the validate button every time, it makes more sense to track only the groups where you removed unwanted redirects. In other words, a failed validation does not always mean your site has a problem.

For example, one method from the help page works well here. Submit a separate sitemap with only your most important pages, then filter the report by that sitemap. That way you separate normal redirects from your key pages.

Meanwhile, you can keep working on other fixes. Validation tracks only the instances of that one issue. Still, avoid large structural changes while it runs, because new redirects can muddy the result. In short: clean up, notify, then monitor calmly.

Example scenario: what do you see after a domain migration?

Example scenario: a business moves its site from old.example.com to example.com and maps every page with a permanent redirect. In the weeks after the move, the page with redirect count on the new property may stay flat, while it starts to climb on the old property.

That rise is expected, because Google is following the new setup. Still, the team should check three points: are the new URLs getting indexed, does the sitemap list only the new URLs, and do internal links use the new domain? If all three answers are yes, the setup is healthy.

We discuss how long to keep migrated redirects live in our post on how long 301 redirects should stay.

Example scenario: why do ecommerce rules create redirects?

Example scenario: a store turns on a setting that automatically redirects out of stock product pages to the category page. A few weeks later, hundreds of page with redirect rows appear. Worse, some products come back in stock and their pages keep redirecting.

This shows how automatic rules create side effects when nobody watches them. In that case, find the condition that triggers the rule, then remove the redirect for products that return. Also make sure a product page goes to the closest related page, not an unrelated category.

Products that are gone for good need a different call. If a close alternative exists, a permanent redirect to it makes sense. If not, clearly reporting that the page no longer exists is a more honest signal. Google can treat irrelevant redirects much like missing pages over time.

What is the difference between page with redirect and redirect error?

People mix the two up because the names are similar, yet they mean different things. Page with redirect records a working redirect: Google reaches the target and skips indexing the source. Redirect error covers cases where Google cannot reach the target.

Google's help page groups the causes of that error into four buckets: a chain that is too long, a loop, a target that exceeds the maximum URL length, and a bad or empty URL in the chain. Therefore, a redirect error always needs action, while page with redirect needs a review first.

• Page with redirect: the redirect works and the source stays out of the index.
• Redirect error: Google cannot reach the target.
• Common ground: in both cases the source URL is not indexed.

For loop errors, our post on the too many redirects error walks you through the fix.

Where do unwanted redirects come from on WordPress sites?

When the permalink structure changes or a post URL is updated, WordPress tries to send old addresses to the new one on its own. This behavior helps most of the time. Even so, it sometimes causes surprises. For example, when one of two pages with similar slugs is deleted, its old address may land on the other.

Also, redirect plugins, SEO plugins, caching plugins and server rules can all create redirects at the same time. When these layers overlap, finding the rule that fires gets hard. So the first step is to gather every redirect source into one list.

• Rules in the server configuration file.
• Rule lists in redirect and SEO plugins.
• Redirects inside the theme or custom code.
• Domain forwarding in the hosting panel.

Example scenario: a site owner installs an extra redirect plugin and defines the same rule both there and in the server file. The result is a two step chain. Removing one of the rules fixes it.

How do canonical tags and redirects work together?

A canonical tag suggests your preferred address to Google, while a redirect physically sends visitors and crawlers to another address. Both should point to the same target. Otherwise, Google receives two different messages and makes its own choice.

In practice, the mismatch we see most often is a canonical tag that still names an old address. For instance, a page moved to a new URL, but the template still prints the old one as canonical. Google then sees you proposing a redirecting address as canonical. Therefore, after any move, update canonical tags to the final URL.

We cover the basics in our post on what a canonical tag is. Here we only stress how it should line up with redirects.

Why does page with redirect grow on multilingual sites?

When a multilingual site redirects visitors automatically based on language, the same content opens from different addresses for different people. Google mostly crawls from one location, so it may never see some language versions. Moreover, when the root address sends each visit to a different language, page with redirect rows pile up.

That is why we recommend keeping each language version at its own fixed address and showing a language suggestion instead of a forced redirect. As a result, every version gets crawled at its own URL and hreflang tags work properly.

We examined the impact of IP based language redirects in our post on automatic language redirects and SEO.

Which tools help you monitor redirects?

No single tool shows everything. Therefore, you combine a few sources. Search Console shows what Google saw, while your own crawl shows the site as it is today.

• Search Console Page indexing report: redirecting URLs Google detected.
• URL Inspection tool: the target and canonical choice for one address.
• Redirect checker: chains and response codes one by one.
• Server logs: which old addresses Googlebot visits and how often.
• Desktop crawlers: old addresses in internal links, found in bulk.

For example, if your server logs show frequent requests to the same old address, a link to it probably still exists somewhere. Then you can find the source of that link and update it.

When you run your own crawl, check more than response codes. Also confirm that the final target is the right page. A redirect can work technically and still send visitors far from the content they expected. So open a few examples in a browser too.

What should you do if the page with redirect count does not drop?

First, do not expect the number to fall right after a fix. Google recrawls old addresses on its own schedule, and the report reflects that over time. Intended redirects also stay in the list, so reaching zero is not the goal.

That said, if nothing changes for a long time, ask a few questions. Are new redirects appearing? Did a plugin update bring old rules back? Are many old links coming in from external sites? One of these usually holds the answer. In short, look at the quality of the URLs in the list, not just the count.

Which mistakes should you avoid?

A rushed fix sometimes creates new problems. These are the wrong moves we run into most often in the field:

• Removing every redirect and leaving old addresses on a 404 response.
• Sending every deleted page to the homepage regardless of relevance.
• Using a temporary redirect for a permanent move.
• Leaving the sitemap to a plugin and never checking it.
• Using the URL removal tool to clean up the page with redirect list.

The last item is a common misconception. The removal tool hides URLs temporarily, and Google did not design it for this status. Instead, fix the redirect setup and let Google recrawl.

How often should you monitor this status?

On a small, stable site, a monthly check is usually enough. However, after big projects such as a migration, a redesign, a plugin change or a URL structure update, we suggest checking more often in the first weeks. Unwanted redirects tend to appear in exactly those periods.

If you would rather tie this to a steady process than handle it yourself, you can request a quote for our SEO consulting service. We do not promise rankings. Instead, we find issues at the source, fix them and share the results with you openly.

While monitoring, watch for new URL patterns in the list, not just the totals. A folder or parameter you have not seen before usually signals a new rule or plugin. That way you catch the problem while it is small.

Quick summary: a page with redirect checklist

In short, page with redirect is usually an information row, not an error. The real work is to understand whether the redirects behind it are intentional. This short list is enough for that:

• Is the target address indexed?
• Is the redirect permanent and a single hop?
• Does the sitemap list only final URLs?
• Do internal links and canonical tags point to the final URL?
• Did an important page start redirecting by accident?

If all five answers look good, the remaining rows in the report should not worry you. As a result, you can spend your time on the issues that actually cost you traffic.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.