Page With Redirect in Search Console: When It Hides a Problem

"Page with redirect" in Search Console means Google requested a URL, the server sent it somewhere else, and Google considers the destination for its index instead of the URL you see in the list. Most of the time this is a redirect doing exactly what you built it to do, after a move to HTTPS, a www decision or a URL change. It becomes a problem when the destination is wrong or unindexed, or when your own sitemap, links and canonical tags keep sending Google to the old address.

What Google says the status means

Google's Page Indexing report documentation (checked October 2026) describes it as "a non-canonical URL that redirects to another page", adds that this URL "will not be indexed", and says the target "might or might not be indexed, depending on what Google thinks about that target URL."

Two consequences follow from that wording:

• The status is about the source URL, never the destination. Seeing http://example.com/pricing in the list tells you nothing about whether https://www.example.com/pricing is indexed. You check the destination separately.
• The redirect type matters. Google's redirect documentation (checked October 2026) splits redirects in 2 groups. Permanent ones (HTTP 301 and 308, a meta refresh or HTTP refresh set to 0 seconds, and a JavaScript location redirect) are used as a signal that the target should be canonical, and the target is what search results show. Temporary ones (302, 303, 307, and a delayed meta refresh or HTTP refresh) are followed, but are not used as that signal, so search results show the source URL. A JavaScript redirect is only seen if Google renders the page successfully.

This is a different status from "Redirect error", which Google uses for redirects it could not complete: a loop, a chain that was too long, a redirect URL that exceeded the maximum URL length, or a bad or empty URL in the chain.

Where redirecting URLs come from

The normal sources produce most of the URLs in this list on a healthy site:

1. Protocol and host normalization. http:// to https://, and the apex domain to www or the reverse.
2. Trailing-slash normalization. /blog to /blog/, set by a platform or server default.
3. Migrations and URL changes. A new domain, a new path scheme, a renamed product. WordPress, for example, sends a 301 from a post's old slug to its new permalink when you edit the slug.
4. Retired pages consolidated into a successor. An old guide merged into a newer one.

The problem patterns are all things your own site does:

1. Your sitemap lists URLs that redirect. In 29 external websites whose sitemap pages SEOReport fetched between May and October 2026, 6 (21%) listed URLs in their XML sitemap that redirect elsewhere.
2. Your internal links, canonical tags or hreflang annotations name the old URL. Navigation templates, old in-body links and canonical tags hardcoded with http:// keep feeding Google the redirecting address.
3. The redirect goes to the wrong place. Google's site-move guidance (checked October 2026) warns that redirecting many old URLs to one unrelated page, such as the homepage, "might be treated as a soft 404 error."
4. The redirect is a chain, or temporary when it should be permanent. Several hops to reach the destination, or a 302 left in place after a move that is never going to be reverted.

Redirects were the most common of the 3 mixed signals in that sample. Each one asks Google to index a URL you have already told Google is not the real one.

Is it a problem? Leave, fix or monitor

flowchart TD
    A["URL listed as Page with redirect"] --> B{"Did you mean to redirect it?"}
    B -->|no| C["Remove the redirect or restore the page"]
    B -->|yes| D{"Is the destination the right replacement?"}
    D -->|no| E["Redirect to the closest equivalent, or return 404 or 410"]
    D -->|yes| F{"One hop, and permanent?"}
    F -->|no| G["Collapse to a single 301 or 308"]
    F -->|yes| H{"Does your sitemap, a link or a canonical name the old URL?"}
    G --> H
    H -->|yes| I["Update every reference to the final URL"]
    H -->|no| J{"Is the destination indexed?"}
    I --> J
    J -->|yes| K["Leave it"]
    J -->|no| L["Check the destination's own status"]

How to confirm which cause applies

Start with the sitemap filter. At the top of the Page Indexing report, switch the filter from "All known pages" to "All submitted pages" and open "Page with redirect" again. Any URL still listed there is a redirecting URL that one of your sitemaps submitted. The example table is limited to 1,000 rows, so on a large site test the sitemap directly as well (below).

Inspect a few URLs. Google's URL Inspection documentation says the indexed result reflects the URL you entered, not its redirect target. Two fields point at the source of the problem: "Referring page" shows a page Google possibly used to discover the URL, and "Sitemaps" shows any sitemap that lists it. If the referring page is on your own site, you have an internal link to update. If it is on another site, the redirect is doing its job.

Trace the hops yourself. The same documentation says the live test ("Test live URL") follows redirects without saying so and does not display the final URL it tested. A terminal shows every hop:

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

One 301 or 308 followed by one 200 is a clean redirect. Two or more redirect lines is a chain, and a 302 or 307 on a permanent move should change.

