Squarespace to a headless CMS
when growth means duplicating pages.

We move Squarespace sites onto DatoCMS or Storyblok with a real codebase underneath. Your design comes with you and your URLs stay where they are. What changes is underneath the pages: content your team reuses instead of duplicates, and custom code that someone actually stands behind.

Trusted by

On Squarespace, the page is the unit.

Squarespace builds a site out of pages, and that is the whole design. It is why the first version goes up in a weekend and looks good doing it. It stops being free the day the same block has been pasted into fifteen pages and a second language means duplicating all of them. Squarespace's multilingual guide says as much: duplicate the pages from your first language, then update the text. That is fine at ten pages. At a hundred and forty it is a maintenance job with a marketing team attached. This is one path through our wider headless migration practice. Teams leaving Wix and Webflow run into their own version of this. The ceiling sits in a different place on each of them.

A second language means a second set of pages. Squarespace's own guide suggests duplicating the pages from your first language and updating the text.

Language subdomains are not available. Squarespace states you cannot have different domains or subdomains for different languages.

Built-in text stays in one language whatever you do. Squarespace says this also affects metadata across the site, like dates on blog pages.

Code injection is the escape hatch and Squarespace says plainly that custom code falls outside the scope of their support, and can cause display issues with future platform updates.

The same block gets pasted into fifteen pages, because the page is where content lives and there is nothing underneath it to reuse.

The export takes one blog page and leaves the rest. Everything else has to be read off the live site.

The Reality

The export is real, and it is partial. Squarespace documents exactly one blog page coming out with its posts, while album, cover, index, info, calendar, portfolio and store pages do not. Getting the rest out is the actual project.

What You Take With You

One blog page exports. We crawl the rest.

A Squarespace migration is mostly a reconstruction job, and knowing which half is which is what keeps it predictable. The export covers a slice, the crawl covers everything else, and both are scoped before anyone writes code. What your visitors see stays the same throughout.

  • Your blog

    comes out through the export, which carries one blog page with all of its posts. A second blog page has to come across through the crawl, and most growing sites have one.

  • The pages Squarespace will not export

    are named in their own documentation: album, cover, index, info, calendar, portfolio and store pages. Those get reconstructed from the live site, which is where the audit starts.

  • Your visual design

    read off the live site and rebuilt in code. Style settings and custom CSS both sit on Squarespace's no-export list, so the rendered page is the only specification of your design that exists.

  • All your URLs

    every page slug, every blog post, every gallery item. Squarespace generates a good number of these for you, so the redirect map gets built from the crawl instead of from a list someone typed.

  • Your media

    sized today by whatever the template asked for. We pull it, resize it against the layout that actually ships, and serve WebP and AVIF.

What Changes

Duplicated pages become one component.

The page-shaped habits go away with the platform that created them. Duplication, injected code, and hand-maintained language copies are answers to how Squarespace stores a site, and they stop being necessary once the content lives somewhere with a structure of its own.

  • A second language

    stops being a second set of pages. Locales live in the CMS against the same entries, and each one gets a real URL you choose.

  • Repeated blocks become components

    that take props, live in source control, and ship everywhere they are used the moment one of them changes.

  • Code injection goes away

    and custom behaviour becomes code in the repository, reviewed and owned by the people who wrote it.

  • Hosting and CDN

    you choose. Bunny, Cloudflare and Vercel are where most clients land, and a static build takes away the page-speed ceiling that arrived with the template.

  • Lock-in ends

    because the content sits in a CMS with an API. Changing agency, host, or CMS later becomes a decision you make on your own timeline.

How It Works

Rebuilding a Squarespace site as content

1

Crawl first, export second

We crawl the live site before we touch the export, because the crawl is what tells us how much of the site the export will miss. Gallery and portfolio pages, duplicated language pages, and anything sitting in a code injection block get listed individually. Then we design the content model, including which page types collapse into one entry type. You approve the model before any code is written.

2

Rebuild in code, migrate the content

We rebuild the design in Astro, faithful to the Squarespace version. The blocks that appeared on fifteen pages become one component used fifteen times. Content is imported into DatoCMS or Storyblok through their API, with each locale modelled as a locale. We test every page against the live Squarespace site before cutover.

3

Cutover and 30 days of watching

We launch on a low-traffic window, swap DNS, and monitor Search Console, Analytics, and Core Web Vitals for 30 days. Squarespace stays live as a fallback during the watch window. After 30 days you decide whether to keep us on with a subscription or take it from here.

A note on custom code

Squarespace is honest about code injection, and that is worth reading carefully.

Their documentation says custom code modifications fall outside the scope of their support, that they cannot guarantee functionality or full compatibility, and that custom code can cause display issues with future platform updates. Code injection also runs on the Core, Plus, Advanced and some legacy billing plans. That is a fair description of an escape hatch. It is also the reason the injection block on most sites has grown into something nobody wants to open.

Start with an audit

Pricing

Fixed price, scoped from the crawl

Squarespace migrations are priced on how much the export leaves behind. A 30-page brand site with one blog and no second language is one thing. A 140-page site running two duplicated language trees, several portfolio pages and years of injected code is another. The ranges below are where typical projects land. Once the crawl is done, you get a fixed quote.

Migration project
€ 20.000 — € 50.000fixed price
  • Full crawl and audit of every page type the export will miss

  • Content model that replaces duplicated pages with reusable entries

  • Redirect map for every page, post and gallery item

  • Faithful rebuild in Astro

  • Frontend in Astro, CMS in DatoCMS or Storyblok

  • Locales modelled properly, with a real URL per language

  • 30 days of post-launch monitoring with Squarespace as fallback

Ongoing subscription
€ 1.500 — € 3.500per month (optional)
  • Same team stays accountable for the system

  • Performance and uptime monitored continuously

  • Content and component changes handled monthly

All prices are net, excluding applicable VAT.

Who This Is For

Who this is for

This works well if you

  • Run a second language as a duplicated set of pages and maintain both by hand

  • Keep pasting the same block into new pages because there is nothing to reuse

  • Have a code injection block that nobody on the team wants to touch

  • Care about organic traffic and need every URL preserved through the move

  • Want the same content to feed more than the website, like an app or a partner feed

  • Want to own your hosting rather than depend on a single SaaS vendor

This is not a fit if you

  • Run Squarespace Commerce as the core of the business and need a commerce-first replatform. Different scope. Talk to us first

  • Run a marketing site that changes a few times a year. Squarespace is doing its job and a migration is overkill

  • Want a designer-first workflow with no developer involvement. That is what Squarespace is good at

  • Are not sure yet what is wrong. Start with a Headless Audit

  • Need a new build from scratch with no legacy to preserve. See Headless Website

If your website has become a bottleneck, let’s talk.

Let's talk Or email me directly