How to Hand Off a Squarespace Site as Static HTML

A Squarespace handoff goes wrong when the client receives a login and a vague promise that everything is ‘in there.’ A better handoff is a working copy of the public site, a place to host it, and a short record of what still needs a live service. That gives a small team something useful when a redesign starts, an account changes hands, or the original subscription becomes the wrong fit.

ExFlow’s Squarespace exporter is built for that job: it can collect a published Squarespace site as static HTML, CSS, JavaScript, images, and media, then let you download a ZIP or send the output to Git, S3, FTP, or ExFlow Hosting. The important word is published. Treat this as a preservation and deployment workflow for the visitor-facing site—not a magic migration of every editable Squarespace control.

1. Define the handoff before you export

Start with one question: what must the next person be able to do without you? The answer is usually one of three things: put the current marketing site somewhere safe, publish it on a new host, or review it while a rebuild happens elsewhere. Each needs a different package, but all start with the same inventory.

Make a route list from the live navigation, footer, campaign links, and CMS-driven pages. Include the unglamorous pieces: 404 page, policy pages, search-result URLs, downloadable files, image-heavy case studies, and any page shared in ads or email. Note the site’s current domain, analytics tags, form destination, and redirects. This takes fifteen minutes and prevents the classic ‘we exported the homepage’ handoff.

If a redesign is coming, this route list becomes a much better safety net than a folder named final-final-2. The same idea is useful in a Webflow staging-copy workflow: preserve the version visitors can actually reach before changing the source.

2. Export the public site into a portable build

Run the export against the published Squarespace URL. With ExFlow, the aim is a static package containing pages and the resources they call: styles, scripts, fonts where available, images, and media. Save the downloaded ZIP untouched as the archival copy, then unpack a separate working copy for inspection and deployment.

A generic site copier can be fine for a tiny brochure page. It gets less reassuring when the site has lazy-loaded media, template scripts, responsive images, or many routes. Use a platform-aware exporter when the handoff has to resemble the original site rather than merely capture a few screenshots.

The deliverable should have a boring, obvious structure: one dated archive, one deployable directory, a route inventory, and a short readme. Boring wins here. It means a client can find the source package six months from now without asking which of twelve folders is real.

3. Test the copy like a visitor, not a file browser

Before sending the package anywhere, serve or deploy the static output somewhere non-public and walk the visitor paths. Don’t stop at whether an HTML file opens locally. Check these five things:

1. Routes and internal links: navigation, footer, campaign pages, and deep links should land on the expected page.
2. Assets: inspect high-resolution images, background media, fonts, favicon, and downloadable files on a normal connection and a phone.
3. Responsive layout: test the primary landing page, a long page, and a CMS-style listing at narrow and wide widths.
4. Interactive pieces: note what happens to forms, search, member areas, bookings, commerce, embeds, and consent tools. A static export may preserve the interface but not the hosted service behind it.
5. Metadata and redirects: check page titles, descriptions, social previews, canonical behavior, and any old URLs that still matter.

This is where the handoff becomes honest. Mark every live dependency in the readme rather than pretending the static copy is a drop-in replacement for a database or third-party workflow. That makes the limitations actionable instead of surprising.

4. Pick the deployment path that matches the owner

For a client who wants an emergency copy, the ZIP plus a documented static host may be enough. For a team that expects periodic updates, sync the output to Git so changes are versioned and deployment is repeatable. If the infrastructure already uses object storage or a traditional server, S3 and FTP can be practical targets. ExFlow also offers a managed hosting route when the goal is to keep the publishing path small.

Keep DNS changes separate from the first technical handoff. Publish the static copy on a temporary URL, verify the route list, and only then plan a domain cutover. That sequence leaves you with a reversible test instead of a tense afternoon of cache-clearing.

5. Leave a handoff note a real person can use

A good note fits on one page. Include the original site URL, export date, where the archive lives, deployment target, domain/DNS owner, the command or button path for future exports, and the dependencies that require separate credentials. Add the three visitor paths you tested and a contact for unresolved services.

If the project later moves away from Squarespace entirely, the same discipline carries over. Our guide to archiving a retired Webflow CMS collection as static HTML shows the value of defining what needs to survive before taking the platform away. And if motion is the risk, this Framer-to-GitHub Pages export checklist is a useful reminder that visual QA needs to cover behavior, not just page count.

ExFlow also has dedicated exporters for Webflow and Framer, but keep the first pass platform-specific. A Squarespace handoff should begin with the live Squarespace site, its routes, and its real dependencies.

The next action is simple: make the route inventory, export one current copy with ExFlow for Squarespace, and test it on a temporary host before anyone needs it.