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

7.0 vs 7.1 · § 2.9.3 · How-to

7.1 URL structure for SEO — what changed and what to map

7.1 generates URLs the same way 7.0 does at the page level: lowercase, hyphenated, descriptive, no special characters1. The difference is at the collection level. 7.0's blog index path was sometimes prefixed by a template-specific segment that 7.1 has cleaned up, and 7.1's universal template normalises portfolio and events URLs in ways some 7.0 sites do not match. A 7.0-to-7.1 migration is therefore a URL-mapping project, not just a content port, and the mapping has to cover collection items individually — not just pages.

This leaf documents what 7.1 does with URLs, where the migration risk lives, and the two Squarespace-specific gotchas (trailing slashes and reserved-word slugs) that quietly produce 404s on a half-mapped migration. The full redirect-mapping workflow lives in the migrations leaf in the Redirects cluster; this leaf is the per-version-difference reference.

What 7.1 does with URLs by default

A 7.1 site generates page URLs from the page title automatically: title-cased input becomes lowercased, hyphenated, and stripped of special characters. The result is a clean slug at the bottom of the URL hierarchy. The slug is editable from the Page Settings panel up to the point of publishing; after publish, edits trigger a Squarespace-managed 301 redirect from the old slug to the new one. Collection items (blog posts, portfolio entries, events) follow the same rules with one wrinkle: their parent collection URL prefixes their slug, so a blog post lives at /blog-collection-url/post-slug/.

Google's URL structure guidance3 aligns with Squarespace's defaults: hyphenated, lowercase, descriptive URLs are preferred. The risk is not in the slug generation; it is in the collection-prefix portion of collection-item URLs. A 7.0 site whose blog collection URL was /journal and a 7.1 site whose blog collection URL was renamed to /blog during the rebuild end up with every post on a different URL even though the post slugs themselves are identical.

Collection-item URLs are where the migration risk lives

A 7.0 site with 80 blog posts, 40 portfolio items, and 12 events has 132 collection-item URLs that could potentially change between versions. Each is a URL that backlinks may point at, that internal links use, that Google indexed in 2020, and that 404s on the new site unless mapped. The page-level URLs are usually identical because operators rebuild the same about, services, contact, and pricing pages with the same slugs. The collection-level URLs are the trap.

The two most common collection-prefix changes during a 7.0-to-7.1 migration: the blog collection moving from /journal or /news to /blog as part of the rebuild, and the portfolio collection moving from /work to /portfolio or vice versa as part of a brand refresh. Each rename multiplies into N redirects where N is the number of collection items. None of the renames is required by Squarespace; they happen because operators take the rebuild as an opportunity to "clean up" the URL structure and underestimate the redirect-mapping cost.

Trailing slashes and canonical consistency

Squarespace's default is trailing-slashed URLs on both 7.0 and 7.1: /about/, /pricing/, /blog/post-slug/. Google treats /about/ and /about as canonically equivalent when one redirects to the other consistently. Squarespace handles this redirect automatically. The risk is custom redirects in URL Mappings that introduce a slash inconsistency by mapping /old-url to /new-url/ (or vice versa), which can produce a chain of two redirects and a small but cumulative ranking signal loss across many migrated URLs.

The fix is to author every URL Mapping with trailing slashes consistent on both sides. Map /old-slug/ -> /new-slug/, not /old-slug -> /new-slug/. The Squarespace URL Mappings panel2 does not enforce trailing-slash consistency, so the operator has to enforce it editorially.

URL Mappings The consistent trailing-slash pattern (preferred) 
 # Consistent: every source and destination has a trailing slash /journal/ -> /blog/ 301 /journal/old-post-slug/ -> /blog/old-post-slug/ 301 /work/ -> /portfolio/ 301

Reserved-word slug conflicts

Squarespace reserves a small set of slug patterns for its own internal routes: /search, /sitemap, /robots.txt, /static, /s. A 7.0 site that uses any of these as a page or collection slug will not be reproducible on 7.1 without renaming. The conflict usually surfaces during the staging-site build when a page refuses to save with a reserved slug. The fix is to rename the slug, ship the page, and add a URL Mapping that redirects the old reserved-pattern URL to the new one.

The most common conflict in practice is a 7.0 site that named its store-locator page /search. On 7.1 the slug is taken by the platform; the page must be renamed to /find-us or /locations and the old /search URL needs an explicit redirect to the new slug. The same conflict appears on sites that named a collection /static (often a holdover from a developer who was experimenting with static-asset routing).

Mapping the old to the new — the discipline that makes the migration safe

Build a complete URL audit of the 7.0 site before starting the 7.1 rebuild. Export every URL: pages, blog posts, portfolio items, events, products, gallery entries, and any tag or category pages that have ranked. Cross-reference each row with the planned 7.1 equivalent. Submit the resulting CSV-format redirect map to URL Mappings before cutover, not after. The migrations cluster's <a href='/squarespace-seo/migrations/7-0-to-7-1/'>7.0-to-7.1 leaf</a> ships the full template.

The single most common reason migrations underperform: operators only map the pages they remember to map. A 7.0 site with 80 blog posts and 12 events typically has the about/services/contact URLs mapped correctly, the blog posts mapped about half the time, and the events not mapped at all. The mapped subset retains backlink equity; the unmapped subset 404s on cutover. The fix is the discipline of mapping every URL, not just the URLs that look important.

Submit the new sitemap to Search Console on cutover day. Verify the URL Mappings panel2 shows every redirect as active. Spot-check the highest-traffic 7.0 URLs from the GSC export in a private browser window to confirm they 301 to the right 7.1 page. The URL Mappings syntax leaf in the Redirects cluster covers the exact syntax and the wildcard patterns that compress repetitive mappings.

Keep reading · § 2.9.3