Why a Next.js or Turbopack ZIP fails static-site validation

First prove the project can be a static export

Next.js can emit HTML for each route, but only when the project does not rely on request-time server behavior. Cookies, rewrites, redirects, request-dependent route handlers, Server Actions, ISR, and default image optimization are among the features that do not work in static export mode.

If those features are essential, keep the application on a Next-capable server host. Do not remove necessary product behavior merely to fit a static host.

Primary reference: Next.js: static exports.

Use an explicit static configuration

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "export",
  distDir: "dist",
  trailingSlash: true,
  images: { unoptimized: true },
};

export default nextConfig;

Rebuild without the prohibited Turbopack output

Small Site's static scanner rejects browser code that loads worker scripts because that expands the v1 execution boundary. The production validator gives this repair for affected Next.js packages: rebuild with next build --webpack, then validate the new export before packaging it.

Do not upload .next, the source project, or an old export next to the corrected dist directory. A stale Turbopack chunk anywhere inside the declared output can make the new ZIP fail again.

npx next build --webpack

Package the exported artifact, not the Next project

• The ZIP root contains small-site.json and dist/ only.
• dist/index.html exists and every intended route has exported HTML.
• dist/404.html exists for file routing.
• No .next directory, source maps, server bundle, API route, dependency tree, lockfile, or build script is included.