# Page with redirect in Search Console: normal, until it is not

You see “Page with redirect” in Search Console. That is fine for retired URLs after a migration or a slug change. It needs work when Google still finds the old path through your sitemap or your links, or the redirects are messy.

Updated 2026-09-14 · Source: https://porteur.ai/guides/page-with-redirect

## Why “Page with redirect” is normal

Search Console’s Page indexing report lists every URL Google knows for your property as Indexed or Not indexed, with a reason. “Page with redirect” means the URL redirects. Google indexes the target, not the source. That is expected after you move a page or rename a slug.

If you changed “/pricing-old” to “/pricing”, you want Google to drop the old URL. “Page with redirect” on “/pricing-old” is the correct end state. You do not need to force Google to index the source. You want it to pass signals to the target and disappear from results over time.

## When it becomes a problem

Three cases need action. Each wastes crawl, slows users, or risks errors. Fix them and the status resolves on its own.

- Your sitemap still lists the old URL. Google keeps re-finding it and reporting “Page with redirect”.
- Your internal links still point to the old URL. Users and bots hit a hop on every click.
- You have a redirect chain or a loop. Google may show “Redirect error” or stop at an intermediate hop.

Fix the source of truth first. Remove old URLs from the sitemap. Update links in code and content. Collapse chains to a single hop. Close loops.

## Find redirect cases in Search Console

Start in Page indexing. Filter to “Page with redirect”. You get up to 1,000 example URLs. These are sources that redirect, not the targets.

1. **Check a sample URL with URL Inspection** Paste an example. See if it is on Google, how it was discovered, the last crawl, and any canonical. Use Test live URL to fetch now. Confirm the HTTP response is 301 or 308 from source to the final target. Note the referring page or sitemap shown.
2. **Look for discovery paths** In URL Inspection, check Discovery. If it lists a sitemap, your sitemap still holds the old URL. If it lists a referring page, that page links to the old URL.
3. **Spot chains or loops** In Test live URL, open View tested page. Check the HTTP response and any fetch failures. “Redirect error” in Page indexing points to loops or a too long chain.
4. **Map the hop** Open the old URL in your browser with DevTools, Network tab. Or use curl. Watch the Location headers. You want old to new in one step, not old to mid to new.

Use Request indexing for a single fixed URL. It queues a crawl and has a small daily quota per property. It does not guarantee indexing, but it is enough here to re-check the hop and the new target.

## Clean your sitemap of old URLs

Your sitemap is a list of canonical URLs you want indexed. Do not list sources that redirect. List only final targets. This keeps Google from re-crawling dead paths.

1. **Find the sitemap used** In Search Console, open Sitemaps. Note the submitted files and the Last read time. If you output per section, check each.
2. **Search for the old URL** Download the XML. Search for “/pricing-old”. If present, your generator has not updated since the rename.
3. **Fix the generator** Update your CMS or build step so only live URLs are exported. For static sites, rebuild after the change. For custom apps, filter out 3xx and 4xx.
4. **Resubmit and ping** Resubmit the sitemap in Search Console. Also serve it at /sitemap.xml and link it in robots.txt. Google will re-read it on its own as well.

A fixed sitemap for the “/pricing-old” case lists only “/pricing”. The old URL drops from the next report batch once Google re-crawls it or stops discovering it through the sitemap.

> Rule: your sitemap must only contain 200 OK canonical URLs, never redirects or 404s.

## Update internal links that still hit redirects

Google follows redirects, but every hop costs crawl budget and speed. Users feel it too. Do not rely on redirects inside your site once the move is done.

1. **Find linking pages** Use URL Inspection on the old URL. Note the referring page. For more, run a crawl with your own tool, or grep your repo for the old slug.
2. **Fix templates first** Change nav, footer, and shared components. A single header link can send every user through a redirect on every pageview.
3. **Fix CMS content** Search and replace in your CMS for “/pricing-old”. Update posts, docs, and landing pages. Save a list of edited URLs for re-crawl.
4. **Check JavaScript and meta** Look for redirecting links in client code, JSON, hreflang, and Open Graph tags. Update to the final targets.

After you update links, the fixed “/guides/getting-started” page links straight to “/pricing”. No hop. Re-crawl with Test live URL on a few edited pages, then let Google find the rest.

## Collapse redirect chains and stop loops

A chain is old to mid to new. A loop is old to mid to old. Both waste crawl and can trigger “Redirect error”. Your goal is one hop from every old source to the live target. Prefer zero hops on internal links.

1. **List current rules** Export your server or edge redirect rules. Include app-level rewrites. Note normalisers like http to https and slash rules.
2. **Trace common paths** Test with curl or your redirect checker. Try “/pricing-old”, http to https, www to non-www, and trailing slash variants. Write down each Location target.
3. **Set the final target once** Update the source rule so it points straight to the live URL. If you must normalise, do it before or after, not both. Keep the total to one 301 or 308.
4. **Remove obsolete hops** Delete mid rules that only exist to catch traffic no longer linked anywhere. Keep a backup, then remove and test again.

Examples to set a single hop. Adapt with care and test in staging first.

```en
# Apache, httpd.conf or .htaccess
RewriteEngine On
# Normalise http to https first
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://yourproduct.com%{REQUEST_URI} [R=301,L]
# Single hop from old slug to new
RewriteRule ^pricing-old/?$ https://yourproduct.com/pricing [R=301,L]

```

```en
# Nginx, server block
# Normalise www to non-www
server {
  listen 80;
  server_name www.yourproduct.com;
  return 301 https://yourproduct.com$request_uri;
}
# Single hop from old to new
location = /pricing-old {
  return 308 https://yourproduct.com/pricing;
}

```

