Old URLs Still Showing in Search Console After 301 Redirects

By Idea to Traffic Editorial Team · Published October 14, 2026 · Last updated October 14, 2026

You changed your URL structure, added a 301 redirect from every old address to its new one, and the new pages are indexed. Weeks later, the old URLs are still sitting in the Page indexing report under "Why pages aren't indexed." It looks like a problem. In most cases it is the report telling you the redirects work.

What "Page with redirect" actually means

Google lists a URL as "Page with redirect" when it crawled that address and got sent somewhere else. A URL that redirects is, by definition, not the page Google should index, so it goes in the not indexed column. The page it points to is the one that gets indexed. That is the outcome you wanted when you set up the 301s.

The report is a record of every URL Google knows about and what it decided for each one. It does not forget an address just because you stopped linking to it. Old URLs live on in backlinks, bookmarks, other sites' sitemaps, social posts and Google's own crawl history, so Googlebot keeps checking them from time to time. Each check confirms the redirect, and the URL stays listed. Two months after a restructure, seeing hundreds of old URLs there is normal. Seeing them a year later is also common and still harmless.

The status to worry about is not "Page with redirect." It is any of these appearing for URLs that should redirect:

• Not found (404): the redirect is missing for that path, so the old URL is a dead end and any link value it had is lost.
• Redirect error: a loop, a chain that is too long, a redirect to an empty or broken URL, or a URL that is too long.
• Soft 404: the old URL redirects to the homepage or a generic page instead of a matching one. Google often treats that as a missing page.
• Duplicate, Google chose different canonical than user: on the new URLs, this can mean signals still point at the old ones.

Check the redirects yourself in two minutes

Do not trust the report's sample alone. Export the "Page with redirect" list (open the status row, then the export button at the top right) and test a handful of URLs directly. From a terminal:

curl -sIL https://example.com/old-category/old-post/ | grep -iE "^(HTTP|location)"

A healthy result shows exactly one 301 followed by a 200:

HTTP/2 301
location: https://example.com/guides/new-post/
HTTP/2 200

What to look for in the output:

• More than one 301 in a row. For example, old path to http, http to https, https to the new path. Google follows up to 10 hops, but every extra hop wastes crawl and slows users. Point each old URL straight at its final address.
• A 302 or 307 instead of 301 or 308. Temporary redirects tell Google the old URL may come back, so it can keep the old one as canonical for longer. Use a permanent code for a permanent move.
• A final 404 or 5xx. The redirect target itself is broken. Fix the mapping.
• A redirect to the homepage. Map each old page to the closest matching new page, not to the root.

To test a whole export at once, save the URLs one per line in old.txt and run:

while read u; do printf "%s  " "$u"; curl -s -o /dev/null -L -w "%{http_code} %{num_redirects} %{url_effective}\n" "$u"; done < old.txt

Every line should end with 200 1 and the correct new URL. Anything with 2 or more redirects, or a final code other than 200, is worth fixing.

Clean up the signals that still point at old URLs

Google keeps recrawling old URLs mostly because something keeps mentioning them. You cannot remove every external link, but you control your own site. Go through this list:

1. Sitemap. Your XML sitemap should list only the new, final URLs that return 200. If an old URL is still in it, you are asking Google to crawl a redirect on purpose. In Search Console, go to Indexing, then Sitemaps, and confirm the submitted sitemap shows a recent "Last read" date.
2. Internal links. Menus, footers, related post widgets and hard coded links inside older articles often still use the old paths. Each one costs a redirect hop. Search your source or database for the old path prefix and replace it.
3. Canonical tags and hreflang. These should name the new URL exactly, including the trailing slash and https. A canonical that points at a redirecting URL sends mixed signals.
4. Structured data and Open Graph tags. The url field in your schema and og:url should match the new address.
5. Backlinks you can edit. Your own social profiles, directory listings and guest posts. Update the ones that send real traffic.

If you host on Cloudflare Pages, a _redirects file in the build output folder handles the mapping without any server code. One line per rule, and a splat covers a whole folder move:

/old-category/* /guides/:splat 301
/about-us /about 301

Keep specific rules above the general ones so they match first.

What not to do

• Do not remove the redirects to make the report shorter. Google's own site move guidance says to keep redirects in place for as long as possible, and at least a year. Pull them early and those URLs flip to 404, which is the outcome that actually loses traffic.
• Do not use the Removals tool on old URLs. It only hides URLs from results for about six months and does nothing to the redirect or the report. Since the old URLs already are not showing in search, there is nothing to hide.
• Do not block old URLs in robots.txt. If Googlebot cannot crawl the old address, it cannot see the 301, so it cannot pass signals to the new page.
• Do not run "Validate fix" expecting the rows to vanish. Validation rechecks the URLs, finds they still redirect, and the status stays the same, because nothing is broken.

How to tell the move worked

Judge the restructure by the new URLs, not the old ones. Three places tell you more than the not indexed list:

1. URL Inspection on a new URL. Paste a new address into the bar at the top of Search Console. You want "URL is on Google" and, under Page indexing, "Google-selected canonical" matching the URL itself.
2. Performance report filtered by page. In Performance, add a Page filter for the new path prefix, for example /guides/. Clicks and impressions should be climbing as the old prefix fades. Comparing the 28 days before the change with the most recent 28 days gives a fair picture.
3. Indexed page count. The "Indexed" number in the Page indexing chart should land close to your count of live pages. If it is much lower, the issue is with new pages, not old ones.

A quick outside view helps too. Our free Site Checker runs 30 checks on a URL, including canonical, redirect and sitemap basics, so you can confirm a new page is set up the way Google expects.

The short version: if the old URLs return a single 301 to a matching page that returns 200, and your sitemap and internal links use only the new URLs, the "Page with redirect" list is a receipt, not a warning. Leave it alone and watch the performance of the new pages instead.

Where this question came from

• Reddit r/SEO: Outdated URLs remain in Google Search Console but are not indexed
• Shopify Community: Google keeps indexing outdated URLs even after redirects

Questions about redirected URLs in Search Console