Move the site in a way Google can understand
The safest way to move from Squarespace to Solo is to keep the same important URLs whenever you can, and use 301 redirects for every URL that changes. If you preserve page intent, transfer content cleanly, and update technical signals like canonicals, internal links, and your sitemap, you can reduce ranking loss during the switch.
The biggest mistake is treating the redesign like a fresh start. Search engines do not know your new site should replace the old one unless you explicitly connect the two. A migration is mainly an exercise in matching old pages to new pages and removing confusion as quickly as possible after launch.
Start with an inventory of the Squarespace site
Before you build anything in Solo, export or list every indexable page on the current site. You need a complete map of what exists today so nothing important gets lost.
Capture these URLs first
- Homepage
- Core service pages
- Location pages
- Blog posts that bring traffic
- About, contact, and FAQ pages
- Any landing pages used for ads or email campaigns
- Image pages, if Squarespace created indexable attachment URLs
If you have access to Google Search Console, also check which pages receive impressions and clicks. Those are the pages you should protect most carefully. A page with low traffic can sometimes be merged or retired, but a page earning search visibility should usually be recreated or redirected to the closest equivalent.
Make a simple URL map
Create a two-column sheet with old URL and new URL. Add a note for each page explaining whether it will be:
- Kept with the same slug
- Rebuilt on a different slug
- Combined into another page
- Removed and redirected to a broader relevant page
This document becomes your migration checklist. It also helps when you later test redirects, update internal links, and verify that no important page was dropped.
Preserve URLs whenever possible
The easiest way to protect rankings is to keep the same URL path for important pages. If your current Squarespace page is /services, try to keep the Solo page at the same path if the platform allows it. Search engines see a same-URL move as a much smaller change than a new URL with the same content.
If you have to change the slug, keep the new one short, descriptive, and close in meaning to the old one. For example, /custom-web-design is a better replacement for /web-design-services than a vague new slug like /offerings.
Do not change URLs just because the new design looks cleaner. A prettier slug is not worth losing established search signals unless there is a real content or structure benefit.
Set up 301 redirects for every changed page
Every old URL that no longer exists should send users and search engines to the best matching new page with a 301 redirect. That tells browsers and crawlers the move is permanent and transfers as much value as possible to the replacement page.
Redirect rules that work best
- One old page to one closest relevant new page: Redirect a service page to the new service page, not to the homepage.
- Do not chain redirects: Old URL should go directly to the final destination, not through multiple hops.
- Avoid redirecting everything to the homepage: This is a common mistake and usually weakens relevance.
- Use the most specific matching page: A blog post should redirect to a closely related post or updated version, not a generic category page unless there is no better option.
Example: If your Squarespace site has /wedding-photography and your new Solo site has /photography-for-events, redirecting to the new service page may make sense if the content is clearly aligned. If the old page was a blog post, redirect it to the best matching article or a refreshed version of that article.
After launch, test the redirects manually in a browser and with a crawler or redirect checker. Confirm they return a 301 status and land on the intended page.
Keep page content aligned with search intent
When you rebuild pages in Solo, preserve the core topic, search intent, and useful detail of the original page. You can refresh the design and improve readability, but do not rewrite an existing ranking page so aggressively that it becomes a different page.
What to keep from the old page
- Primary topic and main keyword theme
- Headings that match user intent
- Important proof points, service details, and FAQs
- Location references if the page is local SEO focused
- Internal links to related pages
What you can improve
- Shorten long paragraphs
- Clarify the call to action
- Add recent examples or updated process notes
- Improve image alt text
- Remove outdated offers or old contact details
If you are moving a local service business to Solo, keep location and service phrasing consistent. For example, if the old page ranked for “emergency plumber in Portland,” your new page should continue to use that phrase naturally where appropriate, rather than replacing it with broad branding language.
Handle canonicals carefully
Canonical tags help search engines understand which version of a page should be treated as the primary one. During a migration, canonicals should point to the final live URL on the new site, not the old Squarespace URL.
Check for these common problems:
- A page canonicalizing to a URL that now redirects
- Duplicate versions of the same page with different slugs
- Parameter URLs or preview URLs being indexed
- Old Squarespace pages still accessible and indexed after the move
If your new Solo site has both a live version and a preview version, make sure the preview is blocked from indexing or otherwise kept out of search results. Search engines should see one clear canonical version for each important page.
Update internal links on launch day
Redirects are a safety net, not a substitute for clean internal linking. Once the new Solo site is live, update all navigation links, footer links, in-content links, and button URLs so they point directly to the final destinations.
This matters for two reasons. First, direct links reduce crawl waste and redirect chains. Second, they make the site easier for visitors to use. If a visitor clicks from your homepage to a service page, they should arrive there immediately, not after a redirect hop.
Internal link cleanup checklist
- Check main navigation
- Check footer links
- Check sidebar or related-post modules
- Update blog post links to new service pages
- Fix contact buttons and booking or inquiry links
- Replace any hardcoded old Squarespace URLs in page content
If you link from blog posts to services, use the migration as an opportunity to strengthen those pathways. For example, a post about pricing can link to a service page and a contact page, while a general blog post can link to a lead magnet or about page. If you use a platform like Solo for a simple marketing site, keeping those internal paths tidy helps both users and search engines understand the site structure.
Submit the new sitemap and check robots access
After the new site is live, publish a clean XML sitemap and submit it in Google Search Console. The sitemap should contain only indexable pages on the new site, not redirected URLs or drafts.
Also check that robots directives are not blocking important pages. It is common during development to accidentally leave noindex tags, password protection, or blocking rules in place after launch.
Post-launch indexing checklist
- Submit the new sitemap
- Confirm important pages are crawlable
- Verify the homepage and core landing pages are indexable
- Remove noindex tags from public pages
- Check that old URLs are returning 301s, not 404s
- Inspect the rendered page source for canonical and robots tags
If your Squarespace site previously had a sitemap indexed by search engines, let the old URLs phase out naturally through redirects. Do not keep both sitemap versions competing indefinitely.
Plan the migration in the right order
A clean move follows a sequence. If you skip steps, you create avoidable ranking problems.
Recommended migration sequence
- Inventory all current URLs and traffic data
- Map old pages to new pages
- Build the new Solo site with matching or improved content
- Set up 301 redirects
- Update canonicals and internal links
- Check metadata, headings, and image alt text
- Launch the site
- Submit the new sitemap
- Test redirects and indexability
- Monitor Search Console for errors and traffic changes
This order prevents a common problem: launching a new site before the redirect plan is ready. If that happens, Google may crawl broken links or temporarily treat your content as partially missing.
Watch the first 30 days closely
Expect some volatility after the move. A small amount of ranking fluctuation is normal while search engines recrawl the new URLs and process redirects. What you want to avoid is a pattern of broken pages, missing content, or widespread indexation issues.
What to monitor weekly
- 404 errors
- Redirect chains
- Pages dropped from the index
- Search impressions and clicks for key pages
- Top queries attached to your former ranking pages
- Mobile usability and page speed issues
If a page loses traffic after the move, compare the old and new versions side by side. Check whether the heading changed too much, whether the redirect target is too broad, or whether the page lost internal links. Often the fix is practical: restore important copy, tighten the redirect target, or add links from related pages back to the affected URL.
Use a rollback plan for critical pages
For your highest-value pages, have a fallback plan before launch. That might mean keeping the old Squarespace page available for a short overlap period while testing, or saving exact content blocks so you can restore wording quickly if a new page underperforms.
A rollback plan does not mean you expect failure. It means the pages that drive leads and revenue get extra protection.
If you are rebuilding a simple marketing site in Solo, this is usually manageable because the structure is straightforward: a homepage, a few services, some trust pages, and a set of blog posts. That simplicity can actually make the migration easier, as long as the redirects and content mapping are disciplined.
Quick migration checklist
- List every indexable Squarespace URL
- Map each old URL to a new destination
- Preserve the same slugs where possible
- Set up direct 301 redirects for all changed URLs
- Keep content aligned with the original search intent
- Point canonicals to the final new URLs
- Update navigation and in-content internal links
- Submit the new sitemap in Search Console
- Verify robots, noindex, and password settings
- Monitor traffic, errors, and index coverage for 30 days
If you follow those steps, moving from Squarespace to Solo can be a controlled SEO transition rather than a ranking reset. The goal is not to make search engines guess. The goal is to make the new site feel like the obvious successor to the old one.
For businesses that want a cleaner build for a simple marketing site, Solo can be a practical place to land, as long as the migration is handled with the same care you would use for any platform change.
FAQs
These answers cover the most common questions people ask during a Squarespace-to-new-builder migration.
Should I keep the same URLs when moving from Squarespace to Solo?
Yes, for your most important pages. Keeping the same URL is the safest option for SEO because it preserves continuity. If a URL must change, use a direct 301 redirect to the closest matching new page.
What should I redirect old blog posts to if I delete them?
Redirect each deleted post to the closest relevant replacement, updated version, or the most specific related page. Avoid sending deleted posts to the homepage unless there is no better match.
Do I need to change canonicals after the move?
Yes. Canonical tags should point to the final live URL on the new site. Do not leave canonicals pointing at old Squarespace URLs or at pages that now redirect.
How soon should I submit a sitemap after launch?
Submit the new sitemap as soon as the Solo site is live and crawlable. The sitemap should include only public, indexable URLs on the new site.
Is it normal to see ranking drops right after migration?
Some fluctuation is normal for a short period while search engines recrawl the site and process redirects. A larger or lasting drop usually means there are issues with redirects, content changes, internal links, or indexability.
