Page Is Not Indexed: Page with Redirect — What to Do

Quick Answer

Google Search Console reports “Page with redirect” when a URL redirects to another URL and is not expected to be indexed as the original page. Keep the redirect if it is intentional and correct. Inspect the destination separately, and fix the redirect only when it leads to the wrong page, fails, or conflicts with your intended site structure.

Key Takeaways

The right fix depends on which URL you want Google to show in search results. These findings help separate a normal redirect from a technical problem.

• A “Page with redirect” status usually describes an excluded source URL, not a broken website.
• Google may index the redirect destination, but the redirect alone does not guarantee inclusion.
• An unexpected destination calls for a check of the source URL, routing rules, hostname, protocol, and path.
• Redirect loops, invalid destinations, and problematic chains need technical investigation before another crawl request.
• Permanent and temporary redirects should reflect the actual move, not an attempt to change a Search Console status.
• Internal links, canonical annotations, and sitemap entries should point toward the intended destination whenever practical.
• A successful live test shows current access, not proof that Google has indexed the page.
• URL submissions and indexing notifications cannot force Google to accept a URL as canonical or include it in search results.

The best next step is to identify the URL you actually want indexed. Keep a correct redirect, repair a faulty one, or investigate the destination if it has a separate indexing problem.

What “Page with redirect” means in Google Search Console

“Page with redirect” means Google found a URL that sends visitors or crawlers to another URL. Google does not normally index that redirecting source as the page representing the content. It evaluates the destination separately.

For example, suppose https://example.com/old-guide redirects to https://example.com/new-guide. If the move is intentional, Google may exclude the old URL while considering the new one for indexing. That is an expected outcome, not automatically a technical failure.

Google's official Page indexing report documentation explains this exclusion and lists redirect errors separately. A normal redirect exclusion does not establish that the destination is indexed, accessible, or the correct canonical URL. Those are separate questions.

Three URLs or concepts matter during diagnosis:

• Source URL: The address entered into Search Console that redirects elsewhere.
• Destination URL: The address reached after following the redirect. It may be the page you want indexed.
• Canonical URL: The URL Google selects to represent a page when several URLs contain the same or very similar content.

These addresses can play different roles. A destination can work perfectly while the source remains excluded. A correctly redirected source can also lead to a destination that Google cannot index or chooses not to include.

Do not treat every excluded URL as a problem to eliminate. A site may have old URLs, duplicate paths, or retired pages that should not appear independently in search results. The objective is to make the intended page accessible and its signals consistent, not to turn every Search Console row into an indexed URL.

Decide whether to keep or fix the redirect

Keep the redirect when it serves a clear purpose and leads to the intended replacement. Change it when the destination is wrong, the redirect fails, or the original URL should still serve its own content.

Start by comparing the observed behavior with the site's intended URL structure. A migration from an old article to a replacement page is different from a routing rule that sends every article to the homepage. Both can produce redirects, but only one may reflect the intended design.

The matrix below connects common observations with the next action. Use it to choose what to test instead of changing redirect rules solely to clear an exclusion.

The distinction between an exclusion and an error matters. Google's documentation lists redirect errors separately, including loops, chains that are too long, URL-length problems, and bad or empty URLs within a redirect chain. It does not establish a universal hop count that every site must follow.

If the redirect is correct, changing it can create a new problem. If the destination is wrong, repeatedly requesting indexing will not repair the routing rule. Choose the action based on the behavior you observe and the page you intend Google to index.

Inspect the destination before requesting indexing

Inspect the final destination as a separate URL. Do not rely only on a live test of the redirecting source to determine whether the destination is indexed.

Google Search Console's URL Inspection tool provides two different views. Its indexed information describes Google's most recently processed version of a URL. The live test checks what Google can access at the time of the test. These views answer different questions, so a difference between them does not automatically mean something is broken.

Google's URL Inspection documentation explains that the live test follows redirects. Its displayed results do not identify the final URL reached through that redirect. Inspecting the destination directly avoids confusion about which page you are evaluating.

Use this sequence to separate the source's status from the destination's condition.

1. Copy the exact source URL. Include its protocol, hostname, path, and relevant trailing slash. Confirm that this is the URL reported by Search Console.
2. Follow the redirect. Identify the destination and check whether the source reaches it successfully. Look for unexpected intermediate URLs or a loop.
3. Inspect the destination directly. Enter the final URL into URL Inspection and review its indexed information. Run a live test to check its current accessibility.
4. Read the destination's own status. If Google reports another exclusion or error, diagnose that condition separately. Do not assume the source's redirect status explains it.
5. Choose the next action. Correct a real technical fault, align conflicting URL signals, or leave a healthy redirect in place.

A successful live test does not guarantee that a page will enter Google's index. Google may still assess canonical selection, content quality, security issues, manual actions, and other indexing conditions.

For more detail, see how Google's URL Inspection live test works. The guide explains the difference between current accessibility and the stored index state. That distinction helps when a destination works now but its reported index status has not changed.

Match redirect type to the intended move

Use a permanent redirect for a genuinely permanent move and a temporary redirect for a genuinely temporary one. Do not change a status code simply because Search Console lists the source as excluded.

