Squarespace SEO: correct by default, and firmly bounded

Squarespace SEO is unusually easy to describe, because the platform's design philosophy shows through it more clearly than through any other part of the product. The defaults are correct. Canonical tags are written for you and point at the right place. Sitemaps generate themselves. Titles and descriptions are editable everywhere a reasonable person would look for them. And then, at a fixed distance out, there is a wall — and what is on the other side of that wall is not documented as coming soon. It is documented as not yours.

For a large number of projects that is the right trade and not a compromise at all. A designer maintaining a studio site does not want shell access to robots.txt; they want a product where the default is right and the temptation to break it does not exist. The question this page answers is where exactly the wall is, so that you find out now and not in year three.

Titles, descriptions and the site-wide formats

Every page has an SEO tab carrying an SEO title and an SEO description, and both override whatever Squarespace would otherwise assemble. Above them sits a site-level layer of title formats, which build a page title out of components such as the page name and the site title.

The formats are the part that repays five minutes of attention. Left alone, they produce titles that are consistent and slightly wasteful — the site name eating characters on every page, the same structure repeated so that two pages read almost identically in a result. Set the format once so it is sane, then write the important pages' titles by hand. The reasoning behind that split is in the note on meta fields.

URL Mappings is the entire redirect story

Squarespace handles redirects in one place: Settings → Advanced → URL Mappings, a text field taking lines in the form /old-path -> /new-path 301. You can paste many lines at once, which makes a bulk restructure tolerable, and the syntax is simple enough to generate from a spreadsheet.

There is one precondition that catches nearly everyone the first time. The redirect only takes effect when the old URL no longer exists on the site — you have to delete the old page, disable it, or change its URL first. A rule pointing away from a live page does nothing, silently, and you will not get an error to tell you so. There is also no .htaccess, no server configuration and no plug-in that extends this: URL Mappings is not the easiest route to a redirect on Squarespace, it is the only one. The cross-platform redirect note puts that in context.

robots.txt belongs to Squarespace

All Squarespace sites are served the same robots.txt file and customers cannot access or edit it. Squarespace's stated reasoning is that this keeps every site on the platform following crawling best practice, which is a defensible position and, for most of its customers, probably a correct one.

What you get instead is a checkbox. In the crawler settings there is an option to block search engine crawlers, which adds a rule to the shared file on your site's behalf — an all-or-nothing switch appropriate for a site under construction and for nothing else. If your plan involves excluding a URL pattern, throttling crawl on a parameter space, or pointing at a sitemap Squarespace did not generate, that plan does not survive contact with this platform.

The noindex toggle, and the two places it is missing

Individual pages have a "hide page from search results" toggle in the page's SEO tab, and it does what it says. This is the correct tool for a thank-you page, a private landing page, or a page that exists for a campaign and should not compete with anything.

The gap is specific and it is worth committing to memory: the toggle does not exist on the homepage, and it does not exist on individual collection items. Collection items are blog posts, products, events and gallery entries — in other words, the bulk of what most Squarespace sites actually publish. If your intention was to noindex a batch of thin blog posts rather than delete them, Squarespace does not offer that as a setting, and because robots.txt is also closed, the workaround people reach for next is closed as well.

Canonical tags: generated, correct, and not yours

Squarespace writes a self-referencing canonical on its pages, which resolves the ordinary duplication problems — www against non-www, http against https, trailing slash against no trailing slash — without you doing anything. As a default it is genuinely good.

It is also part of the core HTML and not editable from the dashboard. The workaround circulated in Squarespace communities is to inject a canonical through the advanced per-page code option, and specialists who work on the platform full-time warn that this can leave the page carrying two conflicting canonical tags rather than one corrected tag. Two canonicals is a worse state than the default you were trying to improve. If you need cross-domain canonicalisation — syndicating a post to a partner site, running a campaign microsite — check that requirement against this limit before you build.

Structured data has no front door

There is no native panel for custom JSON-LD. Squarespace emits some structured data of its own on certain content types, and anything beyond that goes in through code injection, which means writing the markup by hand and maintaining it there.

Before deciding that matters, get clear on what schema is still worth having. FAQ rich results were restricted to well-known authoritative government and health sites in August 2023, and HowTo rich results were withdrawn from search results entirely. Structured data remains worth shipping so that machines can read the page — but the specific reason most people want a schema panel, snippet decoration, stopped being available three years ago. The schema note sets out what survived.

Who this ceiling actually constrains

It constrains multi-site operators, anyone running content in several languages, anyone whose site will be restructured repeatedly, and anyone who will at some point need to do something specific and unusual to one URL. For those projects Squarespace is a platform you will eventually leave, and leaving is expensive.

It does not constrain the studio site, the restaurant, the consultancy, the portfolio — projects where the pages are stable, the number of URLs is small, and the value of correct defaults exceeds the value of controls nobody will use. That is a large share of the web and there is nothing second-rate about being well served by it. Where Squarespace sits against the alternatives is set out in the seven-builder control audit, and the answer to "is the ceiling the reason my traffic is flat" is almost always no — which is a piece of its own.