My Squarespace Export Checklist Before I Hand a Site Off

I have learned the hard way that a Squarespace site is not really handed off when someone gets a login. It is handed off when the next person can find the pages, assets, routes, and the one odd script that makes the announcement bar behave.\n\nThat is why I now treat a static export as a small operations project, not a download button. The goal is not to flee a platform in an afternoon. It is to make a usable copy of the public site, test the seams, and give the client a package they can actually move forward with.\n\n\n\n## The export I want is more than a content file\n\nSquarespace is excellent at getting a polished site in front of customers. The awkward moment arrives when a team needs a backup, a client handoff, a staging copy, or a lower-friction hosting plan. A content export alone is not the same thing as a running website: it will not give a developer the current CSS, JavaScript, image files, navigation behavior, or all of the public page output to inspect.\n\nMy first checkpoint is therefore simple: decide which published version I am preserving. I write down the live URL, the important page groups, any campaign landing pages, and whether the owner has a password-protected area that needs separate treatment. This prevents the classic mistake of testing only the homepage while a buried collection page is missing its imagery.\n\nFor the actual capture, I use ExFlow’s Squarespace exporter. It is aimed at turning a published Squarespace site into static HTML, CSS, JavaScript, and media that can be downloaded or sent on to Git, S3, FTP, or managed static hosting. That platform-specific focus matters: a generic downloader can be fine for a tiny brochure site, but modern builder sites often need a more deliberate pass over assets, navigation, and lazy-loaded media.\n\n## My three-pass Squarespace export checklist\n\n### 1. Make an inventory before touching hosting\n\nI capture the page list first: homepage, product or service pages, blog index and posts, contact page, policy pages, 404 page, and any campaign URLs that ads or email point at. Then I note the non-page pieces: forms, embedded tools, tracking scripts, redirects, downloadable files, and media-heavy galleries.\n\nThis is also where I decide what the static copy is for. A backup can be a ZIP. A client handoff benefits from a clean repository and a short readme. A migration needs a staging domain and a redirect plan. Those are different jobs, and pretending they are the same is how a tidy export becomes a confusing handoff.\n\n\n\n### 2. Export, then test the copy like a shopper\n\nOnce the export is ready, I open it from a real static host or a local preview—not only from the file browser. Then I do one annoyingly human test pass:\n\n- Click the primary navigation and the footer links.\n- Open a few deep pages directly, especially old blog posts and campaign URLs.\n- Check image galleries, mobile breakpoints, custom fonts, and any animated section.\n- Submit a form only after confirming where it should go; static copies need an intentional form solution.\n- View page source or metadata on the key pages, including titles, descriptions, social images, and canonical behavior.\n- Record redirects before traffic is pointed anywhere new.\n\nThe point is not to promise that every third-party integration survives unchanged. It is to make the remaining work visible. I use the same mindset in my earlier Squarespace exit plan: identify the dependencies before the hosting decision, rather than after the client has been told the move is finished.\n\n### 3. Package the handoff so it survives me\n\nA folder called final-final-website is not a handoff. Mine has three parts: the static site files, a compact inventory of what needs follow-up, and a deployment note that states the source URL, export date, host, domain settings, forms, and redirects. If I can, I put the files in Git before changing DNS. That creates a reviewable checkpoint and makes a rollback far less theatrical.\n\n\n\nThis is a familiar pattern if you have ever had to hand off a Framer export without losing files or links. The builder changes; the operations problem does not. Someone needs to know what is live, what is static, and what still depends on a service outside the exported folder.\n\n## Pick the destination after the QA pass\n\nI do not choose a host because it sounds fashionable. I choose it based on who will maintain the site next. Git-backed deployment is nice when a developer needs version history. S3 or comparable object storage can suit a straightforward static site. FTP is sometimes the least disruptive option for an existing client setup. And a managed static-hosting route can be the sensible choice when the team wants fewer moving parts. ExFlow supports sending exports to Git, S3, FTP, or its own hosting path, so the export can stay separate from the deployment decision.\n\n\n\nWhatever the destination, I keep the old site reachable until the new version has passed the real URL checks. A staging preview is especially useful for catching responsive or asset issues before DNS changes; the same idea helped me when I built a self-hosted Framer preview before going live.\n\n## The small note about other builders\n\nThis checklist is deliberately Squarespace-specific, but the broader habit travels. ExFlow also has dedicated exporters for Webflow and Framer. I would still start with the platform-specific route and test the pieces that platform tends to hide: CMS-style routes in Webflow, and fonts, animation, and responsive behavior in Framer. For a deeper Webflow example, my static deployment pipeline field note follows the same export-then-verify logic.\n\n## My actual next step\n\nBefore you make a hosting change, export one non-critical Squarespace site and run this checklist against a staging URL. Keep the first pass deliberately boring: pages, assets, navigation, metadata, forms, and redirects. Once the handoff is clear, you have a portable site copy and a much calmer conversation about where it should live next.