If part of your Framer site uses page-level password protection — a client preview area, a private portfolio section — exporting requires actually thinking through how that protection gets replaced, since it doesn't come along automatically.
Why it doesn't survive a static export
Framer's password protection is enforced server-side, as part of Framer's hosting — a request for a protected page checks credentials before the content is served. A static HTML export is, definitionally, just files — there's no server-side gate built into plain static hosting to check a password against before serving a file.
What actually replaces it, by export type
Static HTML export: You'll need hosting-level protection instead of page-level. Most static hosts (Netlify, Vercel, Cloudflare Pages) support HTTP Basic Auth or similar access controls at the deployment level — coarser than Framer's per-page protection (it typically protects the whole deployment or a whole directory, not one specific page among many public ones), but functional for a genuinely private section.
Next.js export (runtime-intact): Keeping Framer's runtime doesn't bring the protection along — the password check happens on Framer's servers, as described above, not in the runtime. And a converter that reads public URLs, as FNJ's does, can't capture a protected page at all, so plan to protect that route yourself, as below.
Next.js export (JSX/code-based): You'd implement your own auth check — even something simple like a middleware function checking a password against an environment variable before serving that specific route — genuinely more setup than Framer's built-in toggle, but gives you precise, per-page control rather than protecting an entire deployment.
The realistic recommendation
If you only need to protect one or two pages and the rest of the site should stay fully public, a Next.js export with a small custom auth check on just those routes is the most precise fit. If the entire section you're exporting is meant to be private (a whole separate portfolio subdirectory, say), hosting-level Basic Auth on that specific deployment is the fastest to set up correctly.
Either way — test the protected page specifically after any export. It's exactly the kind of thing that's easy to overlook while checking that the public pages all look right, and the failure mode (a "private" page that's actually now publicly accessible) is a genuinely bad one to discover late.
If you need member logins rather than one shared password, does Framer have user login? covers the membership tools that work with Framer and the code route after export.
Starting a new site instead? FNJ's AI website builder designs one from a description and a site you like, then gives you the code to host anywhere.
