September 9, 2026
How I Build a Squarespace Static Staging Copy Before Renewal
A practical Squarespace export, staging, and QA workflow for keeping a portable site copy before renewal day.
Squarespace is great right up until a renewal notice turns a normal Tuesday into a migration project. I do not wait for that moment anymore. Before I make a redesign, hand a site to a client, or decide whether to keep paying for hosting, I build a static staging copy. It gives me something concrete to test: pages, media, navigation, and the little scripts that make an ecommerce landing page feel finished.
For this job, I use ExFlow’s Squarespace exporter because I need a copy of the published site as HTML, CSS, JavaScript, and media—not a loose content export that still leaves me reconstructing the site around it. The goal is not to flip DNS immediately. The goal is to make a portable, reviewable copy while the original is still live and easy to compare.

Start With a Small Inventory, Not an Export Button
My first pass is deliberately boring. I write down the homepage, every navigation destination, campaign landing pages, the contact path, legal pages, and the handful of product or collection pages that actually drive revenue. Then I note anything with behavior: newsletter forms, embedded booking tools, video blocks, cookie banners, analytics, and links that leave the site.
This catches the difference between “the pages downloaded” and “the site is portable.” A good static copy needs its image paths, lazy-loaded media, menus, metadata, and responsive layout to survive the trip. If your site has private client pages, add the access details to the handoff notes; I used the same approach in this password-protected Squarespace export workflow.
I also take a few reference screenshots at desktop and mobile widths. They are not glamorous, but they make visual regressions obvious later.
Export While the Original Is Still Your Reference
Once the inventory is ready, I enter the live URL in ExFlow and create the static export. The useful output is a complete file set I can download as a ZIP or sync to a destination such as Git, S3, or FTP. I prefer Git for this first pass because it gives me a dated checkpoint and makes later changes easy to inspect.
There is a tempting shortcut here: point a generic site downloader at the homepage and call it done. That can be fine for a one-page brochure site, but modern Squarespace builds tend to include lazy-loaded images, navigation behavior, media, and scripts that deserve a platform-aware export. The export should be treated as an artifact to test, not proof that every interaction will work.
If you have already worked through a general Squarespace static HTML export without missing assets, this is the same idea with a more useful deadline: build the copy before you need it.
Put the Copy on a Staging URL First
I deploy the exported files somewhere intentionally unimportant: a staging subdomain, a temporary static host, or a preview branch. The live Squarespace domain stays put. This is where a static copy earns its keep, because I can compare both versions side by side without a big-bang cutover.

My deployment order is simple:
- Commit the export so I have a known baseline.
- Publish that exact commit to staging.
- Set the staging host to serve the expected index and asset paths.
- Browse the important URLs from the inventory before touching production DNS.
For a small ecommerce site, I also click from the homepage into a collection, a product or lead-capture page, the cart-adjacent links, and the footer. I am looking for relative links that point back to the old domain, images that only load after scrolling, missing fonts, and forms that need a replacement endpoint. A static export is a hosting move, not an automatic replacement for server-side features.
Run a Release Gate That Matches the Site
The fastest way to miss a broken export is to test only the home page. I use a compact release gate instead:
- Check desktop and mobile at the breakpoints your screenshots captured.
- Open every top-level navigation item and a sample of deep pages.
- Verify images, video thumbnails, fonts, and any downloadable files.
- Inspect page titles, descriptions, canonical tags, and social preview metadata.
- Test forms, embedded tools, redirects, and external checkout paths separately.
- Record what needs a static replacement before a real cutover.

That last step is the one I used to skip. A signup form can look perfect while sending nowhere; a storefront button can link correctly while a tracking script silently disappears. Naming those gaps up front turns the export into a clean handoff instead of a mystery for future-you. For a Webflow version of the same pre-redesign habit, this static mirror build note has a useful comparison checklist.
Decide What the Static Copy Is For
I do not assume every Squarespace export must become the new production site. Sometimes it is a backup. Sometimes it is a client archive. Sometimes it is the staging version that lets a team price a migration without putting the current site at risk. The decision becomes clearer once I can point to a working preview and say what is preserved, what needs replacement, and what the next hosting bill is buying.
ExFlow also has dedicated exporters for Webflow and Framer. The QA details change by platform—Framer animations deserve their own pass, as I found in this Framer static-hosting check—but the operator habit stays the same: make the portable copy before the deadline makes choices for you.
My Next Step Before Renewal Day
Export your Squarespace site while it is healthy, deploy the copy to a staging URL, and test the revenue paths before you need an exit plan. If the staging copy is solid, you have a real option—not just a folder of files—when renewal day arrives.