Inspect the destination separately. Paste the final URL into URL Inspection. If it is not indexed, the problem lives on that page, and its own status tells you where to look: a destination that carries noindex is covered in URL marked 'noindex', and one Google fetched but left out is covered in Crawled - currently not indexed.

Find which of your own files still name the old URL

Search Console shows a sample of discovery sources. Your own files show all of them. Test every URL your sitemap lists and print the ones that do not answer 200:

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed -e 's/<loc>//' -e 's/<\/loc>//' -e 's/&amp;/\&/g' \
  | while read -r url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
      [ "$code" != "200" ] && echo "$code $url"
    done

A 301, 302, 307 or 308 in the output is a redirecting entry. If the file is a sitemap index, run the same loop on each child sitemap it lists, and decompress any .xml.gz file first. Then check the templates every page shares, since one header link repeats on every URL:

curl -s https://www.example.com/ \
  | grep -oE '(href|content)="[^"]+"' \
  | grep -E 'http://|//example\.com'

Replace the last pattern with the old protocol, host or path you moved away from. On WordPress, old absolute URLs usually live in post content, and WP-CLI can count them before you change anything:

wp search-replace 'http://example.com' 'https://www.example.com' --dry-run

When you run it for real, take a database backup first and add --skip-columns=guid, so post GUIDs keep their original values.

How to fix each cause

Sitemap entries. Regenerate the sitemap from final URLs only: each entry should answer 200 and declare itself canonical. Google's sitemap documentation (checked October 2026) asks you to include the URLs you want to see in search results, which a redirecting URL is not. Google's canonicalization documentation adds that every page listed in a sitemap is suggested as a canonical. Our XML sitemaps guide covers the rest of a clean sitemap.

Internal links, canonical tags and hreflang. Update them to the destination URL. Google's canonicalization documentation (checked October 2026) advises linking to the canonical URL rather than a duplicate, and a canonical tag that names a redirecting URL asks Google to consolidate signals into an address that does not hold the page. The canonical tags guide explains how those signals combine, and Duplicate Without User-Selected Canonical covers the case where host and protocol variants are not redirected at all.

Wrong destination. Point each old URL at its closest equivalent. When a page has no successor, a 404 or 410 is the honest answer, and it avoids the soft-404 treatment Google describes for redirects to unrelated pages.

Chains and temporary redirects. Write one rule from the entry URL straight to the final URL, as a 301 or 308. Redirect chains: how they happen and how to flatten them works through a 4-hop example, and the redirects and URL normalization guide covers protocol, host and slash rules together.

Keep the redirects themselves. Google's site-move guidance says to keep redirects for as long as possible, generally at least 1 year. External links and bookmarks keep arriving at old URLs long after your own references are clean.

How to verify the fix

1. Rerun the sitemap loop. It should print nothing.
2. Rerun the trace on a sample of old URLs: one permanent hop, then 200, on the right page.
3. Resubmit the sitemap in Search Console's Sitemaps report to ask Google to read it again.
4. Watch the "All submitted pages" filter. The redirecting URLs should leave it once Google rereads your sitemap and recrawls them. Google's recrawl documentation says crawling can take anywhere from a few days to a few weeks, on Google's schedule rather than yours.
5. Use "Validate fix" only for redirects you removed. Validation recrawls the affected URLs to check whether each one still has the issue, and an intentional redirect still redirects by design. Google's documentation says validation typically takes up to about 2 weeks, and in some cases much longer.

Search Console tells you which URLs redirect. A full SEOReport diagnosis audits the site itself and names the redirects you should not be advertising: redirecting URLs among the pages your sitemap lists, each with its destination, a homepage canonical target or alternate-language targets that redirect, and every hop when the address you submit takes more than one. It does not test internal links for redirects, so run the template check above for those.

Common questions

Will the redirecting URLs ever leave the report?

They can stay in the "All known pages" view for a long time, because Google keeps recrawling URLs it already knows, including URLs other sites link to. That is the correct end state when the redirect is intended and the destination is indexed. What should shrink is the number of those URLs that your own sitemap submits.

My homepage is listed as Page with redirect. Is that bad?

Usually the listed URL is a variant such as http://example.com/, which redirects to your preferred https://www.example.com/. Inspect the preferred homepage URL: if it is indexed, the variant is behaving correctly. If the preferred URL itself appears in the list, your homepage redirects somewhere you did not intend, and that needs fixing.

Should I use a canonical tag instead of a redirect?

Use a redirect when the old URL should no longer show its own page to anyone. Use a canonical tag when both URLs need to keep working, for example a filtered view of the same product list. A URL that stays live with a canonical pointing elsewhere is usually reported as "Alternate page with proper canonical tag" when Google accepts that canonical, which needs no action.