Leave Squarespace Without Torching the Rankings You Already Paid For

Yes — you can migrate off Squarespace to a custom site without throwing away the rankings you already paid for, but only if you treat the move as a URL project, not a design project. Inventory every indexed URL, build a page-for-page 301 map, keep titles and primary content stable on launch week, then watch Search Console for 30–60 days. A temporary dip is normal; a permanent cliff usually means broken redirects, blocked staging leftovers, or a redesign that also rewrote every slug. This spoke sits under Websites That Feel Like Films.

The short answer

• Crawl and export before you redesign URLs — the inventory is the source of truth.
• Prefer identical paths on the new host; when paths must change, map old → new with one-hop 301/308 redirects.
• Squarespace’s XML export is a partial head start, not the migration.
• Search Console’s Change of Address tool is for domain moves, not same-domain rebuilds.
• Expect noise for weeks; judge the move on redirect health and recovering queries, not day-three vanity charts.

What to inventory before cutover

Do this while the Squarespace site is still the live production site.

Asset	How to capture	Why it matters
All public URLs	Full crawl (Screaming Frog, Sitebulb, or similar) + sitemap XML	Redirect map starts here
Indexed URLs	Google Search Console → Pages / URL inspection samples	Catch orphan URLs crawlers miss
Top landing pages	Analytics or Search Console by clicks	Protect these first in QA
Blog posts	Titles, slugs, publish dates, categories	Rankings often live here
Images with inbound links	Crawl + Search Console	Hotlinked assets and image search
Forms and thank-you URLs	Manual list	Conversions break silently
Embeds / third-party widgets	Manual list	Scheduling, chat, stores
Canonical host	www vs non-www, http vs https	Avoid redirect chains at DNS time

Also export what Squarespace will give you. As of 2026, Squarespace’s built-in export (Settings → Import / Export, or Advanced → Import / Export depending on your site version) produces a WordPress-compatible XML/WXR file. Treat it as useful for blog copy and basic page text — not for design, layout, galleries, events, albums, index pages, member areas, code injection, form submissions, or a full commerce catalog. Products usually need a separate Commerce CSV export if you sell on Squarespace. Pair the XML with a rendered-site crawl; the crawl is what Google actually saw.

Checklist before anyone touches DNS:

• Crawl saved as CSV with status codes and titles
• XML export downloaded and dated
• Commerce CSV exported if applicable
• Custom CSS / code injection copied out
• Search Console and analytics admin access confirmed under your accounts
• New host staging URL locked behind auth or noindex until cutover

How a 301 map actually gets built

A redirect map is a spreadsheet, then a server config. Not a hope that “SEO will figure it out.”

Build procedure:

1. Paste every old URL into column A (from the crawl).
2. Mark each row: keep path, change path, or retire (410/soft-404 strategy).
3. For keep/change rows, write the final new URL in column B — the URL that returns 200 after launch.
4. Prefer path parity: /blog/my-post → /blog/my-post. Identical paths make the migration boring, which is the point.
5. When marketing insists on cleaner slugs, map old → new explicitly. Never leave the old URL without a destination.
6. Ban chains: old → interim → final. One hop only when you can help it. Google can follow chains; users and some bots get impatient.
7. Use HTTP 301 or 308 at the edge (Netlify _redirects, Cloudflare rules, host config — whatever your stack owns). Do not use 302 for a permanent move.
8. Test 20 high-traffic URLs plus a random sample of 20 long-tail URLs on staging rules before DNS flips.

Example map rows:

Old (Squarespace)	New	Type	Notes
/	/	200 same path	Homepage rebuild, same URL
/about	/about	200 same path	Keep title close
/blog/old-slug	/blog/old-slug	200 same path	Ideal
/services/hvac	/services/heating-cooling	301	Marketing rename — must redirect
/gallery	/work	301	Retired section → nearest equivalent
/old-landing?utm=…	/	301 to clean home	Query strings: decide strip vs preserve

Export the sheet to the format your host expects. On Netlify, that is often a _redirects or netlify.toml redirect block. On Webflow hosting, use the platform’s 301 UI and export a backup CSV of rules. The artifact is part of the handoff — if you cannot leave cleanly, you do not own the migration.

