My Squarespace Exit Plan: What I Check Before I Move a Site

I used to think leaving Squarespace was a hosting decision. It is really an operations decision. The risky part is not downloading files; it is discovering, after the domain changes, that a campaign page, an old form, or a collection of images never made the trip.

For a small store, I now make the export a deliberate handoff: I inventory what customers can reach, capture a working copy, test it away from the live site, and only then choose where it will live. A Squarespace exporter such as ExFlow makes the file collection much easier, but it does not replace the checks around it.

1. Decide what the export is meant to protect

There are two very different reasons to download a Squarespace site:

You want a recoverable copy before a redesign, vendor change, or domain move.
You want to turn the current public site into a static site that you can host and manage independently.

That distinction changes the standard I use. A backup only needs to be complete and readable. A replacement site also needs working navigation, correct asset paths, acceptable forms and embeds, and a hosting plan. I write down which outcome I need before I touch an export setting.

This is also where I put boundaries around the job. A static copy can preserve pages, CSS, JavaScript, images, media, and the public structure of a site. It will not magically recreate services that depend on a live Squarespace account, such as a form workflow or a member-only experience. If a feature is business-critical, I list its replacement before the migration begins.

2. Audit the live Squarespace site like a customer would

My pre-export checklist is short, but I take it seriously:

Visit the main navigation on desktop and mobile.
Open the pages that receive paid, email, or social traffic.
List forms, appointment links, newsletter embeds, checkout links, and analytics scripts.
Check old campaign URLs and the pages that rank or get shared most often.
Spot-check image galleries, downloadable files, videos, and any password-protected area you own.

I keep the list in plain language: “spring lookbook,” “wholesale inquiry form,” “returns PDF,” “best-selling collection landing page.” That makes the post-export test faster than trying to remember which template block held what.

The inventory also tells me whether migration is worth doing now. If the site is mostly evergreen pages and media, static hosting is a clean fit. If it relies on a large number of changing products or operational integrations, I may keep the storefront platform in place and export only the marketing section. That is a much better decision than forcing every page into one technical solution.

3. Export the whole public surface area, then keep the source copy

When I need a full static handoff, I export all pages and include CSS, JavaScript, images, and media. With ExFlow, the useful controls are explicit: enter the Squarespace URL, choose the asset types to include, export all pages with .html extensions, and download the resulting site. It can also sync an export to Git, S3, or FTP when that fits the team’s workflow.

I save the untouched download as the source archive. I do not start editing the only copy. The working copy gets a date, a project name, and a simple note about which public URL it came from. That has saved me from a surprisingly common mistake: fixing a link in the deploy folder and later having no clean baseline to compare against.

If the owner needs to export a password-protected Squarespace site, the product supports that when the owner provides the password. Treat those credentials and any Git, S3, or FTP credentials as sensitive operational data—not something to paste into a shared task document.

4. Choose hosting based on who will maintain it

I do not pick a destination because it sounds technical. I pick it based on the next six months of maintenance.

Git works well when someone already reviews changes, wants version history, and deploys from a repository. It is the route I would choose for a small team that expects content tweaks after launch.
S3 makes sense when the organization already runs AWS and wants the site alongside its existing infrastructure.
FTP is practical when the site is replacing pages on an existing conventional host.
Managed hosting is the simpler choice when the priority is getting the static site online without adding another deployment system. ExFlow offers hosting for exported sites and can connect an external domain.

The export itself should remain portable whichever route you choose. That is why I like keeping the file archive separate from the hosting account. For the Git path, this Squarespace-to-Git, S3, or FTP walkthrough is a useful next read. If GitHub Pages is already in your stack, this self-hosting guide covers that narrower route.

5. Test the copy before pointing a domain at it

I test the export on a temporary host or preview environment before DNS changes. The goal is not pixel-perfect nostalgia; the goal is to catch broken customer paths.

My test pass covers:

Every navigation item and footer link.
A handful of deep pages from the audit.
Images and media on both a fast and an ordinary connection.
Redirects from any old high-value URLs.
Contact and newsletter actions, including the intended replacement if the old form cannot come along.

This is the moment to fix asset paths and trailing-slash issues, not after a customer sends a screenshot. I also compare the exported folder against the source archive so I can tell whether a later “fix” removed something important. If you need a broader overview of the process, I previously shared how I turn a Squarespace site into HTML without rebuilding it.

6. Keep a rollback plan even after the launch looks fine

A good Squarespace exit plan ends with two copies: the original export archive and the deployed, tested version. I also record the current DNS settings, the date of the export, the source URL, and the location of the repository or hosting account. That information turns a stressful rollback into a small operational task.

For stores that want more control without rebuilding every page by hand, ExFlow’s Squarespace export flow is a sensible starting point: capture the current public site, choose a maintenance-friendly destination, and test the result before making the switch.

The next action is simple: make the audit list for your own Squarespace site before you shop for hosting. Once you know what has to survive the move, exporting and self-hosting become a controlled project instead of a leap of faith.