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.

Same-domain rebuild or a real site move?

Most “leave Squarespace” jobs are a hosting swap on the same public URLs. Some also rename paths. A few change the domain. Google publishes different procedures for those cases, and mixing them is how people file the wrong paperwork.

What actually changes	Google’s guide	Change of Address?	The job
Same URLs, new host/CDN	Site move with no URL changes	No	DNS cutover, strip noindex / Disallow, monitor both hosts
Same domain, new paths	Site move with URL changes	No	1:1 301/308 map + new sitemap in GSC
New domain or subdomain	Same URL-change guide + Change of Address	Yes, after 301s are live	Redirects, COA, keep the old domain paid

Google’s own Change of Address help is blunt about combining a move with a full information-architecture rewrite: traffic loss is more likely because Google has to 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.

Classify the project in writing before anyone opens Figma.

• Public hostname stays the same (www vs apex already decided)
• Paths stay identical for money pages and ranking posts
• Paths will change (list them; each needs a 301)
• Domain or subdomain will change (COA is in scope)
• Design will change on the same URLs (allowed; do not also thrash titles)

A pretty rebuild on the same URLs is a hosting move. A pretty rebuild that also invents new slugs is a site move. Those are not the same week of work.

What to inventory before anyone touches DNS

Do this while the Squarespace site is still the live production site. The crawl is what Google already saw. The CMS export is what the platform will admit it can give you.

Asset	How to capture	Why it matters
All public URLs	Full crawl (Screaming Frog, Sitebulb, or similar) + live sitemap XML	Redirect map starts here
Indexed URLs	Google Search Console → Pages / URL Inspection samples	Catch orphan URLs crawlers miss
Top landing pages	Search Console by clicks, last 3–16 months	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

Squarespace auto-generates a sitemap at /sitemap.xml on the primary domain. Official help: View your site map. You cannot edit that file. It excludes disabled pages, password-protected pages, pages hidden from search, uploaded-file URLs, and old URLs that only exist as redirects. So the sitemap is a start, not a complete index of everything Search already knows.

Also export what Squarespace will give you. Pair the XML with the rendered-site crawl. The crawl wins when they disagree.

Checklist before anyone touches DNS:

• Crawl saved as CSV with status codes and titles
• Live /sitemap.xml downloaded and dated
• XML export downloaded and dated
• Commerce CSV exported if you sell on Squarespace
• 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
• Registrar and DNS logins live in a company password manager — see who owns the site when you leave

If GSC still sits in a freelancer’s Google account, stop. You cannot monitor a migration you cannot prove you own.

What Squarespace’s XML export actually includes

Squarespace’s built-in export produces a WordPress-compatible .xml file. Official steps live in Exporting your site: site must be Public, then Import & export content → Export → WordPress icon. The file is WordPress-format even if you are not going to WordPress. Click the icon anyway.

Squarespace is explicit that not everything exports, because many features depend on their JavaScript and CSS. Treat the XML as useful for blog copy and basic page text — not for design, layout, or a full commerce catalog.

Usually in the XML	Usually not in the XML
Layout page text	Gallery / album / cover / index / portfolio / store pages as designed
One blog collection: posts, and comments up to the documented cap	Page-specific headers, footers, sidebars
Text blocks; thin text from some embed blocks	Audio blocks, member areas, form submissions
Basic page copy you can rebuild against	Code injection, custom CSS, scheduling widgets

Products are a separate job. Squarespace’s product .csv path is documented under Importing products from a .csv: Products panel → Export all. That CSV is built for Squarespace’s own importer, not for a custom cart. Re-host images. Do not point production product photos at Squarespace CDN URLs you plan to cancel.

Export procedure:

1. Set site availability to Public so the exporter and the sitemap can see the same site Google sees.
2. Run Import & export content → Export → WordPress.
3. Download the .xml the day it finishes. Date the filename.
4. If you sell, Export all from Products. Date that CSV too.
5. Copy code injection, header/footer scripts, and any hidden landing pages the XML will skip.
6. Crawl the live site the same day. Diff crawl URLs against the XML slugs.

The XML is a manuscript. The crawl is the library catalog. Migrations that trust only the manuscript miss the stacks Google already filed.

