Where to Publish Your Developer Blog: Dev.to, Hashnode, Medium or Your Own Domain

Quick Answer: Publish on a platform for readers and on your own domain for compounding SEO credit — then connect the two with a canonical tag. Dev.to and Hashnode both let you set a canonical URL pointing back to your copy, which tells Google your domain owns the original. Medium gives the widest general audience but the weakest control. The choice is not really "which platform is best"; it is "who owns the audience, and where does the search credit land."

Most advice on this question is a feature table: Dev.to has reactions, Hashnode has custom domains, Medium has a paywall. That is not the decision. The decision is what you still own in three years.

This guide covers the part the comparison posts skip — how canonical tags actually route search credit between your copy and the platform's, why almost none of those platform links count as backlinks, and how to pick a home base without waiting years for traffic. It ends with the uncomfortable lesson we learned publishing 148 technical articles ourselves.

Where should developers publish technical writing?

Publish where your readers already are, and keep the canonical version on a domain you control. Those two things are not in conflict — a canonical tag exists precisely so you can do both.

Here is the decision in one table.

Most working engineers should run one home base plus one distribution channel. Not five.

The three questions that actually decide this

Feature lists are noise. Ask these instead.

1. Who owns the audience?

On Medium and Dev.to, the platform owns the reader relationship. Someone who loves your post follows you on that platform — a relationship you cannot export and cannot take with you. On your own domain, a reader who subscribes is yours.

This sounds abstract until a platform changes its rules. Medium has repeatedly reworked its distribution and paywall model, and each change moved traffic away from writers who had built everything there.

2. Where does the SEO credit land?

This is the part that gets people. If you publish the same article on your site and on Dev.to with no canonical tag, you have two near-identical pages competing for the same query. Google picks one. It is almost never the new domain with no authority — it is the platform with millions of inbound links.

You did the work; the platform ranks. A canonical tag is what prevents this, and it is one line.

3. What survives if the platform pivots?

Anything you do not host is borrowed. Keep the markdown source of every article in your own git repository. Then a platform change costs you distribution, never the writing.

The canonical URL rule — the part nobody explains

A canonical tag tells Google which copy of a duplicated page is the original. When you syndicate a post, the platform copy should carry <link rel="canonical" href="https://yoursite.com/your-post">. Search engines then consolidate the ranking signals onto your URL instead of splitting or misassigning them.

Google's own guidance on canonicalization is explicit that this is the supported way to handle the same content on multiple URLs.

The rule: publish to your own domain first, let it get crawled, then syndicate with the canonical pointing home. Publishing to the platform first and your site second is how you end up outranked by your own syndicated copy.

A caveat worth stating honestly: a canonical tag is a strong hint, not a command. Google can and sometimes does ignore it — usually when the two pages differ substantially, or when the canonical points somewhere Google considers less relevant. Publishing to your own domain first is what makes the hint credible.

Those platform links are not backlinks

Here is a related misconception that costs people years.

Outbound links in user-generated content on large platforms are typically marked rel="nofollow" or rel="ugc". Both tell Google not to pass ranking credit — Google documents ugc as the attribute for links within user-generated content exactly like posts and comments. So the link in your Dev.to bio pointing at your site is not building your domain authority. It never was.

What those links do deliver is real: actual humans, actual referral traffic, actual readers who might subscribe. That is valuable. It is just a different job.

• Distribution = getting humans to read the post. Platforms are excellent at this.
• Link building = getting other sites to cite you, which moves rankings. Platforms do almost nothing for this.

Conflating the two is the single most common mistake in developer content strategy. You can publish for years, get respectable view counts, and move your own domain's rankings not at all.

What we learned publishing 148 technical articles

At SolutionGigs we publish long-form engineering content — data engineering, cloud, DevOps, AI. As of August 2026 the site carries 148 published articles. They rank: dozens sit in the top 20 for real, competitive queries.

The number that mattered was different. Across that entire corpus, the site had earned exactly one referring domain.

That is the honest lesson, and it reframes this whole question: publishing is not distribution. We had solved "write a good article that Google will index." We had not solved "get anyone to know it exists." One hundred and forty-eight posts did not fix that, because volume was never the constraint.

If we were starting again, the order would be:

