Moving A Website To Squarespace: What Actually Transfers And What Doesn't

Squarespace's built-in importer moves blog posts, authors, publish dates, and most images, but it leaves behind themes, plugins, custom post types, forms, redirects, and hand-built layouts. That gap between content and presentation is where most migrations run into trouble, and it applies differently across WordPress, Wix, Shopify, Webflow, and static HTML sites. Redirect mapping decides whether search rankings survive the switch, and DNS or email misconfigurations tend to fail silently, showing up weeks after launch rather than immediately. A straight port preserves what already works, while a redesign costs roughly three times as much but avoids carrying old mistakes into the new site. Migration duration runs two to six weeks for most small sites, scaled almost entirely by page count and how much custom functionality has to be rebuilt by hand.

Squarespace's built-in importer will pull your WordPress posts, their authors, their publish dates, and most of their images into a new blog collection. It will not pull your theme, your plugins, your custom post types, your forms, your redirects, or the careful layout work someone did on your homepage three years ago. That gap is the whole story of a website migration to Squarespace, and it's where most projects go sideways.

So this is a plain accounting of what moves, what breaks, and what you have to rebuild by hand. I'll cover WordPress, Wix, Shopify, Webflow, and static HTML sites, plus the SEO work that decides whether your traffic survives the switch or drops off a cliff in week three.

Squarespace importer transfers posts, pages, images, and metadata only

Squarespace's importer is a blog importer with a generous name. Point it at a WordPress site and it fetches posts, pages, categories and tags, author names, publish dates, and the images embedded in post bodies. That's a real amount of work saved, and if your site is a writing-first blog with 400 posts, the importer will do in twenty minutes what would take you a month by hand.

Here's the part that matters more than the feature list: the importer moves content, not presentation. Every post arrives as raw text and images inside Squarespace's editor. The typography is whatever your new template says it is. Pull quotes styled with a WordPress theme class arrive as ordinary paragraphs. A three-column feature grid you built with a page builder arrives as three stacked blocks of text, in the wrong order, missing its icons.

Rough map of what survives a WordPress import intact, what limps through, and what never arrives:

Item	Transfers cleanly	Needs hand work	Doesn't come at all
Blog post text and titles	Yes	Formatting cleanup	—
Post images	Usually	Alt text, captions, sizing	Galleries built by plugins
Categories and tags	Yes	Consolidation	—
Static pages	Text only	Full layout rebuild	Page-builder sections
Forms and submissions	No	—	Rebuild in Squarespace Forms
Plugins and their data	No	—	Replace with native features or code
Menus and navigation	No	Rebuild by hand	—
Comments	No	—	Export first if you want them
URL structure	Sometimes	Slug fixes	Custom permalink patterns

Notice how many rows sit in the middle column. That middle column is the actual project. Anyone quoting you a migration price based on "just run the importer" hasn't looked at the middle column.

WordPress sites vary wildly; complexity determines migration duration

WordPress is the most common origin and the messiest one, because WordPress sites vary so wildly. A clean install running a well-behaved theme with fifteen posts is a two-day job. A ten-year-old site running a page builder, a membership plugin, a custom taxonomy for staff bios, and 900 posts is a different animal entirely.

Start by taking inventory before you touch the importer. Open your WordPress admin and write down every plugin that produces something a visitor can see: forms, sliders, event calendars, testimonial rotators, booking widgets, custom post types, related-post modules. Each one is a decision you'll have to make. Some map onto a Squarespace native feature. Some map onto a block plus a bit of custom code. Some don't map at all, and you'll need a third-party embed or a rethink of what that section is doing.

Custom post types must be remapped to Squarespace collections

If your WordPress site uses custom post types for staff, case studies, properties, or products, the importer has nowhere to put them. Squarespace organizes content into collections: blog, events, products, gallery, portfolio. Custom post types have to be remapped onto one of those, and the mapping is rarely one-to-one. A staff directory with fields for headshot, title, phone, bio, and specialty might land in a blog collection where those fields become body content, or in a portfolio collection where the layout is closer but the fields aren't structured.