Do slug changes on Squarespace create redirects?

No. Squarespace assigns a slug from the page title, and you can edit it in page settings. Official URL slugs help says traffic does not automatically follow a slug change. Old links, typed URLs, and QR codes 404 unless you add a mapping.

That matters twice:

1. Before you leave. If someone “cleaned up” slugs last year and never mapped them, your crawl already contains the damage. Fix those 404s on Squarespace first, or carry them into the new host on purpose.
2. During rebuild. Designers love prettier paths. Every prettier path is a 301 you now owe.

Squarespace URL Mappings syntax, from URL mappings:

/old-url -> /new-url 301

Rules that bite people:

Rule	What happens if you ignore it
Old URL must no longer exist (deleted, disabled, or slug-changed)	Mapping never fires; the live page wins
Status is 301 or 302	Omit the code and you may get a temporary 302
Homepage / is not a valid source	You cannot 301 the root inside Squarespace mappings
Mappings live on Squarespace	They die the second DNS points somewhere else

Use Squarespace mappings only for cleanup while you are still hosted there. The migration map belongs on the new edge.

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.”

Google’s URL-change guide wants a mapping of old URLs to new URLs, then server-side permanent redirects — HTTP 301 or 308 — and it tells you to avoid chains. Googlebot can follow up to 10 hops; they want you at the final URL in one hop, and not more than three if you cannot help it. Permanent redirects do not, by themselves, cause a loss of PageRank. Blanket-redirecting everything to the homepage does cause a mess. Read it in How to move a site.

Build procedure:

1. Paste every old URL into column A (from the crawl, not from memory).
2. Mark each row: keep path, change path, or retire (404/410 on purpose).
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.
7. Use HTTP 301 or 308 at the edge. Do not use 302 for a permanent leave.
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

Retired URLs need a decision, not a shrug:

Retired page type	Prefer	Avoid
Near-duplicate service page	301 to the living equivalent	Soft-404 “coming soon”
True dead campaign	410 or honest 404	301 to homepage “just in case”
Paginated tag archives	301 to /blog or the parent	Hundreds of thin 200s
Old image CDN paths	301 to the rehosted file	Hotlink rot after cancel

Export the sheet to the format your host expects. The artifact is part of the handoff — if you cannot leave cleanly, you do not own the migration.

Where redirects live after you leave Squarespace

Once the domain points at Netlify, Cloudflare, Webflow hosting, or any other edge, Squarespace URL Mappings are museum pieces. They do not travel.

New host	Where 301s live	Backup you keep
Netlify	_redirects or netlify.toml redirects — see Netlify redirects	The CSV plus the committed file
Cloudflare	Bulk Redirects or Rules	Exported rule list
Webflow hosting	Platform 301 UI	CSV export of rules
Self-hosted / nginx	Server config	The config in git

Netlify _redirects shape for a typical leave:

/services/hvac  /services/heating-cooling  301
/gallery        /work                      301

Force HTTPS and host canonicalization in the same pass, but do not stack them into chains. http://example.com/old → https://www.example.com/old → https://www.example.com/new is three hops for a user who typed the worst variant. Collapse to one hop from each variant you still see in logs.

Checklist for the redirect artifact:

• Every crawl 200 has a keep or a 301
• No row redirects to a URL that itself redirects
• Homepage variants (www / apex / http) resolve in one hop
• File is in git or an exported backup the client holds
• Staging proves the rules before DNS

Pretty can wait one sprint. Redirects cannot.

What must stay identical on launch week

Design can change. Signals should not thrash in the same week. Google’s site-move guidance is “change only one thing at a time”: new domain, new CMS, new layout — sequentially, not as a single stunt.

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

Launch-week freeze:

Signal	Week one	After recovery
Money-page slugs	Frozen or 301’d	Second-pass renames only
Title / H1	Near-identical	Rewrite with a changelog
Canonical	Self-referencing on the live host	Re-check after any CDN rule
robots.txt	Production rules, sitemap line present	Tune crawl waste later
Schema	Same types, valid	Enrich once GSC is quiet

