Own the canonical URL when you syndicate to Substack
Yes, you should syndicate to Substack, but only after you have set the canonical URL to a domain you own. If you publish the same post on both your site and Substack without a canonical tag, Google will pick the version it thinks is more authoritative. Most of the time, that is Substack, whose domain authority (around 87 as of 2025) outranks any personal site that is less than a few years old. The rest of this post explains what canonical means, how Substack and Beehiiv handle it by default, what happens when you get it wrong, and the exact workflow to keep SEO credit on your own domain.
What a canonical URL does for your newsletter content
A canonical URL tells search engines which version of a piece of content is the authoritative one, so that link equity and ranking signals consolidate on that URL rather than splitting across duplicates. It lives in the <head> of an HTML page as a single tag:
<link rel="canonical" href="https://yourname.com/posts/my-post">
When your post exists on two URLs (your site and Substack), search engines must pick one to rank. Without a canonical, they fall back to their own signals: domain authority, inbound link counts, historical indexing patterns, page load speed, and how recently each version was crawled.
Ahrefs puts the risk directly: "If you don't [add a canonical], there's a risk of Google treating the syndicated or republished version of the content as the original and ranking it ahead of your site in the search results."
Google's own documentation is consistent: "if you don't specify a canonical URL, Google will identify which version of the URL is objectively the most complete and useful for search users, and marks it as canonical." The practical consequence for newsletter writers: a three-year-old Substack domain with 40,000 subscribers and thousands of inbound links will look more authoritative to Google than a personal site you launched six months ago. Your original post may lose the coin flip even if you wrote it first.
One important caveat: Google treats rel="canonical" as a strong signal, not a directive. It can override your stated canonical if it finds stronger evidence pointing elsewhere (more authoritative inbound links, stronger indexing history). This is why the original post's own signals matter too: publish there first, get Google to crawl it first, and build links to your domain over time.
How Substack and Beehiiv handle canonical URLs (and what they don't do)
Neither Substack nor Beehiiv lets you set a custom canonical URL on a post without a paid plan or custom domain, which means every post you publish directly to these platforms self-canonicalises to their domain by default.
| Platform | Default canonical | Custom canonical per post | How to set |
|---|---|---|---|
| Substack (free) | name.substack.com/p/slug |
No | Not supported without custom domain |
| Substack (custom domain, paid) | yournewsletter.com/p/slug |
Points to your domain | Point DNS to Substack in settings |
| Beehiiv (no custom domain) | name.beehiiv.com/p/slug |
Not documented | No per-post canonical override found |
| Beehiiv (custom domain, any plan) | yournewsletter.com/posts/slug |
Points to your domain | Add custom domain in Beehiiv settings |
| Ghost (self-hosted or Ghost Pro) | Your domain | Yes | Post settings panel: "Canonical URL" field |
| Anchorify | anchorify.io/org/project/slug |
Single stable URL, no splits | Published URL is the canonical |
Substack does not expose a canonical URL field in the post editor. Every post published on Substack.com gets a self-referencing canonical pointing to <publication>.substack.com/<slug>. The only way to make that canonical resolve to your own domain is to pay for Substack's custom domain feature and point your DNS records to Substack's servers. That makes Substack issue the canonical at your domain, but your content still lives on Substack's infrastructure, and you are still dependent on Substack's platform for the URL to keep working.
Beehiiv follows a similar pattern. Custom domains are available on all plans, but a per-post canonical override to an external URL is not documented as a standard feature on the pricing page or in the public help docs. If you add your own domain in Beehiiv settings, the canonical resolves to your domain. Without it, Beehiiv owns the canonical.
Ghost is the clearest counterexample: the post settings panel has an explicit "Canonical URL" field where you can enter any URL. Ghost was built to respect canonical ownership. If you want to publish at yourname.com and syndicate the same text to Substack, Ghost lets you declare the canonical explicitly.
The plain conclusion: if you are on free Substack or free Beehiiv without a custom domain, every post you publish there is canonically owned by that platform, not you.
What happens when you syndicate without setting the canonical URL
When you publish the same post on your own site and Substack without a canonical tag, Google treats them as duplicate content and picks the version it believes is more authoritative. The consequences are practical and compounding.
First: your original post may be outranked by your own Substack copy. You write the post, you do the research, you publish it. Then a search for the title shows yourname.substack.com/p/post in position two while your site is in position eight. You are sending traffic to Substack, not to your own domain. Every click on that result builds Substack's engagement metrics, not yours.
Second: inbound links accumulate at the wrong URL. Someone reads your Substack version and links to it from their blog. That link builds Substack's domain authority. Even if the link was earned by your content, the SEO benefit goes to the platform. Over time, this compounds: more links to the Substack version make the Substack version look even more authoritative, making it even harder for your own domain to win the canonical contest.
Third: platform lock-in gets deeper every month. The longer you publish only to yourname.substack.com, the more Google has indexed, cached, and ranked those URLs. If you leave Substack, those URLs disappear or start 404ing. Readers who bookmarked your posts lose them. Sites that linked to you now have broken links. The SEO work you did is gone because it was done on borrowed infrastructure.
Google acknowledges the tracking problem directly: without canonical specification, "you lose control over your content's performance metrics." You cannot get a unified view of how your content performs if it lives at three different URLs with no canonical to consolidate the data.
The workflow to own your canonical URL when syndicating to Substack
The right syndication workflow publishes to your own domain first, establishes the canonical there, then sends the content to Substack or Beehiiv as a distribution layer only. Here is the exact sequence.
Step 1: Decide on the permanent URL before you write. Pick the slug you will use at your domain. yourname.com/posts/my-post or yourname.com/newsletter/march-2026-edition. The slug should be stable. Do not change it after publishing.
Step 2: Publish at your domain first, with the correct canonical. If you use Ghost, the post settings panel has a "Canonical URL" field. Set it to the full absolute URL of the post. If you use a static site generator (Hugo, Jekyll, Eleventy), add canonical: https://yourname.com/posts/my-post to the frontmatter. If your CMS does not have a canonical field, contact support or add it manually via a custom template.
Step 3: If you do not have a website or CMS, use a tool that gives you a stable URL at a domain you control. Anchorify is built for this: anchorify publish my-post.md --slug my-post publishes your post to https://anchorify.io/<yourname>/<project>/my-post with one command. That URL becomes the canonical. No CMS to configure, no hosting to manage. See the getting started guide for the full setup.
Step 4: Ping Google Search Console. Go to the URL Inspection tool in Search Console, enter your canonical URL, and click "Request Indexing." This tells Google to crawl your version before it discovers the Substack version. The window is typically 24–48 hours.
Step 5: Publish to Substack (or Beehiiv) for email distribution. In the Substack editor, paste the post content. At the top, add a line: "Originally published at [link to your canonical URL]." This is a visible link back to your domain. It does not inject a canonical tag into Substack's HTML, but it adds an explicit inbound link from Substack to your site, which is a useful signal.
Step 6: If you have a custom domain on Substack or Beehiiv, skip step 5's workaround. With a custom domain, the Substack or Beehiiv version already canonicalises to your domain. The important thing is that your DNS is pointed at the platform and the custom domain is configured correctly in settings.
Step 7: Verify the canonical on your post. Use a browser dev tools check (View Source and search for canonical) or a free tool like Ahrefs' SEO toolbar to confirm the canonical tag on your published post points to the correct absolute URL.
Platform portability is the real reason canonical ownership matters
Canonical ownership is not just an SEO tactic. It is the difference between content you own and content that lives on a platform's terms.
Newsletter writers who control their canonical URL can move platforms at any time. Substack subscribers can be exported as a CSV and imported into Beehiiv, Ghost, or any other email tool in a few hours. But if the indexed URLs are at yourname.substack.com, those URLs go dark when you leave. Readers who saved or shared your posts get 404s. Sites that linked to you now link to nothing.
Writers who rely solely on yourname.substack.com are in a structurally similar position to writers who built their audience on Medium's domain between 2016 and 2019. The content was theirs; the URLs were Medium's. When Medium changed its algorithms and de-prioritised their work, the SEO investment went with it.
The correct model is to treat Substack or Beehiiv as an email delivery layer, not as your canonical home. The post lives at your URL. Substack handles the inbox delivery to paying and free subscribers. When you decide to move to a different email platform, you export subscribers, update your publishing workflow, and your indexed URLs are untouched. Consultants and solo operators who write regularly for clients are especially exposed to this risk: client-facing posts with inbound links from client sites should not be hosted at a platform URL.
For newsletter writers who also deliver SEO work, the same principle applies: if you write monthly SEO reports for clients and link to your writing as credentials, those links should point to URLs you own.
Frequently Asked Questions
The five questions below come up most often from newsletter writers deciding how to syndicate without giving away their SEO equity.
Does Substack support canonical URLs?
Substack does not have a per-post canonical URL field in the standard editor. Every Substack post self-canonicalises to <publication>.substack.com/p/<slug> by default. If you add a custom domain to your Substack publication (a paid feature), the canonical resolves to your custom domain instead. Without a custom domain, the canonical is owned by Substack.
Does Beehiiv let you set a custom canonical URL?
Beehiiv does not document a per-post canonical override to an external URL as a standard feature. Adding a custom domain in Beehiiv settings makes posts canonicalise to your domain rather than name.beehiiv.com. Without a custom domain, the canonical is owned by Beehiiv's infrastructure.
What happens to my SEO if I cross-post to Substack without setting canonical?
Google may index the Substack version as the authoritative copy, especially if Substack's domain has higher authority than your site. Inbound links pointing to the Substack URL build Substack's authority, not yours. If you later leave Substack, those indexed URLs disappear and any SEO equity accumulated there is lost.
Is it safe to syndicate to Substack if I have my own website?
Yes, with the right setup. Publish at your own domain first, get Google to index it (use Search Console's URL Inspection tool), then publish the same content to Substack. Add a visible "originally published at [your URL]" link at the top of the Substack post. This establishes your site's version as prior, adds an inbound link from Substack, and keeps your domain as the indexed source.
What is the easiest way to own the canonical URL without setting up a full website?
If you do not have a website or CMS, publishing to a stable public URL at a domain you control is the first step. Anchorify lets you do this with one command from the terminal: anchorify publish post.md --slug my-post-slug. Your post publishes to a clean, indexed URL that you can use as the canonical before syndicating to Substack or Beehiiv. Setup takes about ten minutes. See the getting started guide.
Sources
- Google Search Central: Canonicalization. Google's official guidance on how it selects canonical URLs and how to signal your preference.
- Google Search Central: Consolidate duplicate URLs. Consequences of unresolved duplicate content: crawl budget waste, fragmented ranking signals, tracking complications.
- Ahrefs: Canonical Tags Guide. Syndication risk and the correct workflow for setting canonicals on republished content.
Anchorify publishes any markdown file to a stable public URL with one command: no CMS, no hosting config. If you want to own the canonical URL on your newsletter posts before syndicating to Substack, that is what it is built for. Free during beta at anchorify.io.
Last updated: 2026-05-24