How to migrate from Squarespace to a coded site

Migrating a small business site from Squarespace to a coded setup takes real work but gives you a faster site, full ownership of your code and content, and eliminates the monthly platform fee. The technical parts are well-understood. The hard parts are rarely what you expect, they’re content conversion (Squarespace’s export is bare-bones), form replacement (Squarespace forms don’t carry over), and getting the redirect map right.

This guide covers the full sequence, whether you’re doing it yourself or working with a specialist.

Who this is for

Good fit:

• Small business sites on Squarespace with mostly static content (pages, blog, contact forms)
• Sites currently on Personal or Business plan, not relying heavily on Member Areas or deep Commerce features
• Owners who either want to learn enough to maintain a coded site, or are willing to hire a specialist
• Sites that update weekly at most, not daily

Not a good fit:

• Sites built around Squarespace-specific features: Member Areas (memberships), heavy use of Squarespace Scheduling, or multi-location Commerce
• High-traffic stores processing significant ecommerce volume
• Sites requiring real-time dynamic content or logged-in user areas
• Businesses where the team isn’t willing to touch text files or Git in any form

For sites that don’t fit, consider Ghost (if content-led), Shopify (if ecommerce-led), or staying on Squarespace. See Squarespace alternatives for more options.

Before you start: audit your current site

Migration scope is almost always larger than expected. Inventorying up front prevents mid-migration surprises.

Create a spreadsheet with columns for:

• URL, every page, blog post, and sub-page
• Page type, static page, blog post, product, collection archive
• Content source, is it text you wrote, a Squarespace block, an embedded widget, or something fetched from an integration?
• Status on new site, migrating as-is, rewriting, consolidating, or removing
• New URL, even if identical, document it explicitly for the redirect map later

Also inventory:

• Images and media, total file count and storage size
• Forms, each form, where submissions go, what integrations it triggers
• Integrations, analytics (Google Analytics, Plausible), pixel tracking, booking tools, ecommerce, marketing automation, chat widgets
• SEO assets, current meta titles, descriptions, structured data, sitemap status in Google Search Console
• DNS records, every A, CNAME, MX, TXT record on your domain (you’ll need these post-cutover)

Step 1: Export Squarespace content

Squarespace’s built-in export is basic but it’s a starting point.

1. In Squarespace: Settings → Advanced → Import / Export → Export
2. Download the resulting XML file (WordPress-compatible WXR format)
3. Save a copy somewhere durable (not just the download folder)

The WXR export includes:

• Blog posts (content, categories, tags, author, publish date)
• Most static pages
• Some metadata

It does NOT include:

• Images (filenames reference original URLs, but you need to download images separately)
• Product data
• Member Areas content
• Form submissions or form configurations
• Custom code blocks in some cases
• Layouts, galleries, and complex block configurations

Downloading images

Squarespace does not provide a bulk image export. Options:

• Manual download, right-click each image on the live site and save. Fine for small sites.
• Site crawler, tools like SiteSucker, HTTrack, or wget --mirror can pull every image the site serves
• Scripted approach, parse the WXR file for image URLs and download with a script

Preserve original filenames where possible, they’re often referenced in blog post content.

Step 2: Choose your static site generator

For small business migrations in 2026, three strong options:

Generator	Language	Best for
Astro	JavaScript/TypeScript	Most small business sites, component-based, great for mixed content + marketing pages
Hugo	Go	Very large sites, fast builds, simple template model
Eleventy	JavaScript	Simple sites, minimal config, maximum flexibility

Astro is the most common default in 2026. It feels like modern web development without the complexity of Next.js, has excellent Markdown support, integrates cleanly with Tailwind CSS, and is well-documented. If you’re unsure, start with Astro.

See Static site generator (SSG) for more background.

Step 3: Set up hosting

Cloudflare Pages is the recommended default for 2026 small business sites:

• Free tier covers most small business traffic (500 builds/month, unlimited requests)
• Git-based deploys, push to GitHub, Cloudflare builds and deploys automatically
• Global CDN, automatic SSL, DDoS protection all included
• Custom domain support with automatic SSL certificates

Alternatives: Netlify (similar model, slightly different free tier), Vercel (optimized for Next.js), GitHub Pages (bare-bones but truly free).

Setup:

1. Create a GitHub repository for your site
2. Sign up at Cloudflare Pages, connect your GitHub account
3. Configure build command (npm run build for Astro) and output directory (dist/ for Astro)
4. Your first deploy will be live on a *.pages.dev subdomain
5. Connect your custom domain later, after the site is ready