Google’s no-URL-change hosting guide also tells you to drop staging blocks at the start of the move and to lower DNS TTL about a week ahead so the cutover is not stuck in ISP caches. That is Changing your hosting.

A redesign that also rewrites every slug is two migrations wearing one invoice.

Search Console: sitemap, inspection, Change of Address

Add and verify the new property before cutover if the hostname changes. If the hostname does not change, you already have the property — confirm the verification method still works on the new host (HTML file, meta tag, or DNS TXT). Then do three things in this order: redirects live, sample inspect, sitemap submit.

Sitemap. Google’s build and submit a sitemap docs treat a sitemap as a hint, not a command. After a URL-change move they want a sitemap of the new URLs submitted in Search Console. On a same-URL hosting swap, regenerate /sitemap.xml on the new stack so lastmod and the URL list match production, then resubmit. Do not leave the Squarespace sitemap as the only file Google has if that host is going away.

Sitemap job	Same-URL host swap	Path or domain change
File contents	Live canonical URLs only	New URLs from the mapping
Submit in GSC	Resubmit after cutover	Submit new; old sitemap warnings about redirects are expected
robots.txt	Sitemap: line points at the live file	Same, on the new host
Staging sitemap	Never submitted	Never submitted

URL Inspection. Fetch a handful of money URLs and a handful of redirected URLs the morning after DNS. You want: live URL indexed or indexable, canonical is the production URL, no noindex, redirect target is the 200 you mapped.

Change of Address — verified against Search Console Help:

Use it when you move from one domain or subdomain to another (for example oldbrand.com → newbrand.com). Requirements: owner of both properties under the same Google account; domain-level properties (not a path-only property like example.com/blog/); working 301s already in place. The tool tells Google to 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. Google also recommends keeping the old domain paid for at least a year so it is not snatched for spam.

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). Do not chain move A→B→C in a hurry. The tool will not move leftover subdomains you forgot to list.

GSC launch checklist:

• You are an Owner on the property (not a borrowed login)
• www, apex, http, and https variants that still resolve are understood
• HTML/DNS verification survives the new host
• New sitemap submitted after redirects are live
• Change of Address filed only if this is a true domain move
• URL Inspection samples saved as a before/after note

Paperwork is not a redirect.

What breaks with forms, embeds, and commerce

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 the new stack; test 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 the old domain	Update allowed domains
Chat widgets	Domain whitelist	Add the new host
Commerce checkout	Cart URLs change; XML skipped the store	Separate commerce plan; CSV is not a store
Password / member areas	Not in the XML export	Manual rebuild or delay cutover
301 on POST endpoints	Forms fail oddly	Keep form actions on 200 URLs

Commerce is not “a few more rows in the redirect sheet.” Product URLs, cart, checkout, inventory, and payment processor domains are their own move. Export the CSV so you have titles, slugs, SKUs, and prices. Rebuild checkout on the new stack. 301 old product paths to the new product 200s. Do not 301 every SKU to /shop.

Conversion smoke test the morning of launch:

• Every form submits and lands in the real inbox
• Thank-you URLs return 200 or a one-hop 301
• Scheduler books a real test slot
• Newsletter confirm works
• Chat loads on the production host
• If you sell: test add-to-cart, checkout, and a refundable order

Rankings will not save a dead lead pipe.

Launch-day sequence that protects SEO

Google’s hosting guide starts the move at DNS, after the new copy is tested and crawl blocks are gone. Their URL-change guide starts the move when redirects turn on. A Squarespace leave is usually both: new files on a new host, then DNS, with 301s already deployed for any path that could not stay identical.

1. Final crawl of the old site archived (CSV + /sitemap.xml + XML export).
2. New site live on the production host with staging noindex, basic-auth, and Disallow: / removed.
3. Redirect rules deployed and sampled (homepage, top 20, random 20, a known 404, the old logo URL).
4. TTL already lowered (about a week out, per Google’s hosting guide).
5. DNS / domain cutover during a low-traffic window if you can choose. If the domain is registered at Squarespace and you are transferring it away, that is a separate registrar process — Transferring a domain away from Squarespace — and it is a bad week to also invent new slugs.
6. Fetch a handful of URLs with Search Console URL Inspection.
7. Submit the new sitemap.
8. File Change of Address only if this is a true domain move.
9. 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. Do not disconnect the domain in Squarespace until the new DNS answers correctly from more than one resolver.

