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

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.

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.

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. 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. 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. 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. 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.

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. 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. 2

   Search for the old URL

   Download the XML. Search for “/pricing-old”. If present, your generator has not updated since the rename.

3. 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. 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.

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. 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. 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. 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. 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.

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. 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. 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. 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. 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.

# 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]

# 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.

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.

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.

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. 1

   Fix sitemap

   Ensure your sitemap lists only “/guides/start”. Remove the old slug from the generator. Resubmit the sitemap.

2. 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. 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. 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.