“Page with redirect” is not an error: the URL redirects somewhere else, so Google considers the destination for indexing instead of the source URL. “Redirect error” is a genuine fault: Googlebot could not follow the redirect to its end, so neither the source nor the target can be indexed. Both statuses live in the Not indexed section of the Indexing > Pages report in Search Console, and Google’s own reminder applies: being not indexed is not necessarily bad, what matters is the reason given.
The distinction matters because the first status usually asks for nothing more than updating internal links and the sitemap, while the second points to a broken redirect chain on the server or in the CMS. The full list of reasons a page stays out of the index is covered as an ordered checklist in the diagnosis guide; the two redirect statuses are its third step.
Two statuses, two meanings
| Search Console status | What Google saw | Problem? | First step |
|---|---|---|---|
| Page with redirect | The URL is a non-canonical address that redirects to another page. This URL is not indexed; whether the target gets indexed depends on the target’s own status. | Usually no | Confirm that the target is the page you intended and that the target itself is indexed. Point internal links and the sitemap at the final URL. |
| Redirect error | Googlebot could not complete the redirect: the chain was too long, there was a loop, the URL exceeded the maximum length, or the chain contained a bad or empty URL. | Yes | Trace the chain hop by hop from the command line or a debugging tool, then reduce it to a single hop. |
The example list in the report is capped
The Pages report shows at most 1,000 example URLs per reason. On a large site with more redirecting URLs than that, exporting the list and comparing it with your own crawl is the only way to find the addresses that fall outside the sample.
When “Page with redirect” is normal, and when it is not
Google does not index a redirecting URL itself; with a permanent redirect it treats the target as the canonical. So in every one of the following cases, seeing the “Page with redirect” row is the expected outcome:
- Protocol and hostname variants: http://, www or non-www, and trailing-slash versions redirect to a single canonical address. These URLs should not be in your sitemap, but it is natural for them to show up in the report.
- Moved content: an old URL sends a 301 to the new address. The old address leaves the index and the new one enters it. As long as links keep pointing at the old address, Google keeps crawling it and listing it here.
- Removed products and pages: a discontinued product redirects to the closest category. If the target is genuinely related, this is fine; redirecting everything to an unrelated page or to the homepage is a different problem (see below).
- Case and parameter clean-up: the server redirects variants such as /Product and /product, or URLs with tracking parameters, to the clean address.
The same row is a warning sign, and sometimes a real loss, in these situations:
- Wrong target: a page you want indexed redirects somewhere else. The usual culprits are a CMS setting, two conflicting redirect rules, or a badly configured language or region redirect. Read the target in URL Inspection and check that it really is the page you meant.
- Target not indexed: the redirect is correct, but the final page carries noindex, is blocked by robots.txt or sits in “Crawled - currently not indexed”. Then neither source nor target is in search, and the problem is the target page, not the redirect.
- Temporary redirect used for a permanent move: with 302 or 307, Google may keep showing the source URL in results; the switch to the target canonical is delayed or never happens. Use 301 or 308 for permanent moves.
- Internal links and sitemap still point at the old address: technically not an error, but every crawl wastes a hop and the report keeps growing. Updating links to the final address saves a request for users and for Googlebot alike.
Redirect error: four causes and the fix for each
Google lists four causes in the report: a redirect chain that was too long, a redirect loop, a redirect URL that eventually exceeded the maximum URL length, and a bad or empty URL in the redirect chain. All four are about the responses your server returns; the page may open fine in a browser while Googlebot follows a different path. The quickest way to see the chain is an HTTP request that follows redirects one at a time:
curl -sIL "https://www.example.com/old-page" | grep -iE "^(HTTP|location)"Each HTTP line in the output is one hop and each Location line is the next address. The expected result is a single 301 or 308 followed by a 200. Google also suggests a web debugging tool such as Lighthouse to get more detail about the redirect, and the Network tab of your browser’s developer tools shows the same chain.
- 01
Chain too long
When http → https → www → trailing slash → new URL stack up into four or five hops, Googlebot may give up. Write every rule straight to the final address: the old URL should land on https://www.example.com/new-page/ in one step, not pass through intermediate versions. CDN, server and CMS layers can each add their own redirect, so check the chain at every layer separately.
- 02
Redirect loop
Page A sends to B and B sends back to A. The most common form is the server redirecting to https while the CMS redirects back to http; another is a language redirect that throws the visitor back to the start. The same address appearing twice in the curl output is proof of a loop. Find the conflicting rule and remove one of them.
- 03
URL exceeds the maximum length
A redirect that appends a parameter on every hop (for example adding ?ref= or a session ID each time) grows the URL without limit. The redirect target must be a fixed address with no parameters; do not carry tracking parameters through the redirect.
- 04
Bad or empty URL in the chain
The Location header is empty, holds a relative path that resolves incorrectly, or contains invalid characters. This usually comes from a plugin or from a faulty line in a hand-written redirect map. Write the target as a full absolute URL starting with https, save, and trace it again with the command.
Opening in a browser is not proof
Browsers tolerate long chains and some malformed headers; Googlebot may not. If the report shows an error, verify with the command line or the live test in URL Inspection rather than with your own eyes.
How URL Inspection reports a redirect
URL Inspection gives two separate results, and for redirects they say different things. The indexed version is the record for the exact URL you tested and ignores redirects, so a redirecting URL shows “Page with redirect” here. The live test follows redirects and tests the final URL; according to Google’s documentation, the live test does not indicate that it followed a redirect. That is why seeing “URL is available to Google” in the live test while the index result says “Page with redirect” is not a contradiction: the first describes the target page, the second the source address.
Run the live test on both addresses
Test the source URL first and note the target, then open the target URL in a separate inspection. If the index result for the target says “URL is on Google”, the redirect has done its job; if not, the problem is the target page and the diagnosis order continues from there.
Redirect type: permanent or temporary?
Google evaluates redirects in two groups, permanent and temporary. With a permanent redirect the target is used as a signal for the canonical choice and the target is shown in results; with a temporary redirect Googlebot still follows it, but the source page keeps appearing in results. Google’s advice is to use permanent redirects when you are sure the redirect will not be reverted.
| Method | How Google treats it | When to use |
|---|---|---|
| HTTP 301 / 308 | Permanent; the target receives the canonical signal | Moved pages, merged content, http → https, www preference |
| HTTP 302 / 303 / 307 | Temporary; the source stays in results | Short-lived campaign pages, maintenance, A/B tests and anything you will revert |
| meta refresh (0 seconds) | Treated like a permanent redirect | When a server-side redirect is not possible |
| meta refresh (delayed) | Treated like a temporary redirect | Rarely; to show the visitor a message before moving on |
| JavaScript redirect | Followed; Google recommends it only when server-side and meta refresh are impossible | Last resort |
After the fix: links, sitemap and validation
- Every redirect reaches the final address in one hop (one 301/308 in the curl output, then a 200)
- The sitemap contains only final URLs that return 200; redirecting addresses have been removed
- Menu, body and footer links point at the final address, not the redirecting one
- The target page has no noindex, is not blocked by robots.txt and its canonical points to itself
- Permanent moves use 301 or 308; 302 remains only where the move really is temporary
- “Validate fix” was clicked once under the relevant reason in the Pages report
Fix every instance of the issue before you start validation; Google says not to click the button again until validation has succeeded or failed, and notes that validation typically takes up to about two weeks and can take much longer in some cases. A URL that can no longer be reached moves to the “Other” state during validation, which is not an error state.
If you want to speed up the recrawl of many target URLs, make sure the list you submit consists of final addresses, not redirecting ones. WeRankLab’s URL indexing tool checks every address before sending it: a redirect, a noindex tag, a robots.txt block or a canonical pointing elsewhere keeps the URL out of the submission, and you are not charged for it. Whether the target pages actually made it into the index after the fix is something you can see per URL with the bulk index checker.
Frequently asked questions
- Do I need to “fix” URLs in the Page with redirect status?
- Not if the target is correct and the target is indexed. The only work left is pointing internal links and the sitemap at the final address; old addresses keep appearing in the report as long as external links send traffic to them, and that is normal.
- I set up the redirect, but the target is still not indexed. Why?
- A redirect only takes Google to the target; whether the target is indexed depends on the target’s own status. Inspect the target URL separately: noindex, robots.txt, canonical and quality reasons are found there.
- How many redirects does Googlebot follow?
- Google’s Pages report documentation gives no number; it only says “too long”. The safe goal is always a single hop. If more than one hop is unavoidable, at least make sure every hop goes to a short, absolute URL.
- The redirect error is fixed; when does it disappear from the report?
- After “Validate fix”, Google recrawls the affected URLs and shows the outcome in the validation status. The process usually takes around two weeks. The report may show stale data in the meantime; the up-to-date answer for a single URL is the live test.