November 7, 2026
How to Build a Squarespace Rollback Kit Before a Homepage Launch
Create a tested Squarespace rollback kit with a static export, exception list, and safe deployment path before changing your homepage.
If you are about to replace a Squarespace homepage for a sale, relaunch, or new merchandising direction, make a rollback kit first. A tested static copy gives you a known-good reference for public pages and assets; it is not a replacement for Squarespace server features such as checkout, form submissions, member areas, search, or scheduling. You need a published Squarespace site, permission to export it, and a place to store the resulting files.
This workflow creates a practical recovery point before you touch the live page. It is deliberately different from a full migration: the goal is to preserve what visitors can see, record what needs a separate service, and keep one fast route back to the prior experience.
1. Define the rollback boundary
Write one sentence before exporting: “If the homepage launch fails, we can restore the previous public pages, assets, and routes at a static host while we repair the live build.”
That sentence keeps the kit honest. A static export can preserve rendered HTML, CSS, JavaScript, images, media, and public routes. It cannot automatically recreate services that depend on Squarespace servers.
Make a small inventory with your launch owner:
| Include in the kit | Record as an exception |
|---|---|
| Home, collection, product, blog, policy, and campaign pages | Checkout, customer accounts, member areas |
| Navigation, redirects, hero imagery, fonts, CSS, JavaScript | Form delivery, site search, scheduling |
| The live URL for each key page and the expected destination | Inventory, order, and other server-side data |
Expected result: everyone agrees on what the rollback can show and what needs a temporary replacement or a support message. This same boundary is useful when checking forms before moving a Framer site to static hosting: visible pages and server-owned actions are separate acceptance checks.
2. Capture the public site while it is still correct
Open the ExFlow Squarespace exporter and enter the published Squarespace URL or custom domain. Enable CSS, JavaScript, images/media, and Export all pages. If your published site has a frontend password, use it only in the exporter setting intended for that password.
ExFlow documents this as a browser-based crawl that downloads the pages and assets served to visitors, then rewrites links for the exported files. Leave the site live while the crawl runs; a rollback kit should represent a state a visitor could actually reach.

When the file list is ready, download the ZIP and name it with an unambiguous timestamp, such as 2026-11-07-pre-homepage-launch.zip. Store it somewhere versioned or access-controlled. Do not treat a local Downloads folder as the only recovery copy.
Expected result: you have one archive containing the public site footprint, rather than a list of screenshots or an incomplete content export. If you are planning a broader rebuild later, pair this with a Webflow CMS content-freeze archive approach: choose representative dynamic routes before a deadline makes sampling impossible.
3. Create an exceptions file next to the archive
Add a plain ROLLBACK-NOTES.md file beside the ZIP. Keep it short and operational:
# Homepage launch rollback
Snapshot: 2026-11-07-pre-homepage-launch.zip
Static preview: <temporary preview URL>
## Works as static output
- public pages and navigation
- images, fonts, CSS, and JavaScript
- documented redirects
## Needs a replacement or a decision
- newsletter form: route to <form provider or inbox>
- checkout buttons: point to <storefront URL>
- site search: hide or replace
- member-only area: keep on the original platform
## Restore owner
- deployer: <name>
- domain/DNS owner: <name>
- approval channel: <link>
Expected result: a teammate can tell the difference between an export defect and a feature that was never static. This prevents the common mistake of declaring a rollback broken because a hosted checkout does not run from downloaded HTML.
4. Preview the archive before the launch
Unzip the export into a fresh folder and serve it with the preview method your host recommends. Test it under the same path structure you would use in a recovery. Then open a deliberately small test set: homepage, one product or service page, one article, one image-heavy page, one policy page, and one route reached only from navigation.
For each page, check these in order:
- The URL loads without a redirect loop or missing asset.
- Navigation and primary calls to action land where the kit says they should.
- Images, fonts, and responsive layout look complete on phone, tablet, and desktop widths.
- Any server-backed control is labelled or replaced according to
ROLLBACK-NOTES.md.

Expected result: you have evidence that the archive is deployable, not merely downloadable. This is the same reason a Framer responsive export QA receipt should cover more than a desktop homepage.
5. Choose the recovery destination before you need it
A rollback kit is useful only if its destination is ready. ExFlow can provide the ZIP or connect an export to Git, S3, FTP, or ExFlow Hosting. GitHub Pages is one option for a static recovery site: GitHub describes it as hosting HTML, CSS, and JavaScript from a repository, optionally through a build process.
Use a non-production preview URL first. If you intend to use the production domain during an outage, write down the exact DNS or hosting change, who can approve it, and how you will reverse it. For a larger move, a Squarespace redirect-map workflow is a helpful companion because a visually correct page still fails if its old URLs disappear.

Expected result: the team has a rehearsalable sequence—archive, preview, approval, deploy, verify—rather than a ZIP whose owner and destination are unclear.
6. Run a five-minute launch receipt
Immediately before publishing the new homepage, record these five answers:
- Is the archive dated and stored in a second location?
- Does the static preview load the agreed sample pages?
- Are forms, checkout, search, and member areas explicitly accounted for?
- Is the rollback destination ready, with an owner and access confirmed?
- Does the launch channel know the condition that triggers rollback?
If any answer is no, pause the homepage change long enough to repair the gap. That is usually faster than reconstructing a prior layout under pressure.
Keep the kit small, tested, and current
Your next action is simple: run one static export of the current Squarespace site, test a six-page sample, and save the exceptions file beside it. ExFlow’s Squarespace exporter is a practical way to create that public-site snapshot; use its Webflow and Framer exporters later when those platforms are the actual source. A rollback kit does not make a launch risk-free, but it turns a vague recovery promise into a tested path.