1. Home base first. Own the domain from post one, even with zero readers.
2. Syndicate deliberately to one platform where the audience already is, canonical pointing home.
3. Treat every post as needing a distribution plan — where will the first 100 readers come from? If the answer is "search, eventually," the post will not land.
4. Optimise titles and descriptions for clicks, not just rankings. A page ranking at position 8 that nobody clicks earns nothing.

Two of those we learned the expensive way.

Common mistakes

• Publishing on the platform first, your site second. Your own copy becomes the duplicate. Reverse it.
• Skipping the canonical field because the post "isn't important." Every syndicated copy needs it — there are no exceptions worth the risk.
• Chasing five platforms at once. Copies compete with each other; maintenance compounds; nothing gets a real audience.
• Treating platform followers as an owned audience. You cannot export them.
• Assuming a bio link builds authority. It is nofollowed.
• Writing for search volume instead of for a reader. Both Google's helpful-content signals and every AI answer engine now reward genuine first-hand experience — the thing only you have.
• Never keeping the source. If your only copy of a post is inside a CMS you do not control, you are one policy change from losing it.

Where a niche community fits

There is a fourth option the big comparisons ignore: smaller, topic-specific community sites.

The trade is straightforward. You reach fewer people, but they are the right people — engineers in your specific domain rather than a general audience skimming. For a post about Iceberg hidden partitioning or choosing between a data lake, warehouse and lakehouse, 300 readers who work with those systems beat 5,000 who do not.

This is why we run the SolutionGigs Community — an open section where any engineer can publish. It is deliberately narrow: data engineering, cloud, DevOps, AI, databases, and career writing for engineers. Articles keep your byline and link to your own site, and there is no editor queue to wait in — the write-for-us guidelines explain exactly what we accept and how the review works.

It is new, and honest framing matters here: it is a place to reach a focused technical audience and keep a permanent, indexed URL with your name on it — not a replacement for a large platform's reach. Use it the way this whole article recommends using any platform you do not own: as a distribution channel, with the canonical pointing at your own copy if you have one.

Frequently Asked Questions

Does publishing on Dev.to or Medium hurt my own site's SEO?

Not if you set a canonical URL pointing back to your own copy. Dev.to and Hashnode both support a canonical field, which tells Google your domain holds the original. Without it you have two near-identical pages competing, and Google usually picks the higher-authority platform, not you. Medium's canonical support is limited to its import tool.

Do links from Dev.to and Medium count as backlinks?

Mostly no. User-generated links on large publishing platforms are typically marked rel="nofollow" or rel="ugc", which tells Google not to pass ranking credit. They still deliver real readers and real referral traffic. Treat them as distribution, not as link building — those are different jobs.

Should I start with my own domain or a platform?

Start on a platform if you have no audience. A new domain has no readers and no authority, so your first posts reach nobody. Publish on a platform for reach, keep the canonical on your own copy from day one, and let the domain accumulate credit while the platform supplies readers.

How many platforms should I publish to at once?

One home base you control plus one or two distribution channels. Beyond that the duplicate copies compete with each other in search and the maintenance cost rises fast. Every syndicated copy must carry a canonical tag pointing at the home base.

What happens to my articles if a blogging platform shuts down?

You lose the URLs, the rankings and usually the comments. Anything you do not host is borrowed. Keep the markdown source of every post in your own git repository so a platform change costs you distribution but never the writing itself.

Is it worth writing a technical blog if nobody reads it?

Yes, but only if you plan distribution as deliberately as you plan the writing. Publishing is not distribution. A post with no plan for who sees it earns nothing regardless of quality, which is why choosing where to publish matters as much as what you publish.

Conclusion

The platform comparison everyone writes — reactions versus custom domains versus paywalls — is the least important part of this decision. What matters is that you keep a copy on a domain you own, that every syndicated version carries a canonical tag pointing home, and that you understand platform links for what they are: excellent distribution, and essentially zero link equity.

Get that structure right early and the platform choice becomes reversible. Get it wrong and you spend years building an audience on rented land, with your own domain sitting empty behind it.

If you write about data engineering, cloud, DevOps or AI and want a focused technical audience for your next piece, publish it on the SolutionGigs Community — it is free, your byline and links stay yours, and there is no editor queue. Or start with the write-for-us guidelines to see what we publish.