Pick the collection type based on how visitors browse, not on how the data was stored. A property listing set that people filter by neighborhood works differently than a staff page that people scan top to bottom. When the mapping gets ugly, that's usually the point where custom Squarespace builds and where code fits in stops being optional and starts being the cheapest path to the thing you want.

Media library files and linked assets often don't migrate automatically

Images inside post bodies usually come across. Featured images sometimes do. PDFs in your media library, downloadable price sheets, whitepapers behind a form: those often don't. If your old site links to /wp-content/uploads/2023/rate-card.pdf from six different pages, that file needs to exist somewhere on the new site and every link needs updating.

Download your full media library before you cancel hosting. All of it. You will find something in there you forgot you needed, and once the old server is gone it's gone.

Wix, Shopify, Webflow, and hand-coded sites require manual content extraction

Wix has no export. None. Whatever your Wix site contains, you're copying it out by hand or scraping it. Blog posts have to be pasted one at a time, images downloaded one at a time from the live pages. For a small brochure site that's an afternoon. For a Wix blog with 200 posts, budget real hours or write a script.

The upside of a Wix migration is that you get to throw away the layout constraints. Wix's absolute-positioning editor produces sites that look one way on desktop and get rearranged on mobile, and it teaches people to design around the tool's limits. Rebuilding in Squarespace's section-based editor means you're rebuilding the intent, not the pixel positions. Bring the copy, bring the photos, redraw everything else.

Shopify to Squarespace is a product data problem more than a design problem. You can export products, variants, and inventory as CSV and import them into Squarespace Commerce, but the column formats don't match perfectly and variant handling differs between the two platforms. Customer accounts don't move. Order history doesn't move. Subscriptions definitely don't move. If you run a store with recurring billing, sort out what happens to those customers before you pick a launch date, not after.

Webflow and hand-coded HTML sites both export as static files, which sounds helpful and mostly isn't. You get clean markup you can copy text out of, and you get CSS that has no relationship to how Squarespace styles things. Treat these as content sources: harvest the copy, harvest the assets, harvest the URL list. Rebuild the rest.

One thing that carries over from every platform, and this is the underrated one: your existing site is documentation. It records which pages people visit most, which headlines you settled on after three rounds of debate, which service descriptions your sales team quotes verbatim. Before anything moves, pull twelve months of analytics and sort pages by traffic. That list tells you which twenty pages deserve careful attention and which eighty can be consolidated or dropped.

---

Broken redirects after migration tank search rankings permanently

This is the section people skip, and it's the section that causes the panicked email six weeks later. A website migration to Squarespace changes your URLs unless you go out of your way to prevent it, and changed URLs without redirects mean every ranking page in Google's index now points at a 404.

Squarespace has firm opinions about URL structure. Blog posts live under a collection path. Pages live at the root or nested under a folder. WordPress permalink patterns like /2023/07/post-name/ or /blog/category/post-name/ won't survive as-is. Neither will Wix's /post/ prefix or Shopify's /collections/ and /products/ paths.

The sequence that works:

1. Crawl the old site and export every indexed URL, before you change anything. A crawler, your XML sitemap, and Google Search Console's page report together will get you close to complete coverage.
2. Build the new site's URL structure deliberately. Decide slugs on purpose rather than accepting whatever the importer generates. Short, readable, keyword-relevant. The rules for writing Squarespace URL slugs are worth reading before you lock in 300 of them.
3. Map old to new in a spreadsheet. Two columns. Every old URL gets a destination, even if that destination is a parent category page because the original content is being retired.
4. Load the redirects into Squarespace before launch, not after. They live in the URL Mappings panel, one rule per line, using /old-path -> /new-path 301 syntax.
5. Verify after launch by crawling the old URL list against the live site and checking for anything that returns a 404 or a redirect chain.

That fourth step trips people up more than the others. Redirect chains, where an old URL points to a second URL that points to a third, bleed authority and slow crawling. If you're touching a site that has already been migrated once before, you may inherit chains you don't know about. Working through 301 redirects and 404 handling on Squarespace is the single highest-use hour of a migration.

