PublishedVerifiedEvery 6 weeksSources7 namedAuthored bySquareRank Team
Cluster 2I · 7.0 vs 7.1
Squarespace 7.0 vs 7.1 — the SEO and AI-search comparison without the cheerleading
7.1 is the only version on which new Squarespace sites can be created1. 7.0 sites are still hosted, still indexed, and still supported — but no longer growing. The two versions ship slightly different HTML, slightly different URL behaviours, and meaningfully different defaults around heading hierarchy, image handling, and section-based editing. None of those differences alone makes one version "better for SEO" than the other. What matters is how cleanly the operator runs the platform, which is the same conclusion most honest practitioners arrived at by 2024.
This cluster strips the version debate down to the four things that actually move SEO: URL structure, HTML output, AI Overviews compatibility, and Core Web Vitals. It documents where 7.1 ships better defaults, where 7.0 ships better ones, and the three editorial decisions that matter more than the version number. The three leaf articles take the upgrade decision, the AIO compatibility question, and the URL-structure differences in turn.
Build new sites on 7.1. Leave well-tuned 7.0 sites on 7.0 unless a redesign is already on the calendar. Squarespace will not migrate the site for you — there is no automated upgrade path — and a mid-stream rebuild costs 30 to 90 hours of work plus four to twelve weeks of traffic recovery. The version number is not the lever that moves rankings. URL discipline, heading hierarchy, schema coverage, image optimisation, and crawler-panel state are the levers, and they apply equally to both versions.
Squarespace's own help center is unambiguous on the upgrade mechanic2: "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." Anyone presenting an automated converter is either selling a manual service with marketing copy attached or misrepresenting what the platform supports.
The cost framing matters because the version-upgrade conversation is dominated by 7.1 cheerleading. 7.1 ships a more flexible editor, a universal template family, and ongoing platform investment from Squarespace's product team. None of those benefits, on their own, fix a slow 7.0 site or rescue rankings from a thin-content problem. Migrate when the existing site has run its course as a design or business asset; do not migrate to chase imagined SEO upside that the version difference does not deliver.
What the version actually decides
0
automated upgrade paths from 7.0 to 7.1. The migration is a manual rebuild.
7.1 collapses 7.0's template families into a single universal template, shifts the editor to section-based composition, ships a fluid engine that lets sections stack and overlap, and unifies styling controls across the platform. The SEO-relevant differences are narrower: the default HTML 7.1 emits is slightly different from 7.0, the URL behaviour is more consistent, and the platform's image handling has changed enough to require an LCP review even on otherwise identical content.
The 7.1 announcement and subsequent help-center coverage1 reframe Squarespace's product around a single template that all sites start from. In 7.0, choosing the Brine family, the Bedford family, or the York family determined the HTML structure, the styling controls, and a subset of the available features. Some 7.0 templates supported blog post summaries that others did not. Some had stronger sticky header behaviour than others. The fragmentation made SEO advice template-specific; what worked on Brine often did not work on York.
In 7.1, every site uses the same template engine. The visual differences come from style choices, not template family. The SEO consequence is that platform-wide advice is now reliable advice: a Code Injection JSON-LD pattern that works on one 7.1 site works on every 7.1 site. That uniformity is the biggest practical win of the version. It does not, by itself, change rankings. It changes the cost and reliability of operating the site, which is a different and quieter benefit.
§03URL and templates
URL structure and template families — the practical differences
Both versions produce clean, hyphenated, lowercase URLs by default. The differences are at the collection level: blog post URLs in 7.0 sometimes included template-specific path segments that 7.1 has cleaned up, and 7.1's universal template means a blog collection URL pattern is now identical across every 7.1 site. For most migrations the URL change is small but non-zero, which means redirect mapping is non-optional.
The leaf article on URL structure covers the per-collection-type differences in detail. The high-level takeaway: blog post URLs typically follow /blog/post-slug/ on both versions, but the parent collection URL ("blog index") behaviour and the gallery/portfolio item URLs can differ. Anyone migrating a 7.0 site to 7.1 must map every URL of every collection item, not just the page-level URLs. The migration-map article in the Redirects cluster covers the mapping pattern.
Squarespace handles the canonical tag automatically on both versions, so duplicate-content issues from URL changes are usually flagged correctly to Google. The risk is not duplicate content; it is broken backlinks. A backlink pointing at a 7.0 URL that 404s on the 7.1 rebuild is a lost ranking signal, full stop. URL Mappings catches this if the redirects are mapped before cutover.
§04HTML output
HTML output — the section-based H1 break in 7.1
7.1's section-based editor encourages a section-per-idea composition where each section reads as its own self-contained unit. The default tag for a section's primary text is often H1, which produces pages with three to eight H1 elements once a designer has built four to eight sections. The blog index page is worse: 7.1 tags every visible blog post title as H1, so a page listing twelve posts ships twelve H1 elements. Squarespace's framing is that Google does not penalise multiple H1s. The framing is correct for classical Search and incomplete for AI Overviews passage extraction.
Squarespace's heading-tags help article3 states the index-page behaviour directly: "On collection pages (blogs, events, portfolios), Squarespace automatically applies H1 tags to item titles. For instance, blog post titles receive H1 tags both on blog index pages and individual post pages in Version 7.1." Google's own published position4 agrees that multiple H1s are not a direct ranking factor. That is true for classical ten-blue-link Search.
The framing breaks down once AI Overviews enters the picture. Search Engine Land's 2026 GEO guide5 documents passage-based extraction as the layer that decides which sections of a page get cited in AI answers. Passage extraction reads cleaner DOM trees more reliably; a page with one clear H1 and four H2 sections segments into clean passage candidates, while a page with twelve H1 elements segments into nothing useful. The Pillar 1 leaf on heading hierarchy for AI Overviews covers the audit and the Code Injection patch.
7.0 templates vary on this point. Bedford-family templates often shipped cleaner heading hierarchies than Brine-family ones. The variation makes 7.0 advice harder to generalise, which is itself an argument for moving new builds to 7.1 where the default behaviour is at least predictable.
§05AIO compatibility
AI Overviews compatibility — neither version wins by default
A default 7.0 site and a default 7.1 site are both moderately well-prepared for AI Overviews and moderately ill-prepared for ChatGPT, Perplexity, and Claude. The platform-level wins (XML sitemap, canonical tags, fast hosting) are identical across versions. The platform-level gaps (no native JSON-LD beyond Article and basic Product, no native llms.txt, multi-H1 index pages on 7.1, slow default LCP on both versions) are also identical. The fix list is the same on both versions; only the implementation paths differ slightly.
The AI Overviews compatibility leaf in this cluster covers the per-version fix list. Headline: regardless of version, the install is Code Injection JSON-LD for Article/LocalBusiness/Service/Product, the multi-H1 patch where the platform emits it, alt text discipline on every image, and the 134-167 word passage shape for blog content. The version determines which fix is the editor pass and which is the Code Injection block, not whether the fix is needed.
One asymmetry worth flagging. 7.1 ships a single template engine which makes Code Injection patches consistent across sites — write the JSON-LD once and reuse it. 7.0's template family fragmentation means a JSON-LD block tested on a Brine site sometimes needs adjustment on a Bedford site, especially for collection-item schema where the template emits the page wrapper differently. The reliability win is small but real for operators running multiple sites.
§06Site speed
Site speed and Core Web Vitals — operator wins, not version wins
Both versions ship Squarespace's image CDN, automatic responsive image variants, and basic HTTP/2 delivery. Neither version is fast by default on mobile because both default to high-resolution hero images and uncompressed font payloads. LCP under 2.5 seconds on mobile is achievable on both versions; it requires the same operator-level work on either. The version number is not the lever.
web.dev's published Core Web Vitals thresholds6 are version-agnostic: LCP under 2.5s, INP under 200ms, CLS under 0.1. Squarespace 7.1 default sites measured at scale frequently land in the 3.5 to 5 second LCP range on mobile due to large hero images and the platform's font-loading strategy. Squarespace 7.0 default sites land in a similar range. The 7.1 platform has marginally better support for modern image formats (AVIF is served on more 7.1 templates than on 7.0), but the dominant LCP cost on both versions is the operator's choice of hero image, not the version's rendering pipeline.
The actionable list is identical: compress hero images, use Squarespace's built-in image-optimization toggle, lazy-load below-fold images via the SEO settings, avoid heavy custom fonts. The Site Speed cluster covers the implementation. Migrate for editor reasons, not for speed reasons. The speed is roughly identical for the same operator running the same install.
§07Schema and code
Schema and Code Injection availability across versions
Code Injection availability depends on the Squarespace plan, not the version. Personal plan blocks Code Injection on both 7.0 and 7.1. Core, Plus, Advanced, Business, Commerce Basic, and Commerce Advanced unlock it on both versions. The JSON-LD patterns covered in Pillar 3 work identically on both versions. The cross-cluster install logic is therefore version-agnostic; only the editor steps differ slightly.
The Code Injection cluster documents the four placement scopes (site-wide Header, per-page Header, site-wide Footer, in-page Code Block) and the per-scope patterns. Every pattern works on 7.0 and 7.1. The Pillar 3 placement leaf covers the scope-selection decision for schema specifically. Read those two together for the complete pattern; this cluster covers the version comparison, not the implementation.
One Squarespace-side limitation worth naming. Per-page Code Injection (the gear icon on a specific page) requires Business plan or above on both versions. Personal and Core plans can only use site-wide Code Injection, which means schema like Article (per-page) has to be authored via a different placement pattern. The JSON-LD leaf in the Code Injection cluster covers the workarounds.
§08The decision
Should I upgrade? Three honest conditions
Upgrade if a redesign is already on the calendar, if the 7.0 site is on a template family Squarespace has effectively stopped investing in, or if there is a specific 7.1-only feature the business needs (the fluid engine, member areas, the Course Player). Do not upgrade to chase ranking gains the version does not deliver. Do not upgrade because someone told you 7.0 is 'deprecated' — it is supported, indexed, and still ranks. Do upgrade if you can afford four to twelve weeks of traffic recovery and 30 to 90 hours of rebuild work.
The upgrade impact leaf in this cluster walks through the cost-benefit framework in more detail. The short version: a graceful upgrade with proper redirect mapping typically loses 15 to 30 percent of organic traffic for the first 60 days and recovers to baseline within 90 to 120 days, with most operators ending modestly ahead of where they started once the modern platform's editorial wins compound. An ungraceful upgrade — broken redirects, lost canonical tags, mis-mapped collection URLs — can lose 50 percent or more permanently. The cluster's migrations leaf on the 7.0-to-7.1 path covers the redirect mapping in detail.
The single best argument for staying on 7.0: a well-tuned 7.0 site with proven backlinks, ranked content, and a working revenue model has nothing to gain from a version migration that the operator could not also achieve by tightening schema, fixing image weight, and patching multi-H1 pages in place. The single best argument for migrating: a 7.0 site that needs a redesign anyway should redesign onto 7.1, not into a fresh 7.0 build it cannot start.