Google treats permanent redirects as a strong signal that the destination should become canonical. Temporary redirects do not provide the same canonicalization signal, although Google may still index the destination when other signals support it. The actual code should match the site's intended behavior.

Google's redirect guidance for Google Search documents these common examples.

Consider a site that has permanently replaced an outdated product page with a new URL. A 301 or 308 is consistent with that move. If the site temporarily routes visitors elsewhere during maintenance, a temporary redirect may be more appropriate.

These examples describe intent, not guaranteed indexing outcomes. A permanent redirect does not ensure immediate index changes, inclusion in results, or a particular ranking outcome. Google's canonical choice depends on its evaluation of the available signals.

Before changing a code, check the reason for the redirect, how long it should last, and whether the original page is supposed to return. A status-code change made only to improve a report can misrepresent the site's actual behavior.

Align canonical signals, internal links, and sitemaps

Make the intended destination consistent across the redirect, canonical annotation, internal links, and XML sitemap. Conflicting signals can make it less clear which URL should represent the content in search results.

Google uses several signals when selecting a canonical URL. Its canonicalization guidance describes redirects and rel="canonical" annotations as strong signals. Sitemap inclusion is a weaker signal. These signals can support one another, but Google makes the final choice.

Suppose an article has moved from /old-guide to /new-guide. The redirect sends users to /new-guide, but navigation menus still link to /old-guide, the canonical annotation names another URL, and the sitemap lists the old address. The redirect may work, yet the site's signals are inconsistent.

Review the main elements together:

• Redirect: The old address should lead to the intended replacement, not an unrelated page.
• Canonical annotation: The destination should identify the preferred canonical URL when a canonical annotation is appropriate.
• Internal links: Update important menus, category pages, and article links to point directly to the preferred destination where practical.
• XML sitemap: List the canonical URLs you want considered for search results, rather than obsolete redirecting duplicates.
• Protocol and hostname: Keep the preferred HTTPS address and hostname consistent across these elements.

Google's sitemap guidance recommends including the canonical URLs that should appear in search results. A sitemap helps communicate URL preferences, but it does not force Google to crawl or index every listed page.

Do not rebuild the sitemap merely because one redirecting URL appears in the report. First confirm that the source is obsolete and the destination is the preferred page. Then update the sitemap and internal links if they still point to the old address. The change should improve consistency across the site, not just alter a report entry.

Troubleshoot redirect chains, loops, and regional redirects

Investigate the redirect path when it fails to reach the intended page or sends crawlers somewhere unexpected. Test the source and every intermediate response, then correct the rule that causes the problem.

A redirect chain passes through multiple URLs before reaching its final destination. A loop sends the browser or crawler back through an earlier URL without reaching a stable page. Other documented redirect errors include invalid or empty URLs and URLs that exceed the allowed length. These conditions differ from a normal “Page with redirect” exclusion.

Check these symptoms when the redirect does not behave as intended:

• Unexpected destination: Confirm the source-to-target mapping and check for broad rules that send many paths to the same page.
• Redirect loop: Inspect conflicting rules across the application, server, proxy, or content management system.
• Broken chain: Check every intermediate response and remove unnecessary or faulty steps where appropriate.
• Invalid destination: Confirm that the target is a complete, valid URL and that the final page responds as intended.
• Protocol or hostname conflict: Check whether HTTP-to-HTTPS, www-to-non-www, or other rules send the request back to an earlier address.
• Regional redirect: Check whether location-based routing sends crawlers away from alternate regional pages that should remain discoverable.

Regional redirects deserve special attention on international sites. A forced geo-IP redirect can send a crawler to one locale and prevent it from reaching another version. In its August 2024 Search Central office-hours discussion, Google addressed this type of issue and discussed letting visitors choose a regional version instead of forcing every visitor to one location.

That advice is contextual, not a rule against every geographic redirect. The correct setup depends on the site's regional content and how users and crawlers can reach each version. If alternate regional pages should appear in search, make sure the redirect strategy does not hide them from discovery.

For complex cases, give a developer the exact source URL, each observed redirect destination, the final response, and the intended result. That evidence is more useful than reporting only that Search Console says a page is not indexed.

Verify the correction without chasing an indexing guarantee

After correcting a genuine fault, retest the affected URL and inspect the intended destination. Confirm that the site now behaves as planned before requesting another crawl or indexing review.

Use a consistent verification order so you can distinguish a repaired redirect from a separate indexing issue.

1. Recheck the source. Confirm that it redirects only when intended and reaches the correct destination.
2. Check the final response. Make sure the destination loads the intended page and does not unexpectedly redirect elsewhere.
3. Review indexability and canonical signals. Check that the destination is accessible to Google and that its canonical annotation, internal links, and sitemap support the intended URL.
4. Inspect the destination in Search Console. Compare the stored indexed information with the live test. Read any reported issue against the destination itself.
5. Request indexing when appropriate. If the destination is intended to be indexed and a meaningful correction has been made, use the available Search Console workflow to request another review. This is optional, not a guarantee.
6. Allow Google to reevaluate the page. Check the status again after Google has had an opportunity to recrawl and process the changes. Do not assume that a status change must occur immediately.

