Search Console Says “Page with Redirect”: Which URL Should You Check?

You move a service page from /old-service to /services/design. Later, Search Console lists the old address under “Page with redirect.” The new page opens in your browser. Do you need to get the old address indexed too?

Usually, the useful question is whether the old address leads to the page you actually want people to find. Google describes this status as a non-canonical URL that redirects to another page. That source URL is not indexed under this status; the destination may or may not be indexed. A different report entry, “Redirect error,” describes a problem Google encountered following a redirect, such as a loop or an excessively long chain.

The example above is illustrative, not a finding from a customer's site. Here is a way to check one important URL before changing redirects across the whole site.

Write down the source and the intended destination

In Search Console, open the Page indexing report, select “Page with redirect,” and choose a URL. Copy the complete address, including http or https, the hostname, path, trailing slash and any query string. Record the date of Google's last crawl if the report provides it.

Next, write down both the reported URL (the source) and the address you intend visitors to reach (the destination). A move from an old service URL to its replacement may be intentional. A paid campaign URL that sends visitors to an unrelated homepage may deserve a closer look.

A URL in this report does not, by itself, establish that the destination is indexed or that the redirect has harmed your rankings. It also does not tell you which setting created the redirect.

Follow the address without signing in

Open the source URL in a private browser window and note the final address in the address bar. Does it reach the expected page with the expected content? If the page redirects to a sign-in screen, the wrong language, an unrelated service, or an error, keep a record of what happened and when. A private browser shows the path for that visitor; Googlebot may receive a different response, for example if a rule varies by user agent.

When the final address is unexpected, check the route using your hosting platform's redirect tools or a web debugging tool that shows each response and its Location header. A chain might look like this:

/old-service → /services → /services/design

The chain above is only an example. If a step returns to an earlier address, or points to an invalid or empty destination, investigate that step. Google lists redirect loops, overly long chains, invalid or empty URLs, and URLs that become too long under “Redirect error.” A “Page with redirect” entry is not automatically one of those errors.

If you use a platform, redirects may be configured in its dashboard, a plugin, the web server, or another layer such as a CDN. Rules at different layers can conflict, so trace the path and check which layer owns each rule before changing one. Avoid pasting private URLs, access tokens, or customer information into a public debugging service.

Inspect the destination separately

In URL Inspection, look at the indexed result for the source and its crawl date. Then inspect the intended destination as its own URL. The report for the source does not establish the destination's index status. If the destination is outside a property you can inspect, check its public accessibility and ask its owner if appropriate. You may not be able to see its Search Console index status; a missing inspection result is not proof that it is not indexed.

Google says the live test follows a redirect and tests the final URL without showing that it followed the redirect or which address it ended up testing. That makes the live test useful for a current access check, but it cannot replace checking the path from source to destination. The live result also does not guarantee indexing or predict Google's selected canonical. Compare it with Google's recorded index information and dates rather than treating both as one observation.

If the destination is not indexed, inspect its own reported reason. For example, an intentional noindex on the destination is a different issue from a source address that correctly redirects. Address the destination's own indexing reason. Removing a working redirect only to clear the source entry does not resolve a destination's noindex.

Decide whether to leave it or fix it

If an old address intentionally and reliably leads to the relevant replacement, and the replacement is the page you want visitors to find, the status alone is not a reason to remove the redirect. Keeping the old address working can also help someone following an existing link. Google may continue to encounter an older address through links or other discovery sources. An entry remaining in the report does not identify its discovery source or prove your current sitemap still contains it.

If an important page unexpectedly redirects to the wrong destination, find and correct the rule responsible. A product page that redirects to an unrelated homepage is a different situation from an old URL that leads to its replacement. If there is no suitable replacement for a removed page, a 404 Not Found or 410 Gone response may be appropriate. Redirecting unrelated retired pages to the homepage can be treated as a soft 404.

For a permanent move, Google's redirect guidance treats permanent redirects such as 301 and 308 as signals that the target should be canonical. Temporary redirects such as 302 and 307 have different semantics. Google lists server-side redirects first among the methods it is most likely to interpret correctly. Choose based on whether the move is intended to last; Google's selected canonical can differ from your preference.

Point your own links at the page you intend to use

If your current sitemap or an internal link still uses the old URL, update it to the intended destination where appropriate. For example, after moving /old-service to /services/design, a navigation link you control can point directly to /services/design. Keep the redirect for old links that you cannot update. Do not remove it merely because you have changed your own navigation.

This cleanup gives visitors a direct route and gives Google clearer information about the preferred address. It is not a promise of indexing or a reason to replace every old link on the web. Search Console can report URLs it discovered from sources other than your current sitemap.

Recheck one path and record the outcome

After a correction, repeat the source-to-destination check and inspect the destination again. Note the source, final URL, response or redirect steps you observed, the change you made, and the date. If you fixed a genuine issue, Search Console offers validation so Google can recheck it. Validation does not guarantee that the destination will be indexed or that the report will update on a particular date.

For a separate homepage review, SEOHabit's website SEO checker offers a limited first homepage check after registration. Site ownership verification is not required for that first check, but is required for ongoing checks. It cannot tell you why Google selected a particular redirect destination; use Search Console and the actual redirect path for that question.

A redirect can be the intended route rather than a defect. Start with the exact reported address, verify where it goes, and inspect the page you actually want people to find.

Sources: Google's Page indexing report (https://support.google.com/webmasters/answer/7440203), URL Inspection help (https://support.google.com/webmasters/answer/9012289), and redirects guidance (https://developers.google.com/search/docs/crawling-indexing/301-redirects).