Your redirect map is the most valuable file in the entire project. Build it first, keep it in version control if you can, and hand a copy to whoever maintains the site after you.

Beyond redirects: page titles and meta descriptions don't transfer from WordPress SEO plugins. If you spent years writing custom title tags in Yoast or Rank Math, that data lives in the plugin's database tables and the importer ignores it. Export it before you go, then re-enter it in Squarespace's SEO fields page by page. Tedious, unavoidable, and much cheaper than rewriting a hundred title tags from memory.

Structured data is a similar story. Schema markup generated by plugins vanishes. Squarespace outputs some schema natively for products, events, and blog posts. Anything more specific, LocalBusiness with service areas, FAQ markup, review markup, gets rebuilt as custom code injection.

Silent failures in DNS and email setup surface weeks after launch

Some migration damage shows up immediately: a 404, a broken image, a form that doesn't send. Those get fixed in the first week because someone notices. The dangerous failures are the silent ones.

• Email deliverability. If your domain's DNS moves and someone forgets the MX records, mail stops. If SPF and DKIM records don't come along, mail starts landing in spam. Copy your full DNS zone file before you change nameservers.
• Tracking gaps. Google Analytics, Meta Pixel, LinkedIn Insight, call tracking, heatmaps. Each one is a snippet that lived in your old theme and now lives nowhere. Reinstall them in Squarespace's code injection panel before launch, and check that events fire as expected.
• Third-party embeds. Booking widgets, chat, review carousels, MailChimp signup forms, calculators. These usually work, but some rely on scripts that conflict with Squarespace's own JavaScript, and the failure mode is often a widget that renders fine on desktop and collapses on mobile.
• Internal links inside post bodies. The importer brings your posts across with their old absolute URLs intact. A post linking to https://oldsite.com/services/consulting keeps pointing at a domain you no longer control. Find and replace across the whole collection.
• Font and brand drift. Your old site used a licensed typeface. Squarespace's default library may not include it. You can now upload OTF, TTF, and WOFF files directly, so if you have the license files, uploading custom fonts to Squarespace keeps your brand from softening into whatever the template ships with.

Add one more to the list, because it's the one that stings: image alt text. Alt text from a WordPress media library sometimes rides along and sometimes doesn't, and there's no warning either way. Spot-check twenty images after the import. If the alt fields are empty, you've lost accessibility and image search visibility in one stroke, and you'll want to know that in week one rather than in month six.

Build on a trial URL while keeping the old site live

Build the new site on a Squarespace trial URL first. Every Squarespace site gets a temporary address like yoursite.squarespace.com, and you can build, review, and revise there for as long as the trial and then the subscription allow, with the old site fully live the entire time.

A workable order of operations, roughly:

• Week one: inventory and export. Content, media, DNS zone, analytics data, plugin list, URL crawl. Nothing gets built yet.
• Week two: structure. Sitemap for the new site, URL decisions, collection mapping, redirect spreadsheet started.
• Weeks three to five: build and import. Template setup, page layouts, content import, hand-rebuilding of anything the importer mangled.
• Week six: pre-launch checks. Redirects loaded, tracking installed, forms tested end to end (send yourself a submission from a phone, not just a desktop), mobile review on a real device, page speed pass.
• Launch day: point DNS. Keep the old hosting alive for at least thirty days afterward.

That last point is not optional. Do not cancel the old host on launch day. You will discover a missing PDF, a forgotten subdomain, an image you can't find anywhere else. Thirty days of overlap hosting costs almost nothing and has saved more projects than any other single habit.

Launch mid-week and mid-morning, when you're awake and available. Friday afternoon launches are how you spend a weekend on the phone with a registrar.

Straight ports preserve working sites; redesigns cost three times as much

Here's the judgment call worth making early, because it changes the budget and the timeline by a factor of three.

A straight port makes sense when your current site converts well, your content is current, and your only problem is the platform, high hosting costs, plugin maintenance, a developer you can no longer reach. You like the site. You want the same site, somewhere easier to run.

