Squarespace Export Checklist for Static Hosting and Client Handoffs

A Squarespace site can look finished long before it is portable. The awkward moment arrives when a client needs a handoff, a backup before a redesign, or a lower-cost static hosting plan—and the only thing available is a live site and a content export.

For a real escape hatch, you need a static copy that includes pages, styling, JavaScript, images, and media. That is the difference between a useful archive and a folder that cannot reproduce the site. This checklist is the one I would use before calling a Squarespace export ready.

1. Decide what the export is for

Start by naming the job. A backup, a client handoff, a staging copy, and a permanent migration deserve different levels of effort. For example, a backup can be a ZIP plus a short README; a handoff should include a working hosted copy and a list of anything that still depends on third-party services.

Before exporting, write down:

• the live domain and every important page type
• whether the site uses a password, commerce, forms, member areas, or custom code
• the intended destination: Git, S3, FTP, or a managed static host
• the person responsible for DNS and post-launch checks

If the goal is only a safety copy, this guide to creating a Squarespace backup you can self-host is a useful companion. For an actual handoff, treat the exported version like a small release.

2. Export the whole published site

A platform-aware exporter is less likely to miss the odd corners of a modern site than a generic downloader. ExFlow’s Squarespace exporter is built for this job: give it the published URL, then export the site as static HTML, CSS, JavaScript, images, and media. You can download a ZIP or sync the result to Git, S3, FTP, or ExFlow Hosting.

For password-protected sites, make sure the owner supplies the password during the export setup. Do not assume a public-looking home page means every private route, image, or lazy-loaded asset has been collected.

The deliverable should make sense when opened as a folder: page files, asset folders, and a predictable place for styles and scripts. If it does not, stop there; deployment will only make diagnosis harder.

3. Run the static-site QA pass

This is the step most people skip. Open the export locally or on a private staging host and inspect it as a visitor would. Then inspect it like the person who will have to fix it at 5 p.m. on a Friday.

Check these areas deliberately:

• Navigation and internal links: header, footer, buttons, blog pagination, and canonical URLs should land where expected.
• Media: test image-heavy pages, galleries, embedded video posters, and lazy-loaded images on a small screen as well as desktop.
• Scripts and custom code: cookie tools, analytics, maps, sliders, and embedded widgets commonly need an extra look.
• Metadata: inspect page titles, descriptions, social images, favicon, and any redirects you need to carry over.
• Forms and commerce: static output can reproduce a page, but it does not magically replace a hosted form handler, checkout, membership system, or inventory workflow. Document those dependencies plainly.

A deployment test is worth doing before changing DNS. If GitHub Pages is your destination, follow the practical deployment sequence in How to Deploy a Squarespace Export to GitHub Pages.

4. Package the handoff so it survives a busy week

The best client handoff is boring: one working URL, one source archive, and one short note that says what needs ongoing attention. Include the export date, original domain, destination host, repository or storage location, and any services that remain external. A French-language field note on exporting a Squarespace site for client delivery makes the same point well: the files are only half the handoff; the operating context matters too.

If you sync to Git, make the first commit before launch. That gives the next person a known-good recovery point and makes later edits reviewable. If you choose S3 or FTP, keep a local ZIP alongside a dated deployment note.

Where this approach stops

Static hosting is excellent for brochure sites, portfolios, documentation, landing pages, and many content-heavy sites. It is not a replacement for server-side features. A live checkout, dynamic member area, or form processing still needs its own service plan. Be precise about that boundary before promising a full migration

The same portability habit applies beyond Squarespace. ExFlow also has dedicated exporters for Webflow and Framer; the QA list changes slightly, especially around CMS routes and animations. If you are staging a Framer redesign, this staging-copy workflow shows why making the copy before the redesign is the calmer move.

The simple next step

Make one static export before you urgently need one. Run it through this checklist, publish it on a non-production URL, and note every dependency that is not part of the files. When a client handoff, redesign, or hosting change lands, you will have a tested kit instead of a scramble. Start with ExFlow’s Squarespace exporter and make the first export a deliberate rehearsal.