In short. Static site generation produces reusable HTML at build time, allowing crawlers to read prebuilt content in the initial response.

Definition: Static site generation (SSG) produces a page's HTML during a build, before a visitor or crawler requests it. The prebuilt HTML is reused across requests and can contain the page's main content before browser JavaScript runs.

Key facts

As of 17 October 2026, Google's JavaScript SEO documentation recommends server-side rendering or pre-rendering and explains that some bots cannot run JavaScript.
The Next.js static generation documentation describes HTML generated by next build and reused on each request.
Google's Rendering on the Web describes static rendering as generally producing a separate HTML file for each URL ahead of time.
Google's URL Inspection documentation provides separate checks for the indexed version of a page and its live version.

Why does prebuilt HTML matter for crawling?

Crawling retrieves a page; rendering executes its scripts to produce the HTML used for indexing. Google's JavaScript SEO guide explains that Googlebot, Google's search crawler, extracts links from the HTML response, then extracts links again after rendering. Google uses the rendered HTML to index content.

When an initial response contains only an application shell, Google needs JavaScript execution to see the actual content. Prebuilt HTML can make that content available in the response. This also helps crawlers that cannot execute scripts.

Google's example contains ordinary text and links directly in HTML. This excerpt illustrates the form that a build can emit:

<h1>Welcome to example.com!</h1>
<div id="placeholder">
  <p>Learn more about <a href="/products">our products</a> and <a href="/services">our services</a></p>
</div>

How does generation differ from request-time rendering?

Server-side rendering generates HTML in response to a request. Static generation moves that work to the build. Google's Rendering on the Web explains that a framework can support both approaches, choosing static rendering for suitable pages and request-time rendering for others.

The Next.js Pages Router documentation gives a concrete data-fetching example: getStaticProps fetches data during the build and passes it into the page. Its suggested uses include help and documentation pages. Frequently updated content can instead use request-time rendering or client-side data fetching, where browser JavaScript fills in parts of the page.

That choice determines which content is already present in prebuilt HTML. A browser-fetched section still depends on script execution even when the surrounding page is statically generated.

How can the deployed page be checked?

An implementation check compares the initial HTML response with the rendered page: the question is whether the main text is already present before scripts execute. Google's URL Inspection tool then supplies evidence about Google's processing of a deployed URL.

The indexed report's View crawled page exposes the request, response and returned HTML. A live test checks the current page; View tested page > More info exposes resources and JavaScript output. These views help separate a build output problem from a rendering problem. The indexed report can describe an older deployment, so the current page needs the live test.

FAQ

Can a statically generated page use browser JavaScript?

Yes. The Next.js documentation describes combining static generation with client-side data fetching. If your main text uses that approach, check whether it appears in the initial HTML.

Does Google skip rendering when HTML is prebuilt?

Google's JavaScript SEO guide says pages returning HTTP 200 enter the rendering queue, including pages without JavaScript, unless an indexing directive prevents it. Prebuilt content remains useful in the initial response.

Sources

Check how a page reads to answer engines. Open the GEO score analyzer