A Squarespace Static Handoff Checklist for Client Sites

I used to call a Squarespace project handed off when the login had changed hands. That was a soft ending: the client still owned a subscription, and nobody had a portable copy of the thing we had actually built. A better handoff is a tested static copy plus a short record of the services that cannot travel with it. Squarespace’s own content export creates an XML file for supported content; it is useful, but it is not the same as a runnable copy of the rendered site.

For a brochure site or a catalog that can live without a platform checkout, I now use this order: capture the public site, test the copy on its future host, and name every remaining dependency. ExFlow’s Squarespace exporter is built for that capture: it exports the published pages, CSS, JavaScript, and media as static files, then can download a ZIP or send the output to Git, S3, FTP, or ExFlow Hosting. The important qualifier is that static files do not replace server-backed features by magic.

Decide whether a static handoff is the right handoff

A static copy is a strong fit when the client needs a marketing site, lookbook, announcement archive, or mostly informational catalog under their control. It is a weaker fit when the live experience depends on Squarespace Commerce checkout, member areas, scheduling, site search, or form processing. Those are service decisions, not missing files.

Here is the decision note I put at the top of a handoff:

That little split prevents the awkward version of a migration where the visual QA passes and a lead form silently stops landing anywhere. If the client needs a fully platform-native store, keep Squarespace live or plan a real commerce migration. If they only need the public shell to stay available, a static copy can be the clean boundary.

1. Capture the published version, not a work-in-progress

Start with the exact public URL you intend to preserve. A password-protected preview needs its frontend password supplied to the exporter; an unpublished site is not the same thing as a public page someone can crawl. I choose all public pages for a handoff unless there is a deliberate reason to exclude an archive.

In ExFlow, the export job can collect pages, styles, scripts, images, media, and linked public assets, and it can rewrite the copied links for local use. That is the practical distinction from keeping only a content XML: the client receives a site-shaped directory, not a pile of copy waiting to be rebuilt. For the larger context, my earlier note on scoping a Squarespace handoff with a testable static copy explains why I make the testable copy the deliverable.

2. Run the six checks before you call it portable

I do not compare every pixel. I check the routes and assets most likely to make the site feel broken. Open the exported output locally if appropriate, then on the intended staging host. Repeat at one desktop width and one narrow mobile width.

1. Pages and navigation: visit the home page, each main navigation item, footer links, 404 route, and a representative blog or collection page.
2. Media and lazy-loaded assets: scroll long pages and galleries until the lower images load. Check PDF and download links too.
3. Internal and external links: click the logo, primary CTA, in-page anchors, and a few content links. A local path error is easier to fix before DNS changes.
4. Scripts and interactive blocks: try accordions, sliders, cookie notices, embeds, and any custom code injection. Treat a third-party embed as a dependency to verify, not a promised static feature.
5. Metadata and sharing: inspect page titles, descriptions, canonical URLs, social images, and favicon after the target hostname is known.
6. Forms and services: submit a test form only after its replacement endpoint is configured. Record where it should arrive and who owns the credentials.

This is the same impulse behind a browser RAW upload checklist: validate the actual edge cases before announcing that the workflow is done.

3. Choose the deployment path that matches the client

The export is only half the handoff; someone still needs a sensible place to serve it. I pick the lightest option the client can maintain.

• ZIP archive: good for a dated backup and a client-owned source package.
• Git: good when the team wants version history, reviews, or a continuous-deployment host attached to a repository.
• S3-compatible storage: useful when the client already has cloud infrastructure and someone can own access and cache settings.
• FTP/SFTP: sensible for an existing traditional hosting account.
• Managed static hosting: practical when the client does not want to operate deployment plumbing.

ExFlow supports a ZIP download and deployment or sync targets including Git, S3, FTP, and its own hosting path. The tool does not make the choice for you; the decision is about who will update the files and who receives an alert if the domain, certificate, or form integration fails.

4. Hand over a one-page operations note

The folder alone is not a handoff. I include a small README or shared note with these fields:

Live URL:
Static hosting URL:
Source of truth for future edits:
Deployment owner:
Domain and DNS owner:
Form endpoint and inbox owner:
Analytics / cookie tools still installed:
Last verified date:
Rollback location:

It reads almost too basic, but it makes a support request answerable months later. If a client expects ongoing edits in Squarespace, say that plainly: a static export is a snapshot, so a new live change needs a new export and deployment. I use the same “state the source of truth” habit when making Notion the source of truth for a CMS; ownership is what turns a file transfer into a maintainable system.

The small next step

Pick one completed Squarespace site this week and make a dated static copy before there is a redesign, cancellation, or rushed client handoff. Run the six checks, write the operations note, and store both beside the client record. If the copy has to become a new hosted site, start the Squarespace export in ExFlow with the public URL and choose the destination your client can actually maintain.

ExFlow also has dedicated exporters for Webflow and Framer, but I would keep the same rule across all three: export the visible site, test it where it will live, and document the services the static files cannot carry.