review-static-export

Audit your Next.js app for static export readiness by scanning for server-only APIs in client code, implicit SSR usage like headers(), and environment variable exposure that would break the build. Verify build-time data loading patterns to ensure no runtime dependency on server artifacts exists.

Next.js static export fails because headers and cookies are request-scoped server APIs that require a runtime server environment. Static pages are generated at build time, so you must remove these implicit SSR assumptions and switch to build-time data loading patterns to fix the compatibility issue.

You cannot use fs and path for runtime IO in client components with output export because static export eliminates server runtime features. You must replace dynamic server-side file operations with build-time data loading or generateStaticParams patterns to make the site compatible.

Prevent environment variable exposure by separating secrets needed only at build time from values exposed to the client bundle. Audit your code to ensure secrets are not accidentally exposed via NEXT_PUBLIC_ prefixes, keeping sensitive data out of the static output.

Routing features that rely on dynamic server-side rendering or request-scoped data are incompatible with static export. You should verify dynamic features against your Next version docs and use generateStaticParams to pre-render dynamic routes at build time instead of relying on server APIs.