Page with redirect in Search Console: which URLs are affected
Open the Pages report in Search Console and “Page with redirect” is usually sitting near the top of the reasons list with a large number beside it. Nothing labels it an error. It appears in the same table as genuine failures, which is why most people treat it as one.
Most of that count is harmless. Some of it is a page that should be ranking and no longer can. This guide covers how to tell those apart, how to get the affected URLs out of Search Console, and what to do with the list once you have it. A column of four thousand URLs tells you nothing on its own. You need each one’s final status and final destination before any of it means anything.
What “Page with redirect” actually means
Google requested the URL, the server answered with a 3xx, Google followed it and indexed whatever was at the end. The original URL is not in the index because it does not hold content. That is the whole status. It describes one URL’s response, not a defect in your site.
The confusion comes from where the row lives. Search Console groups it under “Why pages aren’t indexed”, which is a list of explanations rather than a list of things to fix. “Not found (404)” belongs there and so does “Page with redirect”, and only one of them is asking for your attention by default.
Every permanent and temporary server redirect lands in this bucket: 301, 302, 307, 308. Meta refresh tags and JavaScript redirects usually end up here too, once Google renders the page and sees where it goes. What matters in all of those cases is the destination. If the destination is indexed and ranking, the redirect did its job and the report is telling you so.
When it is fine and when it is a real problem
The report gives you no way to separate these. Both sets look identical in the interface: a URL and a last crawl date. Knowing which shape you are looking at is the entire task.
Leave these alone:
- Old URLs from a migration that 301 to their replacement. Google keeps rechecking them for years, and keeps reporting them for as long as it does.
- The http to https upgrade, and the www to non-www choice. Both forms of every URL exist at the protocol level and one of them has to redirect. Correct configuration, thousands of rows.
- Trailing-slash normalization, lowercase enforcement, and other tidy-up rules that fire on URLs nobody links to.
- Campaign links, short links, feed URLs and vanity paths that were built to bounce somewhere else.
Go looking at these:
- URLs listed in your sitemap that redirect. The sitemap says index this; the response says go elsewhere. One of the two is wrong, and it is almost always the sitemap.
- URLs with backlinks pointing at them. A single hop passes nearly everything. A chain sitting behind that link does not, and it delays how fast the destination gets recrawled and credited.
- Canonical targets that redirect. You told Google the canonical version of a page is a URL that refuses to serve content. Google resolves it anyway, usually to the destination, but the signal you sent is not the signal you meant.
- Anything with more than one hop, wherever it came from. Chains build up quietly across migrations and nobody notices until a crawler stops following.
- Pages that redirect by accident. A geo or language rule catching the wrong requests, a login wall bouncing crawlers, a case-sensitivity rule, a CMS setting that folded a whole directory into one page during a redesign. These are the expensive ones, and in the Search Console list they look exactly like the harmless rows above them.
Getting the list out of Search Console
In the left sidebar, open Indexing, then Pages. Scroll past the chart to the table headed “Why pages aren’t indexed” and click the “Page with redirect” row. The detail view lists the affected URLs with the date each was last crawled, and the export button sits at the top right: Google Sheets, Excel, or CSV.
Two limits are worth knowing before you start. The list is a sample capped at 1,000 URLs per reason, so a count of 40,000 still exports 1,000 rows. And the export carries the URL and the crawl date, nothing else. No status code, no destination, no hop count. Every article on this subject stops at exactly this point and hands you a spreadsheet of addresses.
The sample is still worth having. Google fills it with URLs it crawls most, which correlates well with the URLs that matter. Ignore the Validate Fix button for now. It measures a fix you have not made yet, and starting it early costs you a two-week window.
Checking every exported URL at once
Open the export, select the URL column, and paste it into the bulk HTTP status checker. It takes up to 1,000 URLs per run, which is the same number Search Console will give you, so one export becomes one run. Each URL is followed through its redirects to the end, and the table reports the final status code with a count of how many were redirected at all.
Export those results to CSV and you get the column the whole exercise depends on: finalUrl, the address each URL actually lands on, sitting next to its status and a redirected flag. Sort by status and the work sorts itself.
| In the CSV | What it means | What to do |
|---|---|---|
| 200, destination looks right | The redirect works and Google indexed the page you intended. | Nothing. This is most of the list. |
| 200, destination is the homepage | A catch-all rule swallowed the URL instead of sending it to a replacement. | Point it at the closest real page, or let it 404. |
| 404 or 410 | The redirect ends on a page that no longer exists. Signal stops there. | Repoint at a live page, or drop the rule and return 410 directly. |
| 5xx or a timeout | The destination is broken, so nothing at the end of this redirect can be indexed. | Fix the destination before touching the redirect. |
| REDIRECT_LOOP or TOO_MANY_REDIRECTS | The chain never resolves. No visitor and no crawler reaches a page. | Find the cycle and break it. Highest priority on the list. |
| redirected = true, more than one hop | A chain. Every extra hop costs a request and leaks a little signal. | Rewrite the first rule to point at the final URL. |
For any URL that took more than one hop, run it through the redirect chain checker to see the individual hops and the rule that emits each one. The bulk run tells you a chain exists; the chain checker tells you where to edit. If you have hundreds of chained URLs rather than a handful, the redirect mapper traces them all in one pass.
One pattern deserves a second look before you move on: a large group of unrelated old URLs all landing on the homepage. That is a catch-all rule doing damage quietly. Google treats a mass redirect to an irrelevant page as a soft 404, so those URLs get no benefit from the redirect and the pages they replaced get none either.
Fixing what you find
Work from the CSV rather than from Search Console. You now know which URLs are the harmless residue of old moves and which ones need a change, and only the second group is work.
- Take redirecting URLs out of your sitemap. A sitemap should list URLs that answer 200 and are canonical to themselves. Run yours through the sitemap checker to find the leftovers, then regenerate it.
- Repoint internal links at the destination. A redirect exists for traffic you do not control. Your own navigation, body links and canonical tags have no reason to route through one, and every link that still does keeps feeding the old URL to crawlers.
- Flatten every chain to a single hop. Find the rule that emits the first redirect and rewrite it to point at the last URL in the chain. Do not add another rule on top of the existing ones; that is how the chain got there.
- Un-redirect anything that should rank. If a page with its own traffic, links and content was folded into a category page during a redesign, restore it at its own URL and delete the rule. This is the only fix on the list that can move rankings on its own.
- Repair redirects that end on a 404 or 410. Send them to a live page, or remove the redirect and let the old URL return 410 directly so Google drops it cleanly instead of chasing a dead end.
- Leave the correct ones alone. Old URLs that 301 to the right place need no action, no removal, and no sitemap entry. They will stay in the report and that is the report working.
Why it comes back after you fix it
The Pages report describes the last time Google crawled each URL, not the state of your server right now. Change a rule this morning and the row stays until Google comes back to that URL and re-evaluates it. For a page it visits daily that takes days. For a URL retired four years ago it can take months, because Google crawls old redirects rarely on purpose.
Validate Fix queues a recheck of the sample and runs for up to about two weeks. Clicking it again partway through restarts the count rather than accelerating it, and resubmitting the same URLs repeatedly changes nothing about crawl priority. Start it once, after the fixes are live, then leave it.
Expect the number never to reach zero. Every site that has ever moved a URL carries a permanent population of correct redirects, and they belong in this report. The measure of success is not the total. It is whether the specific URLs you flagged in your CSV have changed status. Keep the export, re-run the same list in the status checker a few weeks later, and compare the two runs. That answers the question in a minute, from your server rather than from Google’s crawl backlog.
Frequently asked questions
- Is 'Page with redirect' an error?
- No. It is a status that means Google requested the URL, got a redirect, followed it, and indexed the destination instead. Search Console files it under reasons a page is not indexed, which is a list of explanations rather than a list of faults. It becomes a problem only when the URL redirects and should not have.
- How do I fix Page with redirect in Search Console?
- Export the affected URLs, check each one's final status and final destination in bulk, then act on the ones that are wrong. Remove redirecting URLs from your sitemap, repoint internal links at the destination, flatten any chain longer than one hop, repair redirects that end on a 404, and un-redirect any page that should rank on its own URL. Correctly redirecting old URLs need no action.
- Which URLs are affected by Page with redirect?
- Open Indexing, then Pages, and click the 'Page with redirect' row under the reasons list. Search Console shows the affected URLs and an export button. The export caps at 1,000 example URLs per reason, so a count of 40,000 still gives you a sample of 1,000 — weighted toward the URLs Google crawls most, which are the ones worth checking first.
- Should redirected URLs be in my sitemap?
- No. A sitemap is a statement that these URLs should be indexed, and a redirect says the opposite. Listing both sends contradictory signals and wastes crawl requests on URLs that never resolve to content. A sitemap should contain only URLs that answer 200 and are canonical to themselves. Redirects keep working for anyone who arrives at the old address regardless of whether it is listed.
- How long until Search Console updates after I fix it?
- Until Google recrawls the URL, which can take days for pages it visits often and months for old URLs it checks rarely. The report describes the last crawl, not the current state of your server. Clicking Validate Fix queues a recheck of the sample and runs for up to about two weeks; starting it again mid-run resets the progress rather than speeding it up.
- Does Page with redirect hurt my rankings?
- The status itself does not. A single 301 passes nearly all ranking signal to the destination, and Google indexing the destination instead of the old URL is the intended outcome. Damage comes from the specific cases underneath: chains that lose signal at every hop, redirects that end on a 404, and pages that were folded into a redirect while still earning traffic and links.
Related tools
Paste your Search Console export
Up to 1,000 URLs per run, final status and destination for each, CSV out. No signup.