Canonical Tags in Squarespace

How Squarespace handles canonical tags

Squarespace automatically injects a self-referencing canonical tag into the <head> of every page it renders. There is no setup step, no toggle to find, and no configuration screen involved -- the tag is simply present in the rendered HTML from the moment a page is published, and it points back at that page's own URL.

The important framing here is that the platform, not the site owner, owns the canonical tag on Squarespace. That is a meaningfully different posture from platforms where a canonical is something you actively configure or override through a dedicated field. On Squarespace, the canonical tag is closer to infrastructure -- part of how the page-rendering system builds the page, on the same level as something like the doctype declaration.

For the overwhelming majority of Squarespace sites, this is a fine default: a self-referencing canonical on every page is exactly the correct baseline signal in the absence of any duplicate-content problem to solve. Where it gets more complicated is when a site owner wants to change that default -- and Squarespace doesn't give you a straightforward field for that.

Why you can't natively edit the Squarespace canonical

Squarespace does not expose a first-class, dedicated field for editing or removing the canonical tag it auto-generates. There is no Canonical URL control sitting inside Page Settings or SEO Settings that lets you type in an alternate value. The automatic, self-referencing canonical is simply what ships, and Squarespace's own settings surface doesn't offer a native override.

You will find some third-party tutorials and forum posts that describe a native canonical URL field somewhere in Squarespace's SEO settings. Treat that claim with real skepticism: it is unverified against Squarespace's documented, established behavior, which is auto-managed canonicalization with no first-class edit control. It's possible such claims describe outdated interfaces, confuse canonical URLs with a different setting, or are simply incorrect. If you encounter this claim while researching your own site, don't act on it without testing it live on your own account first -- check View Source on a page after making the change to confirm what actually shipped, rather than trusting the tutorial's word for it.

The practical upshot: if you need a canonical tag pointed somewhere other than the page's own URL on Squarespace, you are not choosing between a native field and a workaround -- you are choosing a workaround, full stop. That workaround is Code Injection, and it comes with a real risk, covered next.

Code Injection and the duplicate-tag risk

Squarespace lets you inject custom HTML into the page <head> in two places: site-wide, via Settings, then Advanced, then Code Injection, then the Header field; and per-page, via that page's Page Settings, then Advanced, then Page Header Code Injection. Either location lets you hand-write a <link rel="canonical" href="..."> tag.

Here is the critical fact to understand before you do that: a canonical tag added through Code Injection is added alongside the automatic canonical Squarespace already generates -- it does not replace it. Code Injection is additive by design; it inserts your markup into the page, it does not remove or rewrite what the platform itself is already outputting. A naive Code Injection canonical therefore produces a page with two rel=canonical tags: the native self-referencing one Squarespace always ships, plus your injected one. Two canonical tags on one page is exactly the situation SEO guidance warns against, because search engines then have to decide which one to trust, and that behavior isn't something you want to leave to chance.

There's also an availability caveat worth knowing before you plan around per-page injection: per-page Header Code Injection is not uniformly available across the whole platform. It generally requires a Business plan or higher, and even where the plan supports it, it is not available on individual blog posts on all plans. If your plan or content type doesn't support per-page injection, site-wide Header injection is the only option -- but that applies the same injected markup to every page, which is rarely what you want for a canonical tag specifically.

If you do need to inject a canonical, the only way to avoid the duplicate-tag problem is to verify, via View Source on the live page, exactly what Squarespace already ships, and to be honest with yourself that a Code Injection canonical is not a clean override -- it's an addition you have to actively manage the consequences of.

7.0 vs 7.1

If you're running an older Squarespace 7.0 site versus a newer 7.1 site, there is no documented difference between the two versions in how canonical tags are generated or managed. Both versions auto-inject a self-referencing canonical, and neither version offers a native editing field beyond what's described above. Version does not change the Code Injection additive-duplicate risk either -- it applies the same way on both.

This matters mainly as a negative finding: if you're troubleshooting a canonical issue on a 7.0 site and find guidance written for 7.1, or vice versa, you can generally trust that the canonical-tag mechanics themselves are not the variable causing your discrepancy. Look elsewhere -- template differences, Code Injection placement, or plan-level feature availability -- before assuming version is the cause.

Common Squarespace canonical mistakes

The single most common mistake on Squarespace is injecting a canonical tag via Code Injection without realizing the native, auto-generated canonical is still shipping right alongside it. The site owner's intent is usually reasonable -- consolidate a duplicate page, or point a variant back at the main URL -- but the execution creates two competing canonical tags instead of one clean override, because Code Injection adds rather than replaces.

Adding a rel=canonical tag through Code Injection without first confirming, via View Source, whether Squarespace's own automatic canonical is still present on the rendered page.
Assuming a native Canonical URL field exists somewhere in SEO Settings and building a workflow around a control that likely isn't there.
Attempting per-page Header Code Injection on a blog post, or on a plan tier where that feature isn't supported, and not realizing the injection silently didn't apply.
Using a protocol or host in an injected canonical, such as http instead of https, or the wrong subdomain, that doesn't match how the page is actually served, creating a mismatched canonical even before the duplication problem is considered.

Because Squarespace's default behavior -- a correct, self-referencing canonical with no configuration required -- already solves the vast majority of canonical needs, the safest posture for most Squarespace site owners is to leave it alone entirely. Reach for Code Injection only when you have a specific, well-understood reason to override the default, and verify the live rendered output afterward rather than assuming the injected tag behaved the way you intended.

Frequently Asked Questions

Does Squarespace add canonical tags automatically?

Yes. Squarespace automatically injects a self-referencing canonical tag into the head of every page, with no configuration required. The platform manages this itself rather than exposing it as a setting you turn on.

Can I edit the canonical tag Squarespace generates?

Not through a native, first-class field. Squarespace does not expose a dedicated Canonical URL control in its settings. Some third-party tutorials claim otherwise, but that claim is unverified and contradicts Squarespace's documented, auto-managed canonical behavior -- test it live on your own account before trusting it.

If I add a canonical tag through Code Injection, does it replace the automatic one?

No. Code Injection is additive. A canonical tag you add via Header Code Injection appears alongside the automatic self-referencing canonical Squarespace already generates, which means the page can end up with two canonical tags rather than one corrected tag.

Can I use per-page Code Injection on any Squarespace plan?

Not reliably. Per-page Page Header Code Injection is generally available starting on the Business plan and above, and even where it's available, it is not supported on individual blog posts on all plans. Confirm availability for your specific plan and content type before relying on it.

Does the canonical mechanism differ between Squarespace 7.0 and 7.1?

No documented difference exists between 7.0 and 7.1 in how canonical tags are generated or managed. Both versions auto-inject a self-referencing canonical and neither offers a native edit field.