If your Google Search Console Page Indexing report is filling up with “Page with redirect” issues, your first instinct might be to fix every single one.
But do not do that. Most pages with a “Page with redirect” status are there because your redirects are working exactly as intended.
Google found the old URL, followed the redirect, and indexed the right page.
The ones worth your time are the entries where something on your own site, your sitemap, your internal links, or an old 302 nobody updated, keeps sending Google back to a URL that can no longer be indexed.
Those are the ones quietly wasting your crawl budget. So let’s talk about it.
Page with Redirect Status Is a Signal, Not Always a Problem
This status shows up when Google crawls a URL, hits a working redirect, and indexes the destination instead.
The old URL gets excluded from the index on purpose. If you set up that redirect intentionally, the report is just confirming it did what you wanted.
That said, the label appears under “Why pages aren’t indexed,” which makes it look like an error list. It is not.
After an HTTPS migration, a slug cleanup, or a content merge, this report will naturally fill up. That is expected.
This Is Different from “Redirect Error”
Google Search Console has a separate status called “Redirect error,” and that one actually means something is broken.
According to Google’s Page Indexing report documentation, redirect errors happen when Google hits a loop, a redirect chain that is too long, or a destination that does not load.
Always check the exact label first. “Page with redirect” is informational. “Redirect error” needs immediate attention.
When You Can Safely Ignore It
You will see “Page with redirect” entries after any normal site change. These are fine and need no action:
- HTTP to HTTPS migration: The old HTTP URLs redirect to their HTTPS versions, and Google indexes the secure ones.
- www vs non www setup: Your server forces one domain format, so the other version shows as redirected.
- Trailing slash cleanup: Your site enforces one URL format, and the alternate version redirects.
- Content merges: You combined weaker pages into a stronger one and redirected the old URLs.
If the count has been flat for months and matches changes you made on purpose, there is nothing to fix. Start paying attention when new entries appear without a clear reason, or when pages you actually want indexed are being redirected.
Three Causes That Are Worth Fixing
The question is not “why does this URL redirect?” The question is “what keeps sending Google to the old URL in the first place?”
If nothing on your site links to it and it is not in your sitemap, the entry is noise. But if your own site keeps pointing Google toward a URL that redirects, that is worth investigating.
Especially if you have also noticed pages dropping out of Google’s index.
Your Sitemap Still Includes Redirected URLs
Your XML sitemap should only list pages that return a 200 status. If a URL in your sitemap redirects, you are telling Google “index this” and “go somewhere else” at the same time.
Most CMS plugins generate sitemaps automatically, and many site owners assume the plugin filters out redirects.
It often does not. A slug change, a category update, or a page move can leave stale URLs in your sitemap for months without anyone noticing.
Internal Links Still Point to Old URLs
This one compounds fast. You move a page, set up the redirect, and the new page ranks. But your menu, footer, sidebar, and older blog posts still link to the old address. Every time Google crawls any of those pages, it hits the redirect first.
One outdated link in a global footer can mean hundreds or thousands of unnecessary hops per crawl cycle. Fixing a single template link often clears more GSC entries than rewriting a dozen redirect rules.
Redirect Debt from Multiple URL Changes
Redirect debt happens when a site goes through several rounds of URL changes without cleaning up older rules. An old URL redirects to a newer one, then that newer URL redirects to a third.
Nobody created a chain intentionally, but after two or three migrations, chains form on their own. Google’s redirect documentation confirms that every extra hop uses crawl resources. The cleanest setup is always one redirect straight to the final page.
A Quick Five Minute Check
You do not need a full search console technical audit to figure out whether your redirect report is a problem or just noise. A few minutes inside Search Console is usually enough.
Start with Submitted URLs
Open the Page Indexing report, click “Page with redirect,” and filter the list to show only URLs submitted in your sitemap. This one filter is the fastest way to find what actually matters.
A redirected URL outside your sitemap is probably just an old address doing its job.
A redirected URL inside your sitemap means you are actively asking Google to crawl something that cannot be indexed.
Check a Small Sample Before Making Bulk Changes
Export the filtered list and pick 15 to 25 URLs. Run them through the URL Inspection tool and check two things for each one:
- Where does the redirect land?
- Is the final destination correct and returning a 200?
If the destination is right and already indexed, the only fix is removing the source URL from your sitemap. If the destination is wrong, broken, or blocked, you have a real redirect problem.
In most cases, the issues cluster around one migration, one plugin, or one URL pattern. Find the cluster and you find the root cause.
Fix the Source, Not Only the Redirect
Most troubleshooting guides jump straight to editing redirect rules. That can help when a redirect is genuinely broken, but it skips the structural cause.
If your sitemap or internal links keep sending Google to old URLs, the same entries will come back next month.
Clean Your Sitemap First
Remove every redirecting URL from your XML sitemap. If a CMS plugin generates it, check whether it has an option to automatically exclude redirected pages.
After cleanup, resubmit the sitemap in Google Search Console. This alone can reduce “Page with redirect” entries significantly in the next reporting cycle.
Update Internal Links to the Final URLs
Crawl your site with Screaming Frog, Sitebulb, or a similar tool. Export internal links that return a 3xx status. Update each one to point directly to the final destination.
Start with global template links (header, footer, sidebar, navigation) because those appear on every page and have the largest multiplier effect.
If you are also seeing 404 errors in Search Console, this same crawl catches both problems in one pass.
Then Fix Redirect Rules That Are Actually Broken
Once the sitemap and internal links are clean, look at the redirect rules themselves. Focus on three patterns:
- Redirect chains: A URL passes through two or more stops before reaching the final page. Update the rule so it goes directly to the destination in a single 301.
- Redirect loops: URL A sends to B, and B sends back to A. Pick the correct final page, keep one redirect, and delete the conflicting rule.
- Stale 302 redirects: If a temporary redirect has been active for weeks or months and the move is permanent, switch it to a 301. Google will eventually treat old 302s as permanent anyway, but being explicit speeds things up.
You can check redirect types with httpstatus.io, Chrome DevTools (Network tab with “Preserve log” on), or a bulk crawl tool for larger sites.
WordPress Sites Need Extra Attention
WordPress can create redirects quietly in the background.
That does not make it bad for SEO, but it does mean redirects can come from multiple layers: the CMS itself, SEO plugins, standalone redirect plugins, .htaccess, caching, or your CDN.
If your site runs on WordPress, two areas are worth checking even if your report looks clean right now.
Slug Changes Create Hidden Redirects
Every time you change a post or page slug, WordPress (or your SEO plugin) silently creates a 301 redirect from the old URL. No notification, no log entry.
Over months of editing and reorganizing, your site can collect dozens of forgotten redirects. The same thing happens when you update a category slug or change a parent page’s permalink: every child URL gets redirected too.
Check your SEO plugin’s redirect manager regularly. If an old redirect points to a URL with no backlinks, no traffic, and no internal links, you probably do not need it anymore.
Letting the old URL return a 404 is fine when nothing points to it.
Plugin Conflicts Can Stack Redirect Rules
Running more than one plugin that manages redirects (like Rank Math alongside the Redirection plugin) can create conflicting rules.
One sends URL A to page B, the other sends it to page C. The result depends on plugin load order and can change after updates.
Keep your redirects in one place: a single plugin or .htaccess, not both. If a redirect works in your plugin’s test tool but behaves differently in the browser, check .htaccess, your cache, and CDN rules. That mismatch is almost always caused by rules stacking across layers.
Make Redirect Checks Part of Your Monthly Routine
Fixing redirects once does not mean they stay fixed. Plugins update. Team members rename slugs. Old links get copied into new posts. The “Page with redirect” count should be something you glance at monthly.
If the number is flat, you are fine. If it spiked, filter to the newest entries and trace what changed. Spikes almost always tie back to a specific event: a content reorganization, a plugin update, a theme change, or a permalink edit.
If you are also tracking statuses like crawled but not indexed or discovered but not indexed, consider running a full GSC indexing audit.
Redirect issues rarely exist in isolation. They connect to your sitemap health, your internal link structure, and how efficiently Google crawls your site overall.
