Squarespace Static Migration: Build a Redirect Map Before You Move Hosting

My rule for a Squarespace static move is simple: treat old URLs as inventory, not debris. A static export can preserve the pages people see, but it will not automatically decide where every old campaign, blog, or thank-you link should go on the new host. Make a redirect map before you point the domain, then test it against the deployed copy. That protects useful links while giving you a clean, reviewable migration.

Squarespace’s own site-content export is an XML export with documented limits: it does not include several page types, custom CSS, or more than one blog page. That can be useful for content, but it is not a deployable copy of the live site. For a rendered static copy, I would start with ExFlow’s Squarespace exporter, then put equal effort into the route map that surrounds the export.

Start with a route inventory, not the home page

The home page is almost never the risky part. The fragile traffic usually comes from old paid-campaign URLs, email links, seasonal landing pages, blog posts, PDF links, and the thank-you page a form used to send people to. Make one row per path before the move:

Use your analytics, ad accounts, email platform, Search Console, site navigation, and any campaign spreadsheet as inputs. The goal is not to preserve every historical typo. It is to make a deliberate call on every route that matters. If a page has no useful successor, a clear 404 can be more honest than sending everyone to the home page.

This is the same operational distinction behind a Squarespace static handoff checklist: files are only one half of a handoff; the behavior around them is the other half.

Export the visible site, then mark the non-static edges

When the route list is ready, export a staging copy. ExFlow says its Squarespace workflow captures published HTML, CSS, JavaScript, media, and linked public assets, and can deliver a ZIP or sync to Git, S3, or FTP. That makes it a practical source copy for a static-host test.

But do not describe the result as a full replacement for every Squarespace service. On its Squarespace page, ExFlow explicitly calls out server-side features that need another solution: form submissions, Commerce checkout, member areas, scheduling, and site search. Put these in the migration board as replace, retain, or retire before launch.

Here is the small decision card I use:

• Keep static: landing pages, editorial pages, images, downloadable PDFs, and client-side galleries that work in the preview.
• Replace: forms, search, authenticated content, scheduling, and checkout. Give each an owner and destination.
• Retain elsewhere: keep a commerce or member flow on its supported service if a static replacement does not meet the job.
• Retire: old promotions with no current offer; add an intentional outcome to the route map.

That boundary prevents a common bad launch: a page looks correct in a screenshot, while the form or buying path quietly stopped being real. For the related preflight mindset, a Webflow static release gate is a useful adjacent read.

Turn the map into host-specific redirects

A redirect map is a source document, not yet a deployment. Translate it for the host you selected. For example, Cloudflare Pages reads a _redirects file in the static output; each rule has a source, destination, and optional status code. Its documentation also notes that rule order matters and that static rules should appear before dynamic ones.

A small example:

/spring-bundle /collections/spring 301
/journal/size-guide /fit-guide/ 301
/newsletter-thanks /thanks/ 302

Use a temporary redirect while you are still testing a newly chosen destination; use a permanent redirect only when the mapping is settled. Keep the original spreadsheet beside the deployed file so the next campaign owner can understand why a route exists. If you are moving a Framer project later, the same habit applies—this Framer form handoff guide makes the server-side boundary particularly concrete.

Run a 10-minute redirect walk before DNS changes

I would not change DNS until this short walk is clean:

1. Open the staging host in an incognito window and click primary navigation, footer links, campaign links, and the 404 page.
2. Paste ten high-value old paths from the route map directly into the browser; confirm each reaches its intended destination in one hop.
3. Submit a real test form and inspect the confirmation path, email, and ownership of the submission.
4. Test a real purchase or scheduling journey where those functions remain in scope.
5. Check mobile at the same three breakpoints you care about on the live site, then inspect page titles and descriptions for the core landing pages.
6. Save a timestamped copy of the export and redirect map in Git or with the project handoff.

Cloudflare Pages documents that it normalizes some HTML URLs to extension-less paths. That is helpful, but it is not a substitute for testing the routes you promised in the map. A host convenience is not a campaign migration plan.

Make the move reversible

The useful output from this process is not only a new host. It is a small operating packet: the export, a route map, the redirect rules, a list of replaced services, and the test record. That packet makes a domain move less theatrical and the next change less mysterious.

Start by exporting one non-critical Squarespace campaign site to a staging URL with ExFlow. Then make a route map for its ten most-linked paths before you touch DNS. You will know whether the static move is truly ready—and which services still need a home.

For a broader recovery perspective, see how to run a Framer static recovery drill.