Structure mapping
Blocks become components, not copies
Squarespace's stacked block layout is rebuilt as a reusable Webflow system.- BlocksCatalog every content block
Text, gallery, form, and embed blocks documented per page.
- ExportUse the WordPress XML export
Squarespace's one real export path for blog content.
- SEOReplace automatic settings
Sitemap, canonicals, and metadata rebuilt explicitly.
- RedirectsMap blog and product URLs
Squarespace's own redirects stop working once the site leaves.
- CommerceReconnect checkout and forms
Tested end to end before the domain moves.
Inventory Squarespace's block-based pages before rebuilding
Squarespace pages are built from stacked content blocks rather than a single exportable document. Each page needs its block structure cataloged: text, gallery, form, and embed blocks, along with any custom code injected through the code block.
Style Editor choices, fonts, colors, and spacing live inside Squarespace's own settings and do not carry over. Record the intended look so it can be rebuilt as a Webflow style system rather than recreated page by page.
- Every page's block structure documented
- Galleries, embeds, and custom code blocks listed
- Fonts, colors, and spacing choices recorded for the new system
- Style Editor settings treated as a rebuild, not a transfer
Export blog and commerce data through Squarespace's own tools
Squarespace is one of the few platforms that offers a real export path: blog content can be exported in a WordPress-compatible XML format, giving a usable starting point for posts, categories, and tags.
Product catalogs need separate handling. Export or document variants, pricing, and inventory structure before deciding how commerce will work in the new Webflow build.
- Blog exported using Squarespace's WordPress-format XML export
- Post categories, tags, and authors mapped to CMS fields
- Product catalog and variants documented separately
- Member or gated content access rules noted
Recreate Squarespace's automatic SEO settings
Squarespace automatically generates some meta tags, a sitemap, and canonical URLs behind the scenes. None of that configuration transfers, so it needs to be rebuilt explicitly in Webflow rather than assumed to continue working.
Carry over existing alt text and metadata where it is already good, and treat thin or missing metadata as something to fix during the rebuild rather than after launch.
- Meta titles and descriptions recreated per page
- robots.txt and sitemap.xml configured in Webflow
- Image alt text carried over or rewritten
- Squarespace's automatic canonical behavior replaced with Webflow's own settings
Map Squarespace URLs and prepare redirects
Squarespace blog and product URLs typically follow a predictable pattern, which makes building the redirect map more straightforward than on some platforms, but the work still has to happen before the domain moves.
Squarespace's own redirect rules, set inside its dashboard, should be reviewed and carried into the new redirect map rather than left behind when hosting changes.
- Every live Squarespace URL inventoried
- Blog, product, and page URLs mapped to Webflow destinations
- 301 redirects built and tested ahead of the domain move
- Squarespace's existing redirect rules reviewed so none are lost
Test commerce, forms, and the domain cutover
Squarespace Commerce checkout, email campaign integrations, and forms all need equivalent setups in the new system, tested with real submissions and a real order before launch.
Schedule the DNS cutover with a rollback plan in case an integration needs more time, rather than treating the domain move as the final, unreviewable step.
- Commerce checkout tested end to end in the new system
- Forms and email notifications verified with real submissions
- Newsletter or email integrations reconnected
- DNS cutover scheduled with a rollback plan