Canonical Tags in Framer

Automatic on a connected domain, with one site-wide control

Framer, the hosted website builder, adds a self-referencing canonical to every published page on its own once your domain is connected and managed through Framer. What it does not offer is a per-page override: the only canonical control is a single site-level Canonical URL field, intended for sites Framer serves through a reverse proxy or a subdirectory.

The Framer Help Center states the default plainly: "Framer automatically generates the correct canonical tags when your domain is connected and managed through Framer." There is no toggle to enable and nothing to fill in per page. The tag is derived from the domain Framer knows it is serving, which is also why the edge cases all involve Framer not knowing that domain.

A September 2026 check of live pages showed the tag doing sensible work. A template published on a free subdomain, requested with ?ref=test, returned a canonical to the bare subdomain root with the query string removed. A Framer-built help page requested with ?utm_source=test likewise returned a clean canonical, with a trailing slash. Those were two sites fetched through a summarizing tool, one of them Framer's own, so they show the pattern rather than a documented guarantee; trailing-slash behavior on customer sites in particular is not documented.

As with any canonical, Google treats the tag as one signal among several, alongside redirects, HTTPS, and sitemaps. Framer's automatic tag gets the declaration right; whether Google agrees still depends on the rest of the site pointing the same way.

When the Canonical URL field is needed

The field exists for one situation: visitors reach the site on a domain that Framer is not directly serving. That covers reverse-proxy hosting, Multi Site setups, and a Framer site mounted in a subdirectory of another site. In those cases Framer warns that "SEO tags may default to your project's .framer.website domain", which means every page would name the Framer origin as its preferred URL instead of your public one.

The fix, per Framer's canonical article:

1. Open the project settings and go to Domains.
2. Scroll to the bottom to the Canonical URL field.
3. Enter the public URL, either the root (https://example.com) or a subdirectory (https://example.com/blog).
4. Republish, then view source to confirm the canonical now names that URL.

Framer's own articles label the path inconsistently, "Settings > Domains" in one and "Site Settings → Hosting → Domains" in others, so look for Domains under either. Plan requirements are also inconsistent: the reverse-proxy article says the canonical URL is part of the Advanced Hosting add-on, while the canonical article mentions no plan. The same proxy article is emphatic about the stakes: "Sites without a Canonical URL perform worse in search." It also says *.framer.app domains are not indexed by search engines, so a proxy should point at a custom origin domain or a *.framer.website address, never a .framer.app one.

On a normally connected domain, Framer does not describe the field as necessary, and filling it in there solves nothing.

Per-page settings, and the canonical they leave out

Framer's per-page SEO controls are real but narrow. Page Settings carry a title, a page description, a social preview image, and a Search engines toggle; CMS collection pages accept variables such as {{Title}} in those fields. Switching Search engines off adds <meta name="robots" content="noindex">. None of these touch the canonical.

That leaves no native way to point one page at another, the usual reason for a non-self-referencing canonical, such as near-duplicate landing pages or a republished article. Framer's Search engines toggle is sometimes pressed into that role, but noindex removes a page rather than consolidating it, and Google's duplicate URL guidance does not recommend noindex for choosing a canonical within a site.

The better answers are structural. If two pages are near-duplicates, merge them into one. If an old page should give way to a new one, redirect it. Both are simpler than trying to override a canonical that Framer regenerates on every publish.

Why custom code is a poor override

Framer's Custom Code settings can target specific pages, including CMS pages, and plugin code can inject at headStart, headEnd, bodyStart, and bodyEnd. Agency blogs suggest pasting a tag like this into a page's head code, or binding it to a CMS text field:

<link rel="canonical" href="https://example.com/original-page">

The problem is that Framer is already emitting its own canonical. Whether page-level custom code can replace Framer's tag, rather than sit beside it, is undocumented, and the default expectation is two canonical elements that disagree. Google asks that an injected canonical be the only one on the page, and even the agency blog promoting the technique warns that when two tags appear, Google will likely ignore both. The workaround can therefore leave a page worse off than the automatic tag alone would.

A response header is not an escape route either. Framer's custom headers, under Hosting on the Advanced Hosting add-on, are an allowlist that includes X-Robots-Tag, Content-Security-Policy, and Strict-Transport-Security. Link is not on it, so an HTTP-header canonical is not available, though Framer accepts requests for additions.

Duplicates the automatic canonical does not cover

Framer's tag handles parameters on the page it is printed on. It cannot address duplication that lives at the domain level.

• The free subdomain is public. The *.framer.website site observed in September 2026 was crawlable, carried no noindex, listed a sitemap in robots.txt, and canonicalized to itself. A project built on the subdomain and later moved to a domain hosted elsewhere leaves a live, self-canonical copy behind. What happens to the subdomain once a custom domain is connected inside Framer is not documented, so test it on the real project.
• Redirects stop at the domain boundary. Framer's Redirects feature supports wildcards and capture groups, but only for sub-paths within the current domain. Redirecting a whole old domain has to be configured wherever that domain is hosted.
• Proxied origins leak. A reverse proxy without the Canonical URL field set is the one configuration where the automatic tag actively points the wrong way.

Verifying a Framer canonical

Checks worth running after publishing, and after any hosting change:

• View source, not DevTools. Search the page source for rel="canonical", confirm there is exactly one, and confirm the host is your public domain.
• Add a query string. Request a page with ?utm_source=x; the canonical should come back without it, matching the observed behavior.
• Test through the proxy. On proxied sites, fetch pages through the public domain and confirm the canonical does not name a .framer.website host.
• Compare in Search Console. URL Inspection shows the user-declared canonical beside the Google-selected one. Framer's own indexing help article discusses the "Duplicate, Google chose different canonical than user" status, which has its own page here.

For a standard site on a connected domain, those checks are a formality, and the right decision is to leave the canonical alone. The settings worth an owner's attention are the ones that change which domain Framer thinks it is serving.

Frequently asked questions