Skip to content
50% OFF $299 $599
Lock in
§ 2.11.5 ARTICLE
Published VerifiedEvery 6 weeks Sources5 named Authored bySquareRank Team

Migrations · § 2.11.5 · Checklist

Squarespace 7.0 to 7.1 migration SEO checklist — the manual-rebuild playbook

Squarespace ships no automated 7.0-to-7.1 conversion tool1. The migration is a manual rebuild on a fresh 7.1 site followed by a DNS cutover. A graceful migration with complete URL Mappings typically loses 15 to 30 percent of organic traffic for the first 60 days and recovers within 90 to 120 days — smaller than a cross-domain migration because the domain authority stays the same5. The recovery is faster when the operator ships better schema, faster page speed, and tighter heading hierarchy on the new 7.1 site than the old 7.0 site carried. The version upgrade is the entry point; the install layer is where the ranking lift compounds.

This leaf is the implementation playbook. The upstream decision (should I upgrade at all?) lives in the upgrade impact leaf. If you have already decided to migrate, this is the checklist that protects rankings during the transition.

The 7.0-to-7.1 migration mechanic

A 7.0-to-7.1 migration is a same-domain rebuild. The domain stays at yoursite.com; the underlying Squarespace site changes from a 7.0 build to a 7.1 build. Squarespace's documentation<InlineCite n={1} sourceId='sq-7-to-71' /> is direct: 'There's no way to convert a Version 7.0 site to Version 7.1 directly. To switch versions, you'll need to build a new Version 7.1 site, then add the content from your Version 7.0 site.' The mechanic is two Squarespace sites in your dashboard — the 7.0 production site and the 7.1 staging site — with a DNS cutover that points the domain at the new build.

The same-domain nature is the most important asymmetry. A cross-platform migration (WordPress to Squarespace) changes infrastructure, URL patterns, and platform-level signals all at once. A 7.0-to-7.1 migration changes the platform version and (usually) the URL patterns slightly, with the domain authority and historical Search Console data fully preserved. Google's site-move guidance4 does not require a change-of-address request for same-domain migrations; the URL Mappings and sitemap resubmission are sufficient.

The 7.0-to-7.1 migration profile

0

automated upgrade paths. The migration is a full manual rebuild.

Squarespace Help · 2026
15-30%

typical organic traffic drop in first 60 days for graceful 7.0-to-7.1 migrations.

Moz migration guide · 2025
Same

domain stays at yoursite.com; backlinks transfer through URL Mappings without a change-of-address request.

Google Search Central · 2026

The pre-migration URL audit

Before opening the staging 7.1 site, pull every URL from the 7.0 site and cross-reference each row with Search Console traffic data. The list must include: pages, blog posts, portfolio items, events, gallery items, products if Commerce is in use, and any tag or category archive pages that have ranked. Export Search Console's Performance report for the trailing 12 months and identify the top 50 URLs by impressions and the top 20 by conversions. Those are the URLs that must survive the rebuild cleanly.

The most common pre-audit miss: collection item URLs that the operator does not interact with day to day. A 7.0 site with 80 blog posts and 12 events typically has the operator remembering 8 to 12 page URLs and forgetting the rest. The full audit surfaces the long tail, which is where most backlinks accumulate. The migration-map leaf covers the CSV-template approach.

The rebuild sequence

Order of operations: build the homepage first, then services or about pages, then portfolio or blog index pages, then the blog content via Squarespace's content port, then any product pages if Commerce is in use, then secondary pages and footer-linked content. Match the 7.0 site's H1s, meta titles, meta descriptions, and overall content structure on the new 7.1 site. Cosmetic redesign is encouraged — that is part of the migration's upside — but substantive content stays consistent so Google's recrawl treats the new pages as the same content at new URLs.

The Squarespace dashboard allows multiple sites at once. The 7.0 production site stays live and indexed while the 7.1 site is built on a trial URL. The two sites can be open in separate browser tabs for side-by-side reference during the rebuild. Plan for 30 to 90 hours of rebuild work depending on site complexity; budget a third of that for the SEO re-author pass.