Re-test with curl -I https://yourproduct.com/pricing-old. You should see one Location header, straight to “/pricing”. If you see two or more, adjust the order or merge rules.

> Warning: infinite loops often come from mixed normalisation, for example non-www to www in one place and www to non-www in another.

## 301, 302 or 308 for Google

For permanent moves, use 301 or 308. Google treats both as permanent and passes signals. 308 keeps the request method. 301 is the most common and fine for most pages.

Use 302 for a temporary move only. Google may keep the source indexed if it thinks the change will revert. Do not leave long term slugs on 302 if you want the target to rank.

Whatever you choose, be consistent. A mix of 301 and 302 across the same path confuses both bots and caches. Pick one per intent and stick with it.

## After fixes: re-check and monitor

Go back to Page indexing. Open the “Page with redirect” report. Click Validate fix. This starts a re-check that can take about two weeks. It confirms your sitemap and links are now clean, and the problematic sources now resolve as expected.

- Use URL Inspection to Test live URL on the old source and on a few edited pages. Confirm a single hop and a 200 on the target.
- Request indexing on any key page you changed, such as “/guides/getting-started”.
- Watch for “Redirect error”. If it appears, look for a loop or an empty Location.
- Check Crawl stats for spikes in 3xx after a deploy. It hints at new chains.

Expect the count in “Page with redirect” to fall as Google stops discovering old sources through your sitemap and links. It will never be zero on a site that keeps shipping. That is fine. Focus on the three fix cases, not the number itself.

## Worked example: a slug rename without noise

You renamed “/guides/getting-started” to “/guides/start”. You added a redirect from old to new. Search Console shows “Page with redirect” on the old slug. Here is how to keep it tidy.

1. **Fix sitemap** Ensure your sitemap lists only “/guides/start”. Remove the old slug from the generator. Resubmit the sitemap.
2. **Fix links** Search the codebase and CMS. Update any link that points to “/guides/getting-started”. Pay attention to nav and onboarding emails.
3. **Collapse hops** If http to https or slash rules add steps, adjust order so “/guides/getting-started” goes to “/guides/start” in one hop after normalisation.
4. **Validate** Use URL Inspection on the old slug. Test live. You should see a 301 or 308 to “/guides/start” and a 200 on the target. Request indexing once.

A week later, the Page indexing report still lists some “Page with redirect” entries. They were found through old blog posts you missed. You fix those links. The next crawl drops the count further. Nothing else to do.

## Questions

### What is “Page with redirect” in Search Console?

It means the URL you submitted or Google discovered returns a redirect. Google indexes the target, not the source. This is normal for old URLs after a migration or a slug change. It needs work only when your sitemap or internal links still use the old URL, or when there is a chain or a loop.

### Do I need to fix every “Page with redirect” entry?

No. You only need to fix the three cases that cause waste or errors. Remove old URLs from the sitemap, update internal links to point to the final URL, and collapse chains or loops. The rest are harmless leftovers from past changes.

### How do I see what causes the redirect status?

Open an example in URL Inspection. Check Discovery for the referring page or sitemap. Test live to see the HTTP response and the Location target. This tells you if the source is in your sitemap, linked from a page, or part of a broken chain.

### Should I use 301, 302 or 308 for moved pages?

Use 301 or 308 for a permanent move. Google treats both as permanent and passes signals. Use 302 only when the move is temporary. Be consistent per path.

### How long until the status clears after I fix it?

Search Console updates in batches. If you Validate fix, the re-check can take about two weeks. Counts also fall as Google re-crawls sitemaps and pages. You can request indexing on key URLs, but indexing is not guaranteed.

### Why did I get “Redirect error” instead?

That points to a loop, a chain that is too long, or an empty or invalid Location. Trace the hops with curl, shorten to one step, and correct any malformed targets. Then validate the fix in Search Console.

## Read next

- [How to use Google Search Console in ten minutes a week](https://porteur.ai/guides/how-to-use-google-search-console): A quick weekly routine: set four filters, compare 28 days, check pages then queries, and fix three findings, without getting lost in noise.
- [The Sitemaps report: what Success, Has errors and Couldn’t fetch mean](https://porteur.ai/guides/search-console-sitemaps-report): How to submit your sitemap URL, read Success, Has errors and Couldn’t fetch, and fix invalid XML, 404s, cross‑host URLs and missing child sitemaps.
- [How to use the URL Inspection tool in Search Console](https://porteur.ai/guides/url-inspection-tool): Read each panel, run Test live URL, and know when to request indexing. Fix new pages, dropped pages, and canonicals Google ignores.
- [Internal linking for a small site: which pages link to which](https://porteur.ai/guides/internal-linking-for-seo): Decide which pages rank. Build hubs, write clear anchors, fix orphans, and crawl your site to map links you control.
- [301 redirect](https://porteur.ai/glossary/301-redirect): A 301 redirect is a permanent move. Use it to send users and bots to a new URL, keep signals, avoid chains, and choose 308 when methods must persist.
- [Redirect checker](https://porteur.ai/tools/redirect-checker): Follow a URL's redirects hop by hop: each status and destination, the time each took, the kind of hop, meta and script redirects, one rule to replace it.
- [Google is not indexing your site: find the reason in Search Console](https://porteur.ai/guides/google-is-not-indexing-my-site): Use the Page indexing report to find the cause. Check for sitewide blockers, then quality reasons. Request a recrawl only after you fix them.

Want a second set of eyes on redirects and links, fast? Paste your URL and get a free check in about thirty seconds with three findings you can act on. Free check: https://porteur.ai/