How to fix redirect chain on Gatsby

Steps for Gatsby

1. Audit all redirect chains: run a crawl (e.g. Screaming Frog, `gatsby-plugin-sitemap` output, or a custom Node script) against your built site to enumerate every internal URL that resolves through 2+ hops. Export the mapping of `stale_url → final_destination_url` into a JSON file (e.g. `src/data/redirect-map.json`) that your build can consume.
2. Centralise the canonical URL resolver: create `src/utils/resolveUrl.js`. It imports `redirect-map.json` and exports a `resolveUrl(href)` helper that walks the map until it finds a URL with no further redirect, returning the final destination. All internal `<Link>` usages will call this helper so stale paths can never slip through.
3. Replace every raw internal `<Link to={href}>` / `<a href={href}>` across page templates, components, and MDX/Markdown-sourced content with `<Link to={resolveUrl(href)}>`. Prioritise high-traffic components first: `src/components/Header.jsx`, `src/components/Footer.jsx`, `src/components/ProductCard.jsx`, navigation menus, breadcrumbs, and any component that renders CMS-sourced rich text.
4. Patch `gatsby-node.js` (or `gatsby-config.js`) to remove or consolidate `createRedirect` calls whose `fromPath` is itself a destination of another `createRedirect`, so Gatsby's own redirect table no longer creates chains at the platform level.
5. Add a build-time validation step in `gatsby-node.js` (`onPostBuild` lifecycle): iterate every page's internal links (parsed from the HTML output in `public/`) and assert none of them appear as a key in `redirect-map.json`. Fail the build with a descriptive error if a stale link is found, preventing regressions.
6. Run `gatsby build && gatsby serve`, re-crawl the local server, and confirm zero redirect chains remain. Update `redirect-map.json` and re-run this process whenever new redirects are added to the commerce platform or CMS.

What is redirect chain?

A redirect chain occurs when clicking or following a link takes a visitor (and search engine crawlers) through two or more redirects before landing on the final page — for example, Page A → Redirect 1 → Redirect 2 → Final Page. Each step in that chain is an extra stop the browser and Googlebot must make before reaching the real content. Even a single unnecessary redirect adds latency; a chain of two or more compounds the problem significantly. The fix is straightforward: change the link's href so it points straight to the final URL, cutting out all the middlemen.

Every hop in a redirect chain costs you in three ways. First, PageRank (link equity) is diluted with each redirect — Google has confirmed that it loses some signal at every step, meaning pages at the end of long chains rank lower than they should. Second, each hop adds real load time (typically 100–300 ms per round trip), which directly hurts Core Web Vitals scores like Largest Contentful Paint and Time to First Byte — both ranking factors in Google's page-experience signal. Third, Googlebot has a limited crawl budget per site; chains waste that budget on intermediate URLs instead of your actual content pages, slowing down discovery and indexing of new or updated pages. Fixing redirect chains on your own internal links is entirely within your control and delivers immediate, measurable improvements to ranking potential, page speed, and crawl efficiency.

See the complete Redirect chain guide for every platform and the full background.