Guides

One link, always current

To update a shared document without changing the link, stop sharing copies and start sharing an address. Send Artifact publishes a self-contained HTML artifact to a stable URL — sendartifact.com/you/q3-proposal — and republishing puts a new version behind the same address. The link you shared last month serves the version you published this morning. Every version is retained, a wrong republish rolls back in one step, and views are recorded per version, so you know whether the client has read the rewrite or is still quoting the draft. You share the link once; after that, keeping the document current is an edit, not a re-send.

That is the whole answer. The rest of this page is why the two usual approaches — attachments and chat-tied publishing — fail in opposite directions, and what version history buys you once the URL is stable.

What are the two ways a shared document fails?

Every shared document dies one of two deaths, and most tools pick one.

The frozen copy. An attachment is a snapshot. The moment you fix a number, the version in their inbox is wrong — and it will stay wrong forever, because you cannot edit someone else's inbox. So you re-send. Now proposal-v2.pdf circulates alongside v1, someone forwards v1 to their boss, the CRM links to whichever copy got pasted in first, and by proposal-v3-FINAL-final.pdf nobody, including you, is certain which document is the document. The newer sharing tools have mostly noticed this, and mostly stop at the same place: "latest wins" — whoever opens the link sees the newest copy. Latest-wins is half the job; the other half is below.

The vanished copy. Publishing straight from an AI lab's chat interface solves the freshness problem and introduces a lifespan problem: the link is a feature of the conversation, not a durable address. Heather Cooper, who writes an AI newsletter, flagged this in her walkthrough of Claude's public artifacts: "Deleting a conversation containing a published Artifact will also remove the public version" (heatherbcooper.substack.com). A marketer's guide from GetMasset is blunter about the other exit:

"Unpublishing permanently deletes all associated storage data. Once unpublished, you cannot republish that same artifact." (getmasset.com)

Even routine updates hit walls. A recurring Claude Code bug report shows the failure verbatim: "This version can't be shared publicly. Publish a new version or change the shared version, then try again" (github.com). A link tied to a chat inherits the lifespan and the moods of a chat.

So an attachment can't change, and a chat-tied link can't be trusted to stay. What you want is the third thing: an address more durable than any version behind it.

What does "same URL, new version" actually mean?

The mechanics are deliberately boring. You publish a folder of static HTML once:

npx @sendartifact/cli publish ./out --slug q3-proposal

That mints sendartifact.com/you/q3-proposal. You paste that URL into the email, the CRM, the Slack thread — once. When you edit, you republish to the same slug. That creates an immutable new version and flips the live pointer; the URL does not change, so every place it was ever pasted now serves the fix. Nobody re-clicks anything, and there is no v2 file to fork the audience.

Nothing is overwritten in the process. Each version is kept, listed in the artifact's history, and older versions stay addressable — so "what did we send them in June" has an exact answer instead of an archaeology project. Even renaming the artifact later doesn't break anything: retired URLs redirect permanently to the current one, and the old address can never be claimed by a different artifact.

What if the republish was wrong?

This is the safety half that "latest wins" skips, and it matters more than it sounds. A stable URL without history is a liability: one bad publish silently replaces what your prospect sees, with no record of what was there before and no way back.

With versions retained, a wrong republish costs one click: rollback points the URL at any earlier version, instantly, without the link ever changing. Because versions are immutable, rolling back doesn't destroy the bad version either — it stays in history, which is occasionally exactly what you want when reconstructing what went out and when.

The practical effect is that you republish more, not less. When updating is reversible, you fix the typo the moment you see it instead of batching corrections for a v4 you'll re-send someday.

Did they read v3, or are they still quoting v1?

Here is the part no attachment and no chat link can give you. Suppose you rewrote the pricing section on Monday and the call is Thursday. Has anyone on their side opened the document since Monday — or is everyone walking into the call holding v1 in their head?

Because views are attributed to the version that served them, the analytics answer that directly: views by day and by version, distinct viewers, and per-reader identity where it's available. Active read time and maximum scroll depth tell you whether the rewrite got read or merely opened; bot traffic and link-preview fetches are filtered out so the counts mean something. Your own views are tagged separately too, so checking your own page a dozen times before the call doesn't inflate the numbers you actually care about — outside readers.

Who you can identify depends on how you shared it. Access runs from private, to specific guests (individual emails or whole email domains, always verified), to anyone with the link, to fully public — and the open modes can optionally ask readers for their email, either self-reported or verified with a code. Viewers never need an account in any mode.

Note what the re-send spiral does to all of this: it destroys the signal entirely. Five copies of a PDF can't tell you which version anyone read, because a file reports nothing and the versions aren't even connected to each other.

Isn't hosting free everywhere?

Yes, and it's worth being straight about. GitHub Pages, Netlify, or an S3 bucket will give you a stable URL you can republish to, and several of the newer artifact-sharing tools do stable-URL republish too. If your entire requirement is "the link shows the latest," plenty of things work and you should use whatever is closest to hand.

The difference is everything after the link is sent: retained history, one-click rollback, per-version and per-reader analytics, access control without reader accounts, and comments from readers anchored to the exact passage. Static hosts treat publishing as the end of the job. For a document you're trying to get someone to act on, publishing is the beginning.

How does this fit an agent workflow?

The reason to make updating cheap is that cheap updates change behavior. Send Artifact is agent-native: there's a CLI on npm as @sendartifact/cli — npx @sendartifact/cli login signs you in from the terminal, no dashboard trip required — and a skill file at sendartifact.com/skill.md that teaches your agent the whole flow, plus a web drop-zone when you just have a file. Once your agent knows the slug, "update the proposal" ends with:

npx @sendartifact/cli publish ./out --slug q3-proposal

Same URL, new version, done. Keeping the document current stops being a re-sending chore and becomes the last line of the edit itself.

Reader feedback closes the same loop, on your terms. Readers can leave comments pinned to the artifact; you review them, and when you decide the feedback is worth acting on, you point your agent at the open threads — it pulls them with npx @sendartifact/cli comments, makes the edits, republishes to the same URL, and replies as it resolves each one with npx @sendartifact/cli resolve. Nothing changes because a reader typed a comment; things change when you say so.

One constraint to know: artifacts are self-contained static HTML, up to 25 MB. That comfortably covers reports, proposals, dashboards, and prototypes — the documents that go stale — and rules out video libraries.

Publish once. Share once. Republish freely. The filename spiral was never a discipline problem; it was a format problem, and the fix is a link that outlives its versions.

Published 2026-08-27 · markdown twin at /guides/one-link-always-current.md · questions: support@sendartifact.com.