Gatsby

What Is Gatsby?

Gatsby is a React-based static-site generator (SSG): a framework that takes React components and content from many sources, then compiles them at build time into fast, pre-rendered HTML pages backed by a GraphQL data layer. If you want the short answer, Gatsby lets you build a website with React's component model but ship it as static files, so visitors get pre-built HTML that loads quickly and is friendly to search engines.

Gatsby is open source. It rose to prominence in the late 2010s as one of the frameworks that popularized the "Jamstack" approach, building sites at deploy time and serving them from a CDN rather than rendering on every request. The hosting company Netlify acquired Gatsby Inc. in 2023, which is part of why Gatsby sites are so frequently deployed on Netlify. Exact usage figures vary by source and detection method, so treat any single percentage cautiously. What technology-detection surveys consistently show is that Gatsby remains a recognizable presence among React content sites, though its share has softened as newer frameworks like Next.js and Astro absorbed many of the same use cases.

Gatsby appears most often behind documentation sites, marketing pages, blogs, and portfolios, the kinds of content-driven sites where build-time rendering and a unified data layer pay off.

How Gatsby Works

Gatsby's defining idea is that work that can happen at build time should happen at build time, not on every visitor request. The build process is where Gatsby does most of its heavy lifting.

When you run a Gatsby build, the framework pulls content from source plugins. These plugins connect to data sources, a headless CMS like Contentful or Sanity, a WordPress backend, local Markdown files, a database, or a remote API, and load all of that data into an internal GraphQL data layer. This unified schema is Gatsby's signature feature: every piece of content, regardless of where it came from, becomes queryable through a single GraphQL interface.

Your React components then declare exactly what data they need using GraphQL page queries and static queries. At build time, Gatsby runs those queries, injects the results into the components, and renders each page to static HTML. The output is a folder of pre-built HTML files, optimized JavaScript bundles, and a set of JSON data files.

That last detail matters for both performance and detection. Gatsby pre-computes the data each page needs and writes it to page-data JSON files under a /page-data/ directory. When a visitor lands on a page, they get the pre-rendered HTML immediately. As they navigate, Gatsby's client-side router fetches the small page-data.json file for the next route and swaps the content in without a full reload, an architecture often described as "rehydration plus client-side routing."

Gatsby also bakes in performance optimizations by default: automatic code-splitting per page, link prefetching that quietly loads the data for nearby pages before you click, image optimization that generates responsive image sets with lazy loading and blur-up placeholders, and a build output designed to be served straight from a CDN.

Because the final product is static files, Gatsby sites are typically deployed to static hosts and CDNs, with Netlify being especially common given the corporate relationship. This is why hosting signals (covered below) often accompany Gatsby's own fingerprints.

It helps to walk through the visitor's experience to see why this architecture produces the signals it does. A first request returns a fully rendered HTML document, the page's text and markup are already there, so the content paints quickly and crawlers see everything without running JavaScript. Once Gatsby's JavaScript loads, it "rehydrates" that static HTML into a live React application. From that point on, internal navigation is handled client-side: when you click a link, Gatsby does not request a whole new HTML page; it fetches the small page-data.json for the destination route and re-renders just the changed parts. This is exactly why the /page-data/ requests appear in the Network tab as you browse, and why they are such a dependable fingerprint.

The build itself is the part teams feel most. Because every page is generated ahead of time, build duration scales with the number of pages, which is fine for hundreds of pages but becomes a consideration for very large sites. Gatsby addresses this with incremental builds that rebuild only what changed, but the fundamental model remains build-time generation. Content updates therefore require a rebuild and redeploy rather than appearing instantly, which is the central trade-off of any static-site approach.

How to Tell if a Website Uses Gatsby

Gatsby's build output is distinctive, which makes it one of the easier frameworks to identify with confidence. Here are the signals and the tools that reveal them.

1. The /page-data/ JSON requests. This is the strongest single fingerprint. As you navigate a Gatsby site, the browser fetches files like /page-data/index/page-data.json or /page-data/some-route/page-data.json. Seeing requests to a /page-data/ path in the Network tab is nearly conclusive, because that structure is specific to Gatsby's data-loading model.

2. The ___gatsby root div. Gatsby mounts the application into a container element with the id ___gatsby (three leading underscores), usually accompanied by a gatsby-focus-wrapper. Inspecting the page and finding <div id="___gatsby"> is a direct giveaway.

3. Gatsby's runtime scripts. Gatsby emits recognizable bundle files, notably an app-[hash].js entry script and a webpack-runtime-[hash].js file. Seeing both referenced in the HTML, alongside framework-[hash].js, points strongly at Gatsby's build pipeline.

4. Prebuilt HTML. Because Gatsby pre-renders pages, the raw HTML you get from "View Source" already contains the page's full content (headings, paragraphs, markup) rather than an empty <div> waiting for JavaScript. Combined with the signals above, fully populated static HTML reinforces the diagnosis.

5. Hosting hints. Gatsby sites frequently sit on Netlify, so response headers or other host fingerprints pointing at Netlify add circumstantial support, though hosting alone never proves the framework.

6. Tooling. You do not have to read HTML manually:

