getStaticPaths offers three fallback options: false, true, and 'blocking' that control how non-pre-rendered paths are handled
In the Next.js Pages Router, the fallback option in getStaticPaths determines what happens when a user requests a dynamic route path that wasn't pre-rendered at build time. This is essential for balancing build speed, user experience, and SEO when dealing with large sites where pre-rendering every possible path is impractical. The three options—false, true, and 'blocking'—offer different trade-offs between showing content immediately and generating pages on-demand.
Behavior: Any paths not returned by
getStaticPathswill result in a 404 page .Use Case: Ideal for small sites with a fixed, known set of content that doesn't change often, like a personal blog with 20 posts .
Advantages: Fastest build time for the paths that are generated; simple and predictable behavior .
Disadvantages: Not suitable for large sites; new content requires a full rebuild .
SEO Impact: 404 pages are properly returned, which is fine for non-existent content but problematic if new content is added frequently .
Behavior: Shows a fallback version of the page immediately while generating the full page in the background. Once generated, the page is cached and future requests get the static version .
Use Case: Large e-commerce sites with thousands of products where you want to pre-render popular items but still support long-tail content .
Advantages: Fast initial page load (shows fallback UI), supports infinite content without rebuilding, good user experience .
Disadvantages: You must handle a loading state in your component; slightly more complex implementation .
SEO Impact: The fallback page isn't considered a valid page by search engines, but once generated, the full page is indexable .
Behavior: The user waits for the server to generate the page on the first request. No fallback UI is shown; the request blocks until the page is generated, after which it's served and cached .
Use Case: SEO-critical pages where you don't want search engines to see a loading state, like product pages that need to be indexed immediately .
Advantages: Better for SEO since crawlers never see a fallback state; simpler component code (no need to check
router.isFallback) .Disadvantages: Slightly slower first-page load for new paths as the user waits for generation to complete .
Behavior with ISR: When combined with
revalidate, the page will be served from cache after the first generation, then revalidated in the background .
| Option | First Visit | Subsequent Visits | SEO | Use Case | |--------|-------------|-------------------|-----|----------| | false | 404 immediately | 404 | ❌ No page | Fixed, small sites | | true | Fallback UI → background gen | Static HTML | ⚠️ Fallback not indexed | Large sites, good UX | | 'blocking' | Waits → generated page | Static HTML | ✅ Full page indexed | SEO-critical, large sites |
Combining with ISR: All fallback options work with
revalidatefor Incremental Static Regeneration. Pages generated on-demand can also be updated periodically .Error Handling: Always check if data exists in
getStaticPropsand return{ notFound: true }for missing content to show 404 pages appropriately .Performance Impact: With
fallback: true, the first user to request a non-pre-rendered page triggers the generation. Consider pre-rendering popular paths to avoid slow first experiences .App Router Equivalent: In the App Router, use
generateStaticParamswithdynamicParamsexport (true/false) - there's no direct 'blocking' equivalent as Server Components naturally handle this .Caching Behavior: Generated pages are cached according to your
revalidatesetting and CDN configuration. The first generation might be slow, but subsequent requests are fast .