A Pre-Migration Checklist Before Switching To Squarespace
Before you touch the Squarespace importer, open a spreadsheet and paste in every URL your current site has. All of them. That list is the single most valuable artifact you'll produce while switching to Squarespace, and almost nobody makes it until after something breaks and Search Console starts filling up with 404s.
This is a working checklist, sorted by what you need to collect, what you need to decide, and what you need to have running before launch day. Some items take four minutes. A couple take an afternoon. Run them in order and the migration becomes a boring, well-lit process instead of a weekend of panic.
Export your full URL inventory before losing access
Your old host is a library that's about to close. Get the books out first. Even if you're paid up through next year, treat access as temporary, because the moment you stop paying, some of this becomes unrecoverable.
- A full URL inventory. Crawl your site or export the sitemap, usually at /sitemap.xml. Every page, post, tag archive, category page, and PDF. Add a column for monthly organic traffic pulled from Google Analytics or Search Console so you can see which twelve URLs carry the site.
- Your title tags and meta descriptions. These do not come across in any import. Copy them into the same spreadsheet, one column each. You wrote them once; don't write them twice from memory.
- Original image files at full resolution. Not the 800px versions your old theme served. Pull from your original folders if you have them, or download the largest version the media library holds. Squarespace will compress on its own; feed it something with room.
- Every form submission and email list. Export contacts to CSV from whatever collects them now. Form entries stored in a plugin database vanish with the plugin.
- Blog content as XML or CSV. WordPress gives you a WXR export. Other platforms vary. Do this even if you plan to hand-copy posts, because it's your backup of the text.
- Product data, if you sell things. SKUs, variants, prices, descriptions, inventory counts, and the image filename mapped to each product.
- Your DNS records, screenshotted. The MX records especially. Nothing sours a launch faster than pointing a domain and discovering that email stopped an hour ago.
Keep all of it in one folder with the date in the folder name. You will open it more times than you expect.
Text and images transfer; layouts, plugins, and redirects do not
The importer is decent at text and mediocre at everything else. Blog posts, basic pages, and images usually come through. Layouts, plugins, custom fields, forms, redirects, and metadata do not. I'd rather you know that now than discover it at 11pm on a Thursday with a client asking why the pricing page looks like a Word document.
| Asset | Transfers automatically? | What you do about it |
|---|---|---|
| Blog post text and titles | Usually yes | Spot-check twenty posts for broken formatting and orphaned shortcodes |
| Images inside posts | Often, at reduced quality | Re-upload hero and product images from originals |
| Page layouts and design | No | Rebuild in Fluid Engine; budget real time for this |
| Title tags and meta descriptions | No | Paste back in from your spreadsheet, page by page |
| Forms and their stored entries | No | Rebuild forms, export entries first |
| 301 redirects | No | Write a fresh redirect list before launch |
| Plugin functionality | No | Find a native feature, a code injection, or a third-party embed |
For the full accounting of where the importer succeeds and where it drops things on the floor, I wrote out what survives a move to Squarespace and what quietly doesn't in more detail than fits here.
Decide your scope before switching to Squarespace
Migration tempts you into a straight port: same pages, same order, same words, new paint. Sometimes that's right. Usually it isn't, because the old structure was shaped by an old platform's limits and a business you've since outgrown.
Is this a migration or a redesign?
Answer this out loud before you start. A migration keeps your information architecture and moves it to new rails. A redesign rethinks what the pages are and what each one has to accomplish. Doing both at once is fine, and often smart, since you're already touching every page. What isn't fine is starting a migration and drifting into a redesign around page fourteen, which is how three-week projects become three-month ones. If your instinct is that the site underperforms rather than just looks dated, run through the signals that a rebuild is truly overdue and decide deliberately.
Which URLs are you keeping?
Squarespace has its own path conventions. Blog posts sit under a collection slug, and pages built inside a folder inherit the folder path. So some of your URLs will change whether you want them to or not. Go down your inventory and mark each URL: keep as-is, change with a redirect, or retire entirely. Anything with meaningful traffic gets kept or redirected, never retired. Thin tag archives and duplicate category pages are usually the right things to cut, and it's worth reading up on how Squarespace handles slugs before you commit to a naming pattern you'll be stuck with.
Which plan do you need?
Squarespace tiers run from a basic site plan up through commerce plans, and the commerce tiers are where transaction fees drop and selling features open up. Plan names and prices shift, so check squarespace.com/pricing for the current lineup rather than trusting a blog post's numbers, including mine. What matters for your checklist is one thing: pick the tier your feature list requires before you build, because discovering mid-build that a needed feature sits on a higher tier is an annoying way to spend a Tuesday.
Who owns the domain?
Find out today. If a former developer registered it, or it lives in an agency account nobody has credentials for, that recovery process can take weeks. Log into the registrar and confirm you can edit DNS yourself. This one item has delayed more launches than any design decision.
Build redirects before launch to preserve search rankings
Traffic loss during a platform move is almost always self-inflicted, and almost always redirect-shaped. Google has your old URLs indexed. If they return 404s, rankings drop, and the recovery takes far longer than the prevention would have.
Build your redirect map as a two-column sheet: old path on the left, new path on the right. Every URL you marked "change" gets a row. Squarespace takes redirects in its URL Mappings field, one per line, and the syntax matters, so the mechanics of 301 redirects and redirect chains on Squarespace are worth a read before you paste in two hundred lines. Watch for chains: if old page A once redirected to old page B, point A directly at the new page, not at B.
A redirect written before launch takes ninety seconds. The same redirect written after a ranking drop takes ninety seconds plus six weeks of waiting for Google to trust you again.
Then work through the rest of the pre-launch list: paste your saved title tags and meta descriptions back onto their matching pages, confirm every page has a unique H1, check that images carry alt text after the import (they often don't), and verify your sitemap generates at /sitemap.xml. If you want the whole sequence in one place, the pre-launch SEO run-through covers site-wide settings through post-launch verification.
Keep Google Search Console and Analytics open during migration
Nothing exotic here. This is the set I'd keep in browser tabs during a switch.
- Google Search Console. Non-negotiable. Export your top pages by clicks before migration so you have a baseline, then watch the Coverage report for 404 spikes in the two weeks after launch.
- Google Analytics. Note the property ID now. Squarespace injects the tag in a different place than most platforms, and re-adding it after launch means a gap in your data.
- A site crawler. Any crawler that produces a full URL list with status codes and title tags. Run it once on the old site for your inventory, once on the staging build to catch broken internal links, once after launch.
- PageSpeed Insights. Run it on the old site so you have a before number. Squarespace usually improves mobile performance over a plugin-heavy build, but you want proof, not vibes.
- Your registrar's DNS panel. Bookmarked and logged in. Screenshot the records before you change anything.
- The Wayback Machine. Real, practical insurance. Request a fresh capture of your important pages before launch, so if a page's copy goes missing in the import, the text still exists somewhere.
- A shared spreadsheet. URL inventory, redirect map, metadata, and a punch list of unfinished items, all in one file. This is the project, more than any design tool.
Launch sequence: review, redirect, test forms, switch domain
Order matters more than speed. Here's the sequence I'd follow:
- Final content review on the Squarespace site while it's still on the built-in *.squarespace.com domain. Read every page on a phone. Typos hide on desktop.
- Paste in the full redirect list. Do this before the domain moves, so redirects are live the second traffic arrives.
- Confirm forms send to the right inbox by submitting a real test from a real email account.
- Point the domain. Keep MX records untouched unless you're deliberately changing email hosts.
- Wait for propagation, then crawl the live site and check every status code. Fix any 404s the same day.
- Submit the new sitemap in Search Console and request indexing on your five most important pages.
- Leave the old site's hosting active for at least thirty days. It's cheap insurance and gives you somewhere to check original copy from.
Two weeks later, go back through Search Console and compare your top pages against the baseline you exported. A small dip that recovers is normal. A dip that doesn't recover almost always traces to a missing redirect, and you'll find it in your own spreadsheet.
Frequently asked questions
How long does switching to Squarespace usually take?
When switching to Squarespace for a small brochure site, a focused week is realistic if your content is already written and your redirect map is short. A content-heavy site with hundreds of posts, an ecommerce catalog, or custom functionality replacing old plugins runs considerably longer, mostly because rebuilding page layouts and rewriting metadata is manual work that resists shortcuts. The export and decision-making stages in this checklist are what compress the build stage.
Will I lose my Google rankings?
Only if your old URLs stop resolving. Rankings attach to URLs, so as long as each indexed page either keeps its path or 301-redirects to a close equivalent with similar content, positions generally hold with a short settling period. The damage happens when redirects get skipped or point to the homepage in bulk, which tells Google the old page is gone rather than moved.
Should I move my domain registration to Squarespace too?
Not necessarily, and there's no rush. Pointing your existing domain's DNS at Squarespace works fine and keeps registration where you already have access. Transferring can simplify billing into one account, but I'd get the site live and stable first, then decide about the domain when nothing else is in motion.
Can I keep my old site up while building the new one?
Yes, and you should. Squarespace gives every new site a temporary subdomain, so you can build and review the whole thing while your live site keeps serving customers and search traffic. The domain only switches when you're ready.
What about plugin features Squarespace doesn't have natively?
Make a list of them at the start, before you build, because this is the one item that can change the plan on its own. Most gaps close with a code injection or a third-party embed, and some close by dropping a feature nobody used. Occasionally there's something a platform simply won't do, and it's much better to learn that in week one than week five.
Start with the URL inventory; everything else follows
Pick the URL inventory. It takes an hour, costs nothing, and every other item on this list depends on it. Once you can see all your pages and their traffic in one view, the rest of switching to Squarespace stops feeling like a leap and starts feeling like a list. If the rebuild part is what's giving you pause, the projects in my portfolio will show you what a migrated site can look like when the structure gets rethought instead of copied, and a short conversation is usually enough to tell whether yours is a one-week move or something bigger.