A redesign makes sense in every other case, and I'd argue it's the more common one. If you're already touching every page, rebuilding every layout, rewriting every URL and re-entering every title tag, you have done most of the labor of a redesign anyway. The incremental cost of also fixing the navigation, the messaging hierarchy, and the mobile experience is much smaller than doing those things as a separate project six months later. Ports carry old mistakes across. So do most migrations sold as ports.

Non-profits hit this fork especially hard, because their old sites often accumulated pages for grant reporting, board minutes, and program archives that no visitor has opened in years. The migration is a rare licensed excuse to prune. If that's your situation, what nonprofit sites need that stock templates miss covers the structural side of serving donors, clients, and funders from one set of pages.

Whichever way you go, decide before the build starts. Migrations that turn into redesigns halfway through are the ones that run over on both time and money, because the design decisions get made under deadline pressure instead of before the clock started. If you want a sense of what a finished rebuild looks like across different industries, the Squarespace project work in my portfolio shows the range.

Commerce plans remove transaction fees but cost more than basic tiers

Squarespace pricing is tiered: lighter site plans at the low end, commerce plans above them, and the commerce tiers remove the transaction fee that applies on lower tiers. Plan names and rates change, so check squarespace.com/pricing for what's current rather than trusting a number in any article, including this one. The breakdown of how the plan tiers compare is useful for understanding the structure and where the feature lines fall.

The unexpected invoice is usually domain-related. If your domain is registered somewhere else, you can keep it there and just change DNS, or transfer it in. Transferring has a waiting period and requires an auth code from your current registrar. Get that code early. Registrars are slow, support queues are slower, and a domain transfer stuck in a 60-day lock will delay a launch by two months for reasons nobody controls.

Budget separately for the things the platform doesn't do natively. Advanced form logic, a filterable directory, member gating, a custom booking flow: these need either a third-party integration or custom code, and either way they're a line item. Pretending otherwise during scoping is how a fixed-price migration turns into an hourly one without anyone deciding that on purpose.

FAQ

How long does a website migration to Squarespace take?

Migrating a website to Squarespace typically takes two to six weeks for most small business sites, driven almost entirely by the page count and how much custom functionality has to be rebuilt. A twelve-page brochure site with a contact form moves fast. A 300-post blog with a staff directory, an events calendar, and a resource library takes the long end of that range, and the content import is the smallest part of the work.

Will I lose my Google rankings when I move to Squarespace?

Not if the redirects are right. Rankings follow URLs, so a complete 301 map from every old URL to its new home preserves the authority those pages built. Expect a short, shallow dip in the first two to four weeks while Google recrawls and reconciles the new structure, then recovery. Sites that lose rankings permanently almost always skipped or half-finished the redirect map.

Can I keep my domain name when switching to Squarespace?

Yes, always. You can point your existing domain at Squarespace by updating DNS records at your current registrar, or transfer the registration to Squarespace outright. Pointing is faster and reversible; transferring consolidates billing. Either way, save a copy of your existing DNS records first, especially the MX records that route your email.

Do my blog comments transfer?

No. Squarespace removed native commenting, so WordPress comments have nowhere to land. If comments matter to you, export them from WordPress before the migration and either archive them or move to a third-party commenting service you embed on post pages.

Should I import everything or start fresh?

Import the content that earns traffic or gets referenced, rebuild the rest. Pull twelve months of analytics, sort pages by sessions and conversions, and take a clear-eyed look at the long tail. Carrying 200 dead pages into a new site inflates the build cost and gives Google a thin-content problem you didn't have to inherit.

Inventory Your Site Before Migrating a Website to Squarespace

Before you sign up for anything, do the inventory. Crawl your current site and export the URL list. Download the full media library. Save the DNS zone file. Pull twelve months of page-level analytics. List every plugin or widget a visitor can see. That's four or five hours of unglamorous work, and it converts a website migration to Squarespace from a guess into a scoped project with a known shape.

Then look at your top twenty pages and ask whether you'd build them the same way today. The answer to that question decides whether you're porting or rebuilding, and everything downstream follows from it. If you'd rather have someone else hold the spreadsheet and the redirect map when migrating a website to Squarespace, say what you're moving and from where and we can figure out which of the two it is.