Step 4: Convert content to Markdown

The goal: one Markdown file per page or post, with frontmatter for metadata.

For blog posts, each file looks like:

---
title: "Post title"
description: "Short summary"
date: 2025-11-12
slug: post-slug
tags: ["tag-1", "tag-2"]
---

Post body in Markdown.

Converting from WXR

Options:

• WXR to Markdown scripts, search GitHub for “wxr-to-markdown” or “wordpress-to-hugo”; several mature converters exist
• Manual for small sites, under 10 posts, copy-paste and reformat is fastest
• AI assistance, paste WXR content into Claude or ChatGPT and ask for Markdown with frontmatter

Verify every converted post renders correctly, the automation rarely handles embeds, galleries, or inline HTML perfectly.

Placing images

• Put images in public/images/ (Astro convention) or equivalent in your SSG
• Update image references in Markdown to use the new paths
• Compress images while you’re at it, most Squarespace sites ship oversized images

Step 5: Rebuild pages and preserve URL structure

This is where migrations most often go wrong.

The critical rule: every existing URL must either work as-is on the new site or have a 301 redirect to its new location.

Astro’s default routing generates URLs from file paths. If your Squarespace blog post is at /blog/about-migration, create src/pages/blog/about-migration.md (or use a dynamic route with the slug from frontmatter).

Don’t change URL structures during migration unless absolutely necessary. If you have to, plan redirects meticulously.

Recreate:

• Navigation (header and footer)
• Key page sections (hero, problem/solution, pricing, contact)
• Blog index and post pages
• Contact page and form
• Any category or tag archive pages

Design can be a near-match or a light refresh, just don’t introduce a full redesign at the same time as the migration.

Step 6: Replace forms

Squarespace forms won’t work on the new site. Pick a replacement.

Simplest: third-party form service

• Formspree, free tier covers 50 submissions/month; paid from $10/mo
• Web3Forms, free unlimited, ads on dashboard
• Basin, paid only, $4/mo

You add a form endpoint to your HTML form’s action attribute; the service handles submission, spam filtering, and emails you the results.

Better long-term: Cloudflare Pages Function

A small JavaScript function that runs on Cloudflare’s edge. Triggered on form submission, it validates the data and sends an email via an email API or (on Cloudflare) the Workers send_email binding.

• Free tier is generous
• No vendor lock-in
• Can include custom logic (conditional routing, CRM integration, etc.)

SiteShiftCo’s own contact form uses this pattern, source visible in the codebase at functions/api/contact.ts.

Test thoroughly:

• Submit the form with real and invalid data
• Verify the email arrives
• Verify spam protection is working
• Test on mobile

Step 7: Preserve SEO assets

This is what separates a clean migration from a ranking disaster.

Metadata per page

Every page needs, at minimum:

• <title> tag, matches what was working on Squarespace unless intentionally updating
• <meta name="description">, ditto
• <link rel="canonical"> pointing to the canonical URL
• Open Graph tags for social sharing (og:title, og:description, og:image, og:url)
• Structured data (JSON-LD), re-implement schema markup for Articles, Organization, LocalBusiness, etc.

Sitemap

• Astro has @astrojs/sitemap, add the integration, done
• Other SSGs have similar plugins
• After launch, submit the new sitemap to Google Search Console and Bing Webmaster Tools

robots.txt

• Place at the root of the site
• Allow crawling by default unless you have a specific reason not to
• Reference the sitemap URL

See Sitemap, Robots.txt, Schema markup, Canonical URL.

Step 8: Build the redirect map

Every URL on the old Squarespace site → its URL on the new site.

Even if most URLs are identical, plan redirects for:

• www to apex (or apex to www, pick one and enforce it)
• HTTP to HTTPS, the new host will usually handle this
• Trailing slash consistency, /about and /about/ should not both work; pick one and redirect the other
• Renamed pages, old slug to new slug
• Deleted pages, redirect to the most relevant alternative, or to the homepage as a last resort
• Squarespace default pages, /config, /login, old preview URLs

Implement redirects in your hosting platform:

• Cloudflare Pages, _redirects file in the project root
• Netlify, same _redirects file
• Vercel, vercel.json with redirects array

Example _redirects:

/old-about         /about               301
/blog/:slug        /blog/:slug          301
/old-product/:id   /products/:id        301
/discontinued      /                    301

See 301 redirect for more on the mechanics.

Step 9: Test on staging

