Fix Export encountered errors on following paths in Next.js

TL;DR#

The message is a summary, not a cause. During next build, Next.js prerenders every static page, and each path whose render threw is collected into that list. The real exception, usually a TypeError with a code frame, is printed a few lines above, after Error occurred prerendering page. In the Stack Overflow question, the listed path is /about/undefined: a URL most likely produced by the project's own getStaticPaths, not a page anyone wrote. Fix the code that produces or renders that path, then build again. The three causes from the question and its answers were rebuilt below: the /about/undefined case on Next.js 14.2.35 and 16.4.2, the other two on 16.4.2, each with the single change that makes the build pass.

What the build prints#

The question, from December 2020, shows a Vercel build stopping like this:

15:02:38    > Build error occurred
15:02:38    Error: Export encountered errors on following paths:
15:02:38        /about/undefined

Its author says the site has no page called about and cannot tell what the build is referring to. For Next.js to prerender /about/undefined, some page file under pages/about/ (such as a dynamic route) must exist, so it is worth searching the project for one. The wording depends on the Next.js version, which matters when you search your own log. Rebuilt in Docker (node:20-alpine, Next.js 14.2.35, React 18.3.1) with a pages/about/[slug].js whose paths come from a missing field, the end of the build reads:

   Generating static pages (1/4) 
   Generating static pages (2/4) 
   Generating static pages (3/4) 
 ✓ Generating static pages (4/4)
 
> Export encountered errors on following paths:
	/about/[slug]: /about/undefined
[exit code: 1]

The same project on Next.js 16.4.2 (node:22-alpine, React 19.3.1) never reaches a summary. It stops at the first failing page:

  Generating static pages using 3 workers (0/4) ...
TypeError: Cannot read properties of null (reading 'name')
    at <unknown> (pages/about/[slug].js:14:22)
  12 |
  13 | export default function Member({ member }) {
> 14 |   return <h1>{member.name}</h1>
     |                      ^
  15 | }
  16 |
Error occurred prerendering page "/about/undefined". Read more: https://nextjs.org/docs/messages/prerender-error
TypeError: Cannot read properties of null (reading 'name')
    at <unknown> (pages/about/[slug].js:14:22)
  12 |
  13 | export default function Member({ member }) {
> 14 |   return <h1>{member.name}</h1>
     |                      ^
  15 | }
  16 |
Export encountered an error on /about/[slug]: /about/undefined, exiting the build.
⨯ Next.js build worker exited with code: 1 and signal: null

For a dynamic route, an entry has the form route, colon, concrete URL: /about/[slug] is the file pages/about/[slug].js, and /about/undefined is the URL it was asked to render. A static page, or the fallback render of a dynamic route, is printed as the route alone (/components/Navbar and /about/[slug] in the cases below).

Why it happens#

The prerender-error page of the Next.js docs lists the usual reasons a page throws while it is prerendered: non-page files in the pages/ directory, props that are expected but not available during prerendering, browser-only APIs, and incorrect getStaticProps or getStaticPaths configuration. The summary line itself only reports which paths failed.

Why newer versions print one page and exit comes from the build's source. In packages/next/src/export/worker.ts at tag v16.4.2, a page that fails is reported with "exiting the build" when the experimental prerenderEarlyExit option is on, and the process exits. In config-shared.ts at that tag, the option defaults to true. The same file in Next.js 14.2.35 sets it to false, which is why the 14.2.35 build above went through every page and then printed the list. The summary's wording changed as well: 14.2.35 says "on following paths", while export/index.ts in 16.4.2 counts them ("Export encountered errors on 2 paths", shown further down). Search your log for "Export encountered" rather than the full sentence.

Fix: find the failing path, then the cause#

1. Read the lines above the summary. The first Error occurred prerendering page "<path>" gives the URL, and the stack trace or code frame just before it gives the file and line. In the 16.4.2 output above, that is line 14 of pages/about/[slug].js, where member is null.

2. If the frames are minified (the 14.2.35 log shows frames such as at g (/tmp/app/.next/server/pages/about/[slug].js:1:1044)), the 14.2.35 output gives the URL but not the source line. On Next.js 15.4.0 or later, rebuild with the debug flag documented in the next CLI reference, which lists it as added in v15.4.0 (a 14.x project does not have it). On 16.4.2 the default output above already shows the file, line and code frame; the flag mainly adds the component name and lets the build continue past the first error:

npx next build --debug-prerender

3. Match the path to one of the three causes below and change only that code. Each fix was tested as a single change against the broken version.

The path ends in /undefined: getStaticPaths uses a missing field#

The question does not show its code; the most likely cause, reproduced here, is a dynamic route whose paths are built from a field the records do not have. In this reproduction the records have an id, but the paths are built from slug, so every template literal becomes /about/undefined. The broken file used in the reproduction:

import { team } from '../../data/team'
 
export async function getStaticPaths() {
  // Bug: the records have an `id` field, not `slug`
  return { paths: team.map((m) => `/about/${m.slug}`), fallback: false }
}
 
export async function getStaticProps({ params }) {
  const member = team.find((m) => m.id === params.slug) ?? null
  return { props: { member } }
}
 
export default function Member({ member }) {
  return <h1>{member.name}</h1>
}