What must stay identical on launch week

Design can change. Signals should not thrash in the same week.

Keep stable for the first 7–14 days unless you have a documented reason:

• URL paths for money pages and ranking blog posts (or airtight 301s if paths change)
• Primary page titles and H1s for those URLs — rewrite later, not on cutover day
• Meta descriptions can tighten, but do not swap every title into clever brand copy overnight
• rel=canonical pointing at the live final URLs (not staging)
• Robots access: remove staging noindex, password walls, and Disallow: / the moment you go live
• Structured data that already worked (Organization, LocalBusiness, Article) — fix errors, do not invent a new schema science project on day one
• NAP consistency for local businesses (name, address, phone) matching Google Business Profile

Google’s own site-move guidance is blunt: combining a domain/host move with a full information-architecture rewrite makes traffic loss more likely because Google must relearn the pages. If you need a deep IA change, stage it — migrate with path parity first, then rename in a second controlled pass with a fresh redirect layer.

Pair launch hygiene with a normal launch checklist for brand sites: forms, analytics, and redirects belong in the same go-live gate.

Search Console: what to do (and what not to file)

Add and verify the new property before cutover if the hostname changes. Submit an updated sitemap after redirects are live.

Change of Address tool — verified against Google’s Search Console Help (current as of writing):

Use it when you move from one domain or subdomain to another (for example oldbrand.com → newbrand.com). Requirements include ownership of both properties under the same Google account, domain-level properties (not a path-only property), and working 301s already in place. The tool helps Google emphasize the new site and forward signals for about 180 days. Maintain redirects at least 180 days — longer if Search still sends traffic through old URLs.

Do not use Change of Address for:

• HTTP → HTTPS on the same host
• www ↔ non-www on the same domain
• Path reshuffles inside the same domain (/old → /new)
• Hosting/CDN swaps where the public URL does not change

Most “Squarespace → custom on the same domain” projects are same-URL or path-map migrations. In those cases, 301s + sitemap + monitoring are the job. Filing Change of Address incorrectly does not fix a bad redirect map.

If you are changing domains, file Change of Address for each relevant old host variant Google documents (including www / non-www as separate cases when required), keep paying the old domain for at least a year so it is not snatched for spam, and do not chain move A→B→C in a hurry.

What breaks with forms and embeds

SEO people watch rankings. Owners watch lead flow. Migrations often break the second while the first looks fine.

Thing	Typical break	Fix before DNS
Native Squarespace forms	Endpoint disappears with the old site	Rebuild forms on new stack; test delivery to inbox + CRM
Form success URLs	Old thank-you pages 404	301 thank-you URLs or recreate them
Embedded scheduling (Acuity, Calendly)	Wrong domain allowlists / CSP	Re-embed and book a test appointment
Newsletter embeds	API keys tied to old domain	Update allowed domains
Chat widgets	Domain whitelist	Add new host
Commerce checkout	Cart URLs change	Separate commerce migration plan
Password / member areas	Not in XML export	Manual rebuild or delay cutover
301 on POST endpoints	Forms fail oddly	Keep form actions on 200 URLs

Run a conversion smoke test the morning of launch: submit every form, trigger every embed, place a test order if you sell online. Rankings will not save a dead lead pipe.

Launch-day sequence that protects SEO

1. Final crawl of old site archived.
2. New site live on production host with staging protections removed.
3. Redirect rules deployed and sampled (homepage, top 20, random 20, 404 logo).
4. DNS / domain cutover (or Squarespace domain disconnect → new DNS) during a low-traffic window if you can choose.
5. Fetch a handful of URLs with Search Console URL Inspection.
6. Submit the new sitemap.
7. File Change of Address only if this is a true domain move.
8. Watch server logs for redirect loops and 404 spikes for 48 hours.

Keep the Squarespace subscription alive until redirects are proven — either via DNS still pointing through a redirect layer you control, or until you are sure no critical dependency still lives inside Squarespace. Do not cancel the old platform the night before cutover.

Monitor the first 30–60 days honestly

A temporary dip is normal. Google recrawls, reprocesses redirects, and reshuffles snippets. Panic redesigns during week one often cause the real damage.

Watch weekly:

Signal	Healthy pattern	Worry pattern
404s in Search Console	Spike then fall as redirects cover gaps	Rising 404s on old money URLs
Redirect errors	Near zero	Chains, loops, redirect to soft 404
Top landing pages	Clicks wobble then stabilize	Money URLs disappear from top queries
Impressions	Soft dip then recovery	Cliff with no redirect coverage
Form completions	Flat or up	Silent zero after launch
Coverage / indexing	New URLs indexed	Staging URLs indexed; canonical wars

Practical monitoring window:

• Days 0–7: Fix redirects and indexing blockers only. Do not rewrite IA.
• Days 8–30: Compare query clusters and landing pages to the pre-move baseline.
• Days 31–60: Decide whether path changes need a second redirect pass or content recovery.

Keep 301s in place for at least 180 days on any URL that still receives Search clicks — Google’s Change of Address guidance uses that floor for domain moves; same discipline helps path maps.

When migration is the wrong project

Do not migrate “for SEO” if the Squarespace site has no meaningful organic traffic and the real problem is conversion, photography, or offer clarity. A custom rebuild can still be right for brand and performance — just do not sell it as a rankings rescue.

Also pause if:

• Nobody owns DNS, Search Console, or the domain registrar
• The redesign requires a brand-new URL tree and new messaging and new tracking in one weekend
• Forms and CRM ownership are unclear
• You cannot staff 30 days of monitoring

In those cases, fix ownership and analytics first, then migrate. Custom craft still matters — see when to leave a template for stack choice — but SEO survival is a procedure, not a theme.

Failure mode: redesign + new slugs + cancelled Squarespace

What breaks: every blog post 404s, the homepage 302s through a temporary URL, staging noindex stays on for a week, and forms post into the void. Rankings fall for months; the team blames “Google punished the redesign.”

What it costs: months of organic recovery, emergency redirect archaeology, and a second launch.

What you do instead: path-parity launch, redirects tested, Squarespace kept until the map is boringly correct. Pretty can wait one sprint. Redirects cannot.

Worked example: same-domain Squarespace → Astro on Netlify

1. Crawl 180 URLs; 62 are blog posts ranking for long-tail queries.
2. Rebuild in Astro with identical /blog/<slug> paths; marketing pages keep /about, /work, /contact.
3. Three retired service pages 301 to the nearest living service URL.
4. _redirects generated from the sheet; QA finds two chains and fixes them to one hop.
5. Cutover Friday night; Search Console sitemap submitted Saturday.
6. Week one: 14 soft 404s from old tag pages → add redirects to /blog.
7. Day 45: money queries recovered within normal noise; blog long-tail mostly intact because slugs never moved.

No invented traffic percentages — the lesson is procedural: parity first, vanity slugs later.

FAQ

Will my rankings dip temporarily?

Often yes, briefly, while Google recrawls and processes redirects. A short wobble with healthy 301s is different from a cliff caused by 404s, noindex, or rewritten URLs. Monitor 30–60 days before declaring failure.

Can I keep the same URLs?

Yes, and you should whenever possible. Point the same domain at the new host and rebuild on identical paths. Same URLs make SEO the boring part of the project.

What about blog posts and images?

Export Squarespace’s XML for post copy, but migrate from a crawl of live URLs so nothing indexed is missed. Re-upload images to the new host, update internals, and 301 any old image URLs that earned links or image-search traffic.

Do I need Search Console change-of-address?

Only for true domain or subdomain moves between hosts Google treats as a site move. Same-domain Squarespace → custom rebuilds rely on 301s, sitemaps, and monitoring — not Change of Address. Never use the tool as a substitute for redirects.

What breaks with forms and embeds?

Native Squarespace forms, thank-you URLs, scheduling embeds, chat widgets, and domain-whitelisted scripts. Rebuild and test every conversion path before DNS flips; SEO checks will not catch a dead inbox.

When is migration the wrong project?

When you lack DNS/Search Console ownership, cannot staff monitoring, or are trying to fix conversion problems by burning the URL graph. Stabilize ownership and measurement first, or split IA changes into a second phase.

CTA

Migrating a brand site off Squarespace and want the redirect map treated like a product? Explore /websites or book a sprint at /contact?intent=websites-sprint.