The goal is to confirm that the technical state is correct. An old URL may remain excluded because it still redirects as intended. That is not a failed correction. The more relevant question is whether the destination is accessible, suitable for indexing, and the URL you want Google to select.

If the destination still has an indexing problem, use this broader Google indexing troubleshooting guide after completing the redirect-specific checks. It covers wider indexing issues without treating every exclusion as a redirect defect.

Submission services have a limited role. They cannot correct a faulty redirect or resolve a canonical conflict by themselves. They also cannot force Google to include a page. Google makes its own crawling, canonicalization, and indexing decisions.

Bing uses a different inspection process. Its URL Inspection documentation explains that the Live URL test reports the redirect destination instead of following the redirect in the same way as Google's live test. Inspect that destination separately. Bing's URL submission guidance also states that submission does not guarantee indexing in Bing. That is Bing-specific evidence, not proof of Google's exact submission policy.

Frequently Asked Questions

These answers separate expected redirect exclusions from faults that need repair. They also distinguish the source URL's status from the destination's ability to enter Google's index. Check the actual redirect path before changing server rules. If the redirect works as intended, investigate the destination only when its own indexing status or accessibility gives you a reason to do so.

Does “Page with redirect” mean my website is broken?

No. Google Search Console normally uses this status when a URL redirects elsewhere and is not expected to be indexed as the source. Check whether the redirect is intentional and whether the destination is correct. Investigate further if the redirect fails or the destination has its own indexing issue.

Should I request indexing for the redirecting URL?

Usually, inspect the destination instead. If the source is meant to redirect permanently, its exclusion is generally expected. If the source should display an independent page, correct the redirect first. Request indexing for the intended destination only when it is appropriate and technically ready.

What if the redirect destination is also not indexed?

Treat the destination as a separate URL with its own status. Use URL Inspection to review its stored index information and current accessibility. Then investigate the reported cause, such as conflicting canonical signals or an access problem. A healthy redirect does not guarantee that the destination will be indexed.

Should I change a 302 redirect to a 301?

Only if the move is genuinely permanent. Google treats a 301 as a permanent redirect and a 302 as a temporary redirect. Changing the code solely to clear an exclusion can misrepresent the intended behavior. Choose the status that matches the actual move.

Does a successful live test mean Google has indexed my page?

No. A live test checks the URL's current accessibility and potential indexability. It does not prove that the page is already in the index or guarantee future inclusion. Inspect the destination's indexed information separately and review any reported indexing issue.

Should redirecting URLs appear in my XML sitemap?

Generally, list the preferred canonical destination rather than obsolete redirecting URLs. Google recommends using sitemaps to communicate which canonical URLs you want considered for search results. Check internal links and canonical annotations as well. Sitemap inclusion alone cannot guarantee indexing.

How do I fix a redirect error?

Test the source URL and every redirect step. Look for loops, invalid destinations, problematic chains, and URL-length issues. Correct the faulty routing rule or destination, then confirm that the request reaches the intended page. Do not assume that every normal “Page with redirect” exclusion is an error.

Can geo-IP redirects affect indexing?

Yes, in some configurations. A forced regional redirect may prevent crawlers from reaching alternate regional pages. Review how each locale can be accessed and whether the redirect sends crawlers away from intended content. Google's guidance discusses regional-choice options, but not every geographic redirect is inherently wrong.

Can IndexNowFast or another submission service force Google to index a URL?

No. Submission and notification tools do not override Google's canonicalization or indexing decisions. Fix a wrong redirect, resolve technical access issues, and inspect the intended destination first. A submission request may prompt another look, but it cannot guarantee inclusion.

Next Steps

Start with the exact source URL shown in Search Console. Record the destination it reaches and compare that address with the page your site is meant to use. If the redirect points to the correct replacement and works reliably, keep it. The source may remain excluded for that reason alone, and removing the redirect could damage the intended URL structure.

If the destination is unexpected, trace the full redirect path. Check the protocol, hostname, path, server rules, and intermediate URLs. Correct the specific rule that sends visitors or crawlers to the wrong place. Then test the source again and confirm that the final destination serves the intended page without a loop or an unexpected second redirect.

Next, inspect the destination directly in Search Console. Compare its stored index information with the live test, and review the declared and selected canonical URLs when available. A successful live test confirms current access under the test conditions. It does not prove that Google has indexed the page. If the destination has a separate exclusion or error, follow that report instead of treating the source's redirect status as the cause.

Finally, align the destination's canonical annotation, internal links, and sitemap entries. Request indexing only when the destination should appear in search and a meaningful correction is live. Then allow Google to recrawl and reevaluate the page. The goal is a correct redirect and a clear preferred URL, not a Search Console report with no excluded URLs.

For a separate indexing problem, continue with the Google indexing troubleshooting guide. You can also browse the IndexNowFast blog for related search and indexing resources. Use evidence from the destination's actual status to choose the next repair rather than repeatedly submitting the redirecting source.