PublishedVerifiedEvery 6 weeksSources5 namedAuthored bySquareRank Team
7.0 vs 7.1 · § 2.9.1 · Decision
Should I upgrade Squarespace 7.0 to 7.1? The honest SEO impact
The version upgrade is a manual rebuild — Squarespace ships no automated converter2 — and a clean migration with proper 301 redirects typically loses 15 to 30 percent of organic traffic for the first 60 days and recovers to baseline within 90 to 120 days4. An ungraceful migration can lose 50 percent or more permanently. Upgrade if a redesign is already on the calendar, if 7.1-only features are non-negotiable, or if the existing 7.0 template family is no longer fit for the business. Do not upgrade to chase ranking gains the version does not deliver.
This leaf is the cost-benefit framework, not the migration playbook. The migration playbook lives in the migrations cluster. The decision before the playbook is the question this article answers: given the rebuild cost, the traffic curve, and the version differences, is the upgrade the right call for this site?
§01The short answer
TL;DR — the honest verdict
A well-tuned 7.0 site with proven backlinks, ranked content, and steady traffic has nothing automatic to gain from a version upgrade. The version is not the lever that moves rankings; URL discipline, schema coverage, image weight, and heading hierarchy are. If the existing site is already operating cleanly, the upgrade is a 30-to-90-hour rebuild project for a marginal editor improvement. If a redesign is already on the calendar or the site needs a deeper reset, do the redesign on 7.1 rather than spinning up a fresh 7.0 build that the platform no longer lets you create.
Squarespace's own help-center page on the topic1 states the version mechanic plainly: 7.0 sites are supported and indexed and ranking, but no new 7.0 sites can be created. The platform is investing forward in 7.1. That means the long-term editor experience improvement is real even when the short-term SEO consequence of the upgrade is negative. The framing this leaf rejects is the version-cheerleading framing that treats 7.1 as automatically better for SEO. It is not. Both versions need the same install layer.
§02What survives
What survives a clean 7.0-to-7.1 upgrade
Domain authority, backlinks pointing at redirected URLs, indexed content that maps cleanly between versions, Search Console history, and Google Business Profile linkage all survive a competent upgrade. Schema markup, llms.txt files, Code Injection blocks, and SEO panel settings have to be re-authored on the new site; they do not migrate automatically. The customer relationship to the brand survives; the customer relationship to the specific URL the brand was last seen at survives only if the redirect map is complete.
Google's published guidance on site moves3 is the authoritative reference for what carries over. Domain-level signals (PageRank-equivalent authority, hreflang relationships, manual actions, structured data freshness) are preserved when the migration uses 301 redirects from every old URL to its new equivalent and the Search Console change-of-address request fires after the cutover. The transfer happens over weeks; Google's own documentation says "Plan on the move taking longer than you expect."
The catch on Squarespace specifically: the rebuild is a separate site in your Squarespace dashboard until you cut over DNS. That means schema, Code Injection, SEO panel content, and any custom CSS must be re-authored on the staging site before cutover. None of that work is migrated by Squarespace. Plan for re-authoring 100 percent of the SEO layer.
§03What does not survive
What does not survive without manual work
Two categories of value are at risk during a 7.0-to-7.1 migration: anything attached to a URL that changes without being redirected, and anything attached to a site-wide setting that has to be re-authored on the new site. The first category includes backlinks, internal links, social-share embeds, and search snippets. The second includes JSON-LD Code Injection, llms.txt, custom CSS, the SEO panel completion state, and any third-party integrations configured at the site level. Both are recoverable; both require deliberate work.
Moz's migration playbook4 documents the typical failure modes in detail. The two that bite Squarespace migrations specifically: collection-item URLs that change between versions because 7.1 normalises the path structure, and 7.0 page slugs that conflict with 7.1's reserved-word list. Both are caught by a complete URL audit run against the staging site before cutover. Both are missed by operators who only audit page-level URLs and forget blog posts, gallery items, and event collection entries.
§04The curve
The typical traffic curve in the first 120 days
A graceful 7.0-to-7.1 migration with complete redirect mapping and a re-submitted sitemap typically shows the following curve: days 1 to 21 see a 10 to 25 percent organic traffic drop as Googlebot recrawls every URL and reranks based on the new structure; days 21 to 60 stabilise at the lower volume while Search Console catches up; days 60 to 120 climb back to or above baseline as the cleaner structure compounds. An ungraceful migration shows a similar drop curve but never recovers, because the lost backlink equity is permanent.
Moz's tracking across hundreds of migrations4 places the typical dip at 15 to 30 percent in the first 60 days. Squarespace migrations cluster around the higher end of that range because the operator is also re-authoring schema, Code Injection, and SEO panel content on the new site. The dip is the cost of the upgrade; the recovery is the version's small upside compounding against operator-level work that would have helped on the 7.0 site too.
What the migration curve looks like
15-30%
typical organic traffic drop in the first 60 days after a graceful Squarespace migration (Moz).
The recovery is faster on sites that resubmit the sitemap on cutover day, file the change-of-address request in Search Console, and update internal links to point at the new URLs natively rather than relying on 301 chains. The recovery is slower on sites that wait to do those things until the dip is visible in the analytics dashboard. Search Engine Land's GEO coverage5 adds an AI-search wrinkle: AI engines re-cite from re-indexed content, so a slow Search recovery is also a slow AI Overviews recovery.
§05When to upgrade
The three conditions where upgrading is the right call
First, a redesign is already on the calendar. Second, the existing 7.0 template family is no longer fit for the business and a 7.1 rebuild would solve a real editor problem. Third, the business needs a 7.1-only feature: the fluid section engine, member areas, the Course Player, the modern Commerce checkout, or specific 7.1-only integrations. Any one of these three conditions makes the upgrade defensible. None of them is 'I want better SEO from 7.1.'
The redesign-on-the-calendar condition is the strongest. Any redesign that requires a full rebuild has to ship on 7.1 because Squarespace will not let you create a new 7.0 site1. The redesign cost is already on the budget; the version upgrade is a free side-effect. The traffic curve still applies, but the operator was paying for it anyway.
The 7.1-only-feature condition is the most concrete. Member Areas, the Course Player, and several recent Commerce features are not available on 7.0. If the business needs one of those, the upgrade is non-negotiable. Plan the migration carefully; the migration's success determines whether the new feature ships on a healthy site or a wounded one.
§06When to wait
When upgrading is the wrong call
Stay on 7.0 when the site is operating cleanly, when no redesign is on the calendar, when no 7.1-only feature is required, and when the team's capacity for a multi-month traffic dip is limited. Stay on 7.0 in the run-up to a high-revenue season (a Black-Friday-dependent ecom store should not migrate in October). Stay on 7.0 when the current rankings are paying the business's bills and the upside of migration is hypothetical.
The most common bad reason to migrate is sunk-cost FOMO: someone in the team has heard 7.0 is "going away" and wants to migrate preemptively. Squarespace's published version overview1 does not name a 7.0 deprecation date. The platform supports 7.0 indefinitely; the only meaningful constraint is that new sites cannot be created on it. A live 7.0 site that pays the business's bills is not at risk just because the platform invested forward in 7.1.
§07The matrix
The decision matrix, simplified
Use the following four-question filter. Is a redesign already on the calendar? Does the business need a 7.1-only feature? Can the business afford a 15 to 30 percent traffic dip for 60 to 120 days? Is the team capacity available for a 30-to-90-hour rebuild and the redirect mapping work? Three or four yeses means upgrade. Two or fewer means stay and run the install on the existing 7.0 site. The answer is rarely a function of the version; it is a function of where the business is in its product cycle.
A worked example. A wedding photographer on a Bedford-family 7.0 site, ranking solidly for "[city] wedding photographer", running 80 to 90 sessions per year off the website. No redesign on the calendar; no 7.1-only features needed; revenue depends on consistent organic visibility. The decision: stay on 7.0, ship the install, revisit in 18 months. Migrating in that situation trades certain short-term loss for a hypothetical long-term gain the version cannot guarantee.
A counter-example. A SaaS company on a 7.0 York-family site, due for a brand refresh in the next quarter, wants to launch a Knowledge Base section that requires Member Areas. The decision: migrate now, time the cutover for the redesign launch, plan for the traffic dip during the quarter the brand refresh is already a known disruption. The version upgrade here is incidental to a larger decision the business was making anyway.
Whatever the answer, the migration playbook in the migrations cluster covers the implementation. The decision is upstream of the playbook; this leaf gives the framework for making it without the version-cheerleading distortion. The cluster hub covers the broader 7.0 vs 7.1 comparison, and the AIO compatibility leaf covers the AI search dimension that the version debate often misses.
