What are the fallback options in getStaticPaths?

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.

Basic getStaticPaths Structure with Fallback

Fallback Option 1: false

1
Behavior: Any paths not returned by getStaticPaths will result in a 404 page .
2
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 .
3
Advantages: Fastest build time for the paths that are generated; simple and predictable behavior .
4
Disadvantages: Not suitable for large sites; new content requires a full rebuild .
5
SEO Impact: 404 pages are properly returned, which is fine for non-existent content but problematic if new content is added frequently .

Example with fallback: false

Fallback Option 2: true

1
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 .
2
Use Case: Large e-commerce sites with thousands of products where you want to pre-render popular items but still support long-tail content .
3
Advantages: Fast initial page load (shows fallback UI), supports infinite content without rebuilding, good user experience .
4
Disadvantages: You must handle a loading state in your component; slightly more complex implementation .
5
SEO Impact: The fallback page isn't considered a valid page by search engines, but once generated, the full page is indexable .

Example with fallback: true

Fallback Option 3: 'blocking'

1
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 .
2
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 .
3
Advantages: Better for SEO since crawlers never see a fallback state; simpler component code (no need to check router.isFallback) .
4
Disadvantages: Slightly slower first-page load for new paths as the user waits for generation to complete .
5
Behavior with ISR: When combined with revalidate, the page will be served from cache after the first generation, then revalidated in the background .

Example with fallback: 'blocking'

| 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 |

Important Considerations

1
Combining with ISR: All fallback options work with revalidate for Incremental Static Regeneration. Pages generated on-demand can also be updated periodically .
2
Error Handling: Always check if data exists in getStaticProps and return { notFound: true } for missing content to show 404 pages appropriately .
3
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 .
4
App Router Equivalent: In the App Router, use generateStaticParams with dynamicParams export (true/false) - there's no direct 'blocking' equivalent as Server Components naturally handle this .
5
Caching Behavior: Generated pages are cached according to your revalidate setting and CDN configuration. The first generation might be slow, but subsequent requests are fast .

Complete Example with Error Handling