The Gatsby Numbers
Gatsby has 55,942 GitHub stars — more than Astro's 60,347 in the same category of content-focused web frameworks. But stars measure adoption history, not current investment. Gatsby recorded 179 commits in the past year, 4 releases, and an activity score of 40.0 on WebPulse's scale. For comparison, Astro recorded 2,909 commits, 50 releases, and an activity score of 82.0 in the same period. The gap between community enthusiasm and maintainer output has widened to the point where the two metrics describe different frameworks.
Three Exit Paths
WebPulse's framework detection data and GitHub migration tooling activity identify three primary destinations for Gatsby sites. Each corresponds to a different organizational profile and a different set of migration trade-offs. The choice depends on what the organization actually uses Gatsby for — and in many cases, Gatsby's capability set far exceeded what the site required, making the migration simpler than the original adoption.
The first and largest destination is Astro. Gatsby and Astro share a content-first architecture philosophy, and Astro provides an official Gatsby migration guide. Astro's island architecture allows Gatsby's React components to be reused during migration — a critical factor for teams with significant component libraries. Astro scores 83.1 overall on WebPulse (vs. Gatsby's 68.2), with a security score of 90.0 and an AI-readiness score of 92.0. The migration preserves the content workflow while upgrading every measurable dimension. Astro's 2,909 commits per year and 50 releases signal a framework under active, intensive development — the kind of maintenance cadence that Gatsby had in 2019 and no longer provides.
The second destination is Next.js. Organizations that used Gatsby primarily as a React static site generator migrate to Next.js when they need server-side rendering, API routes, or incremental static regeneration — capabilities Gatsby never fully delivered. Next.js scores 80.8 overall with 140,129 stars, 5,706 commits per year, and 427 contributors. The trade-off is complexity: Next.js is a full application framework, not a content-focused generator, and migrations to Next.js tend to expand scope. Teams that migrate to Next.js often end up rebuilding features they did not plan to touch, because Next.js's architecture encourages patterns that Gatsby's architecture discouraged. The migration is technically clean — both frameworks use React — but the organizational impact is larger than Gatsby-to-Astro.
The Hugo Option
The third destination is Hugo, chosen by organizations that want to eliminate runtime dependencies entirely. Hugo is a compiled Go binary. It has zero CVEs — not zero critical CVEs, zero CVEs of any severity. Its WebPulse security score is 100.0. Gatsby sites that are primarily Markdown-driven content — documentation sites, developer blogs, knowledge bases — migrate to Hugo with minimal content transformation. The migration strips out the Node.js build chain, the GraphQL data layer, and the plugin ecosystem that Gatsby pioneered. What remains is a static site generator that builds thousands of pages in seconds with no supply chain attack surface.
The Hugo migration path requires the largest architectural adjustment. Gatsby developers write React components. Hugo developers write Go templates. The component model, the data-fetching patterns, and the build pipeline are entirely different. For teams where the content is the asset and the presentation layer is replaceable, this is a non-issue — Markdown files move between static site generators with minimal transformation. For teams that invested heavily in Gatsby's React component library, the Hugo migration means rebuilding the presentation layer from scratch in a different paradigm.
The Cost of Waiting
Gatsby's average issue close time is 273.6 days — nearly nine months. Its average PR merge time is 4.4 days. These numbers describe a project with minimal triage capacity. When a security vulnerability is discovered in a Gatsby dependency, the patch timeline is measured in quarters, not days. Organizations running Gatsby in production are effectively self-maintaining an open-source project that its own creators have deprioritized.
The dependency chain is the immediate concern. Gatsby's plugin ecosystem — once its competitive advantage — is now its liability. Gatsby plugins depend on specific versions of Gatsby core, which depends on specific versions of React, webpack, and GraphQL. As these upstream dependencies release security patches and breaking changes, the Gatsby plugin ecosystem falls further behind. Each quarter of inaction adds another layer of dependency drift that the eventual migration must reconcile.
The 10,133 Gatsby sites detected in WebPulse's WARC scan represent organizations that made a reasonable technology choice between 2018 and 2022. The framework they chose has since recorded 4 releases in a year. The migration is not optional — it is a question of timing, destination, and how much dependency drift accumulates before the decision is made. Astro, Next.js, and Hugo each offer a measurably stronger position on every dimension WebPulse tracks. The gap between Gatsby's 68.2 overall score and Astro's 83.1 is 14.9 points — nearly the full distance between a recommended and a concerning rating on WebPulse's scale.
Organizations that migrate now do so with access to official migration guides, community tooling, and compatible component architectures. Organizations that wait will migrate from a framework whose ecosystem has drifted further from the targets, making the migration longer, more expensive, and more likely to require a full rewrite rather than an incremental transition.
