AI Artifacts & Generated Sites

Static Export

Definition

Frameworks normally expect a Node process in front of them, handling requests, rendering pages and answering API calls. A static export removes that process: the build renders every page it can work out in advance and writes the result to a folder. Next.js does this with output set to export, producing an out directory; Nuxt has generate; Astro, Vite, SvelteKit with the static adapter, Hugo, Jekyll and Eleventy all write to dist or public by default. The folder is the deliverable — you upload it and the host serves each file at its path. What disappears is everything decided at request time, which is why a project that runs fine in development can fail its export outright, with the build telling you which feature is incompatible.

Why It Matters

The saving is substantial. Static files sit on a CDN, cost nothing to serve, survive traffic spikes and have no runtime to patch or restart; a modest server-rendered site costs money every month and can fall over on a good day. The risk is discovering a dependency late. Teams regularly export a site only to find that the search box called an API route, and that route no longer exists — a fifteen-minute job becomes two days of rework. Check what the project actually uses before promising a static deploy: one API route or one dynamic redirect is enough to make the export the wrong shape for the site you have.

How It Works

Run the export build and read what it refuses. Server components that render per request, API routes, middleware, on-demand revalidation, server actions and anything reading request headers or cookies all fail or are silently skipped, because there is nothing left to run them. Image optimisation is the usual surprise: the built-in loader in Next.js needs a server, so exports require the unoptimized flag or a third-party loader. Dynamic routes must be enumerated at build time — generateStaticParams for Next, a comparable hook elsewhere — or those pages are never written. Redirects, rewrites and custom headers declared in the framework config are the server's job too, so they have to be reproduced by the host. Finally, decide how URLs look: a trailing-slash export writes about/index.html, while the other mode writes about.html, and a host that expects one and receives the other returns 404s across the site.

Real-World Example

A studio exports a Next.js marketing site to the out folder — eleven pages, 2.4 MB with images. They zip it, upload it to 99helpers, and it answers at hollow-studio.99helpers.site with every page at its own path. Two things had to change first: next/image was switched to unoptimized, and the newsletter form, which had posted to an API route, now posts to an external form service instead. Nothing else about the site was different from the server-rendered version.

Common Mistakes

  • Exporting a project that still contains API routes — the build either fails or drops them, and every feature that called them breaks with no visible error
  • Leaving the default image loader on — Next.js refuses to export until images are set to unoptimized or a loader that does not need a server is configured
  • Forgetting generateStaticParams for dynamic routes — the section builds with zero pages and the whole path 404s, which is easy to miss if you only test the home page
  • Relying on framework redirects after export — they lived in the server config, so old links go nowhere until the host is configured to handle them

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →