"It works in my Claude artifact" is the new "works on my machine." The AI built the page in one prompt, the demo lands, and then someone asks for a link they can keep.
You can give them one. Claude's Publish button turns an artifact into a public URL, and anyone can open it and interact with it without a Claude account of their own. That part works exactly as advertised.
What you handed over is a page on Anthropic's domain, inside Anthropic's frame. It has no address of your own, no second page, nothing running behind it, and by default the next chat you open will build a new artifact rather than update that one. You gave away a link. You did not give away control.
That is enough to show someone your work. It is not enough to hand over a website.
What the Publish button actually does
Claude creates an artifact when what it is producing is, in Anthropic's words, "significant and self-contained, typically over 15 lines." It starts private. Claude opens it in a panel beside the conversation — a preview you can watch change as you refine the prompt — and, this is the part people miss, it does not appear in your own Artifacts sidebar until you publish it. The broader guide to creating and sharing Claude Artifacts maps the regular, AI-powered, Claude Code, and Cowork live versions of the term; this article stays with the narrower ownership question. Anthropic's help centre is blunt about it: "Artifacts you create in a conversation don't appear in your sidebar automatically. To add an artifact to your Artifacts section, open it and click 'Publish.'"
So Publish does two jobs at once. It lifts the artifact out of the single conversation that produced it, and it makes it "publicly available. Anyone with the link can view and interact with it."
Visitors do not need an account of their own. People without one can "view and interact with any published artifact without signing up," which is exactly why the link feels like a website when you send it.
On Team and Enterprise plans there is a second, different action called Share, which keeps the artifact inside your organisation, and an Owner decides whether members can publish artifacts publicly at all. Publish and Share get used interchangeably in conversation. They are not the same setting.
Where the artifact actually lives
Two things are worth separating here, because the guides answering this question tend to blur them into one.
Artifacts from a Claude conversation are the familiar ones: you ask for a page, it appears in the panel, you press Publish. They are available on the free plan as well as Pro, Max, Team and Enterprise.
Artifacts from Claude Code are a different feature with the same name.
Claude Code publishes a page from your session
to a URL that looks like claude.ai/code/artifact/5fbea6f3-…, and the browser
loads it from a sandboxed *.claudeusercontent.com origin. That needs Pro, Max,
Team or Enterprise, a session signed in to a claude.ai account, and Anthropic's
own API as the model provider — not Bedrock, Vertex, or Foundry.
Five things the artifact does not have
Its own address
There is no custom domain option. The link lives where Anthropic puts it, and every visitor reads Anthropic's name before yours. Anywhere else this is one DNS record, and what pointing your own domain actually involves is a short procedure — just not one that exists here.
A second page
An artifact is one self-contained page, and a React component artifact is under the same rule as a page of plain HTML and CSS. Anthropic's documentation is precise about the consequence: "Relative links do not resolve, because nothing is deployed alongside the page." Multi-section artifacts use in-page anchors rather than separate files. The moment the design needs an About page, the format is out.
Anything behind the page
The published page runs under a strict Content Security Policy that "blocks
scripts, stylesheets, fonts, and images loaded from any other host, along with
fetch, XHR, and WebSocket calls." Styles and scripts are inlined; images are
embedded directly in the page. And nothing runs behind it: the page "can't store
data submitted through a form or authenticate viewers itself."
Read that as a limit of the format, not as a knock on Claude, because a plain static site cannot do those things either — including one published through Birta. A form that actually receives submissions needs a service behind it wherever the page is hosted. That is a property of static hosting, not a quirk of artifacts.
A life outside the chat that made it
This is the one that surprises people. From the Claude Code documentation: "Without the URL, a new session always creates a new artifact rather than updating an existing one." Keep the link and you can point a new session at it. Lose the link, and your next conversation builds a stranger. It is a thin version of editing a live site by re-prompting instead of redeploying, where what the tool stays attached to is the site rather than a chat.
Unpublishing is worse than it sounds, and it goes one way only: "Once you unpublish an artifact, you cannot publish that same artifact again," and doing so "permanently deletes all associated storage data."
An owner who is you
On Team and Enterprise plans an organisation Owner controls a single External sharing toggle, and turning it off "blocks access through existing public links" — every link already handed out, at once, without anyone touching an individual artifact. Owners can also set a retention policy that deletes artifacts automatically after a set period.
None of this is Anthropic behaving badly. It is simply what it looks like to be a guest in somebody else's product.
- The address — Anthropic's domain, fixed. Against: your own domain, once you point it.
- Pages — exactly one. Against: as many as the site needs.
- Changing it — ask Claude, if you still have the URL. Against: ask your agent, and the previous version is still there.
- Who can switch it off — you, an organisation Owner, or a retention policy. Against: you.
- Undoing a mistake — unpublishing is permanent. Against: roll back to a recent published version.
- What a visitor needs — nothing, either way. This one is a tie.
When the artifact is exactly the right answer
Most pages competing for this question want the answer to be "never." It isn't.
Anthropic's own framing is the useful one: an artifact is "a capture of work, not an application." Judged as that, it is very good, and frequently better than a website would be:
- walking a reviewer through a change, with notes beside the relevant lines;
- laying four versions of a layout side by side so somebody can pick one;
- a dashboard built from data the session already had in hand;
- a page with sliders on it, so you can feel a value instead of arguing about it;
- anything you will not maintain past Thursday.
For all of those, a real site is overhead. You would be buying a domain to host a conversation.
The artifact stops being the right answer at a specific point, and the point is not technical. It is when somebody other than you starts depending on the thing being there tomorrow.
What "make it a real website" actually means
So what does it take to turn a Claude artifact into a real website?
Underneath, the artifact is HTML with its CSS and JavaScript inlined. Getting it
out is not the hard part. You can read the code and copy it. Claude Code is
stricter about the shape of it than the chat panel: the published file has to be
.html, .htm, or .md, and the rendered page has to come in under 16 MiB.
What changes is what you are holding afterwards. It stops being a page inside an interface and becomes a folder of files: an HTML file at the root, everything it references, and a structure that has to stay intact. That folder needs somewhere to live, an address to live at, and a way to be changed later without being rebuilt. Those are three separate problems, and the mechanics of solving them are a question of their own.
Plenty of routes exist — a publishing service, Netlify, GitHub Pages, a server you rent. Whichever workflow you pick, the exact steps belong in a different article to this one. The point here is narrower: the step exists, and pressing Publish is not it.
One check before you go looking. If what you built genuinely needs a database, user accounts, or server-side code, moving it to a static host solves nothing. Decide whether you built a site or an application first, because that decision outranks the hosting question.
Where Birta fits
Birta is the narrow version of the step above. If you are doing this from the same Claude conversation that built the artifact, the walkthrough for connecting Claude and publishing from there covers the exact steps.
The agent that already holds your finished files publishes them to a live HTTPS address, and how the agent connection works is an open standard your tool most likely already speaks. The last ten published versions are kept, so a change that turns out wrong can be rolled back rather than rebuilt. Images and fonts travel with the site. Point your own domain at it and visitors see your name in the address instead of somebody else's.
Where Birta stops is where the artifact stops: static sites only. No database, no server-side code, no application logic. If your project owns any of those, use a platform built for them and give it the review it deserves.
And if it seems odd that publishing a finished page is a product at all, that is a fair question with a longer answer.
Take the page out of the chat and give it an address
Keep building in the conversation you already have. When the page is finished, the same chat publishes it to a live HTTPS address you can point your own domain at.