• View Source shows the ___gatsby div, the app-/webpack-runtime- script tags, and the prebuilt content.
• Browser DevTools (Network tab) reveals the /page-data/*.json fetches as you click around the site.
• Wappalyzer and similar extensions detect Gatsby automatically.
• A server-side tool like StackOptic reads the delivered HTML and headers to flag Gatsby without manual inspection.

For a deeper, dedicated walkthrough, see how to tell if a website is built with Gatsby. To separate the React layer underneath from other libraries, how to check if a website uses React, Vue, or Angular is the companion guide. And because Gatsby and Netlify so often travel together, how to tell if a website uses Vercel or Netlify helps confirm the hosting side of the story.

Key Features

• Build-time rendering that pre-generates HTML for every page, producing fast, CDN-servable output.
• GraphQL data layer that unifies content from CMSes, APIs, databases, and files into one queryable schema.
• Rich plugin ecosystem for data sourcing, image handling, SEO, analytics, sitemaps, and PWA features.
• Automatic image optimization with responsive sets, lazy loading, and placeholder previews.
• Link prefetching that preloads data for nearby pages so navigation feels instant.
• Per-page code-splitting so each route ships only the JavaScript it requires.
• React component model, letting developers use familiar React patterns throughout.

Pros and Cons

Strengths	Trade-offs
Fast page loads from prebuilt static HTML	Build times grow with the number of pages
Excellent SEO because content is pre-rendered	GraphQL data layer has a learning curve
Unified data sourcing from many backends	Less suited to highly dynamic, per-request content
Strong image optimization out of the box	Rebuilds needed when content changes (unless using incremental builds)
Large plugin ecosystem	Ecosystem momentum has shifted toward newer frameworks

Gatsby is a strong fit when content is relatively stable and performance and SEO are priorities. It is a weaker fit for dashboards or apps where data changes constantly and must reflect per request.

Gatsby vs Alternatives

Framework	Base	Rendering model	Best for
Gatsby	React	Build-time SSG + client routing	Content sites aggregating many data sources
Next.js	React	SSG, SSR, ISR, RSC	React teams wanting rendering flexibility
Astro	Multi-framework	SSG with selective hydration	Content sites that want minimal JavaScript
Hugo	Go	Build-time SSG	Very fast builds, no React needed
Nuxt	Vue	SSR, SSG, hybrid	Vue teams needing SSG or SSR

Within the React world, the most common alternative is Next.js, which can do static generation too but also supports server-side rendering and incremental regeneration; see the Next.js technology profile for that comparison. Gatsby's distinguishing edge remains its GraphQL data layer, which is uniquely valuable when you are stitching together content from several sources.

Use Cases

• Documentation sites that benefit from fast loads, full-text search, and prebuilt pages.
• Marketing and landing pages where SEO and Lighthouse scores matter and content updates are infrequent.
• Blogs and publications, often sourcing posts from Markdown or a headless CMS through the GraphQL layer.
• Portfolios and agency sites that want polished image handling and snappy navigation.
• Multi-source content hubs that aggregate a CMS, a product API, and local files into one cohesive site.

If you are profiling a site end to end, pairing the framework check with hosting and analytics detection, the process in how to find out what technology a website uses ties the signals together.

Curious whether a site is Gatsby, Next.js, or something else? Run the URL through StackOptic for an instant read.

Frequently Asked Questions

Is Gatsby a framework or a static-site generator?

Both descriptions fit. Gatsby is a React framework whose primary output is a statically generated site. It uses React for authoring components and a GraphQL data layer for content, then compiles everything to static HTML and JavaScript at build time, which is the hallmark of a static-site generator.

What is the easiest way to confirm a site uses Gatsby?

Open DevTools, go to the Network tab, and navigate between pages. If you see requests to /page-data/.../page-data.json, you are almost certainly looking at Gatsby. A <div id="___gatsby"> in the markup and app-/webpack-runtime- script files confirm it.

Why are so many Gatsby sites on Netlify?

Netlify acquired Gatsby Inc. in 2023, and Gatsby's static output is a natural fit for Netlify's CDN-based hosting. The pairing predates the acquisition too, since Jamstack static sites have always deployed well to Netlify. Hosting alone does not prove the framework, but Netlify plus /page-data/ requests is a very strong combination.

Does Gatsby work without JavaScript?

The initial page is prebuilt HTML, so core content is visible even before JavaScript loads. Client-side navigation and interactive features rely on JavaScript, but the static-first approach means search engines and users see real content immediately rather than an empty shell.

Is Gatsby still a good choice today?

Gatsby remains capable, especially for content sites that lean on its GraphQL data layer and image pipeline. That said, ecosystem attention has shifted toward Next.js and Astro for many similar use cases, so the right choice depends on whether Gatsby's particular strengths match your project.

How is Gatsby different from Next.js if both use React?

Both are React frameworks, but their default model differs. Gatsby is built around build-time static generation with a unifying GraphQL data layer, making it ideal when you aggregate content from several sources. Next.js offers a broader spread of rendering options, including server-side rendering on each request and incremental static regeneration, which suits applications with more dynamic, per-request data. In short, Gatsby optimizes for prebuilt content sites, while Next.js optimizes for rendering flexibility.

Why do I see fully rendered content in View Source on a Gatsby site?

Because Gatsby pre-renders each page to HTML at build time. The document the server returns already contains the headings, paragraphs, and markup, so "View Source" shows real content rather than an empty <div>. This static-first delivery is a large part of why Gatsby sites score well on SEO and perceived load speed.