Canonical Tags in HubSpot CMS

Does HubSpot add canonical tags automatically?

Yes. HubSpot's Knowledge Base states it plainly: by default, when you create a new page or blog post, its own URL is set as the canonical for that content. That means website pages, landing pages, and individual blog posts all receive a self-referencing canonical automatically, with no manual setup required for the common case.

There is one documented and important exception: blog listing pages do not have a canonical URL set by default. A blog listing page is the index or archive view that lists multiple posts, as opposed to an individual post's own page. Because HubSpot doesn't canonicalize those listing pages out of the box, they're a frequent source of "missing canonical" flags in SEO audits. The individual posts underneath a blog have canonicals; the listing or index pages sitting above them may not. If your audit tool flags listing pages specifically, that's expected default behavior rather than necessarily a bug, though it's still worth deciding deliberately whether you want to address it with template-level canonical logic.

The page-level canonical URL setting

HubSpot exposes a per-page and per-post canonical override directly in the content editor. The path is roughly: open the page or post in the editor, go to Settings, then Advanced options, where you'll find a canonical URL field, labeled along the lines of "Customize the canonical URL" or simply "Canonical URL." Entering a value there overrides the default self-referencing canonical for that single piece of content, pointing it instead at another URL. This is the standard mechanism for consolidating duplicate or syndicated content, for example when the same article is published on HubSpot and also republished elsewhere, or when two landing pages target overlapping intent and you want one to defer to the other.

A naming caveat is worth stating plainly: HubSpot's UI wording and menu grouping, whether the field sits under "Settings" or "Advanced options" specifically, has shifted across CMS and Content Hub versions. The field lives somewhere in the page's advanced settings, but don't treat a specific label as permanent; verify the exact wording in your current editor before documenting it for a client or team.

Separate from the per-page field, HubSpot also has a global toggle governing whether canonical tags are auto-added at all, found roughly under account Settings, then Content, then Pages, then an SEO & Crawlers tab, with a control for "Pages and blog posts" canonicalization. This is the account-level switch for the automatic self-referencing behavior described above. As with the per-page field, the exact menu path and label vary by HubSpot UI version and by hub, so confirm it in the live portal rather than assuming a fixed screen.

Domain canonicalization in HubSpot

HubSpot does not offer a dedicated canonical switch for choosing www versus non-www or http versus https. Instead, that resolution happens through the connected, primary domain configuration and redirects, not through a free-form canonical rule. When you connect a domain to HubSpot, the platform sets up automatic redirects either from the root domain to the www subdomain, or from www to the root, depending on which version you designate as primary. A subdomain or root domain can host content in only one location at a time, so HubSpot effectively forces a single canonical host and 301-redirects the other version to it. That's how www-versus-non-www gets resolved on HubSpot: through hosting and redirect configuration, so the canonical tag that gets emitted reflects whichever host you chose as primary.

HTTPS works similarly. SSL is provisioned automatically after a domain connects, typically within minutes and up to roughly four hours in slower cases. There's a domain setting to require HTTPS, which forces HTTP-to-HTTPS redirects sitewide once enabled.

There is a known limitation worth flagging directly: users have reported canonical tags rendering with http:// instead of https:// even on pages that are actually served over HTTPS. The community-reported fix is to enable "require HTTPS" in the domain security settings, which causes HubSpot to generate the canonical on the secure protocol; editing the canonical on individual pages one at a time was described as the impractical workaround before that fix. This is worth taking seriously, because a canonical stuck on the wrong protocol directly undermines the whole point of the automatic self-referencing canonical. HubSpot does not document a separate, user-editable protocol or www preference switch specifically for canonical output; the protocol and host you see in the canonical tag follow from the primary domain connection and the require-HTTPS setting, not from a standalone canonical control.

Blog listing pages and AMP

As already noted, blog listing pages do not get a canonical URL by default, which is worth repeating here because it intersects with another HubSpot-specific wrinkle: AMP, or Accelerated Mobile Pages, is available only for blog posts in HubSpot, not for regular website or landing pages. AMP is turned on blog-wide under Content, then Blog settings, then a Google AMP tab with a "Turn on Google AMP formatted pages" option, or it can be enabled per post at publish time.

HubSpot's AMP Knowledge Base article documents the setup process and the associated trade-offs: AMP blocks HubSpot's own tracking JavaScript, it doesn't support custom JS, CSS, or forms, and featured images need to be at least 1200 pixels wide. What that article does not explicitly document is the AMP-to-canonical relationship. In a correctly implemented AMP setup, the AMP variant of a page references the canonical, non-AMP URL, and the canonical page in turn references its AMP variant via an amphtml link. It's reasonable to expect HubSpot follows that standard pattern, but because the Knowledge Base doesn't spell it out, verify the actual emitted tags on any HubSpot blog post that has AMP enabled rather than assuming.

There's also a practical trend worth mentioning: since Google deprecated AMP's ranking and Top Stories carousel advantages, several practitioners writing in 2024 and 2025 recommend turning HubSpot's AMP feature off entirely, to avoid maintaining a duplicate AMP surface with unclear upside and to simplify canonicalization generally. Treat AMP on HubSpot as optional, and increasingly legacy, rather than something to recommend by default.

Common HubSpot canonical mistakes

A handful of mistakes recur across HubSpot sites.

• Blog listing and index pages missing a canonical, which is expected default behavior but still trips up SEO audits and often warrants template-level canonical logic if left unaddressed.
• Canonical tags stuck on http:// on pages actually served over HTTPS, best fixed by enabling require-HTTPS at the domain level rather than editing pages one at a time.
• Overriding the canonical in Advanced options incorrectly, for example pointing several distinct pages at one URL and accidentally deindexing content that should have ranked on its own, or leaving a stale canonical after cloning a page, since a cloned page can inherit the original's manually set canonical.
• Assuming HubSpot dedupes across domains automatically. It resolves www-versus-non-www and http-versus-https through the primary domain connection and its redirects, but cross-domain duplication, such as the same content also published on a non-HubSpot domain, still needs a deliberate canonical set by hand.
• Leaving AMP switched on and creating a parallel AMP surface with unclear ongoing benefit.
• Changing a page's URL without accounting for the automatic canonical and redirect behavior; always confirm the new self-referencing canonical and the accompanying 301 after a URL change.
• Confusing the per-page override with the account-wide toggle; turning off global auto-canonicalization removes self-referencing canonicals sitewide, which is rarely what anyone actually intends.

Frequently Asked Questions