getStaticProps then finds no record for the slug undefined, and the component reads .name from null. The fix is the field name in getStaticPaths, nothing else:

export async function getStaticPaths() {
  return { paths: team.map((m) => `/about/${m.id}`), fallback: false }
}

With that one change, the same 16.4.2 container builds both pages:

Route (pages)
┌ ○ /
├ ○ /404
└   /about/[slug]
  ├ ● /about/amelie
  └ ● /about/tomas

When the paths come from a CMS or an API, log the array before returning it. A single record without the field is enough to put /about/undefined in the list.

The path is a component: a file inside pages/#

The answer with 13 votes describes a components folder inside pages. Every file there becomes a route, so pages/components/Navbar.js is prerendered as a page with no props. The docs say it plainly: "You cannot colocate other files (e.g., components, styles) within the pages directory." Reproduced on 16.4.2 with a navbar that maps over a links prop:

Error occurred prerendering page "/components/Navbar". Read more: https://nextjs.org/docs/messages/prerender-error
TypeError: Cannot read properties of undefined (reading 'map')
    at <unknown> (pages/components/Navbar.js:4:14)
  2 |   return (
  3 |     <nav>
> 4 |       {links.map((l) => (
    |              ^
  5 |         <a key={l.href} href={l.href}>
  6 |           {l.label}
  7 |         </a>
Export encountered an error on /components/Navbar, exiting the build.

Moving the unchanged file to components/Navbar.js at the project root made the next build pass. In the App Router this layout is allowed: the same docs page says it permits colocation "of pages and other files in the same folder", and the page.js reference adds that a page file is required to make a route segment publicly accessible.

The path is the dynamic route itself: fallback: true without a loading state#

If the failing entry is the bracketed route (/about/[slug]) rather than a concrete URL, look at fallback. The getStaticPaths reference says that in the fallback version of a page "The page’s props will be empty", and that router.isFallback is true while it renders. The build renders that fallback version too. The fallback runs used correct paths and a getStaticProps that returns notFound for an unknown id:

export async function getStaticProps({ params }) {
  const member = team.find((m) => m.id === params.slug)
  if (!member) return { notFound: true }
  return { props: { member } }
}

With fallback: true and a component that reads member.name with no guard, 16.4.2 failed on the route itself:

Error occurred prerendering page "/about/[slug]". Read more: https://nextjs.org/docs/messages/prerender-error

The answer with 5 votes suggests an isFallback check, but its snippet writes the JSX without return. Rebuilt exactly that way, as a negative control, the build fails with the same Cannot read properties of undefined (reading 'name'), because an expression statement renders nothing and execution falls through to member.name. The guard has to return:

import { useRouter } from 'next/router'
 
export default function Member({ member }) {
  const router = useRouter()
 
  if (router.isFallback) {
    return <h1>Loading...</h1>
  }
 
  return <h1>{member.name}</h1>
}

With the return added and nothing else changed, the build passed.

Verify the fix#

Run the production build again, locally or in the same Node image your host uses, and check the exit code rather than scrolling for the message:

npx next build; echo "exit code: $?"

A passing build prints the route table with every expected path and exits with 0. Compare the ● lines against your data: a missing page means getStaticPaths dropped it, and an unexpected /undefined means a field is still wrong.

Seeing every failing page in one build#

Because a default 16.4.2 build stops at the first failure, fixing one page can reveal the next on the following deploy. The CLI reference says --debug-prerender "Continues building even after the first prerender error, so you can see all issues at once", and the build announces it:

- Experiments (use with caution):
  ✓ allowDevelopmentBuild (enabled by `--debug-prerender`)
  ⨯ prerenderEarlyExit (disabled by `--debug-prerender`)
  ✓ serverSourceMaps (enabled by `--debug-prerender`)
  ⨯ turbopackMinify (disabled by `--debug-prerender`)

The stack frame also names the component (at Member (pages/about/[slug].js:14:22) instead of at <unknown>). The same docs warn not to deploy a build made with this flag. With both bugs above present and experimental.prerenderEarlyExit: false set in next.config.js, 16.4.2 printed both errors and then the summary:

> Export encountered errors on 2 paths:
	/about/[slug]: /about/undefined
	/components/Navbar
[exit code: 1]

When the error above the list is something else#

The list looks the same whatever the page threw, and several causes have their own page here. If the error above it is ReferenceError: localStorage is not defined in a 'use client' component, the localStorage prerender fix explains why Client Components still render on the server and how to read storage in useEffect. A relative fetch('/api/...') during prerendering fails with only absolute URLs are supported. A getaddrinfo ENOTFOUND that appears only inside docker build is a Compose hostname that the build cannot resolve. If getStaticProps returns a Date, the build fails on serialising the prop as JSON before the page renders. And when the only path in the list is /_not-found on Next.js 16, see the /_not-found prerender page.

In every case the path list is the index and the stack trace is the content. Read the first Error occurred prerendering page line, open the file the code frame points at, and change only what that frame shows. The reproduction behind this page used Docker on 19 October 2026: Next.js 14.2.35 on Node 20.20.2, and Next.js 16.4.2 on Node 22.23.3, with Pages Router projects made of the files quoted above plus a one-line pages/index.js and a data/team.js holding two records with id and name fields.