Does Ghost add canonical tags automatically?
Yes. Ghost adds a self-referencing canonical to posts and pages automatically, and each post and page has a Canonical URL field for pointing the tag at a different address. The tag is rendered through the theme's {{ghost_head}} helper, which Ghost's default themes, including Casper, place in the <head>, so any theme that includes that helper gets correct self-referencing canonicals with no configuration.
The flip side: a theme that omits {{ghost_head}} loses canonical output along with the rest of Ghost's automatic head-level SEO, including sitemaps, structured data, and Open Graph and Twitter tags. When a canonical goes missing or looks wrong on a Ghost site, whether the theme includes {{ghost_head}} is one of the first things to check.
The per-post Canonical URL field
Ghost launched its custom Canonical URL feature in March 2019. It adds a Canonical URL field to each post's or page's settings, in the editor's meta and SEO settings panel. A value there overrides the default, so the rendered tag names that URL instead of the post's own address. The field can also be set through the Ghost Admin API, using the canonical_url field on the post or page resource. It was presented as new around launch; on current versions it is a standard part of the editor.
The field has three documented uses:
- Syndication and republishing: a guest post or an article that first appeared elsewhere points back to the original source.
- Multiple versions of similar content: A-B or tracking variants point to the preferred version.
- Curated link collections: a theme surfaces the field to build lists that link out while attributing SEO value to the original sources.
How the canonical renders in your theme
By default, {{ghost_head}} outputs the <link rel="canonical" href="..."> tag automatically: self-referencing unless a custom canonical URL has been set on that post, in which case it outputs the custom value. Theme developers who want explicit control can use the {{canonical_url}} helper, which Ghost's theme documentation describes as the custom canonical URL set for the post, alongside related helpers such as {{meta_title}} and {{meta_description}}.
Ghost also supports code injection, per post or site-wide, for adding arbitrary head markup. Hand-rolling a canonical there risks duplicating the one {{ghost_head}} already emits, which leaves two canonical links on the page. The Canonical URL field is the intended control for canonicals.
Two posts compared: default and overridden output
Take two posts on a Ghost site at https://www.example.com. The first is original, and its Canonical URL field is empty, so {{ghost_head}} writes a canonical naming the post itself:
<!-- served at https://www.example.com/field-notes/ -->
<link rel="canonical" href="https://www.example.com/field-notes/">The second is a guest essay that first ran on another publication. Its Canonical URL field holds the original address, so the same helper writes that value instead:
<!-- served at https://www.example.com/guest-essay/ -->
<link rel="canonical" href="https://original-site.com/essay/">Nothing in the theme differs between the two; the field is the only switch. The second post now carries a cross-domain canonical, with what that implies: Google treats it as a hint and may still index the Ghost copy, especially if the pages differ.
Republished content: which side sets what
Cross-posting is the clearest use of the Canonical URL field, and the field only works in one direction. It controls the canonical on the Ghost copy. When a Ghost site hosts a guest contribution, or brings over an article its author first published elsewhere, setting the field to the original signals which version the Ghost site considers the source, while the copy stays readable. Without that signal, two live copies of the same article look like ordinary duplicates, and a search engine has to guess which one to treat as authoritative, a guess that will not always favor the original.
The reverse case needs nothing in Ghost. When another site republishes a post that originated on a Ghost site, the Ghost post's automatic self-referencing canonical is already correct, and any canonical or noindex has to go on the other site's copy. Search Console cannot inspect a URL outside a verified property, so checking the partner's page means reading its source and response headers directly.
Filling in the Canonical URL field correctly
The field accepts whatever is typed into it, so the checks that apply to any canonical target apply here:
- A full absolute URL, including
https://. Google asks for absolute URLs in canonicals. - The exact address the original serves. Load it first; if it redirects, use the final URL, with the same host and trailing slash.
- A target that returns a 200 and is indexable. A canonical pointing to a redirect, a 404, or a noindexed page gives Google nothing clean to consolidate onto, and Google may choose its own canonical.
- No
#fragment. Google generally does not support fragments in canonical URLs.
For syndicated content there is one more decision. Since 2023, Google has said the canonical link element "is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different," and prefers that the copy be kept out of the index with noindex. A republished post with a new introduction, added commentary, or edits is the kind of copy Google means. This page covers Ghost's canonical controls rather than a dedicated noindex setting; code injection accepts arbitrary head markup, so a robots meta tag can go there. When one does, clear the Canonical URL field so Ghost falls back to a self-referencing canonical, which is generally considered harmless beside noindex, rather than pairing noindex with a cross-domain canonical.
Checking canonicals on a live Ghost site
- View Source and count. Search a post's source for
rel="canonical". One match is expected. None usually means the theme lacks{{ghost_head}}; two usually means code injection or the theme adds a second tag. - Compare hosts. The protocol and host in the canonical should match the ones serving the page. If canonicals name a different host, for example after a domain change, the problem is site-wide: fix the site's configured address and the redirects, not individual posts.
- Use URL Inspection in Search Console. It shows the user-declared canonical and, from indexed data, the Google-selected one; the live test cannot predict Google's choice. A post whose field points to another page is expected to appear in the Page indexing report as "Alternate page with proper canonical tag." An original post listed as "Duplicate, Google chose different canonical than user" deserves a closer look at whether internal links and the sitemap agree with its canonical.
- Crawl the site. A crawler that reports canonicals across every post catches template-level problems that spot checks miss.
Common Ghost canonical mistakes
- Using a theme that is missing
{{ghost_head}}, or an outdated theme built against an old API version, either of which drops or breaks canonical output. Several historical GitHub issues, including #10367, #10769, #10978, and #12007, trace back to this kind of outdated theme or API mismatch rather than a core defect. - Adding a manual canonical through code injection on top of the automatic one, producing two canonical links.
- Treating the self-referencing default as a bug. It is correct for original content; a custom canonical belongs only on genuinely syndicated, republished, or variant material.
- Setting the Canonical URL field to a source URL that later changes or disappears, and leaving it stale.
Frequently asked questions
Do I need to manually add a canonical tag to my Ghost posts?
No. Ghost applies a self-referencing canonical tag to posts and pages by default through the theme's {{ghost_head}} helper, as long as the theme includes that helper. Adding another one by hand, for example through code injection, creates a duplicate.
How do I set a canonical URL for a post I've republished from elsewhere?
Open the post's settings panel in the editor, find the Canonical URL field in the meta and SEO settings, and enter the original source's full URL. This overrides the default self-referencing canonical so the tag names the original instead. Confirm the original URL loads with a 200 and does not redirect.
Can I set the canonical URL through the Ghost API instead of the editor?
Yes. The Ghost Admin API exposes a canonical_url field on the post and page resource, which can be set programmatically. It controls the same value as the Canonical URL field in the editor.
Why isn't my custom canonical URL showing up on the page?
This is most often traced to an outdated theme that is missing the {{ghost_head}} helper or was built against an old Ghost API version. Historical reports of canonical URLs "not working" have generally been theme or API-version issues rather than defects in current Ghost.
What happens if I add a canonical tag through code injection in Ghost?
You risk duplicating the canonical that {{ghost_head}} already outputs, which leaves two canonical links on the same page. Use the post's Canonical URL field instead.
Should a republished Ghost post use the Canonical URL field or noindex?
Either can work, but not both at once. Google has said since 2023 that it does not recommend the canonical link element for avoiding duplication with syndication partners and prefers noindex on the copy. If the republished post differs noticeably from the original, noindex is the more dependable choice; if it is a near-identical copy, a canonical to the original remains a reasonable hint.