Framer Static Handoff: The Release Receipt I Require Before DNS

I do not call a Framer handoff finished when the design looks right in the editor. I call it finished when I have a static build I can deploy, a short list of checks that prove it behaves like the live site, and a record of what changed. If you need to move a Framer site to static hosting, export the published site, test the things customers actually touch, and keep a redirect map before changing DNS.

That is why I start with ExFlow’s Framer exporter: it turns a published Framer URL into static HTML, CSS, JavaScript, fonts, and media, with options to download a ZIP or send the output to Git, S3, FTP, or managed hosting. It is a handoff artifact, not just a backup.

The release receipt is smaller than a migration plan

A migration plan can become a small novel. A release receipt should be something another person can run in 20 minutes. Mine has four columns: what was exported, where it will run, what I tested, and what is deliberately out of scope.

Receipt line	What I record	Why it matters
Source	Published Framer URL and export timestamp	Ties the static copy to a real release
Destination	Repo, branch, host, and preview URL	Makes the deploy path repeatable
Route inventory	Home, collection/detail pages, legal pages, campaign landing pages	Stops an important page disappearing quietly
Exceptions	Forms, analytics, gated pages, server-side integrations	Prevents a visual pass from becoming a false sign-off

This is particularly useful for a storefront-adjacent marketing site. A campaign page may look fine at the root URL while a product-comparison page, a UTM link, or a mobile menu is broken. The receipt makes those risks visible before a domain change turns them into support tickets.

Export the published Framer site, then inspect the folder

Framer sites commonly rely on client-side JavaScript, hosted fonts, media, and motion. A generic downloader may capture the first HTML response without capturing everything the browser requests after the page loads. ExFlow says its Framer flow loads the published site in a browser, captures its resources, rewrites them to local paths, and includes pages, assets, fonts, and JavaScript bundles. Its export notes also make the important boundary clear: Framer server-side features, including native form handling and platform-tied analytics, need a replacement when you self-host.

My first pass is deliberately boring:

1. Enter the published Framer URL in the Framer export workflow.
2. Export all pages plus CSS, JavaScript, images, media, and fonts.
3. Download the ZIP or connect the deployment target you already use.
4. Put the output on a preview hostname before touching the production domain.
5. Commit the export to a dedicated release branch so the exact handoff is recoverable.

A ZIP is useful for a client archive. A Git destination is better when a developer needs a reviewable change set or the host deploys from a repository. For a related workflow, I use a Webflow collection export receipt for the same reason: the build is only useful once someone can prove which routes were checked.

Test behavior, not just pixels

I test the preview on a real phone and a desktop browser, but I keep the list focused. Here is the smallest QA pass I would accept for an ecommerce or SaaS marketing site:

• Open the homepage, a deep page, and at least one page reached through the main navigation.
• Resize through the breakpoints that matter to your traffic; check the menu, product cards, and CTA buttons.
• Confirm custom fonts load and that image and video URLs return successfully.
• Trigger the interactive pieces: tabs, accordions, hover states, scroll animation, and any carousel.
• Click every primary CTA and verify tracking or the replacement analytics event.
• Submit each form to its new endpoint and confirm the confirmation and notification path.
• View source or inspect the deployed HTML for title, description, canonical URL, Open Graph image, and robots directives.

This is where a static handoff earns its name. If the site depends on a platform form endpoint, a newsletter embed, or a scheduled data fetch, the export cannot magically recreate that server behavior. Decide whether you are replacing it with an external form service, a serverless endpoint, or a different workflow. I used the same separation when documenting how to reconnect a Framer contact form after moving to static hosting: visual fidelity and operational behavior are separate checks.

Map old URLs before DNS changes

The most expensive missing file is often not an image; it is a route that already has links, ads, or search traffic. Create a two-column redirect sheet before the cutover: old path, intended new path. Add a status column for pages you intentionally retire.

Google’s redirect guidance recommends permanent server-side redirects when a move is permanent, which is the right default for a route you want search engines and visitors to treat as relocated. Do not use a JavaScript redirect as a convenient substitute if your host can issue a 301 or 308.

My cutover sample looks like this:

text\n/collections/spring -> /spring/ permanent\n/shopify-setup -> /guides/setup/ permanent\n/old-promo -> retired deliberate 404/410 decision\n

For a broader safety net, pair the redirect sheet with a Squarespace rollback kit and a Framer static-export checklist. The platform differs; the failure mode does not: changing DNS before you can roll back is an unnecessary gamble.

Make the handoff useful to the next person

Before sign-off, I attach three things to the ticket: the preview URL, the release receipt, and the rollback instruction. Then I ask the developer or client to open one route they own. This catches assumptions faster than another round of internal clicking.

If you want the simplest next step, run a free export with ExFlow for Framer, deploy it to a preview destination, and complete the four receipt lines above. ExFlow also has dedicated Webflow and Squarespace exporters, but keep this handoff platform-specific: export first, test the real behavior, map routes, then change DNS.

A static Framer site is not automatically a complete replacement for every hosted feature. It is a concrete, deployable release artifact once you have named and tested the pieces that still need an owner.