I Scope Squarespace Handoffs With a Testable Static Copy

I used to quote a Squarespace handoff as if I were handing over a folder of pages. That was the expensive mistake. A client does not need a folder; they need a website they can open, test, host, and change without discovering the missing pieces after the agency relationship ends.

Now I scope a handoff from a testable static copy. It makes the work visible early: which pages are actually in scope, what the destination host must support, and which platform features need a replacement plan. If you want a full static copy rather than only a content export, ExFlow’s Squarespace exporter can collect a published site’s HTML, CSS, JavaScript, and media into a downloadable site or sync it to Git, S3, or FTP.

Start With the Deliverable, Not the Destination

Before I discuss a host or a date, I make a one-page inventory. I list the public pages, navigation states, downloadable media, contact paths, analytics snippets, cookie tooling, and any page that exists only for a campaign. I also ask whether the client expects editable publishing after the move. A static handoff is great for a stable brochure site, a campaign archive, a backup, or a clean client transfer. It is not a quiet substitute for a live CMS workflow.

This inventory is where an export earns its keep. A site that looks like six pages can contain a gallery with lazy-loaded images, scripts that power forms, a hidden thank-you page, and links buried in a footer. I’ve seen a polished homepage hide the entire cost of a handoff.

For a simple Squarespace site, I use three buckets:

Keep as static: core pages, product or collection pages that do not need daily edits, images, style files, and public downloads.
Replace deliberately: forms, newsletters, booking widgets, payments, gated content, and anything controlled by a third party.
Document before launch: old URLs, analytics IDs, search metadata, domain DNS, and the single person who owns credentials.

That same discipline helped when I built a Squarespace static handoff before a client asked: a working copy turns vague “can we leave?” conversations into decisions someone can approve.

Export One Version You Can Actually Open

The next job is not to publish. It is to produce a copy you can inspect locally or on a throwaway staging URL. In ExFlow, I start from the published Squarespace URL and choose the paths that belong in the handoff. The useful output is more than page markup: it needs the CSS, JavaScript, images, media, and navigation that make those pages behave like the original.

I then download the ZIP or send the result to a versioned destination. Git is my preference whenever another operator will touch the work because it creates an easy record of exactly what was delivered. S3 or FTP can be a sensible fit when the client already has a conventional static-hosting setup.

Do not promise that every Squarespace feature becomes static just because the page loads. For example, an embedded newsletter form may display perfectly while its submission path is still tied to a separate service. Put each dependency in the replacement bucket before you call the export done.

Run a Small, Boring QA Pass

I use the same browser pass I would use before changing a product page: desktop, phone, slow-ish connection, and the routes a real visitor takes. That means navigation, footer, search or filter behavior if present, contact paths, legal pages, and the top landing pages from analytics.

My handoff QA list is short enough to finish:

Open every primary navigation item and confirm internal links stay on the new site.
Check images, fonts, video, and downloadable PDFs after a cold refresh.
Test the narrow mobile breakpoint, not only a resized desktop window.
Compare page titles, descriptions, social-preview images, and canonical URLs against the current site.
Click every form and transaction path; label it “working,” “replaced,” or “out of scope.”

If you are planning a domain change, the rehearsal matters more than the export button. I use the same approach from my Squarespace domain cutover rehearsal: point a staging hostname at the static copy first, test it, and only then schedule the public DNS work.

Make the Handoff Easy to Continue

The final package should let the next person understand the site without a detective story. Mine includes the static files, a short README with the deploy command or host settings, a URL map, a list of replaced services, and a backup of the original public site. If a client wants a lightweight record of why the project changed, I also include screenshots of the important pages and the date of the export.

This is especially useful when the handoff is a hedge rather than an immediate migration. I have used a static copy to give a client breathing room during an agency switch, just as I have tested a Squarespace export before calling it portable. I also borrow the release discipline from packing a Squarespace site for static hosting: list the destination, ownership, and rollback copy before the final transfer. A tested archive is more useful than an unverified download because someone else can deploy it when the timing is right.

Where ExFlow Fits

ExFlow is the practical part of this workflow: it is built to turn a published Squarespace site into static site files, with options to download a ZIP or deploy or sync to Git, S3, FTP, or ExFlow Hosting. That is a better starting point than treating a generic downloader as a finished handoff for a modern site with media, navigation, and scripts.

If this is a client project, make one export, deploy it to a non-public test URL, and have the client click it with you. It is the fastest way to surface scope before the final invoice—not after the old site is already gone. For other site builders, ExFlow also has dedicated Webflow and Framer exporters, but keep the workflow platform-specific.

A static Squarespace handoff is not a download task. It is a tested delivery: export the site, name the exceptions, prove the visitor paths, and leave a package the next operator can actually run.