Cross-posting to Dev.to or Medium without a canonical tag can let the copy outrank your original post. How to set canonical_url right, and when to skip it.
Cross-posting a new post to Dev.to or Medium the same week you publish it is one of the cheapest distribution moves a small blog has. It's also one of the easiest ways to hand a stranger's domain your own rankings, if you skip one setting: the canonical tag. Get it right and cross-posting is close to free reach. Skip it and you're quietly competing with yourself, the cross-domain version of keyword cannibalization, just running between two sites instead of inside one.
Paste the same article onto Dev.to or Medium with no canonical link back to the original, and Google sees two, sometimes three, URLs carrying identical text. It has to decide which one is the source. Left to guess, it doesn't always guess in your favor, and the guess can cost you traffic before you notice anything is wrong.
Duplicate content can cost real traffic long before you notice a problem. Guy Sheetrit, writing for the SEO agency Over The Top SEO, says he's seen businesses lose 30 to 40 percent of their organic traffic to duplicate content problems they didn't even know they had. That figure covers duplicate content in general, not cross-posting specifically, but an unmanaged syndicated copy is precisely the shape of duplicate content that causes it: two URLs carrying the same words, one of which used to be yours alone.
Say you publish a tutorial on your own domain Monday morning, then paste the same Markdown into Dev.to Tuesday afternoon with the canonical field left blank. By the following week, a search for a phrase straight out of your title can return the Dev.to URL first and your own post several spots lower, or not on page one at all. Nothing about your post changed. The only thing that moved was which URL Google decided to credit.
Dev.to, Medium, and Hashnode are large, long-established domains with deep backlink profiles and a lot of crawl budget. Google trusts them by default more than it trusts a two-year-old SaaS blog, simply because they've earned that trust at scale over many more pages and many more years. When the identical paragraph shows up on your domain and on Dev.to, that trust gap becomes a tiebreaker, and it tends to break toward the bigger site, not the one that wrote the post.
That's the domain-authority problem in one sentence: a canonical tag argues for the original, but domain strength is still one of the inputs Google weighs, and yours is usually the smaller number.
Each platform has its own mechanism, and each one's a five-minute fix once you know where to look. Miss it and the platform has no way of knowing your post is a copy rather than the source.
Add a canonical_url line to the post's YAML front matter, or set it through the editor. Dev.to's own community documentation shows the front matter version:
---
title: My Post Title
published: true
canonical_url: https://yourdomain.com/blog/your-original-post/
---Which path you use depends on which editor you're in. Dev.to's help center is specific about the split: if you're on the Rich + Markdown editor, click the icon next to "Save Draft" and you get an input box for the canonical URL directly, no YAML required. If you're on the Basic Markdown editor, that toggle isn't there, you have to add the canonical_url line inside the front matter yourself, as shown above.
I didn't want to take the field on faith, so I checked it against Dev.to's own public API. A GET to dev.to/api/articles?username=raymondcamden, a developer advocate who cross-posts nearly everything he writes, returns a canonical_url value for each article, and it isn't the dev.to URL. It's his own blog: raymondcamden.com. Same JSON field, same pattern, article after article. The setting isn't cosmetic, it's a real value Dev.to stores and serves back through the API, which is exactly what you'd want a search engine to be reading too.
There's a third option if you publish often enough to want this automated. Dev.to's RSS auto-import extension, under Settings then Extensions, can pull new posts from your blog's feed automatically and mark the RSS source as the canonical URL by default. Documented by a Dev.to community member who cross-posts this way, imported posts land as drafts in your dashboard first, so you still review and publish each one rather than letting anything go live unattended.
Hashnode's editor has a section under Draft Settings called "Are you republishing?" Fill in the original article's URL there and Hashnode sets the canonical tag for you. A developer's own writeup of the setting confirms this is exactly where the field lives: "there's a helpful menu under Draft Settings for 'Are you republishing?', where you can specify your post's canonical URL." Skip that field and Hashnode has no way to know the post it's hosting already exists somewhere else.
Medium's canonical handling only kicks in through its dedicated tool. From your profile menu, choose Stories, then Import a story, and paste in your original post's URL. Medium pulls the content in, backdates the post to match your original publish date, and sets the canonical link back to the source automatically, a mechanism confirmed in independent testing of the import flow: using the import feature "automatically dates the post back to the original publication day" and "automatically customizes the canonical link referencing the original post." Paste the same text into a new Medium story by hand instead, and none of that happens. You get a plain duplicate with no canonical pointer at all.
Set every field above correctly and you've still only reduced the risk, not removed it. Google's own John Mueller has said the quiet part out loud: "It might happen that the content that you syndicated to some other website ends up ranking above your content," an outcome he's called "not always completely avoidable," as reported by Search Engine Journal. Mueller's explanation is that a canonical tag assumes the two pages are close to identical, and often they aren't: "It's also the case that a canonical isn't really correct in a case like this because the pages themselves might be completely different."
SEO consultant Glenn Gabe put that unpredictability under a microscope, tracking roughly 3,000 syndicated news URLs to see which version, the original or the syndication partner, Google actually surfaced across Search, Top Stories, and the News tab. His case study found no consistent pattern: "no rhyme or reason why Google was surfacing my client's urls versus the syndication partners (or vice versa)." Gabe reports that Google has since updated its own guidance to reflect the same limitation, and now recommends that "syndication partners noindex news publisher content if the publisher doesn't want to compete with that syndication partner in Search."
That noindex option isn't just for news publishers. It's the honest answer whenever a canonical tag alone won't settle who wins.
Cross-posting is worth it when you want reach on a platform your readers already use and you're willing to set the canonical field every time. It's not worth it when your own domain's ranking is the entire point of the post, since a canonical tag only lowers the odds of losing that ranking, it doesn't remove them.
Dev.to and Hashnode put developer content in front of an audience that already reads there daily, an audience your own blog may never reach through search alone. A well-placed cross-post can also earn a backlink back to your domain from a high-authority page, which is real link equity even if the syndicated copy never outranks anything. And for a genuinely new topic your blog hasn't covered before, wider distribution gets more eyes on the idea while the canonical tag protects your own copy's shot at ranking for it.
The trade works best for posts where the goal is reach and awareness rather than a specific keyword you're trying to own. A launch announcement, an engineering write-up, a "how we built X" post: all good cross-posting candidates, because losing the keyword race to the syndicated copy costs you little.
Skip cross-posting, or ask the platform to keep the copy out of the index, when the post exists specifically to rank on your own domain: a comparison page, a pillar guide you built your topic cluster around, anything tied to internal linking automation that depends on link equity flowing to that one URL. Splitting that equity across two domains works against the exact structure you built the page to support.
None of the three platforms gives you a simple, documented per-post noindex toggle the way a self-hosted CMS would, so the honest fallback for your highest-stakes pages isn't a setting to flip. It's simply not cross-posting them at all, and saving the syndication move for posts where losing the keyword race costs you little.
Run through this before every cross-post, not just the first one:
canonical_url in Dev.to front matter (Basic Markdown editor) or the icon next to Save Draft (Rich + Markdown editor), the "Are you republishing?" field in Hashnode, Medium's Import tool rather than a copy-paste.If you're publishing often enough that this checklist becomes a weekly chore, that's the same publishing cadence the Lyra app is built around: every post ships as a GitHub pull request, so a dropped canonical field or a missed cross-post step shows up as a line in a diff instead of a traffic drop you notice a month later. Our guide to an AI blog writer built for developers covers how that Git-based review flow works end to end. Pair it with the kind of GitHub Actions SEO checks that gate canonical correctness on every PR, and the syndication step stops being something you have to remember by hand.
Cross-posting is a distribution decision, not a formatting one, and getting the canonical tag wrong is the cheapest way to lose the ranking you're trying to protect.
FAQ
It's a rel=canonical link, or the equivalent canonical_url field on Dev.to and Hashnode, that a syndicated copy of your post carries back to the original URL. It tells Google which version to index and rank, so your republished post on Dev.to or Medium doesn't compete with the one on your own domain.
Yes. Add canonical_url to the post's YAML front matter if you're using the Basic Markdown editor, or set it through the icon next to Save Draft if you're using the Rich + Markdown editor. Dev.to's own help documentation confirms both paths.
No. Google's John Mueller has said the syndicated copy can still outrank the original because the two pages, and the sites around them, aren't identical. A canonical tag is a strong signal, not a binding instruction, so treat it as risk reduction, not a guarantee.
Not automatically. Cross-post when the post targets a developer or platform-native audience that reads Dev.to or Medium directly, and always with the canonical field filled in. Skip it, or ask the platform to noindex the copy, for posts where your own domain's ranking is the whole point of writing them.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
How to calculate AI blog writer ROI before you sign: 2026 payback benchmarks, a worked formula, and the inputs that actually move your payback period.
A Webflow to git-based blog migration playbook: why CMS collections don't map cleanly to Markdown, how to protect your rankings, and what you gain in git.
Content marketing for PLG SaaS needs its own playbook: which post types close a self-serve signup without a demo call, and how to measure if they did.