How to Post on dev.to: Get Read, Get Traffic, Get the Backlink Right

What is dev.to

dev.to (the site is at https://dev.to) is a developer community built by Forem. DR 90. It's basically a "Medium for devs" — anyone can sign up, write articles, add tags, and get reactions and comments.

The readers are almost all developers. Front-end, back-end, DevOps, AI engineers, all in there. Topics range from React hooks to Postgres tuning to vibe coding. Pretty wide.

Posting is free. No review process. Sign up and you can post right away. But no review doesn't mean anything goes. The community has its own taste. Marketing posts lose reactions fast and end up read by nobody.

A few things that are different from Medium:

• The audience is mostly developers. Non-tech posts get almost no upvotes.
• Markdown is native. Code blocks work. Liquid tags let you embed CodePen or GitHub Gists right in.
• No paywall. Authors don't earn money from posts here. The payoff is followers, links, and long-term article SEO.
• There's a canonical_url field made for cross-posting. This single feature is dev.to's most valuable thing.

Should you still post here

Depends.

Worth your time if:

• You hit a real bug or limit while building, and the writeup helps other devs. Like "the D1 binding gotcha when deploying Next.js on Cloudflare Workers."
• Your product itself is built for developers (API, SDK, CLI, open source tool). The readers are your users.
• You want some brand content that earns Google search traffic over time.
• You already wrote on your own blog and want to cross-post for reach.

Skip it if:

• You're shipping B2B SaaS for non-devs (HR systems, sales tools). Wrong audience.
• You only want to write a launch post. dev.to is not Product Hunt. "We just launched X" gets ignored.
• You're stacking AI-tool listicles like "10 best X." This stuff gets pushback from the community.
• You're posting translated or AI-generated text without rewriting. Spotted on sight. Tanks your reputation.

For most indie hackers and small teams shipping things to developers, dev.to is one of the better channels by ROI. The condition is you're willing to write something real.

What dev.to picks up

The home page has a few feeds: Latest (by time), Top (by reactions in a window), Relevant (personalized). To get more eyes, a few things matter:

• Early reactions. If you get a few ❤️ / 🦄 / 🔖 in the first 1-2 hours, the post gets pushed to more Relevant feeds. No reactions in the first few hours and the post is buried.
• Right tags. Max 4 tags per post. Tags that don't match your content get folded or flagged.
• Clear title. "How I cut my Postgres query from 2s to 80ms" beats "Optimizing my database" by an order of magnitude.
• Cover image. Not required, but posts without a cover get clicked way less from the feed.
• Author history. A new account posting cold has a hard time. Drop a few real comments under other posts before you post your own.

The most common mistake: writing a launch post and calling it an article. "Introducing X, the future of Y" — devs are trained to spot this. They scroll past in a second.

What to prep before posting

Two weeks out

Pick a specific topic. Not "I built X." But "I used X to solve problem Y." Cut the scope until one article can cover it.

Search dev.to for your topic keyword. Look at the top-ranking posts. Copy the structure, not the content. Hands-on posts in the 1500-3000 word range usually do best.

One week out

Write the body. In Markdown. Use triple-backtick code blocks with a language name (```js, ```python). Compress screenshots to under 200KB. dev.to has its own image host, but it's slow.

Pick 4 tags. The first tag matters most. Make it a big bucket (#webdev, #javascript, #python, #ai). Use the next three to narrow down.

Make a cover image. 1000×420 pixels. dev.to crops to that ratio by default. Other sizes get cut. Canva, Figma, or just a screenshot with a title slapped on top all work fine.

The day you post

Pick the time. 8-10 AM US Eastern is the highest-traffic window on dev.to. If your readers are mostly in Asia, 8 PM Beijing time also works — Japan, India, and Southeast Asian devs are still online then.

After you hit publish, don't just walk away. Watch comments for the first 2 hours. Reply to anyone who comments. Early engagement directly affects whether the algorithm pushes your post.

The publish flow

Step 1: Sign up and fill the profile

URL: https://dev.to/enter. Log in with GitHub, Apple, Google, or Forem account. Use GitHub if you can — your GitHub link shows on your profile and the community recognizes that.

Fill the profile out. Avatar. Bio (one line about who you are and what you do). Website link (this goes to your own site — it's nofollow but still drives traffic). Location, Skills, all of it. A blank profile posting articles gets no follows.

Step 2: Write the post

Click Write a Post in the top right. The editor is Markdown. The top is frontmatter (YAML) where you fill in metadata like title, tags, cover, canonical_url:

---
title: How I cut my Postgres query from 2s to 80ms
published: true
tags: postgres, performance, webdev, backend
cover_image: https://example.com/cover.png
canonical_url: https://yourblog.com/postgres-perf
---

The body is just Markdown. dev.to also has liquid tags — {% github user/repo %}, {% codepen url %}, {% youtube id %} all embed inline.

One rule when writing: write like a person, write the details, write the process. "I tried A, didn't work. Tried B, found C. Ended up using D." That story shape beats a "5 Tips for Postgres Performance" list every time.

Step 2.5: Use canonical_url (important)

If you're also posting this on your own blog (or already have), always fill in canonical_url. Point it at the full URL of the post on your own blog.

Why this matters gets its own section below. For now, just remember: fill it in, and search engines treat your blog as the original. Skip it, and dev.to outranks your own site.

Step 3: Publish and engage

Hit Publish. The post shows up in the feed right away.

After that:

• Drop the link on your Twitter, LinkedIn, or company chat. Send some seed traffic in.
• Come back to dev.to within an hour. Reply to comments if there are any.
• Find 1-2 posts on related topics from other authors. Leave a real comment. The system pushes active users to more readers.

Step 4: Keep going

dev.to isn't post-and-done. Come back a month later, check the dashboard. See which post got the most reactions and views. Take the topic that did well and write a deeper piece, or split it into a series.

How to use canonical_url right

This deserves its own section, because it's the single thing on dev.to that's both easy to mess up and the most important.

Why it matters. Google sees two URLs with the same content. It picks one as the "original" and assigns the SEO weight to that URL. dev.to is DR 90. If your blog is DR 5, Google almost always picks dev.to. The result: nobody finds your blog post, and dev.to ends up with all the link weight.

How canonical_url solves this. Put canonical_url: https://yourblog.com/post-slug in the frontmatter. dev.to adds <link rel="canonical" href="..."> to the HTML. That tells Google "I'm not the original, that one is." Google then assigns the weight to your blog.

Three ways to play this, depending on your goal:

1. Blog first, dev.to second. This is the most common and the safest play. Post on your own blog first (let Google index it for a few days). Then post on dev.to with canonical_url filled in. Result: your blog gets the main ranking. dev.to gets the social reach and engagement.
2. dev.to first, blog second. Don't fill canonical_url. Let dev.to be the original. Use this when your blog DR is low and you don't care about ranking the post on your own site.
3. dev.to only. No blog at all? Just post on dev.to. dev.to becomes the Google ranking page for that topic. No need to overthink it.

Don't do this:

• Post on both, but skip canonical_url. Google picks dev.to as original. Your blog post is wasted.
• Wrong URL. canonical_url has to be a real, indexed page. A 404 or noindex'd URL does nothing.
• Hoping "both pages will rank." That's not how it works. Google picks one. Either your blog wins or dev.to wins. Pick.

For most indie hackers, blog first + dev.to cross-post + fill the canonical is the right move. You get both upsides.

How to actually get traffic and links from dev.to

External links in the post body default to nofollow on dev.to (so does the Website field on your profile). So don't treat dev.to as a pure backlink farm. The real value is in three places:

One, the article URL ranks in Google. dev.to articles rank for a long time. A good post still gets you hundreds of impressions a month a year later.

Two, the profile page sends traffic. Your profile has your website link, GitHub, Twitter. Each post has your bio in the footer. Readers who like the post click through. That traffic is small but high-intent.

Three, the community amplifies. A post with thousands of reactions gets retweeted by the dev.to account, picked up by newsletters, and forwarded out to Hacker News, Reddit, and Twitter. That second-wave reach is where the real backlinks come from. But the post has to actually hold up.

How to play it:

• One deeper post every two weeks. Beats five thin posts.
• Group posts into a series. dev.to has a series feature. Cluster related posts. Readers finishing one will scroll to the next.
• Put your product in the bio. One sentence. No marketing voice. "Building [product] for [audience]" is enough.
• Engage with other authors for real. Pick 5-10 active writers in your space. Drop reactions and comments on their posts regularly. After six months, your visibility goes up way more than just posting your own stuff.

What to do after

A post going live isn't the end. It's the start of a content asset.

Send the link to Hacker News (use the Show HN format if relevant). Drop it in the right Reddit subs (r/webdev, r/programming, r/SideProject). Tweet it. The first hours get a real boost from this. Each Reddit sub has its own rules — read the sidebar before posting.

Once the numbers settle (about a week), put the post in your blog's "As featured in" strip. Or use the link as outside proof on your product landing page. A dev.to link with a few hundred reactions is social proof.

If a post does really well (top 7 days, etc.), turn it into a video, a Twitter thread, a newsletter issue. One topic, at least three formats.

Last thing — make dev.to a regular column. Post 2-3 a month, steady. Six months in, you'll have a few thousand followers, steady profile traffic, and a few posts ranking on Google long-term. That compounding only happens if you keep showing up.

Common mistakes

• Title says "Introducing X." That's launch-post format. dev.to readers don't read past the title.
• Body is all about your product. Devs are sensitive to ads. They scroll past after three paragraphs.
• Random tags. One right tag like #javascript brings traffic. Four wrong tags get the post folded.
• Posting on both dev.to and your blog without canonical_url. Your blog gets outranked. Already covered above.
• AI-generated content with no rewrite. dev.to readers spot AI voice instantly. Two paragraphs in, gone.
• Post and run. No engagement in the first 2 hours buries the post.
• Picking fights when someone questions your product in comments. The community watches how you handle pushback. Tone matters more than being right.

dev.to vs Medium vs Hashnode

For devs writing technical content: dev.to has the most active community. Medium has more total traffic but mixed readers. Hashnode is best if you want it to be your main blog with your own domain. They're not replacements. If you have the time, post to all three. Set the canonical to your own blog on each.

FAQ

Is dev.to free? Yes. Sign up, posting, and all features are free. dev.to runs on corporate sponsors and the Forem open-source project.

How fast do you see reactions? The first 1-2 hours after posting are the window. If reactions are in the single digits at 2 hours, the post is buried. By the next morning the numbers are basically locked in.

Can you post something already published elsewhere? Yes, and it's recommended. But fill in canonical_url to point at the original. Otherwise dev.to outranks your own site.

Are dev.to links dofollow? External links in the body default to nofollow. The Website field on your profile is also nofollow. Don't treat dev.to as a pure backlink farm. The real value is article ranking in Google plus profile traffic.

Nobody is reading my post. What now? Check three things. Are the tags right. Is the title too marketing-flavored. Did you add a cover image. Still nothing? Go drop a few real comments on other posts and get familiar to the community. New accounts going cold is normal.

Can I post a launch announcement? Don't. But you can write "the bug I hit while building this product" — same product, technical-story angle. Readers accept it.

How many posts a week? No required cadence. One deep post every two weeks beats three thin ones a week. The algorithm penalizes low-quality batch posting.

Other platforms to hit at the same time

dev.to is one of the best channels for dev content, but not the only one. Combine these:

• Hashnode: DR 83. Dev blog platform. You can map your own domain. Cross-post after dev.to.
• Medium: DR 94. Wider audience. If your topic isn't pure tech (indie hacking, product thinking), Medium gets better feedback than dev.to.
• Hacker News: DR 44. Send your post to HN right after you publish. Front page once and the article gets 10x the traffic.
• Indie Hackers: Better fit for indie-product content. The community is more product-focused than dev.to.
• CodeProject: DR 90. Old-school dev community. Topics lean back-end and enterprise.
• Substack: DR 93. If you want to run a long-term newsletter, Substack is the main stage. Use dev.to as a cross-post channel.
• Product Hunt: DR 75. The launch-day standard. Use dev.to for long-term tech blog SEO and Product Hunt for the launch spike. They pair well.

The main play: post on your own blog first. Cross-post to dev.to with canonical_url. Push to Hacker News and Reddit for the first wave. Tweet a thread of the key points. One piece of content runs in three or four formats.

For more developer content sites and posting channels, see /c/dev and /c/content.