I Build a Squarespace Static Handoff Before the Client Asks

I learned the hard way that a Squarespace handoff is not complete because the client has an admin login. That is access, not portability. When a campaign ends, an agency relationship changes, or someone asks for a backup before a redesign, the useful deliverable is a working copy they can keep, inspect, and deploy.

That is why I now build a static handoff before the client has to ask. It has made migrations calmer, client offboarding cleaner, and the question of where a site lives far less emotional.

Decide what the handoff has to solve

A static copy is not a replacement for every Squarespace feature. It is a practical answer to a specific operating problem: the client needs a faithful, browseable version of the published site outside their hosted account. For a brochure site, launch page, portfolio, or completed campaign, that can be exactly the right level of independence.

Before I export anything, I write down the handoff goal:

a frozen backup before redesign work starts
a version the client can self-host to control ongoing hosting costs
a client-owned archive for a finished engagement
a staging copy for a migration or domain cutover
a static package a developer can extend without rebuilding every public page

That small decision prevents the usual mess where one person expects a backup and another assumes they are getting a live CMS, form inbox, and editable page builder. If the goal is a portable website, scope it as one.

Export the published site, not a wish list

Squarespace makes it easy to ship a polished site, but the underlying files are not normally handed to you as a portable website. I use the Squarespace exporter from ExFlow when I need a static copy of the published site: HTML, CSS, JavaScript, images, media, and the pages that visitors actually see.

The workflow is straightforward:

Start with the published URL and note any password protection. ExFlow can work with password-protected Squarespace sites when the owner supplies the password.
Export the full public site rather than cherry-picking the homepage. Navigation is where incomplete exports reveal themselves.
Download the ZIP for an archive, or sync the output to Git, S3, or FTP when the handoff includes deployment.
Keep a copy of the export configuration with the project folder. Six months later, that is more useful than a vague message saying “we saved it somewhere.”

I treat this like the publishability gate I use before syncing content between systems: no next step until the current asset can be checked by someone other than the person who made it.

QA the parts that break quietly

A download finishing successfully is not proof of a clean handoff. Modern builder sites often have lazy-loaded media, navigation behaviors, analytics scripts, and third-party embeds that only show their problems when the site is opened elsewhere.

My minimum QA pass covers:

every top-level navigation link and key internal path
images, video, fonts, and any media that loads after scrolling
mobile layouts at the breakpoints the client actually uses
page titles, descriptions, social images, and canonical tags
scripts, cookie tools, embeds, and interactive blocks
contact forms, newsletter forms, and any other workflow that depends on a hosted service
redirects for pages likely to have old links or paid traffic

Forms deserve a separate note in the handoff. A static export can preserve the form interface, but the receiving service still needs a destination. I flag that explicitly instead of quietly letting a client discover it after launch. The same discipline helped when I rehearsed a Squarespace domain cutover: deployment is not the moment to find out which operational pieces were tied to the previous host.

Make the handoff versioned and deployable

A ZIP is necessary, but it is not the whole handoff. I also prefer a versioned copy in Git when the site is likely to keep changing. That gives the client or their developer a clear source of truth, a history of changes, and a deployment path that does not rely on the old account.

For a simple site, the choices are usually practical rather than glamorous:

Git-backed static hosting for version history and repeatable deployments
S3 or similar object storage when the team already owns cloud infrastructure
FTP for an existing traditional host
ExFlow Hosting when the client wants the simplest managed static route

The right answer depends on who will own the next change. I do not put a nontechnical client on a workflow that requires a developer for a one-line update unless that trade-off is clearly intentional. For comparison, the same planning mindset matters when I export a Webflow CMS site before a redesign: portability only helps when the next operator knows where the source lives and how it gets live.

Give the client a handoff they can understand

The best handoff package is boring in a good way. Mine contains the static ZIP, the deployed URL if there is one, repository or host access details, the original Squarespace URL, a short QA record, and a list of anything that needs a replacement service. I include the export date and one named contact for the next technical question.

If the project began as an ecommerce campaign, I also spell out what is deliberately outside the static copy: live inventory, checkout, account areas, and CMS editing. Clear boundaries protect both the client and the person doing the handoff. It is the same reason I test static exports before calling them portable.

ExFlow also has dedicated exporters for Webflow and Framer, but I would start with the platform-specific workflow rather than treating every builder site as the same download job.

A Squarespace site does not need to become a permanent hostage of its original hosting account. Export a working copy, test it like a real handoff, and give the client a clearly owned next step. If you have a finished campaign or client site sitting in Squarespace, begin by exporting it with ExFlow and run the QA list before you need it in a hurry.