I once helped a client lose 40% of their organic traffic during a 7.0 to 7.1 migration. They forgot URL redirects. One week later, every page that ranked was returning 404 errors. Google de-indexed the site. Recovery took 3 months. Here is what I learned, and how to avoid that mistake (and others).
Switching from Squarespace 7.0 to 7.1 means building a new site from scratch. The two versions run on different architectures, which is why Squarespace never built an automated upgrade path. Use coupon code OKDIGITAL10 for 10% off any Squarespace plan.
Why Is There No Direct Upgrade from 7.0 to 7.1?
Squarespace 7.0 and 7.1 use fundamentally different architectures. Version 7.0 uses distinct template families, each with its own features, layout options, and CSS class structure. Version 7.1 uses a unified template system where every site has access to the same features regardless of the starting template.
This architectural difference means content and design cannot be automatically converted between versions. Your 7.0 template, with its specific CSS classes and layout structures, has no direct equivalent in 7.1. Squarespace chose not to build an automated migration tool because the conversion would produce inconsistent results. For a look at the advanced customization possible on 7.1, see our guide to advanced customization and features on Squarespace. 7.1 significantly expands what is possible without code.
Should You Migrate? Pre-Flight Checklist
Before committing to a migration, answer these questions:
- How large is your site? (pages, blog posts, products)
- How much custom code do you have? (custom CSS, code injections, scripts)
- Are you relying on any 7.0-specific features? (certain template index page types, specific extensions)
- What is your traffic like? (will a weeks-long rebuild impact your business?)
- Is your site profitable today? (is growth worth the migration risk?)
If you answered "large" to questions 1 and 2, consider hiring help or waiting for a slow business period. If you answered "yes" to question 3, research whether 7.1 supports your use case before starting. If you answered "very high" to question 4, weigh the uptime risk carefully.
Step-by-Step: How to Switch from 7.0 to 7.1
Step 1: Create a New 7.1 Trial Site
Start a free 14-day trial on Squarespace. Choose any 7.1 template; on 7.1, all templates have access to the same features, so the starting point matters less than on 7.0. The trial gives you full editing access to build your new site. If you are weighing whether to upgrade to 7.1 or simply start over on Squarespace with a fresh site, review both options before committing.
Step 2: Recreate Your Design
Configure Site Styles, fonts, colors, button styles, and spacing. Set up your header and footer layout. Build your page structure using 7.1's section-based editor. Take advantage of new features: section themes for color variety, the Fluid Engine for flexible layouts, and built-in member areas if needed.
Step 3: Transfer Your Content
Blog posts: Export your 7.0 blog as an XML file (Settings > Advanced > Import/Export > Export). Import this file on your 7.1 site. Blog content, categories, tags, and metadata transfer this way.
Pages: No automated transfer. Copy text content from each 7.0 page, paste it into the corresponding 7.1 page, and reformat using 7.1's editor. Re-upload images or drag them from your 7.0 site's file manager.
Products: Export products as CSV from your 7.0 Commerce settings. Import the CSV into your 7.1 site. Product images may need to be re-uploaded.
Step 4: Rebuild Custom Code
This is where most migrations get stuck. Custom CSS from 7.0 will not work directly on 7.1 because class names and element structures are different. Rewrite your CSS using 7.1's class structure. Code Injection contents (header and footer scripts) should transfer directly, copy them from 7.0 and paste into 7.1.
Example of what changes between versions:
In 7.0, you might have written:
.homepage-hero { color: #333; font-size: 48px; }
This targets a class that does not exist in 7.1. In 7.1, the hero section uses different classes. You must inspect the live element using browser developer tools to find the correct class names, then rewrite the CSS from scratch.
To find the correct class names in 7.1:
- Open your 7.1 site in a browser
- Right-click on the element you want to style (e.g., the hero text)
- Select "Inspect" or "Inspect Element"
- Look at the HTML and identify the class name (e.g.,
class="sqs-dynamic-heading") - Use that class name in your CSS:
.sqs-dynamic-heading { color: red; }
Common 7.0 > 7.1 CSS changes:
- 7.0:
.homepage-intro→ 7.1:.sqs-block-summary-v2 - 7.0:
.blog-item→ 7.1:.blog-item-wrapper(may need different targeting) - 7.0:
.product-grid→ 7.1:.sqs-storefront-collection-grid - 7.0: Nav bar styling → 7.1: Header styling (completely restructured)
Start by copying your 7.0 Custom CSS into 7.1's Code Injection > Header section. See what breaks. Use browser DevTools to identify the correct selectors, then update your CSS iteratively. This is tedious but necessary.
Testing your CSS changes:
After each CSS change, reload your 7.1 site in the browser. If the styling did not apply, your selector is wrong. Go back to the inspector, verify the class name again, and try a more specific selector. Example: if .header-nav does not work, try header .nav or .sqs-layout .header-nav.
Do not try to copy all CSS at once. Migrate in chunks: first the header, then the footer, then the homepage, then internal pages. Test each section before moving on. This makes debugging much faster.
Step 5: Set Up URL Redirects
This step is critical for SEO. If any page URLs changed during the rebuild, set up URL mappings (301 redirects) on your 7.1 site to redirect old URLs to new ones. This preserves SEO value from backlinks pointing to old URLs and prevents visitors from hitting broken links. Keep the same URL slugs wherever possible to minimize the need for redirects.
Most content should transfer with the same URLs if you use the same slug names. But if you are reorganizing your site structure during the migration, URL changes are unavoidable. For those, set up 301 redirects immediately after transferring your domain. Do not leave broken links live for even a few hours.
Step 6: Transfer Your Domain
When your 7.1 site is ready, disconnect your custom domain from your 7.0 site (Settings > Domains). Connect it to your 7.1 site. Subscribe to a paid plan on the 7.1 site. Cancel your 7.0 subscription after confirming everything works on 7.1.
Before transferring the domain:
- Test the 7.1 site thoroughly on multiple browsers and devices
- Verify all forms work (contact forms, checkout, etc.)
- Test all internal links
- Confirm all images load correctly
- Test any integrations (email signup, payment processing, etc.)
How Does Switching Affect SEO?
The SEO impact depends entirely on how you handle the migration. This is where most migrations fail.
Same Domain, Same URLs = Minimal Impact
If you transfer your domain and keep all page URLs identical, the SEO impact is minimal. Google sees the same content at the same URLs, just with a new design. You may see minor ranking fluctuations for 2-4 weeks as Google recrawls. No lasting damage is expected.
How to monitor SEO during migration:
- Add your 7.1 site as a new property in Google Search Console before transferring the domain
- After domain transfer, use GSC's "Change of Address" tool to notify Google
- Monitor crawl stats daily for the first 2 weeks (look for crawl errors or 404s)
- Use GSC's URL Inspection tool to check if key pages are indexed
- Submit a new sitemap via GSC if page structure changed
Changed URLs Without Redirects = Significant Damage
If URLs change and you do not set up 301 redirects, Google treats the old URLs as 404 errors. Backlinks pointing to old URLs lose their value. Rankings drop. Traffic decreases. This is the single biggest SEO risk in the migration, and it is entirely preventable with proper URL mapping.
Check your Google Search Console crawl stats before migrating. Note which pages have backlinks (the GSC "Links" report shows this). Prioritize setting up redirects for high-value pages.
New Domain = Full SEO Reset
If you switch to a new domain during the migration, expect a significant ranking drop lasting 3-6 months. Set up 301 redirects from every old URL to the corresponding new URL. Even with redirects, some link equity is lost. Avoid changing domains during the migration unless absolutely necessary.
How to accelerate re-indexing after migration:
- Set up 301 redirects from old URLs to new URLs before transferring domain
- Add the new 7.1 site as a property in Google Search Console
- Submit the sitemap to GSC
- Use GSC's "Request Indexing" tool for key pages
- Build 1-2 internal links to the migrated homepage from other indexed sites
- Wait 2-4 weeks for Google to recrawl and re-index
Do not launch new backlink campaigns during the migration. Focus on maintaining existing links and ensuring redirects work correctly. New links can wait 1 month until the migration is stable.
Common Gotchas and Troubleshooting
Tracking Cookie Doesn't Persist Across Domain Transfer
If you use Google Analytics or third-party tracking tools, the tracking cookie may not persist during the domain transfer. Before transferring your domain, verify that your tracking code is correct on the 7.1 site. Test: (1) Visit your 7.1 site, (2) Click to another page, (3) Check that the session is continuous in Analytics (not separate sessions). If sessions are fragmenting, check your tracking code or contact Analytics support.
Redirects Are Set But Old URLs Still Show 404
This usually means the redirect is not configured correctly. Check: (1) Are the old URLs in your 7.0 settings pointing to the new URLs? (2) Is the redirect showing as "301 Moved Permanently" or "302 Temporary"? (Use an online redirect checker to verify). (3) Is the 7.0 site still live? (If you delete 7.0 before redirects take effect, the old URLs become inaccessible). Keep your 7.0 site live for at least 1 month after domain transfer while redirects are active.
Custom Code Injection Scripts Break on 7.1
Some scripts written for 7.0's DOM structure will not work on 7.1 because the HTML structure is different. If you injected JavaScript that targets specific IDs or classes, test it on your 7.1 trial site before migrating. If it does not work, update the script to target 7.1's class names (same process as CSS migration).
Mobile Responsive Design Breaks
7.0 and 7.1 have different breakpoints and responsive behavior. What looks perfect on mobile in 7.0 may look broken in 7.1. Test the 7.1 site on multiple mobile devices (iPhone, Android, tablets) before transferring the domain. Pay special attention to navigation menus, form inputs, and image sizing.
Is the Switch Worth It?
Switch to 7.1 When
- You want section themes and the Fluid Engine for modern layouts
- Your 7.0 template feels outdated and limits your design options
- You are already planning a site redesign
- You need features only available on 7.1 (member areas, improved integrations)
- Your site is small enough that the content transfer is manageable (under 50 pages)
- You can afford a 1-2 week rebuild window without major business impact
Stay on 7.0 When
- Your site works well and you have no design complaints
- You have extensive custom code that would need complete rewriting
- You have hundreds of pages that would take significant time to migrate
- You rely on 7.0-specific features not available on 7.1
- Your site is high-traffic and any downtime is costly
- You are too close to a major business event (seasonal sales, product launch, etc.)
Migration Timeline and Reality Check
Small site (under 20 pages, minimal custom code): 1-3 days for design, content transfer, and testing.
Medium site (20-50 pages, some custom CSS): 3-7 days including design, content, and custom code migration. Plan for CSS debugging taking longer than expected.
Large site (50+ pages or e-commerce with 100+ products): 1-3 weeks including product migration, extensive testing, and redirect setup. For e-commerce, allocate extra time for payment processing testing and inventory sync.
Large site with heavy custom code (e.g., custom checkout flow, third-party app integrations): 2-4 weeks. Consider hiring a developer. CSS migration alone can take 2-3 days on complex sites.
Reality check: Most site owners underestimate migration time by 50%. Plan for your estimated timeline and add 50%. If you think it will take 3 days, plan for 4-5 days.
Keep both sites running in parallel until you have fully tested the 7.1 site. Confirm responsive design, test all forms, verify checkout (if applicable), and check every internal and external link before transferring the domain.
Is Squarespace 7.0 Being Discontinued? (2026 Update)
As of 2026, Squarespace has not announced an end-of-life date for version 7.0. Existing 7.0 sites still work, stay published, and receive security updates. But every new site is created on 7.1, and Squarespace directs its newest tools (Fluid Engine improvements, section themes, and AI-assisted design) exclusively to 7.1. In practice, 7.0 is in maintenance mode: stable, but frozen in features.
The takeaway for 2026: you are not forced to migrate today, but the feature gap between the two versions widens with every release. If you are planning a redesign anyway, building it on 7.1 avoids a second rebuild later. If your 7.0 site works and you have no design complaints, there is no urgency to switch. Base the decision on your design needs and the migration effort, not on fear that 7.0 is about to disappear.
Frequently Asked Questions
Can I upgrade from Squarespace 7.0 to 7.1 directly?
How long does it take to switch from 7.0 to 7.1?
Will switching to 7.1 hurt my SEO?
Will my Custom CSS work on 7.1?
How do I check if I am on 7.0 or 7.1?
What features are available on 7.1 that are not on 7.0?
* Read the rest of the post and open up an offer