What is generateStaticParams in the App Router?

generateStaticParams is an App Router function that returns an array of route parameters to statically generate pages at build time instead of on-demand at request time

generateStaticParams is a fundamental function in Next.js App Router used for static site generation (SSG) with dynamic routes. When you have dynamic route segments like [slug] or [id] in your folder structure, this function tells Next.js which specific paths should be pre-rendered as static HTML during the build process. It replaces the Pages Router's getStaticPaths function and works seamlessly with Server Components to generate lightning-fast, SEO-friendly pages .

Basic generateStaticParams Example

Key Characteristics

1
Build-time execution: Runs during next build before the corresponding pages are generated, creating static HTML files that can be served instantly from a CDN .
2
Server-side only: Executes exclusively on the server during build, never in the browser, allowing direct database queries and API calls .
3
Replaces getStaticPaths: In the Pages Router, this function replaces the older getStaticPaths with a simpler API that returns a flat array of params objects .
4
Development behavior: During next dev, generateStaticParams is called when navigating to routes, enabling live updates during development .
5
No ISR re-execution: Unlike getStaticPaths which could be used with fallback, generateStaticParams does not run again during ISR revalidation .

The function must return an array of objects, where each object represents the dynamic parameters for one static page. The property names in each object must exactly match your dynamic segment names. For a route like app/products/[category]/[product]/page.tsx, you would return [{ category: 'electronics', product: 'phone' }, { category: 'books', product: 'nextjs' }]. For catch-all routes like app/docs/[...slug]/page.tsx, you return an array with a slug property containing a string array: { slug: ['getting-started', 'installation'] } .

Different Dynamic Route Patterns

Controlling Behavior with dynamicParams

1
Default behavior (true): When export const dynamicParams = true (or omitted), paths not returned by generateStaticParams are generated on-demand at request time and then cached. This is equivalent to fallback: true or fallback: 'blocking' in the Pages Router .
2
Disable on-demand generation (false): With export const dynamicParams = false, any path not included in generateStaticParams returns a 404 page. This is ideal for sites with a fixed set of content .
3
Partial static generation: You can return only a subset of paths from generateStaticParams (like popular products) and let dynamicParams: true handle the rest, balancing build time with coverage .

Complete Example with dynamicParams and ISR

Always return an array from generateStaticParams, even if empty. An empty array means no pages are pre-rendered at build time, and with dynamicParams: true, all pages are generated on first visit . The function cannot be used in Client Components and must be exported from a Server Component page or layout . When working with multiple dynamic segments, you can generate params from child segments (bottom-up) or use parent params to generate children (top-down) for complex hierarchies .

Common Pitfalls to Avoid

1
Using client-side APIs: generateStaticParams runs on the server, so browser APIs like localStorage or window are not available. Accessing them will cause build errors .
2
Forgetting string conversion: Dynamic params must be strings. If your IDs are numbers, convert them with .toString() .
3
Empty returns: If your data fetch fails, ensure you still return an array (even empty) and add error handling with try-catch blocks .
4
Misunderstanding development vs production: The function runs during navigation in development but only at build time in production .

In the Pages Router, you needed both getStaticPaths (to define which paths to generate) and getStaticProps (to fetch data for each path). The App Router simplifies this: generateStaticParams only handles parameter generation, while data fetching happens directly in the Server Component. This eliminates the need for separate data-fetching methods and provides a more intuitive, unified approach to static generation .

Difficulty: 6/10

Topics: static generation, dynamic routes, fallback handling

Scenario Questions

0-2 years experience

1
We have a blog with a known set of slugs. How would you use generateStaticParams to pre‑render each post page?
2
If you forget to export generateStaticParams from a dynamic route, what will users see when they navigate to a valid slug?
3
After adding a new product ID to your data source, what steps are required for generateStaticParams to include it in the next build?

2-5 years experience

1
You notice that some valid slugs return a 404 after deployment even though generateStaticParams lists them. Walk me through how you’d debug the issue.
2
Explain the trade‑offs between using fallback: 'blocking' versus fallback: true when you have a large number of blog posts generated via generateStaticParams.
3
Your external API used inside generateStaticParams has strict rate limits. How would you redesign the function to stay within those limits while still pre‑rendering needed pages?

5-8 years experience

1
Design a build strategy for an e‑commerce site with tens of thousands of products using generateStaticParams, considering build time, cache invalidation, and ISR.
2
What edge cases can cause stale content when relying on generateStaticParams, and how would you mitigate them in production?
3
Multiple teams own different sections of a monorepo that each need generateStaticParams. How would you coordinate to avoid duplicate data fetching and keep type safety?

8+ years experience

1
Our company is migrating from the pages router to the app router across hundreds of dynamic routes. Outline a migration plan that handles generateStaticParams with minimal downtime and risk.
2
Compare the long‑term SEO and performance implications of heavily using generateStaticParams versus server‑side rendering. What policy would you propose for choosing between them?
3
How would you architect a shared library that abstracts generateStaticParams logic for different domains, ensuring testability, type safety, and easy onboarding for new teams?

Follow-up Questions

❓What does the fallback option do when a path isn’t returned by generateStaticParams?
❓How does generateStaticParams interact with incremental static regeneration?
❓What are the performance considerations of returning a very large param list?