If the domain was only connected to Squarespace (registered elsewhere), you are reversing Connect a third-party domain: change A/CNAME/nameservers at the registrar, leave Squarespace’s required records behind, and wait out TTL. That is a hosting move. Treat it like one.

Typical records you are replacing (confirm current values in the registrar before you delete anything):

Record	Often pointed at Squarespace	After leave
A (apex)	Squarespace’s published A set	New host / load balancer IPs
CNAME www	ext-cust.squarespace.com (their connect docs)	New host’s www target
Verification CNAME	Unique verify.squarespace.com host	Remove once disconnected
MX / SPF / DKIM	Mail that must keep working	Do not touch unless mail is moving too

Mail records are not a website migration. If Google Workspace or another mail host is on the same domain, a sloppy DNS paste is how you lose inbox and cards in the same hour.

How to monitor the first 30–60 days

A temporary dip is normal. Google says ranking fluctuation is expected while they recrawl and reindex; a medium site can take a few weeks for most pages to move in the index, and larger sites take longer. 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
Old-host logs	Traffic falling toward zero	Users or Googlebot still hitting Squarespace weeks later

Practical monitoring window:

• Days 0–7: Fix redirects and indexing blockers only. Do not rewrite IA. Do not “improve” titles on the money URLs.
• Days 8–30: Compare query clusters and landing pages to the pre-move baseline. Add missing 301s for tag pages and leftover image paths.
• 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 — that is the Change of Address floor. Google’s URL-change guide says keep redirects as long as possible, generally at least a year, so other sites’ links can be recrawled. Same-domain path maps deserve the same discipline. If Search still sends clicks to an old slug in month eight, that rule stays.

Do not shut down old hosting until old-host logs are boring. Google’s hosting guide says so in those words.

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. Custom craft still belongs on the websites lane. SEO survival is a procedure, not a theme.

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
• The store is the business and nobody scoped checkout as its own project

In those cases, fix ownership and analytics first, then migrate. Split IA changes into a second phase. A studio that will not put the domain and GSC in your accounts is not ready to cut DNS.

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, Squarespace URL Mappings evaporate with the old host, 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 from an expired crawl you never saved, and a second launch.

What you do instead: path-parity launch, redirects tested on the new edge, Squarespace kept until the map is boringly correct. Cancel the old plan after old-host logs are quiet and GSC 404s on money URLs are gone — not the night the new homepage looks finished.

Worked example: same-domain Squarespace → Astro on Netlify

This is a procedure walk, not a client case study and not a traffic-percentage claim.

1. Crawl ~180 URLs; 62 are blog posts that appear in Search Console 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. Tag archives 301 to /blog.
4. _redirects generated from the sheet; QA finds two chains and collapses them to one hop.
5. TTL lowered a week out. Cutover Friday night. Staging noindex removed before DNS.
6. Saturday: URL Inspection on the homepage, two money pages, one 301, one old image URL. New sitemap submitted in GSC. Change of Address not filed — same domain.
7. Week one: 14 soft 404s from old tag pages → add redirects. Forms tested again Monday.
8. Day 45: money queries inside normal noise; blog long-tail mostly intact because slugs never moved.

Parity first. Vanity slugs later. That is the whole trick.

FAQ

Will my rankings dip temporarily?

Often yes, briefly, while Google recrawls and processes redirects. Google’s site-move docs call that fluctuation expected; a medium site can take a few weeks. A short wobble with healthy 301s is different from a cliff caused by 404s, leftover 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 the job a hosting move, which is the boring version — and the version Google’s no-URL-change guide is written for.

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 not leave production <img> tags pointed at Squarespace once you plan to cancel.

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, a submitted sitemap, and monitoring — not Change of Address. Never use the tool as a substitute for redirects, and do not file it for HTTPS or www cleanup.

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, and a 301 on a POST endpoint will not save a form that still posts to Squarespace.

When is migration the wrong project?

When you lack DNS or 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. A custom site can still be the right build — just do not pretend the rankings will survive a weekend of new slugs.

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.