Fetch Build-Time Data with `getStaticProps` in a Pages Router Page

If a Pages Router page needs data that is available before anyone visits, export getStaticProps from the page. Next.js runs it on the server to prepare the page at build time, then passes its returned props to the page component. It is a good fit for a public list of posts that does not depend on who made the request.

Export getStaticProps from pages/index.js

Here is one complete page. The endpoint is illustrative: replace https://example.com/api/posts with an endpoint reachable during your build. It must return a JSON array of posts, each with a stable id and a title—for example, [{"id":1,"title":"First post"}].

// pages/index.js
export default function HomePage({ posts }) {
  return (
    <main>
      <h1>Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </main>
  )
}

export async function getStaticProps() {
  const response = await fetch('https://example.com/api/posts')
  const posts = await response.json()

  return {
    props: { posts },
  }
}

The two exports have different jobs. getStaticProps fetches and parses the response on the server. Its return value puts that array under props.posts. Next.js supplies the returned value to HomePage, where the posts parameter is destructured and each title becomes a list item. The post ID supplies the list key; the code does not rely on a post’s position in the array.

getStaticProps must be exported from a page, not a separate non-page file. Its returned props must also be JSON-serializable. For this example, use ordinary JSON values for id and title, rather than returning values that cannot be represented by JSON.stringify. The Pages Router API reference describes both the page export and the serializable props return value.

With a reachable endpoint returning that shape, next build can generate the page with the fetched titles:

next build

The example does not handle an unavailable endpoint or an unexpected response shape; those are conditions to address for the API you actually use. The important handoff to check is simple: the array returned as props.posts is the array rendered by HomePage.

What visitors receive

For a Pages Router page using Static Generation, next build generates the production HTML. That HTML is reused across requests and can be cached by a CDN; a new visitor does not cause this example’s getStaticProps to fetch the posts again. Next.js also generates a JSON file containing the result of getStaticProps. During client-side navigation with next/link or next/router, it uses that JSON as the page props rather than running getStaticProps in the browser. See the Static Generation guide and the Pages Router data-fetching guide for those two parts of the generated output.

If the posts need to be regenerated after deployment, getStaticProps can optionally return revalidate alongside props. Its value is in seconds and specifies when page regeneration can occur; without it, revalidation is off by default. Leave it out when build-time data is the intended result, as this example does.

Return data meant for this page

The fetch runs on the server, but the returned props are used to render visitor-visible output and are also placed in the generated JSON used for client-side navigation. Return only fields the page needs. This list uses id and title; it has no reason to put credentials, private records, or other secrets in props.

Build-time data also cannot depend on an incoming visitor’s query parameters or HTTP headers: getStaticProps has no access to that request. If a title list must change according to who is asking or what headers they send, it is not the build-time list shown here. The Next.js data-fetching documentation makes that request boundary explicit.