Generate static pages using 'output: export' for full-site export or 'generateStaticParams' with dynamic routes for pre-rendering specific pages at build time
Next.js with the App Router offers two primary approaches for static page generation. You can either statically export your entire application as HTML files for deployment on any static hosting service, or you can use Static Site Generation (SSG) with generateStaticParams to pre-render dynamic routes at build time while keeping your application server-rendered. The App Router automatically handles static optimization without requiring special data-fetching methods like getStaticProps from the Pages Router.
When you set output: 'export' in your Next.js configuration, running next build generates a complete static version of your site in an out folder. With this approach, Server Components are executed at build time, and their output is baked into static HTML files. Client Components still hydrate in the browser. This means you can deploy your Next.js app to any static hosting service like Nginx, Apache, or AWS S3 without needing a Node.js server.
Static export disables features that require a server: API Routes (though Route Handlers with GET can be used), middleware, server actions, and on-demand ISR. Dynamic routes without generateStaticParams will not work because there's no server to generate them at request time. Image optimization also requires either setting unoptimized: true or providing a custom loader for a service like Cloudinary.
At build time, Next.js calls generateStaticParams to get an array of possible route parameters
For each set of params returned, Next.js pre-renders the page by executing the Server Component
Pages are generated as static HTML files (e.g., /blog/hello-world.html) that can be served instantly
Any params not returned by generateStaticParams will result in a 404 or can be handled with fallback options
This approach works with both static export and server-rendered applications
You can combine generateStaticParams with Incremental Static Regeneration (ISR) by setting a revalidate option in your fetch requests or route segment config. This allows you to pre-render the most critical pages at build time while generating others on-demand when first requested. For pages not included in generateStaticParams, set export const dynamicParams = true to allow them to be generated at request time and cached for subsequent visits.
Static Export (output: 'export'): Deploy to any static hosting (Nginx, S3, GitHub Pages). Requires configuring your web server to handle trailing slashes and dynamic routes properly.
Server with Static Generation: Deploy to platforms like Vercel or self-host with Node.js. Static pages are generated at build time but the server remains for API routes and ISR.
For dynamic routes in static export, you may need third-party tools like next-dynamic-exports to handle client-side parameter extraction.
When self-hosting with Nginx, configure rewrites to map requests to the correct static HTML files.
We need a simple product page that never changes. Using the new app router, how would you create the file structure and ensure it’s statically generated?
If you place a component in app/blog/page.tsx without any data fetching, what rendering strategy does Next.js apply?
Which naming convention tells the app router to treat a route as a static page?
Our blog list page should be built at compile time but refreshed every hour from an external CMS. How would you implement that with the app router?
During a recent deployment a page that should be static was rendered on the server at request time. What could cause that behavior?
Explain the trade‑offs between using generateStaticParams versus fetching data inside a component when you want static generation.
We have thousands of product pages. Describe how you would organize static generation in the app router to keep build times reasonable while keeping product data up‑to‑date.
How would you combine Incremental Static Regeneration with dynamic route segments (e.g., [slug]) in the app router, and what edge cases must you guard against?
If we need localized static pages for multiple locales, how would you configure the app router and what performance implications should you consider?
Our organization is migrating a large legacy pages‑router codebase to the new app router while preserving all static‑generation behavior. Outline a migration plan, including how to audit existing getStaticProps and replace them with app‑router equivalents.
Multiple teams need to share common static‑page logic such as SEO metadata generation. How would you design a reusable library or pattern in the app router to enforce consistency across teams?
In a monorepo where some packages generate static pages and others expose APIs, how would you architect the build pipeline to parallelize static generation and avoid bottlenecks?