Using getStaticProps with CMS Data

getStaticProps is one of the features that makes Next.js interesting for content‑led sites.

It lets a page fetch data at build time, render HTML, and serve that HTML statically. For CMS‑backed sites, that is a useful balance: editors manage content in the CMS, developers define the templates, and users get fast pages.

The detail is in how carefully the CMS data is handled.

Fetch Only What the Page Needs

getStaticProps runs for a page during static generation.

That makes it a good place to fetch the content needed by that page:

• article title
• body content
• author
• dates
• SEO fields
• related entries
• images
• category data

The related article on `getStaticProps` versus `getServerSideProps` covers the broader rendering choice. In CMS work, the key habit is to keep the data fetching specific enough that the page is understandable.

Avoid fetching a whole CMS response and passing it directly into the component. Normalise the shape the page actually needs.

Validate CMS Assumptions Before Rendering

CMS data can be incomplete, even when the content model marks fields as required.

Entries can be unpublished, references can be missing, assets can lack dimensions, and slugs can be duplicated. getStaticProps should not blindly trust that every field is present.

Check:

• title
• slug
• publish date
• body content
• required image fields
• referenced entries
• metadata fields

If a page cannot be generated safely, fail with a useful message during the build rather than rendering broken HTML.

Pair with getStaticPaths for Dynamic Routes

For pages such as /articles/[slug], getStaticProps usually works with getStaticPaths.

getStaticPaths decides which paths should be generated. getStaticProps fetches the data for each path.

For CMS pages, the question is often whether content can be generated ahead of time and updated through rebuilds.

Keep Preview Requirements Separate

Published pages and preview pages have different data needs.

A published page should usually fetch published content only. A preview path may need draft content, unpublished references, or a special API token.

Do not mix those concerns accidentally. If preview code can fetch drafts, make sure it cannot leak into public static generation.

This is partly a security concern and partly an editorial workflow concern. Editors need reliable preview, but users should not see draft content.

Think About Rebuild Triggers

getStaticProps does not make CMS updates appear instantly by itself.

If the site is statically generated at build time, a content publish needs a rebuild or another freshness strategy. The article on static generation with CMS content and build‑time data covers that workflow.

When planning CMS integration, decide:

• which publish events rebuild the site
• whether unpublishing triggers a rebuild
• how failed builds are reported
• whether scheduled content is supported
• whether editors understand the delay

Return a Clean Page Model

The component should not need to understand the CMS API.

getStaticProps can turn CMS data into a page model:

• strings are present
• dates are formatted or serialisable
• optional fields are explicit
• images have the data the component expects
• related content is filtered

This makes components easier to test and makes CMS changes easier to isolate.

The same publishing problem shows up in newer cache models too. Content not updating from the CMS is the practical debugging version, while cache tags and revalidation in Next.js covers the App Router version of the same expectation gap.

Wrapping Up

getStaticProps is a strong fit for CMS‑backed public pages when the data is treated carefully.

Fetch the fields the page needs, validate assumptions, keep preview separate, pair dynamic routes with getStaticPaths, and make rebuild behaviour clear. The result is fast static output without pretending CMS data is always tidy.

Key Takeaways

• getStaticProps fetches data at build time for statically generated pages.
• CMS data should be validated before rendering.
• Dynamic CMS routes usually need getStaticPaths as well.
• Preview and published content should use separate data paths.
• Components should receive a clean page model, not raw CMS responses.