How to Export a Framer Site Before a Client Handoff

A Framer handoff can look deceptively simple: send a client a URL, share access, and call it done. I prefer to leave them with a portable version of the site too. A static export gives the project a life outside its original editor, which is useful when a client is changing providers, bringing maintenance in-house, or simply wants an archive before a larger redesign.\n\n\n\nThis is the checklist I use to turn a published Framer project into a handoff that another person can understand and test. ExFlow’s Framer exporter is the practical starting point: it packages a published Framer site into static HTML, CSS, JavaScript, fonts, and media so the result can be kept as a ZIP or deployed elsewhere.\n\n## 1. Define what the handoff is meant to preserve\n\nBefore exporting, I write down the handoff target. Is this a safety copy before a redesign? A client-owned archive? A site that will be hosted somewhere else? The answer changes what I test and what I include in the delivery note.\n\nOpen the published production URL in a private browser window and make a short inventory: every public page, any redirect, primary forms, navigation states, embedded media, and the mobile breakpoints that matter. I also record the page title and description for the key pages. A visual comparison is much easier when you know what the original should do.\n\nExpected result: a compact list of pages and interactions that defines success before any files are generated.\n\n## 2. Export the published Framer site\n\nStart the export from the live version of the site, not an old preview link. With ExFlow for Framer, the goal is to collect the rendered site into a conventional static package rather than manually saving browser assets one by one. Keep the export named with the project and date so it is obvious which handoff it represents.\n\nTreat the first export as a build artifact, not as the final handoff. Put it in a clean folder and avoid mixing it with source design files, screenshots, or previous versions. That tiny bit of separation prevents a client from receiving a bundle full of unrelated material.\n\n\n\nExpected result: one self-contained directory or archive with the pages, styles, scripts, fonts, and media needed by the public site.\n\n## 3. Inspect the package before you test it\n\nI check the exported directory before opening a browser. Look for a clear entry page, asset folders, and readable paths. This is also where I catch accidental dependencies: a logo that still points to an old host, a locally referenced image, or a form integration that was never meant to travel with the static copy.\n\nDo not assume that an export makes every third-party service portable. Analytics, form endpoints, commerce flows, account areas, and embedded apps may still rely on their original services. That is normal. The useful handoff note says what was preserved as static content and what needs separate credentials or a replacement integration.\n\nExpected result: you know which parts are standalone files and which parts remain live-service integrations.\n\n## 4. Test it on a static server, not only from a file browser\n\nOpen the package through a small local static server or a temporary static host. Double-clicking an HTML file can hide routing, module, and asset-path problems that appear after deployment. Visit each inventory page, use the main navigation, and test links from both desktop and mobile widths.\n\nFor a client handoff, I test the important path twice: once from the home page and once by pasting a deep page URL directly into the browser. That catches missing files and relative-link assumptions before the client does.\n\n\n\nExpected result: pages, assets, and direct links load from the static package without relying on your original Framer workspace.\n\n## 5. Run a focused visual QA pass\n\nStatic does not have to mean flat. Compare the exported copy against the published site at the breakpoints your audience actually uses. I look closely at motion, web fonts, hero media, image crops, sticky sections, hover states, and any custom scripts. Then I scan titles, descriptions, canonical links, and social preview metadata so a copied site does not quietly lose its search presentation.\n\nIf an animation or interaction does not survive, document it clearly before choosing whether to repair it. A handoff is stronger when it is honest about a limitation than when it appears complete until someone opens it on a phone.\n\nExpected result: a short, reproducible list of passed checks and any known exceptions.\n\n## 6. Deliver it in the format the client can actually use\n\nChoose the destination around the client’s next step. A ZIP is useful for an archive; a Git repository is useful when a developer will own changes; static hosting, S3, or FTP can make sense when the goal is a live independent copy. Include a plain-language README with the original URL, export date, test URL, deployment target, and notes about services that need their own credentials.\n\n\n\nThe handoff should include a deployed preview whenever possible. It gives the client a simple answer to the only question that matters at the end: does this look and behave like the site we approved?\n\n## Troubleshooting common gaps\n\nA font falls back after deployment. Check that the font files are present and that the CSS paths are relative to the deployed site structure. Also confirm that licensing allows the font to be redistributed.\n\nImages work locally but disappear on the host. Check filename casing and asset paths. Case-insensitive local disks can mask errors that a Linux host exposes.\n\nA deep link returns a 404. The hosting platform may need a static routing rule or explicit generated page path. Test the deployed deep URL directly, not only navigation clicks.\n\nA form no longer submits. Static files can preserve the form UI, but the submission endpoint is a separate integration. Add the endpoint or document the required replacement.\n\n## Keep the workflow reusable\n\nOnce this process works, keep the inventory and QA checklist as a repeatable handoff template. The same idea applies beyond Framer: Webflow exports and Squarespace exports benefit from the same clear scope, static-host test, and client-facing notes. Start with the platform the project uses, then make the quality bar portable.\n\nA client handoff should feel calm. A tested static copy gives everyone a durable reference point, even when the next version of the site takes a different direction.