A Squarespace to Next.js migration is a rebuild, not an export. Squarespace only exports a WordPress-format XML file with your layout pages, gallery pages and one blog, so store pages, portfolios, events, headers, footers and the design itself get rebuilt in Next.js from the live site. Your SEO survives if every old URL either stays the same or 301-redirects to its new home, blog posts and /s/ file links included. The cost is roughly what a new Next.js site of the same size costs, and it's driven by how many page templates you have, how much content has to move and whether you sell products.
I build Next.js and React websites, and I rebuilt the Aura Clips agency site from Framer to WordPress. That job followed the same pattern any platform move does: inventory, rebuild, redirect, launch. I haven't got a Squarespace-to-Next.js project on this site, so treat this as the checklist I'd work through rather than a case study.
What does Squarespace actually export?
One WordPress-format .xml file. It holds layout pages, gallery pages and a single blog, and that's it. Squarespace's help page on exporting lists what goes in, and notes that text from blocks like embeds comes out "with minimum structure". It also lists what stays behind: album, cover, index, info, calendar, portfolio and store pages, page-specific headers, footers and sidebars, dropdowns, audio blocks and product blocks. The site has to be published and public.
Next.js can't import that file the way WordPress can. A developer can parse the XML into Markdown or push it into a CMS, though, which saves retyping your blog. Everything else comes from the live Squarespace site.
| Content | In the XML export? | How it gets to Next.js |
|---|---|---|
| Layout pages | Yes, loosely structured | Rebuilt as components, with copy taken from the XML |
| One blog | Yes | Parsed into MDX or a headless CMS |
| Second and later blogs | No | Crawled from the live site or copied by hand |
| Gallery pages | Yes | Images downloaded and re-hosted |
| Store pages and products | No | Rebuilt on a commerce backend |
| Portfolio, events, index pages | No | Rebuilt from the live site |
| Headers, footers, navigation | No | Rebuilt as layout components |
| Design, fonts, custom CSS | No | Rebuilt from scratch or from a new Figma design |
| Uploaded files on /s/ URLs | Linked only | Downloaded and kept at the same paths |
Two things catch people out. First, the images in the export still point to Squarespace's CDN. Download every one and host it yourself. You don't want the new site depending on a platform you're about to cancel. Second, crawl the whole live site before you cancel anything. That crawl is your content backup and your URL inventory in one go.
Which Squarespace URLs need redirects?
Any URL with traffic, backlinks or an index entry needs either a redirect or an identical path in Next.js. I pull the list from three places: the site's /sitemap.xml, the Performance report and Page indexing report in Google Search Console, and the top landing pages in analytics. Then I sort them by pattern. Exact paths depend on your slugs and settings, but these are the usual ones.
| URL type | Typical Squarespace pattern | What I'd do in Next.js |
|---|---|---|
| Blog posts | /blog/post-title, or dated paths like /blog/2019/3/4/post-title on older sites | Keep the slug; one pattern rule for dated paths |
| Categories and tags | Query strings such as /blog?category=News | Map to new category pages or the blog index |
| Blog pagination | /blog?offset=... | Redirect to /blog |
| Products | /store/p/product-name (under your shop page slug) | Keep the path or map it to the new product URL |
| Portfolio items | /portfolio/item-name | Keep the path where you can |
| Uploaded files | /s/file-name.pdf | Serve the same file from the same path |
| Images | images.squarespace-cdn.com/... | Re-host and update the links in content |
Keep /s/ file links alive for free
Put downloaded PDFs in your Next.js public/s/ folder. They're then served at exactly the same /s/file-name.pdf URL, so links from emails, old PDFs and other sites keep working with no redirect at all.
Query-string URLs are where redirects usually go wrong. A Next.js redirect source matches the path, not the query string, so /blog?category=News needs a rule with a has condition, as the Next.js redirects documentation explains. Without it, the request just lands on the blog index. I built the free Redirect Map Builder for this kind of list. Paste old and new URL pairs and it writes the redirects() array for next.config.js, and it flags chains, loops, duplicates, trailing-slash mismatches and query strings before they reach production.
// next.config.js
module.exports = {
async redirects() {
return [
{ source: '/blog/:y(\\d{4})/:m/:d/:slug', destination: '/blog/:slug', permanent: true },
{ source: '/store/p/:slug', destination: '/products/:slug', permanent: true },
]
},
}
In Next.js, permanent: true sends a 308. Google treats that the same as a 301 for passing signals.
How do you keep your rankings during the move?
Keep URLs where you can, redirect the rest one to one, carry over the metadata and change as little else as possible on launch day. Here's the order I'd do it in.
- 1
Inventory every URL
Combine the sitemap, Search Console and analytics into one sheet, with traffic and backlinks next to each URL.
- 2
Freeze slugs
Decide the new URL for every old one before design starts. Keeping the same slug is always the safest choice.
- 3
Carry over metadata
Copy each page title, meta description, image alt text and Open Graph image from Squarespace into the new pages.
- 4
Add structured data
Squarespace adds some markup for you. In Next.js you add JSON-LD yourself, so cover Organization, Article and Product where they apply.
- 5
Test redirects on staging
Run the whole old URL list against staging and confirm each one returns a single 301 or 308 to a live page. Keep staging set to noindex.
- 6
Switch DNS carefully
Point the domain at the new host, but copy the MX, SPF and verification records first so email keeps working.
- 7
Submit and watch
Submit the new sitemap in Search Console and check the Pages report and 404s daily for the first few weeks.
My Next.js technical SEO checklist covers the build side: metadata, canonicals, sitemaps, robots rules and rendering. For structured data, the free Schema Markup Generator writes the JSON-LD for you.
If you bought the domain through Squarespace, you can leave it registered there and only change the DNS records. If email breaks anyway, it's nearly always a missing MX or SPF record (see email stopped working after a website move). If rankings dip, start with the redirects and the Search Console Pages report, as I explain in traffic dropped after a website redesign.
Where does your content live after Squarespace?
In one of three places: MDX files in the code, a headless CMS such as Sanity, or headless WordPress. On Squarespace your team edits pages in a visual editor. Next.js has no editor of its own, so this choice affects cost and day-to-day work more than anything else in the project.
| Option | Best for | Who edits | Trade-off |
|---|---|---|---|
| MDX files in the code | Small sites that rarely change | A developer, through Git | Marketers can't publish without help |
| Headless CMS such as Sanity | Teams publishing often | Anyone, in a web editor | One more service and schema setup |
| Headless WordPress | Teams who already know WordPress | Anyone, in WP admin | Two systems to host and update |
I've compared Sanity and headless WordPress for Next.js in a separate post, and I build headless WordPress sites too.
If you sell on Squarespace, know that Next.js doesn't come with a store. You'd pair it with a commerce backend, usually Shopify or WooCommerce, and that's a bigger project than a brochure site. It pays off when you need a custom shopping experience. If the shop is the whole business, a regular Shopify store may suit you better than a custom frontend.
How much does a Squarespace to Next.js migration cost?
About the same as building a new Next.js site of the same size. Almost nothing exports in a usable form, so the blog import and the redirect map are the only real extras. For sourced market ranges, see my Next.js website cost breakdowns for the US, UK and India. Where a quote lands inside those ranges comes down to these drivers.
| Cost driver | Keeps cost down | Pushes cost up |
|---|---|---|
| Page templates | A handful of distinct layouts | Many one-off layouts |
| Design | Rebuild the current look | New design in Figma first |
| Blog | One blog with clean posts | Several blogs, hundreds of posts, messy formatting |
| Content editing | MDX files | Headless CMS with custom schemas and previews |
| Commerce | No store | Products, variants, checkout, customer accounts |
| Integrations | A contact form | CRM, bookings, member areas, scheduling |
| SEO risk | Few URLs, little link equity | Many ranking URLs, query-string archives, backlinks to files |
Running costs change too. The Squarespace subscription goes away, and you pay for hosting instead, plus a CMS plan and a form service if you use them. Hosting a small Next.js marketing site can cost close to nothing, but the bill can creep up with traffic and features, so compare Vercel and Cloudflare pricing before you pick.
How long does the migration take?
Mostly it depends on the rebuild and the content work. A store, several blogs or a new design all add time. The phases don't change with size: crawl and inventory, content export and cleanup, design and build, redirect map and SEO checks, staging review, then the DNS switch and monitoring.
Keep Squarespace live and paid until the new site has been stable for a few weeks. If something was missed, you can still go back and look at the old page. For timelines by platform, see how long it takes to build a website.
Should you move to Next.js or to WordPress?
Go to Next.js when you want top page speed, custom features, a design no template can produce, or a site your developers extend in code. Go to WordPress when your team wants to keep editing pages visually without calling a developer. Squarespace's export is built for WordPress, so a blog moves across more cleanly there.
| Factor | Next.js | WordPress |
|---|---|---|
| Squarespace blog import | Custom parsing of the XML | Built-in importer |
| Editing for non-developers | Needs a headless CMS | Built in, with a page builder |
| Speed and Core Web Vitals | Very fast when built well | Good with careful setup |
| Custom features and apps | Strongest option | Plugins or custom PHP |
| Ongoing upkeep | Dependency updates | Core, plugin and theme updates |
If WordPress sounds closer to what you need, I've written up that route in Squarespace to WordPress migration without losing SEO.
What should you ask a developer before you hire?
Ask how they'll handle the content Squarespace doesn't export, the redirect map, /s/ file links and your email DNS records. I'd ask these five:
- How will you get content that the Squarespace export leaves out, such as store, portfolio and event pages?
- Will you give me a full redirect map, as a sheet, before launch?
- How will you handle /s/ file links and query-string category URLs?
- Who edits content after launch, and in which tool?
- How will you protect our email records when DNS changes?
If the answer is "we'll just export it", they haven't read Squarespace's export page.
What's the next step?
Start with your URL list. Export your Squarespace sitemap, download your top pages from Search Console and run the pairs through the Redirect Map Builder to see how messy the move really is. If you'd like a written scope first, the free Project Scope Generator turns a two-line brief into one. When you're ready, book a 20-minute call and send me the list. I'll tell you what moves, what gets rebuilt and whether Next.js is the right destination at all.



