A multi-page site usually means a router and a server. Prompt patterns that give you real pages — Home, Pricing, About — inside one self-contained file or one ZIP you can drop at a private link.
You prompt for "a small site — home, pricing, about." The AI builds something good. You open index.html straight from the folder to check it, and you get the home page and three dead links. Click Pricing: blank, or a 404. Nothing is corrupted. The model gave you separate routes that only resolve when a server is sitting in front of them — and there's no server, just you double-clicking a file.
That's the specific failure of asking for a multi-page site and expecting one sendable thing. A single page comes back as one file you can drop anywhere. The moment you say "multi-page," the model reaches for routing, and routing — by default — means a host. You wanted a few pages to drop at a private link and send to one person. You got a project that expects npm run dev.
The gap is in the prompt, not the tool. "Multi-page" and "one bundle" sound like opposites — more than one page, but a single thing to share. They aren't. You just have to tell the model which routing model to use.
A page, to an AI builder, is a route. Routes get resolved by something — Next.js matches the path on a Node server, React Router rewrites it in the browser but still assumes a host that serves index.html for every path, file-based frameworks map /pricing to pricing.tsx at build time. Every one of these assumes a server or a deploy platform sitting between the visitor and the files.
That assumption is correct when the site gets deployed and maintained. It's exactly wrong when the deliverable is a file you hand to someone. Their browser opening a folder has no server to match /pricing, so the route 404s or silently shows nothing — the three dead links.
So the fix isn't "make fewer pages." It's "use a routing model that needs no server." There are two, and they produce two different kinds of bundle.
Everything — every page — lives in one .html. Navigation swaps the visible view by changing the URL hash (#/pricing, #/about) rather than fetching a new document. The browser never leaves the file; a tiny script shows and hides the right section. Links look normal, the back button works, each "page" has its own URL you can share directly.
The prompt has to say this in plain terms:
Build a multi-page site as a single self-contained HTML file. Pages: Home, Pricing, About, Contact. Use client-side hash routing — each page is a full view inside the one file, and the nav switches pages by URL hash (#/pricing). No server, no framework router, no separate files. The back button and direct links to #/pricing must work. Open from a folder with no web server and every page resolves.
The clauses that matter are hash routing (not history/pushState routing, which needs a server to serve the same file for every path), single file, and the verification line — opens from a folder, no server. Leave the last one out and the model tends to reach for pushState, which breaks the instant the file is opened directly — the same three dead links, one layer down.
Across tools, the framing carries:
fetch or a pushState in.This shape is best when the pages share a layout and the total weight is modest. One file, nothing to extract, every page a real URL.
Once the AI ships the single file, drop it at a private link and click through #/pricing, #/about on a different network before you send it — the fastest way to catch a route that only worked on your machine. No card, no account, 7-day self-destruct.
The other bundle is a folder. Each page is its own .html — index.html, pricing.html, about.html — and they link to each other by relative path (<a href="pricing.html">). Zip the folder; that's the bundle. No router at all, because each file is a real document the browser loads directly.
Build a multi-page site as separate HTML files that link to each other by relative path — index.html, pricing.html, about.html, contact.html. No router, no framework. Every link uses a relative href (href="pricing.html"), no leading slash, no absolute URL. Shared CSS in one styles.css all pages reference. The whole thing should work opened from a folder and packaged as a ZIP.
Two things break this if unspecified, so name them: relative hrefs with no leading slash (a /pricing.html looks for the file at the drive root and fails from a folder), and a shared stylesheet so four pages don't each carry a duplicate copy of the CSS.
This shape is better when pages are heavy or genuinely independent — a docs site, a multi-section microsite, a portfolio where each project is its own page. You don't load everything at once; each page is fetched only when visited. The trade is that it's a folder, not a file, so it travels as a ZIP rather than a single attachment.
The deciding question is how separate the pages really are.
Both are one bundle. Both need no server. Both render from wherever they land — a private link, a colleague's laptop, a flight. The choice is page weight and independence, not capability.
A host that takes either shape matters here: a single self-contained .html is one upload, and a ZIP of linked pages is another. If you're sending a site rather than a file, you want a private link that serves a multi-page bundle without standing up a deploy pipeline for it.
A bundle is static. Every page is content fixed at the moment of generation — that's the whole reason it can travel as one unit with no server.
So the boundary is sharp: the moment any page needs to do something server-side — a login, a signup form that writes to a database, a dashboard reading live data, personalized content — it's an application, not a multi-page bundle. That belongs on a real deploy platform. Vercel, Netlify, and Cloudflare exist for exactly this: server-rendered routes, edge functions, a database behind the pages. For an app, take the framework-routed output the AI gave you first and deploy it there. Don't fight a bundle into doing a server's job.
The honest split:
Most "small multi-page sites" people actually want to send — a pricing-and-about set, a product microsite, a docs pack — sit on the static side. They never needed the server the AI reached for. They needed the prompt to say so, and a bundle to carry them. When the file is portable and the routes resolve from a folder, where it lives is the last small decision: a private link for one receiver, a searchable page for reach.
AI gives you a dark mode that flashes white, forgets the toggle, and hardcodes one shade of gray everywhere. The token-first prompt that makes theming survive in a single self-contained HTML file.
A self-contained HTML file means the images travel inside it, not as links. The prompt wording that makes an AI base64-encode assets on the first pass — plus the size budget, what to inline, and what to leave alone.
Most AI-built HTML looks right on screen and breaks the moment someone hits Ctrl+P. The exact prompt clauses, CSS hooks, and a ninety-second verification pass that make a page export to PDF cleanly the first time.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.