PublishedVerifiedEvery 6 weeksSources7 namedAuthored bySquareRank Team
Cluster 2K · Migrations
Squarespace SEO migrations — the playbook that protects rankings across every source platform
Every site migration is a redirect-mapping discipline more than a content port. A graceful Wix-to-Squarespace, WordPress-to-Squarespace, Shopify-to-Squarespace, Showit-to-Squarespace, or 7.0-to-7.1 migration with complete 301 redirects typically loses 30 to 50 percent of organic traffic in the first 60 to 90 days and recovers to baseline within 90 to 180 days2. An ungraceful migration with missing redirects can lose 50 percent or more permanently. The per-platform import tools cover content. They do not cover URL mapping, SEO settings re-authoring, or schema reinstallation; those are operator-mediated, and they are where every migration succeeds or fails.
This cluster covers the migration mechanic, the traffic curve, and the per-platform specifics. The leaf articles cover Wix, WordPress, Showit, Shopify, the 7.0-to-7.1 internal migration, and the traffic-drop diagnostic in detail. The implementation layer — URL Mappings syntax, bulk redirect patterns, validation — lives in the Redirects cluster. Read both together for the complete migration playbook.
The mechanic that decides every migration's outcome
A migration is the process of telling Google that the content at URL A is now at URL B. The signal is sent via HTTP 301 redirect from every old URL to its new equivalent. When the signal is complete and consistent, Google transfers the ranking equity from URL A to URL B over a recrawl window of weeks to months. When the signal is incomplete — old URLs that 404, redirects that loop, redirects that point at the wrong destination — the ranking equity is lost. The platform-specific details around content import are secondary. The redirect map is the lever.
Google's published migration guidance1 is direct: "Plan on the move taking longer than you expect." The reranking window is weeks-to-months because Googlebot has to recrawl every redirected URL, follow the 301, validate that the destination is responding correctly, and re-evaluate the destination's content against the search query. The operator's job is to make sure every step of that pipeline works: every URL has a redirect, every redirect points at a live page, every live page has the content Google expected.
What the data says about migration outcomes
30-50%
typical organic traffic drop in the first 60-90 days after a Squarespace migration (Moz, Ahrefs).
The traffic curve every migration shows (the honest version)
Days 1 to 21 after cutover show a 10 to 25 percent organic traffic drop as Googlebot starts recrawling every URL and reranking the new site. Days 21 to 60 stabilise at the lower level — sometimes 30 to 50 percent below pre-migration baseline — while Search Console catches up and Google's algorithm reweights the new structure. Days 60 to 180 recover toward and past baseline as the cleaner SEO install compounds. The recovery curve is steeper when the operator ships better schema, faster page speed, and tighter heading hierarchy on the new site than the old.
Moz's migration tracking2 and Ahrefs' parallel guide7 both place the typical dip at 30 to 50 percent in the first 60 to 90 days. Squarespace migrations cluster slightly higher because the operator is also re-authoring schema, Code Injection, and SEO panel content on the new site — work that did not exist on the source. The drop is the cost of the migration; the recovery is the new site's structural improvements compounding.
§03Platform specifics
Per-platform specifics — what each source platform gives and takes
Squarespace's import tools<InlineCite n={3} sourceId='sq-import-overview' /> cover Wix, WordPress, Shopify, Big Cartel, Tumblr, and Blogger natively. Showit, Webflow, ghost, and most other platforms are manual rebuilds. Each source platform has a distinct loss profile: Wix loses apps and animations; WordPress loses plugins and Yoast/SEOPress structured data; Shopify loses theme customisations and apps; Showit loses everything that was not text and images. The redirect-mapping work is the same in every case. The content-port work is platform-specific.
A one-paragraph summary per platform, with the leaf article for each below. Wix: Squarespace's official importer5 ports text and images; layout, animations, and Wix Apps must be rebuilt manually; Wix's URL pattern uses path segments that Squarespace's URL Mappings normalise during the migration; the leaf article documents the per-app loss list. WordPress: XML-based importer4 ports posts, pages, and comments; loses plugins, custom themes, Yoast and SEOPress structured data, custom post types, and most advanced features; the Yoast schema must be rebuilt via Code Injection on every post. Shopify: CSV product import plus manual rebuild of the rest; the per-product URL pattern differs from Squarespace's; the redirect mapping is straightforward but voluminous. Showit: no automated importer; entirely manual rebuild; photography sites typically map cleanly because the structure was simple to begin with. 7.0-to-7.1: no automated path; manual rebuild within Squarespace; the leaf article covers the in-platform migration.
§04The redirects
The 301 redirect pattern that every migration uses
Every Squarespace migration uses URL Mappings as the redirect mechanism. The pattern is: one row per source URL, one destination URL per row, status code 301, and the entire CSV submitted via Settings > Advanced > URL Mappings. Wildcards work for repetitive patterns (every /wp-content/uploads/* redirects to /static/old-uploads-archive/* for example) but the cleanest migrations explicit-map every important URL row by row. The pattern is mechanical; the discipline is in completeness.
URL MappingsSample migration map — Wix to Squarespace
# Top-level pages/about-us->/about/301/our-services->/services/301/contact-us->/contact/301# Blog posts — Wix's /post/ pattern to Squarespace's /blog/ pattern/post/wix-blog-slug-1->/blog/wix-blog-slug-1/301/post/wix-blog-slug-2->/blog/wix-blog-slug-2/301# Catch-all for legacy paths that no longer exist/legacy-page->/301
Squarespace's URL Mappings documentation6 describes the syntax. The URL Mappings syntax leaf in the Redirects cluster covers the wildcard patterns, the validation step, and the edge cases (loops, chains, missing trailing slashes).
§05What survives
What survives every migration
Domain authority, backlinks to redirected URLs, content that maps cleanly, Search Console history, and the customer relationship to the brand all survive a competent migration. The Google Search Console property has to be re-verified for the new platform, but the historical data and the manual actions history carry over when the change-of-address request is filed correctly. Indexed content with stable URLs survives unconditionally. Backlinks survive when their target URL has a working 301 redirect.
The transfer happens over Google's recrawl window, which is typically four to twelve weeks for the bulk of URLs and longer for the long tail. Search Console's Performance report shows the transition as a brief dip in impressions followed by a recovery curve. The pattern is well-documented1: "Be patient. The move can take a while."
§06What does not
What does not survive without manual work
Structured data (Yoast schema on WordPress, JSON-LD apps on Wix, native rich result blocks on Shopify) does not transfer. Custom 404 pages, custom meta titles and descriptions, alt text on images, Open Graph images, hreflang tags, and any platform-specific SEO settings are re-authored on the new site or they are lost. Internal links pointing at the old URLs become 301 chains until updated; the redirects work but the link equity passes through an extra hop that is slightly weaker than a direct link.
The honest, verified fact: a WordPress migration to Squarespace loses Yoast or SEOPress structured data entirely. The schema must be re-installed on every blog post via Code Injection. The WordPress leaf covers the per-post reinstall pattern. The same is true for Wix's structured-data apps: they are app-level on Wix, not site-level, and they do not export.
The recoverable list is long but tractable: title tags re-authored on each page, meta descriptions re-authored, alt text re-authored on every image, hreflang re-installed via Code Injection, internal links updated to point at the new URLs natively. The work is per-page-per-property; for a 50-page site with 200 images, this is two to five working days of dedicated content QA on top of the platform-specific import work. Plan for it in the migration timeline.
§07Pre-cutover
The pre-cutover checklist
Before pointing DNS at Squarespace, verify the new site against the following list. Every page has the correct meta title and meta description. Every image has alt text. Every blog post has a JSON-LD Article block installed via Code Injection. Every page redirects from its legacy URL via URL Mappings. The sitemap is accessible at /sitemap.xml. The robots.txt is configured correctly (AI checkbox state matches the strategy). The Google Search Console verification is ready to be filed for the Squarespace site on cutover day. A custom 404 page is in place to catch unmapped legacy URLs gracefully.
The single most-skipped item: the custom 404 page. A legacy URL the operator forgot to map will hit Squarespace's default 404 page on cutover day. The default page is functional but unhelpful; a custom 404 page can suggest the homepage, the search, or the contact page, and turn an otherwise-lost visitor into a recovered one. The custom 404 lives in Pages > Not Linked > 404 Page.