Before cutting over DNS, verify the new site works end-to-end on the *.pages.dev preview URL (or equivalent).

Checklist:

• Every page loads without errors
• Every navigation link works
• Blog pagination works (if applicable)
• Forms submit successfully and emails arrive
• Analytics events fire
• Structured data validates (Rich Results Test)
• Sitemap generates at /sitemap-index.xml or equivalent
• robots.txt is correct
• Lighthouse scores are acceptable on the key pages (aim for Core Web Vitals all green)
• Images load, are compressed, and have alt text
• 404 page renders cleanly
• Test every redirect URL manually or with a bulk tester

Step 10: DNS cutover

Schedule a low-traffic window. For most small business sites, weekday evenings or weekend mornings work well.

Preparation (24–48 hours ahead):

1. Lower TTL on your existing A/CNAME records at your DNS provider to 300 seconds (5 minutes). This means the switch propagates faster when you make it.
2. Note down every DNS record on the domain, A, AAAA, CNAME, MX, TXT, SRV.

Day of cutover:

1. Change the A or CNAME record for your root domain (and www if applicable) to point at Cloudflare Pages. The specific target is in the Cloudflare Pages dashboard (“Custom domains” tab).
2. Verify SSL certificate provisions correctly (usually within minutes on Cloudflare).
3. Test the live site in an incognito browser, bypass any local DNS cache.
4. Keep the Squarespace site active for 24–48 hours as a rollback option.

Do not change MX records unless you’re also migrating email. Email uses different DNS records from web hosting.

Step 11: Post-launch verification

Immediately:

• Site loads at your custom domain
• A few key pages render correctly
• Form submissions work
• Analytics is tracking

Within 24 hours:

• Submit new sitemap to Google Search Console
• Submit new sitemap to Bing Webmaster Tools
• Check every redirect URL with a status-code tester like httpstatus.io
• Monitor any error tracking you have set up
• Verify SSL is fully propagated (use ssllabs.com)

Within 2–4 weeks:

• Check Google Search Console for crawl errors
• Monitor keyword rankings, expect some volatility, stabilizing within a few weeks
• Watch for 404s reported in Search Console and add any missed redirects

Cancel Squarespace only after:

• 30 days of clean analytics on the new site
• No unexplained ranking drops
• All redirects verified working
• Content backup confirmed saved locally

How long does this actually take?

• DIY, for a small business site with up to 30 pages and a blog: 20–60 hours spread over 2–4 weeks. Most time goes into content conversion and page rebuilds, not technical setup.
• Specialist service: 2–4 weeks elapsed, minimal hands-on time from you. Hands-on work from you is mostly content review and design approval calls.
• First-time DIY learning a new SSG: add 10–20 hours on top for learning Astro/Hugo/Eleventy basics.

DIY vs hiring: honest comparison

DIY makes sense if:

• You have 40+ hours to spare across a few weeks
• You enjoy the technical side (or want to learn)
• The site is small and uncomplicated
• Budget is genuinely tight

Hiring a specialist makes sense if:

• Your time is worth more than the labor cost
• You want SEO continuity preserved correctly
• You’re not confident on the technical details, particularly redirects
• The site has meaningful commercial value and you can’t afford a botched migration

SiteShiftCo handles Squarespace-to-coded-site migrations as Starter ($890) for sites up to 15 pages and 30 blog posts, or Core (from $1,900) for sites up to 30 pages and 150 blog posts. Larger agencies typically charge $4,000–$15,000 for similar work.

After migration: how to edit the new site

The most common concern after migrating is: “will I still be able to update my site easily?”

For a Markdown-based coded site, options:

• Edit Markdown files directly, in VS Code, Obsidian, iA Writer, or any text editor. Commit via Git or drag-and-drop in GitHub’s web interface.
• Use a Git-based CMS, Decap, TinaCMS, Keystatic, or Sveltia give you a familiar admin interface that commits to your repository.
• Use an AI assistant, paste your Markdown, describe the change, get updated Markdown back. Works surprisingly well for content updates.
• Use a headless CMS, Sanity, Contentful, or Storyblok if you want a full-featured editorial interface.

Most small business owners using SiteShiftCo-built sites edit Markdown directly or via AI assistants. It’s not harder than Squarespace, just different.

Related

• Squarespace alternatives, if you’re still deciding where to go
• The real cost of Squarespace over 3 years, cost comparison that often drives migration decisions
• Glossary: Site migration, Site export, 301 redirect, Static site, Static site generator (SSG), Core Web Vitals