Schema and SEO settings re-author

The SEO panel content (meta title, meta description, Open Graph image) does not transfer automatically between Squarespace sites. Open every page on the 7.1 staging site, open the SEO settings panel, and re-author each field from the 7.0 source. Image alt text similarly does not transfer; re-author per image. JSON-LD via Code Injection has to be re-authored because the Code Injection panels are per-site; the patterns from the 7.0 site carry forward, but the panel content has to be re-pasted on the 7.1 site.

Plan 15 to 30 minutes per page for the SEO re-author pass, plus 5 to 10 minutes per blog post for Article schema reinstall, plus 60 to 90 seconds per image for alt text. For a typical 20-page site with 30 blog posts and 100 images, the SEO re-author is 8 to 15 hours of dedicated work.

The 7.0-to-7.1 redirect map

Most 7.0 page URLs preserve identically to their 7.1 counterparts (the about page is still /about/, the contact page is still /contact/) unless the operator renames during the rebuild. Collection item URLs frequently change because the collection wrapper URL can shift (a 7.0 blog at /journal/ becomes a 7.1 blog at /blog/, for example). The redirect map is shorter than a cross-platform migration's map but still has to cover collection items, not just pages.

URL Mappings 7.0-to-7.1 redirect map — typical patterns 
 # Page-level URLs — usually identical, but include them for safety /about -> /about/ 301 /services -> /services/ 301 # If the blog collection was renamed during the rebuild # (e.g. 7.0 /journal/ to 7.1 /blog/) /journal/ -> /blog/ 301 /journal/[slug] -> /blog/[slug]/ 301 # Portfolio rename (common 7.0-to-7.1 cleanup) /work -> /portfolio/ 301 /work/[slug] -> /portfolio/[slug]/ 301 # Event collection — usually preserves /events/[slug] -> /events/[slug]/ 301 # Trailing slash normalisation if 7.0 had inconsistent slashes /contact -> /contact/ 301

The wildcard [slug] compresses repetitive collection-item rows. The same URL Mappings panel3 exists on both 7.0 and 7.1, and the wildcard syntax is identical. Submit the full map to the 7.1 staging site before cutover. The cleanest 7.0-to-7.1 migrations preserve every URL that doesn't need to change; only the URLs that must change get explicit redirects.

The cutover sequence

Cutover day on a 7.0-to-7.1 migration is the moment the domain is detached from the 7.0 Squarespace site and reattached to the 7.1 site. The mechanic varies by Squarespace's exact connection method, but the principle is consistent: DNS pointed at the new site, URL Mappings active, sitemap submitted to Search Console, the 7.0 site retired or kept as an archive but de-indexed. Plan the cutover for a low-traffic window (typically weekends or early morning) to minimise revenue exposure during the brief propagation period.

Same-domain migrations do not require a Google Search Console change-of-address request4. The Search Console property continues to monitor the same domain; the underlying Squarespace site behind the domain has changed, but Google reads the domain via Googlebot regardless of what site it points at. Resubmit the new sitemap on cutover day so Googlebot has the canonical URL list for the 7.1 build.

Post-cutover validation and the long tail

Watch Search Console daily for 14 days. The Coverage report should show 'Page with redirect' counts climbing as Googlebot encounters the URL Mappings; 'Not found (404)' counts should be near zero. The Performance report shows the impression dip in the first 14 days and the recovery starting at day 30 to 45. Top-traffic URLs typically recover within 60 to 90 days; long-tail URLs take 120 to 180 days. The migration is complete when impressions and clicks return to pre-cutover levels and structured-data error counts in Search Console are at zero.

The post-cutover work that distinguishes a good 7.0-to-7.1 migration from a great one: actively run the install layer in parallel with the recovery window. The schema reinstall via Code Injection JSON-LD, the heading hierarchy patch on collection pages, the AI crawler panel state, and the broader Site Speed work are easier to ship on the new 7.1 build than they were on the legacy 7.0 site. By day 90, the new site is structurally better than the old one was on every dimension; by day 120, the rankings reflect it.

Keep reading · § 2.11.5