I Use a Four-Service Ledger Before Moving Squarespace to Static Hosting
A Squarespace site can move to static hosting when its public pages are the valuable part and every server-side service has a named replacement or an explicit retirement decision. My practical rule is simple: do not treat a downloaded site as a migration plan. First, separate what can become files from what still needs a running service.
That distinction has saved me from the most expensive kind of ‘cheap hosting’ move: one that looks polished but quietly stops collecting leads, accepting orders, or serving members. A static copy is excellent for public marketing pages, portfolios, documentation, campaign sites, and frozen archives. It is not automatically a substitute for an application.
For the file side of the job, ExFlow’s Squarespace exporter captures a published site as rendered HTML, CSS, JavaScript, images, media, and linked public assets. Its own documentation is clear about the boundary: Squarespace-managed forms, Commerce checkout, member areas, scheduling, and site search do not move as functioning services. That is exactly why I start with a ledger.
The four-service ledger
Before I export, I put each live feature into one of four columns. The point is not paperwork; it is to make an irreversible hosting decision reviewable.
| Service class | Can the static copy show it? | What must happen before cutover? | Sensible outcome |
|---|---|---|---|
| Public content: pages, posts, galleries, media | Usually yes | Check routes, assets, responsive layouts, and metadata | Export and host statically |
| Lead capture: forms, newsletter signups | The form can render, but delivery is separate | Select and test a new endpoint or form provider | Replace before cutover |
| Transactions and access: checkout, members | Product pages can render; the underlying service remains server-side | Keep Squarespace for that flow or move it to a purpose-built service | Keep, replace, or split the site |
| Operations: scheduling, search, dashboards, private integrations | A link or embed may appear, but behaviour must be tested | Give each dependency an owner, fallback, and test | Replace, link out, or retire |
That table produces a decision I can defend: static is a good fit when column one contains the business value and the remaining columns have a tested plan. If checkout or member access is the business, I do not call a front-end copy a full migration.
Step 1: inventory the live experience, not just the sitemap
A sitemap tells me which pages exist. It does not tell me which pages depend on a remote service after load. I walk the site like a visitor and record every place a visitor can submit, buy, sign in, search, book, or trigger a third-party embed.
My short inventory template is:
- Page and audience:
/contact, prospective client. - Action: submit a project enquiry.
- Current dependency: Squarespace form delivery.
- Cutover choice: new form endpoint, keep the existing form page, or remove the action.
- Owner and proof: who tests it and what a passing test looks like.
This is the same change-management habit I use when I test a Notion-to-Webflow schema change before auto-sync: map the data boundary first, then automate or deploy. It reduces the chance that an attractive front end hides a broken operational path.
Step 2: export a reference copy, then choose a deployment path
Once the ledger says the public surface is portable, I export a reference copy from the published site. ExFlow can download a ZIP or send exports to Git, S3, FTP, or its managed hosting option. The important choice is less about the host than about repeatability.
For a one-time archive, a dated ZIP plus a local smoke test may be enough. For a campaign or marketing site that will keep changing, I prefer a Git-backed destination so a reviewable version exists before every deploy. That makes it possible to compare an updated export, roll back a bad release, and give another operator a concrete artifact instead of a login trail.
A static export is also not a reason to copy blind. ExFlow says it follows the published site, collects served styles, scripts, media, and public assets, and rewrites links to local files. That is useful for a complete reference copy, but it does not prove every interaction on your particular site works away from Squarespace. I still test the result in its target environment.
If you are already used to moving builder output, the discipline carries across platforms. My Webflow CMS route export guide focuses on route coverage; the same question matters here: did the output contain the pages people can actually reach? ExFlow also has dedicated Webflow and Framer exporters, but their platform-specific runtime features deserve their own inventories.
Step 3: run a release test that includes service replacements
I use this compact pre-cutover receipt:
- Routes: navigation, deep links, old campaign URLs, and a useful 404 page work on the new host.
- Visuals: desktop and mobile layouts, fonts, galleries, lazy-loaded media, and custom CSS match the published reference.
- Content: current pages, posts, downloads, SEO titles, descriptions, and social preview images are present.
- Actions: each form sends a real test submission; each booking, purchase, sign-in, search, or private area either works through its replacement or directs people somewhere intentional.
- Measurement: analytics, consent handling, and conversion events are deliberately configured rather than assumed to survive.
- Recovery: the current Squarespace site stays live until the new hostname, redirects, and critical actions pass.
This is why I like treating a move as a recovery exercise, not just a hosting switch. In a recent Framer static recovery drill, the key question was whether a team could restore a coherent version under pressure. Here, the equivalent is whether your team can point traffic back, re-enable a service, or explain a deliberately retired feature without improvising.
When I would not move the whole site
I keep Squarespace in place, or split the architecture, when the site’s highest-value workflows are checkout, memberships, scheduling, or platform-owned search and I do not want to operate replacements. A public brochure site can be static while a booking or commerce flow stays on its original service. Linking to that service is often safer than pretending an exported page is the whole business system.
This is also a useful client-handoff rule. A static folder is a strong deliverable for a completed campaign or a public portfolio; it is not a substitute for credentials, vendor contracts, or an operating manual. For more background on making dependencies visible before export, see this Squarespace dependency inventory guide.
The decision I make
My threshold is straightforward: if every non-static service has an owner, a replacement or retirement choice, and a passing test, I am comfortable moving the public site to static hosting. If not, I export a dated backup and keep the live platform running while the ledger is completed.
Start by listing five actions a visitor can take beyond reading a page. If the list is empty—or every action has a tested replacement—run a free Squarespace export with ExFlow and test it on a staging hostname before touching DNS. That is the difference between a portable site and a pretty screenshot of one.