How to cross-post to DEV.to with a canonical URL
Bring a complete developer article to DEV while identifying the original on your own site. Prepare the Markdown, review canonical metadata, and check the resulting article before sharing it.
Publish the original article on your site, prepare a readable Markdown version for DEV, and set its canonical URL to the original article’s final address. Review the copy, publish it, and check both the visible attribution and the canonical link in the resulting page. Canonical tells search engines which version you prefer; it does not guarantee which page Google will show.
Choose the original article before making a copy.
A developer tutorial can be useful in two places: on your own publication and in a community where readers discuss the problem. Full-article cross-posting means hosting substantially the same work on both sites. A short announcement linking to your tutorial is a different task; use the blog-to-social guide for that.
Start with an article you own or have permission to republish. Open the original while signed out. Confirm that its examples, images, downloads, and final URL work for an ordinary reader. Resolve draft links and temporary preview addresses before creating a second public version.
A canonical URL is the address you nominate as the preferred version of duplicate or very similar content. Google describes canonical annotations as a strong signal, while retaining the decision about the canonical page. Choose the article URL, not your homepage or a campaign tracking link.
Cross-post because the article serves DEV readers. A working example, an explanation of a tradeoff, or an honest failure analysis gives them something to discuss. Republishing an unrelated sales page does not become useful simply because you set a canonical field.
Prepare a complete Markdown version.
Markdown is plain text with markers for headings, links, lists, and code. DEV supports it in its editor. Check the converted body rather than assuming that an imported webpage preserves every element.
| Original element | DEV version | Reader check |
|---|---|---|
| Code examples | Fenced code blocks with the appropriate language | Indentation, punctuation, and sample output remain intact. |
| Images | Images with usable URLs and descriptive alternative text | The diagram is readable and contains no private data. |
| Links | Full URLs to the intended page or download | A relative path does not accidentally point at DEV. |
| Interactive examples | A readable explanation and link to the working example | The tutorial still makes sense without the original interactive component. |
| Article metadata | Title, relevant tags, description, and original URL | The title and summary describe the article readers will actually get. |
For example, imagine a fictional tutorial called “Debugging a webhook signature mismatch.” Its DEV version should retain the failing request, the corrected verification logic, and the explanation of why they differ. You can add a brief introduction for community readers without replacing the technical substance with a teaser.
Add a visible attribution line such as “Originally published on our engineering blog,” linked to the real original. This helps readers find your publication. The visible link and the canonical field perform different jobs, so review both.
Where do you set the canonical URL on DEV?
DEV’s editor guide documents two editor styles. The basic Markdown editor accepts a canonical_url value in its opening YAML front matter, the metadata block between triple-dashed lines. The rich + Markdown editor separates article fields from the body; enter the original address in its canonical URL field.
In the basic editor, the value has the form canonical_url: https://example.com/tutorial. That address is only an illustration: replace it with your article’s public URL. Preview the article before publishing. For tags, DEV documents a maximum of four; select the topics the article actually teaches.
DEV explains that unpublished article links can be shared and opened by people who have the link. Treat a DEV draft as a review link, not a place for confidential notes, API keys, or customer records.
If you use PostOnce, enter the canonical address in the dedicated field described below. Keep YAML front matter out of the body sent through that integration.
Publish a DEV article through PostOnce.
PostOnce offers an unofficial DEV Community integration. It is useful when the full article belongs on DEV and shorter versions also need to reach your connected social channels. Check current DEV support before connecting an account.
- Connect your author account. Create a dedicated API key in DEV settings, then enter it in PostOnce’s DEV Community connection form. Confirm the returned account identity. Connection verification checks the account; it does not publish a test article.
- Prepare the source. Open Create and import your public article URL, Markdown, or full text. Select the connected DEV destination and review its article title and Markdown body. A URL import can carry the detected source URL into the canonical setting; inspect that value yourself.
- Review DEV article metadata. Fill in Canonical URL under DEV article metadata. PostOnce requires an HTTPS address here. Review the optional tags, description, cover image URL, series, and Organization ID as needed.
- Check images and formatting. This connector accepts HTTPS image URLs in Markdown and an optional cover image URL. It does not send binary media attachments to DEV. Remove a leading YAML front-matter block and put its relevant values in the metadata fields.
- Review delivery and timing. Read the exact DEV version before publishing or scheduling. When adding social destinations, give them their own shorter copy. A shared campaign uses one schedule; use separate campaigns if the announcements need a later time.
- Open the result. Inspect the DEV delivery receipt and open its article link. Confirm that the published content matches the version you approved, then run the checks below.
At delivery time, the integration creates a DEV draft, records its article ID, and then publishes that same record. This is part of delivery, not an extra editorial approval stop. Keep the scheduled content ready for public readers.
If a response is lost, check the DEV dashboard for both unpublished and published articles before creating another copy. The failed-post guide explains how to handle an uncertain outcome without duplicating a successful delivery.
Verify the copy after publication.
Open the published DEV page while signed out. Read the introduction, scan the headings, inspect every code block, and follow the original-source link. Compare the final paragraph with the original so an incomplete import does not slip through.
Next, use your browser’s page-source view and search for rel="canonical". Its link should appear in the HTML head and point to the exact original article you intended. If the value is missing or wrong, edit the DEV article’s canonical setting and inspect the page again.
Keep a small record containing the original URL, DEV URL, publication date, and the version you copied. When correcting a command or updating an example later, check both copies. Sending a new PostOnce campaign creates a new delivery; edit the existing DEV article when your goal is to correct that copy.
A canonical annotation does not redirect readers. You can still receive visits and comments on DEV. Evaluate those separately from referrals to your own site. If you have Search Console access for the original site, URL Inspection can help you check Google’s selected canonical after processing; the presence of the tag alone cannot establish that choice.
Common cross-posting questions
Does canonical guarantee that my blog outranks DEV?
No. It communicates a preference for duplicate or similar pages. Google may select a different canonical, and rankings depend on more than this field. Publish for a relevant audience and measure the outcome.
Can I use a canonical URL on an unrelated summary?
Use it for a duplicate or substantially similar article. For a short social announcement or a distinct follow-up article, a normal source link is usually the appropriate way to connect the work.
Can PostOnce update an existing DEV article?
The workflow described here creates and publishes a new article. To correct an existing public copy, edit that article in DEV. Do not submit a new campaign expecting it to overwrite the earlier article.
Why does PostOnce reject my front matter?
The connector rejects a leading YAML metadata block because it can override separately reviewed delivery settings. Move the title, tags, canonical URL, and other supported values into their fields, then send only the article body.
Sources and next steps
Platform documentation checked October 15, 2026.
- DEV: editor guide — Markdown, canonical metadata, tags, and the visibility of unpublished links.
- Forem API: create an article — article fields and draft publication state.
- Google Search Central: canonical URLs — canonical signals and HTML placement.
- Google Search Console: URL Inspection — inspecting indexed URLs and canonical information.
- PostOnce: DEV Community integration — availability and supported format.
Start with one finished article. After checking its DEV copy, use the content repurposing workflow to prepare the surrounding announcements.