How to Tell if a Website Is Built with Gatsby

If you want to know whether a website is built with Gatsby, the fastest answer is to open the DevTools Network tab and watch for requests to /page-data/*/page-data.json, and to View Source and search for a <div id="___gatsby"> (three underscores). Both are baked into how Gatsby ships and runs pages, so finding either is a strong signal and finding both is conclusive. Unlike the server-side frameworks, Gatsby is a client-side React static-site generator — it pre-renders pages to HTML and then hydrates them in the browser — so all of its fingerprints are visible from outside. This guide walks through every signal, how to read it in under a minute, and how to tell Gatsby apart from other React frameworks like Next.js.

It sits alongside how to tell if a website is built with Next.js, the broader framework guide how to check if a website uses React, Vue or Angular, and the wider how to find out what technology a website uses.

What Gatsby is, briefly

Gatsby is a popular open-source React-based framework best known as a static-site generator (SSG). At build time, it pulls content from sources (Markdown files, a headless CMS, APIs) — traditionally through a GraphQL data layer — and pre-renders every page to static HTML. That prebuilt HTML loads fast and is fully crawlable; once in the browser, Gatsby hydrates the HTML into a live React application, so subsequent navigation behaves like a single-page app. Because the output is static files plus client-side React, Gatsby's detection signals are all client-visible: the prebuilt HTML and root container are in View Source, and the page-data JSON and JavaScript bundles appear in the Network tab. This makes Gatsby, like other client-side frameworks, considerably easier to detect than a server-side framework that only returns plain HTML.

Signal 1: the /page-data/ JSON requests (the strongest tell)

The single most distinctive Gatsby fingerprint is its page-data.json requests. Gatsby pairs each pre-rendered page with a JSON file containing that page's data, served from a /page-data/ path — for example /page-data/index/page-data.json for the home page and /page-data/<route>/page-data.json for others. On first load Gatsby may fetch the current page's data, and crucially, as you navigate between pages, Gatsby fetches the next page's page-data.json instead of doing a full HTML reload. To see it, open DevTools (F12), go to the Network tab, reload, and then click around the site — you will see the /page-data/.../page-data.json requests fire. No other common framework uses that exact path and file convention, so seeing it is close to conclusive. There is also typically an /app-data.json request for site-wide data, which corroborates.

Signal 2: the ___gatsby root div

Gatsby mounts its React application into a very recognisable container. View Source (Ctrl/Cmd + U) and search for ___gatsby — Gatsby renders a <div id="___gatsby"> (note the three leading underscores), and inside it you will usually find a <div class="gatsby-focus-wrapper"> and the prebuilt page markup. This root container is a strong, near-conclusive fingerprint because the exact ___gatsby id is specific to the framework. It also distinguishes Gatsby instantly from Next.js, whose root container is __next (two underscores, different word). Finding ___gatsby in the server-rendered source — present before any JavaScript runs, because Gatsby pre-renders the HTML — is one of the quickest ways to confirm the framework.

Signal 3: prebuilt HTML plus hydration

Gatsby's rendering model is itself a signal. Because Gatsby is a static-site generator, View Source shows fully formed HTML content — the real text and markup of the page — not an empty shell waiting for JavaScript. That prebuilt HTML is then hydrated by React in the browser, turning the static page into an interactive app. So the pattern you observe is: complete, crawlable HTML in the source (good for SEO), combined with React taking over on load and fetching page-data.json as you navigate. This "prebuilt HTML that hydrates into React, with JSON-driven client navigation" behaviour is characteristic of Gatsby and is exactly what its SSG architecture produces. It also tells you something useful: Gatsby sites tend to be fast on first paint and SEO-friendly precisely because the HTML is pre-rendered.

Signal 4: the JavaScript bundles

Gatsby ships a recognisable set of JavaScript files, visible in the Network tab and the source. You will typically see:

• app-<hash>.js — Gatsby's app runtime.
• webpack-runtime-<hash>.js — the webpack runtime Gatsby builds with.
• framework-<hash>.js — the bundled framework/vendor code (React and friends).
• component---<route>-<hash>.js — per-route component chunks, an especially Gatsby-flavoured naming pattern.

Those filenames, particularly the component---... chunks and the webpack-runtime/framework/app trio, are characteristic of a Gatsby build. Watching them load in the Network tab corroborates the page-data and ___gatsby signals and confirms the framework is genuinely powering the page.

Signal 5: React underneath and hosting hints

Because Gatsby is a React framework, every React detection signal also fires — React in the bundle, React-style hydration, and so on. As with Next.js, that means React alone does not tell you it is Gatsby; the Gatsby-specific markers (___gatsby, page-data.json, the component--- chunks) are what name the framework on top of the React foundation. On the hosting side, Gatsby outputs static files, so it is frequently served from Netlify (with which Gatsby has long been closely associated), as well as Vercel, Cloudflare Pages, AWS and others. Netlify response headers are therefore a useful corroborating hint — but only that, since Gatsby output can live on any static host. For reading those headers, see how to read a website's HTTP response headers.

The signal table

Signal	Where to find it	What it means
/page-data/.../page-data.json	Network tab (esp. on navigation)	Gatsby's per-page data fetch — strongest signal
/app-data.json	Network tab	Gatsby site-wide data — corroborating
<div id="___gatsby">	View Source / Elements	Gatsby React mount point — strong
gatsby-focus-wrapper	View Source	Inner Gatsby wrapper — corroborating
app-<hash>.js, webpack-runtime-<hash>.js, framework-<hash>.js	Network tab, View Source	Standard Gatsby bundles — strong
component---<route>-<hash>.js	Network tab	Gatsby per-route chunks — strong
React detected	DevTools, JS bundle	Foundation — fires for all Gatsby sites
Netlify headers	Response headers	Hosting hint — Gatsby often on Netlify

Any one of the page-data requests or the ___gatsby div is a strong call; together they are definitive.

Method 1: the DevTools Network tab

For Gatsby, the Network tab is the most powerful single method, because the page-data.json requests are the strongest signal and they fire as you navigate. Open DevTools (F12), go to the Network tab, reload, and then click through a couple of internal links. Watch for /page-data/.../page-data.json and /app-data.json requests, and for the app-<hash>.js, webpack-runtime-<hash>.js, framework-<hash>.js and component---... bundles. This live view shows what the browser actually fetches, including the JSON-driven navigation that is Gatsby's signature. If you want to identify the other libraries loading alongside Gatsby, the same Network view feeds into how to check what JavaScript libraries a website uses.

Method 2: View Source

The quickest static check is View Source. Open the page, press Ctrl/Cmd + U, and search for ___gatsby (three underscores) and the bundle names. Finding the ___gatsby root div — with its inner gatsby-focus-wrapper and the fully rendered page HTML around it — is a strong, immediate confirmation. Because Gatsby pre-renders the HTML, these markers are present in the raw source before any JavaScript runs, so a static source view catches them reliably. Scanning the source also lets you confirm that the page content is prebuilt (real HTML, not an empty shell), which matches Gatsby's SSG model.

Method 3: curl and curl -I

From a terminal, fetching the page with curl https://example.com and searching the HTML for ___gatsby confirms the framework without a browser — handy for scripting checks across many URLs. curl -I https://example.com prints the response headers, where you may catch Netlify or other static-host hosting hints. The page-data requests are best observed live in the Network tab rather than via curl, so use curl for the source-marker and header signals and the browser for the navigation behaviour. This cross-references neatly with hosting detection — see how to find out where a website is hosted for what headers and the resolved IP reveal about the deployment.

A worked example

Say you are sizing up a competitor's marketing site, which feels fast and slick. You open View Source and search for ___gatsby — there it is, <div id="___gatsby"> wrapping fully rendered HTML, with a gatsby-focus-wrapper inside. That alone strongly suggests Gatsby, but you confirm in the Network tab: on reload you see app-<hash>.js, webpack-runtime-<hash>.js, framework-<hash>.js and a couple of component---... chunks. Then you click an internal link and watch a /page-data/about/page-data.json request fire instead of a full reload — the definitive Gatsby behaviour. React is detected in the bundle, as expected. Finally, curl -I returns Netlify response headers, consistent with Gatsby's common hosting. Every signal lines up: this is a Gatsby site, statically generated and served from Netlify. In about a minute you have the framework, the rendering model and the hosting — a complete read of the front-end stack.

Distinguishing Gatsby from Next.js and other React frameworks

The React ecosystem has several frameworks, and Gatsby is most often confused with Next.js, so it is worth being precise. The discriminators are the framework-specific markers, not React itself (which fires for all of them):

• Gatsby: ___gatsby root div (three underscores), /page-data/*.json requests, component---... chunks. A statically generated React site.
• Next.js: __next root div (two underscores), assets under /_next/, an inlined __NEXT_DATA__ script. Covered in how to tell if a website is built with Next.js.
• Create React App / Vite (plain client-side React): a bare React bundle with no server-rendered data blob and no ___gatsby or /_next/ — and typically an empty <div id="root"> in the source, since the HTML is not pre-rendered.

So when you see React, the presence of ___gatsby and page-data.json is what specifically points to Gatsby rather than one of its cousins. A quick rule of thumb: ___gatsby and page-data.json say Gatsby; /_next/ and __NEXT_DATA__ say Next.js; an empty #root with a bare React bundle says a client-only React app. For the wider family, see how to check if a website uses React, Vue or Angular.

What knowing it's Gatsby tells you

The framework is an informative single fact. Gatsby signals a React-based, statically generated site — which carries clear implications. The rendering model (pre-rendered HTML that hydrates) means good first-load performance and SEO-friendly output. The content workflow is often a headless CMS (Contentful, Sanity, WordPress-as-a-backend) or Markdown feeding a build pipeline, rather than a traditional server-rendered CMS. The hosting is typically a static host or CDN (frequently Netlify). And the team's skill set leans modern React and JAMstack. For competitive research it shows how a rival builds; for sales qualification it identifies the stack and the kind of integrations in play; for hiring and partnerships it signals the relevant skills. Gatsby in particular tells you the site favours performance and a decoupled, build-time content approach — useful context that a generic "it's React" would miss. This is the kind of signal that feeds technographic qualification.

How reliable is Gatsby detection?

Very reliable. Unlike the server-side frameworks, Gatsby is client-side and pre-renders its pages, so all its signals are exposed: the ___gatsby root div is in the source, and the /page-data/*.json requests and component---... bundles are in the Network tab. The page-data.json convention in particular is highly specific to Gatsby and is hard to confuse with anything else, especially once you watch it drive client-side navigation. The main thing to remember is the React caveat — React detection fires for Gatsby, Next.js and plain React alike, so you must look for the Gatsby-specific markers to name the framework rather than stopping at "React". Do that, and you can state "this is Gatsby" with genuine confidence. The only real edge case is a heavily customised build that renames or obscures the defaults, which is unusual and fragile; the standard fingerprints are present on the overwhelming majority of Gatsby sites.

The workflow

1. Open the Network tab, reload, and click an internal link — watch for /page-data/.../page-data.json.
2. View Source and search for ___gatsby (three underscores) and the gatsby-focus-wrapper.
3. Confirm the bundles — app-<hash>.js, webpack-runtime-<hash>.js, framework-<hash>.js, component---....
4. Note React as the foundation, and check headers for a Netlify/static-host hosting hint.
5. Combine the signals — ___gatsby plus page-data.json means Gatsby, distinct from Next.js's /_next/ and __NEXT_DATA__.

Go deeper

• The React sibling: how to tell if a website is built with Next.js.
• The framework family: how to check if a website uses React, Vue or Angular.
• The whole stack: how to find out what technology a website uses.
• The libraries alongside it: how to check what JavaScript libraries a website uses.

Want the framework, hosting and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.