How to Rehearse a Squarespace Domain Cutover Before Going Live

You do not need to point a real domain at a new host to discover whether a Squarespace migration is sound. In fact, doing that first is how a tidy export turns into a frantic afternoon of broken images, missing routes and form emails going nowhere.

The safer move is a cutover rehearsal: make a static copy, publish it somewhere disposable, and run the same checks you will run on launch day. That gives you a site you can inspect without putting the live version at risk.

ExFlow’s Squarespace exporter is useful here because it is built to collect a published site as static HTML, CSS, JavaScript and media, then lets you download the result or deploy it to Git, S3, FTP or managed static hosting. The point is not to declare victory when the ZIP arrives. The point is to create a testable release candidate.

Pick a rehearsal address before you export

Use an address that cannot confuse customers with the real site: a temporary host URL, a preview subdomain, or a staging domain. Keep the production domain exactly where it is until the rehearsal passes.

Write down the pages that matter commercially, not just the homepage: top navigation, a representative blog post, high-traffic landing pages, the contact path, privacy and policy pages, any campaign URL still circulating, and the thank-you page after a conversion. If the site relies on password protection, test that requirement before the export; a static copy is not automatically a private preview.

This step also exposes a common planning error: treating a Squarespace content export as a full site backup. Those are different jobs. If you need a practical static backup first, this Squarespace backup testing guide explains the distinction.

Export the published site, then make the output boring

Enter the published Squarespace URL in ExFlow, choose the static export, and send the output to the test destination you selected. For a small site, downloading a ZIP and deploying it manually may be enough. For a repeated workflow, a Git or S3 sync gives you a clearer trail of what changed.

Do not edit the export immediately. First open the root page and look at the file structure. You want to know whether pages, CSS, scripts, images and media made the trip together. Then make only the hosting-specific adjustments your target requires, such as the correct base path or a redirect configuration. Keep those changes documented; they are part of the cutover recipe.

Run a short, ruthless preflight

A visual scan is necessary but insufficient. Work through this list in a private or incognito browser, on a phone as well as a desktop:

• Routes: open every priority URL directly, including a deep blog or campaign path.
• Navigation: test the header, footer, logo and any menu that expands or animates.
• Assets: look for missing images, fonts, videos and lazy-loaded sections.
• Responsive behavior: check at least one narrow viewport before calling it a static site.
• Forms: submit a non-sensitive test entry and confirm where it goes. A copied page may preserve the form markup while its original processing service does not follow it.
• Search and integrations: identify anything dynamic—site search, member areas, checkout, scheduling widgets or dashboards—and give it an explicit replacement plan.
• Metadata: inspect title tags, descriptions, social preview images and canonical URLs.
• Redirects: list old URLs that must continue working and test them at the staging host when possible.

The mechanics are similar to the route and asset checks in this Webflow static-export QA guide, but keep the Squarespace-specific inventory separate. Each builder has its own moving pieces.

Treat the domain switch as a reversible change

Once the preview is clean, make a tiny cutover sheet: current DNS settings, the new host target, TTL values, the exact time you will switch, the person responsible, and the rollback step. Save a browser screenshot of the working old site and the working rehearsal. This sounds fussy until a DNS change needs to be undone under pressure.

Avoid changing content and switching hosts in the same hour. Freeze major edits, create one final export, and rerun the high-priority route list. If you are handing the site to a client, this same release packet makes the work legible; the principles in this static HTML handoff walkthrough transfer directly.

Watch the live site after cutover

After you point the domain, test the canonical domain, the www version if you use one, and several deep routes. Repeat the form test. Watch for mixed-content warnings, redirects that loop, missing fonts and image requests that still point to an old location. Keep the old host available until the checks pass and any DNS propagation window has settled.

ExFlow also has dedicated exporters for Webflow and Framer, but the same discipline applies: export, stage, inspect, then change the address customers use.

A Squarespace domain cutover should feel almost uneventful. Build the rehearsal first, record the few failures it reveals, and only then point the real domain at the tested static copy.