Should you really eliminate all internal redirects from your site?

Why does Google emphasize internal redirects?

An internal redirect occurs when your site points to a URL that redirects to another. Typically: you link to /old-page which performs a 301 redirect to /new-page. For Google, this is an unnecessary extra crawl hit - the bot must follow the chain instead of accessing the content directly.

From a user perspective, each redirect adds HTTP latency. On mobile, on slow connections, this translates into milliseconds that accumulate. And yes, Core Web Vitals are affected: redirects lengthen loading times, particularly the Largest Contentful Paint if the final page contains the LCP element.

Are all redirects problematic?

No. External redirects that you don’t control are not the issue here. If you link out to a third-party site that redirects, there’s nothing you can do — and Google is aware of that.

The problem lies with your internal linking. When you overhaul a site structure, migrate content, or change your URL slugs, you create redirects. If you don't update your internal links, you leave behind chains of unnecessary redirects. And that’s where it gets tricky.

What is the real impact on crawl budget?

Google has a limited crawl budget per site. The more you force the bot to navigate through redirects, the fewer actual pages it explores. On a small site of 50 pages, this is negligible. On a site with 10,000 URLs and a tight crawl budget, each internal redirect is a waste.

The bot may also slow down its crawl if it detects too much latency or successive redirects. A chain of 3-4 redirects — this happens more often than one might think after several migrations — and you may start to see orphaned pages or pages crawled too infrequently.

• Internal redirects waste crawl budget unnecessarily
• Each redirect adds HTTP latency for the user
• Redirect chains (A→B→C) are particularly burdensome
• Large sites are most impacted by this type of friction
• Updating your internal links after migration prevents this waste

Is this recommendation consistent with on-the-ground observations?

Yes, absolutely. It is common to see sites that, after a redesign, leave thousands of internal links pointing to redirected URLs. Crawling becomes less efficient, some fresh pages go unvisited for weeks — and no one understands why.

Crawl log tools clearly show that Googlebot follows redirects but consumes time and resources doing so. On an e-commerce site with 50,000 products and categories revamped every quarter, it's a huge drain. So no, this isn’t just a ‘theoretical best practice’ — it’s measurable and it has an impact.

What nuances should be added to this rule?

First, not all redirects are created equal. A clean, single 301 is manageable. A chain of 3-4 successive redirects becomes problematic. Google theoretically follows up to 5 hops, but in practice, it often abandons before that or deprioritizes the page.

Additionally, context matters. If you have 200 URLs with little internal linking, fixing 10 redirects will have only a marginal impact. But on a media site with 100,000 articles and dense linking, every misdirected link multiplies — and that weighs heavily. [To be verified]: Google has never provided a precise threshold beyond which redirects become penalizing. It's a matter of instinct and crawl data.

In which cases can this rule be temporarily disregarded?

During a migration, you cannot update everything all at once. You migrate URLs, implement 301s, and then clean up the internal linking. That’s the logical sequence — and Google fully tolerates it.

Where it becomes risky is when this ‘temporary’ situation lasts six months or a year. Redirects remain, the linking is never corrected, and you end up with a technically unstable site. Let’s be honest: most sites operate with unresolved internal redirects — and it doesn’t kill them. But it does slow them down.

How can you detect internal redirects on your site?

Use Screaming Frog or an equivalent crawler in 'spider' mode with redirection tracking enabled. Filter for internal URLs that return a 3xx code. You will immediately see which links point to redirected URLs instead of the final destination.

You can also cross-reference with server logs: identify the most crawled redirected URLs by Googlebot. These are the ones that waste the most budget. Prioritize correcting them first — quick impact guaranteed.

What concrete steps can be taken to fix the issue?

Once internal redirects are detected, you have two options. The first: manually update the links in your templates, menus, footer, articles. It’s time-consuming but clean. The second: global replacement script via search-replace in the database — faster but risky if poorly executed.

For a WordPress site, plugins like Better Search Replace can automate mass URL replacements. On a custom site, a well-calibrated SQL script will do the trick — but test first in a dev environment, never directly in production. And that’s where it gets tricky: how many sites actually have a clean process for this?

What mistakes should be avoided when correcting redirects?

Never delete a redirect before updating all internal links pointing to it. Otherwise, you’ll create cascading 404s. First check with a crawler that no internal link points to the old URL, then only consider removing the redirect.

Another common pitfall: correcting links in the content but forgetting about menus, sidebars, footers, dynamically generated breadcrumbs. These elements are often managed in separate templates — they need to be addressed too. A complete audit covers all sources of internal links, not just the articles.

• Crawl the site with Screaming Frog and enable redirect tracking
• Identify internal URLs that redirect and list the pages linking to them
• Update links in templates, menus, content, breadcrumbs
• Verify with a crawler that no internal link points to a redirect anymore
• Monitor crawl logs to confirm that Googlebot accesses the final URLs directly
• Document changes to facilitate future migrations