Claude Website Publishing: Artifact to Live Site

Claude Website Publishing Starts With a File Audit

Claude can draft a landing page, report, calculator, or client demo in one conversation. The harder part is to turn that draft into a link that you can safely send. Good Claude website publishing does not depend on one Publish button. It depends on three tasks: you review the files, you choose a host and access settings, and you plan updates.

This guide takes you from a Claude artifact or generated code to a live static site. An artifact is content that Claude makes in a panel next to the chat. First, you identify the output, review it, and export a clean folder. Then you choose a host and publish on Cloudflare Pages, with access control if you need it. Last, you test the site and update it without a change to its URL. The Claude interface changes by plan and over time. This workflow uses portable files, so it still works when buttons move.

Identify Claude Artifacts, Code, and Other Outputs

Before you publish, find out what Claude produced. A preview that looks complete can still depend on build tools, online libraries, or features that exist only inside Claude.

According to Anthropic’s artifacts guide, artifacts can be documents, code snippets, single-page websites, diagrams, dashboards, and small interactive tools. Inside Claude, an artifact can also call Claude without an API key. That usage counts against the plan of the viewer. An artifact can also save a small amount of data. Both features belong to the Claude environment. An exported copy on another host needs its own backend (server-side code) to replace them.

Output from Claude	What you probably have	What publishing requires
One HTML file	A self-contained static page	Save it as index.html and test it locally
HTML, CSS, JavaScript, and images	A multi-file static site	Keep the folder structure and relative paths intact
React, Vue, or similar source	Source code, not the final site	Install dependencies and run a production build, often into a dist folder
An artifact that calls Claude or saves data	A demo tied to Claude’s environment	Replace those calls with a server-side service, or keep the demo inside Claude
A form, login, database, or API call	A site with server-side behavior	Add a backend or a hosted service for that part
A document or slide deck	Content rather than a custom site	Export it as PDF, Word, or PowerPoint, or place it in a browsable folder

Use this quick test. If index.html opens from the exported folder and the page works without Claude, you are close. If not, ask Claude to list the dependencies. Then ask Claude for a static version that runs on its own.

Review Before You Publish a Website Made by Claude

Review AI output as you review the work of a contractor. Claude can produce plausible placeholder text, controls that work only with a mouse, layouts that break on phones, and links that go nowhere. A draft that looks excellent on a desktop can still fail a client who opens it on a phone.

Use a short release review:

Item	What to do	Why it matters
Claims and numbers	Make sure that names, dates, prices, citations, and calculations match primary sources	Fluent text can still be wrong
Private information	Remove prompts, comments, API keys, internal URLs, customer data, and hidden draft copy	Visitors can read every file that the browser loads
Brand and rights	Make sure that you have the rights and licenses for logos, fonts, and photos, and the approval of the client	A generated page does not transfer third-party rights to you
Navigation	Test every link, button, menu, download, and form	A handsome dead end is still a broken site
Responsive layout	Test phone, tablet, laptop, and large-screen widths	The Claude preview can differ from the device of a client
Accessibility	Make sure that headings, labels, alt text, contrast, focus order, and keyboard use are correct	Access is part of quality, not a finishing touch
Failure states	Try empty inputs, invalid values, slow connections, and blocked scripts	Real visitors do surprising things

The 2026 WebAIM Million report found an average of 56.1 detectable accessibility errors per home page across the top million sites. Automated scanners miss some problems. For this reason, also test the page with only the keyboard, and have a person read the text.

Export a Clean Folder for Static Website Hosting

The safest export is boring. It is one folder with every file that the browser needs. The guide from Anthropic says that chat artifacts have controls at the top of the panel. You use these controls to view, copy, or download the content. You can export design artifacts as standalone HTML or as a .zip file. If you do not see the option that you need, ask Claude for separate files. You can also copy the source into files on your computer. Do not rely on menu paths from old tutorials.

Prepare the package:

1. Ask Claude for a deployment manifest. This is a list of every required file, path, external dependency, and entry point.
2. Save the entry page as index.html. Every host in this guide serves this file as the home page.
3. Keep the directories and their paths, such as assets/logo.svg, css/site.css, and js/app.js. If you move one file, several references can break.
4. Use relative links, such as ./about.html or assets/photo.webp. Do not use paths that work only in the Claude preview or on your computer.
5. If the project uses React or another framework, build it with the instructions of the project. Upload the generated output folder, not the editable source.
6. Remove secrets and clutter. Delete environment files, test data, prompt notes, unneeded source maps, and unused assets.
7. Open the result on your computer. Test the home page and the nested pages. For JavaScript modules, use a local server such as npx serve. A local server is more reliable than a double-click on the files.

Keep a zipped copy of each reviewed release. It is your fallback if a later change breaks something.

Choose Claude Website Hosting for the Job

There is no single best choice for Claude website hosting. Choose by audience: the public, a client team, or a few named people. Also choose by how private the material is and by how often it will change.

Option	Best for	Access control	Main tradeoff
Publishing the artifact from Claude	Quick demos that anyone can see	On Free, Pro, and Max, anyone with the link can open it without a Claude account. Team and Enterprise links stay inside the organization by default	The page stays tied to Claude, and an unpublished artifact cannot be republished
Cloudflare Pages	Static folders, uploaded by drag and drop or built from Git	Public by default. Cloudflare Access can require an emailed code	Access takes a few extra setup steps
Netlify	Static sites from Git, the CLI, or drag and drop	Public by default. Password protection needs a Pro plan or higher	Password protection is a paid-plan feature
Vercel	Framework apps such as Next.js, and static sites	Vercel Authentication on all plans. Password protection is a paid add-on on Pro	Visitors without a Vercel account need a shareable link or a password
GitHub Pages	Public sites maintained in a Git repository	Public, even when the repository is private (private sites need GitHub Enterprise Cloud)	No visitor login on ordinary plans
Traditional web host	Existing company sites and custom server stacks	Varies widely	More setup, security, and maintenance work

The GitHub documentation says that changes can take up to 10 minutes to appear after a push. It also says that Pages sites are public on the internet, even if the repository is private. That makes GitHub Pages a good home for a public product page, not for a client proposal.

The rest of this guide uses Cloudflare Pages. It accepts a plain folder in the dashboard, and it can ask visitors for an emailed code before they see the site. The same folder also works on Netlify, Vercel, or GitHub Pages. If you prefer Netlify, see the Netlify deployment guide.

Publish the Folder on Cloudflare Pages

Cloudflare calls this method Direct Upload. You do not need Git or a terminal.

1. Sign in to the Cloudflare dashboard. Open Workers & Pages.
2. Select Create application > Get started > Drag and drop your files.
3. Enter a project name. Cloudflare uses it in the default pages.dev address of the site.
4. Drag in the reviewed folder, or a zip of it. Select Deploy site.
5. Open the pages.dev address that Cloudflare shows. Make sure that the site works.

The dashboard upload accepts up to 1,000 files, with a 25 MiB limit per file. For a larger site, the Wrangler CLI from Cloudflare accepts up to 20,000 files:

npx wrangler pages deploy ./site --project-name=client-proposal

Know one limit before you start. You cannot connect a Direct Upload project to a Git repository later. If a developer will take over the site through a repository, create the project from Git instead.

Restrict Access for Client Review

A long, unlisted URL is not access control. People forward links, sync them between browsers, and paste them into chats. For a proposal, a draft, or a demo with client details, put a login in front of the site.

On Cloudflare Pages, that login is Cloudflare Access, part of Cloudflare Zero Trust. With the one-time PIN login method, each visitor enters an email address and receives a code. The visitor gets in only if the address matches your policy. Nobody has to share a password.

1. Add a custom domain. In the Pages project, open Custom domains. Select Set up a domain. Access protects hostnames in a domain that is active on your Cloudflare account. For this reason, the simplest choice is a subdomain, such as review.example.com, of a domain whose DNS Cloudflare manages.
2. Turn on one-time PIN. In Zero Trust, open Identity providers. Select Add new identity provider. Choose One-time PIN.
3. Create the application. Go to Zero Trust > Access controls > Applications. Select Create new application > Self-hosted and private > Add public hostname. Pick your review hostname.
4. Add an Allow policy. Under Include, use Emails for named reviewers. For everyone at the domain of the client, use Emails ending in.
5. Finish the setup. Select one-time PIN as the login method. Set the session duration. Select Create.

Two details catch people out. First, protection on the custom domain does not protect the pages.dev address of the project. The Pages known issues page from Cloudflare lists the steps to put that address behind Access too. Second, Cloudflare emails a code only to addresses that the policy allows. But the login page always says that it sent a code. A reviewer who never receives a code is usually missing from the policy.

To see who signed in, open the Zero Trust Logs. Then select Access authentication logs. Each entry shows the email address, the application, the time, and whether Access allowed the visitor. The Cloudflare Pages access guide covers the setup in more detail.

On Netlify, use password protection (Pro plans and above). On Vercel, use Deployment Protection.

Never put an API secret in browser JavaScript. A login controls who gets in, but anyone who gets in can still read the client-side source.

Test Access, Quality, and Performance on the Live Site

An upload does not guarantee a working release. Test the live site in a private window. If you can, also test it on a phone with mobile data. These tests show permission errors, stale files, oversized images, and resources that worked only on your computer.

Test	Pass condition	Common fix
Root URL	The home page loads without a directory error	Put index.html at the top level of the uploaded folder
Access	Access stops an address outside the policy. An approved address receives a code and gets in	Make sure that the Allow policy and the hostname on the Access application are correct
Second address	Access protects the pages.dev address the same way as the custom domain	Add it to Access, as the section above describes
Assets	Fonts, images, styles, and scripts load over HTTPS	Repair paths and remove http:// links
Interaction	Menus, calculators, downloads, and forms work by keyboard and touch	Use real buttons, labels, and visible focus styles
Forms	A test submission reaches the owner	Make sure that the settings of the form service are correct
Performance	The first view appears quickly and the layout stays still	Compress images and set image dimensions

Google measures performance at the 75th percentile of page views. That is, 75 percent of page views must meet each limit. Google rates a page as good when:

• Largest Contentful Paint is at most 2.5 seconds.
• Interaction to Next Paint is at most 200 milliseconds.
• Cumulative Layout Shift is at most 0.1.

Those Core Web Vitals thresholds describe real visits. A single test on a laptop gives only a rough result.

Update the Site Without Changing the Link

A publishing workflow shows its value on the second release. Keep the live URL the same when you replace the files behind it. Clients keep their bookmarks, and nobody reviews an outdated copy.

Use a small release routine:

1. Edit a working copy. Do not change the last published folder.
2. Describe narrow changes. Ask Claude to change specific files or components. Broad rewrites can remove behavior that worked.
3. Review the difference. Make sure that the changed facts, files, and dependencies are correct.
4. Test again on your computer. Repeat the link, mobile, keyboard, and form tests that the change affects.
5. Upload a new deployment. In the Pages project, select Create a new deployment. Choose production. Upload the revised folder. With Wrangler, run the same pages deploy command again. The custom domain and the pages.dev address then serve the new version.
6. Open the site in a private window. Make sure that the change appears and that the login still works.
7. Record the release. Keep the date, a one-sentence change note, and the zipped folder.

If an update goes wrong, open Deployments in the project. Find the earlier production deployment under All deployments. From its menu, select Rollback to this deployment (Cloudflare rollbacks).

Start manually, so that you see each step. If weekly reports or demos become repetitive, Claude Code can run the deploy commands for you. See deploying a Claude Code website from the terminal. When you automate, keep the review and test steps.

Does an update require a new email to the client? Usually, it does not. Send a note only when the change affects decisions, access, or the agreed scope.

Four Real-World Claude Website Publishing Patterns

The same Claude output can need different delivery rules. Choose the setup for the audience.

Scenario	Publishing pattern	Practical measure of success
Freelance proposal	Export the HTML proposal from Claude to Cloudflare Pages. Put it behind Access, with the email addresses of the client in the policy	The Access log shows when the client signed in, so that you can time the follow-up
Agency design demo	Deploy the prototype to Netlify with password protection and a Netlify Forms feedback form	Review stays inside the client team, and comments arrive in one place
Founder launch page	Review the generated site. Then deploy it publicly on Cloudflare Pages or GitHub Pages	The site runs on the company domain and loads quickly. You can maintain it through Git
Monthly consulting report	Deploy the report, charts, and PDF of each month to the same protected Pages project	The link stays the same when the content changes. Earlier deployments stay in the project history

You need no programming skills to publish a website made by Claude from a static folder. You will need developer help for accounts, payments, private database queries, or custom server logic. Use a login for client material. Use public access for marketing pages that people can share freely.

HTML can display a form, but the submissions need somewhere to go. On Netlify, enable form detection (Forms > Enable form detection). Then add data-netlify="true" to the form tag. Netlify’s forms setup describes these steps. On any host, you can embed a Google Form instead. Open the form. From the More menu, choose Embed HTML. Paste the copied code into your page. Before you collect personal information, test the consent wording and the data handling.

Final Thoughts

Claude website publishing becomes straightforward when you separate creation from delivery. First, identify what Claude produced. Then review claims, privacy, accessibility, dependencies, and mobile behavior. Export a complete static folder, and choose a host for the audience. Test the published result from the view of an outsider.

Before you send the link, remember these points:

• A preview does not prove that the exported files work.
• A private repository does not make a GitHub Pages site private.
• A login protects the site only if it also covers the pages.dev address.
• A stable link works best with a repeatable review.

For a public product site, Git-based hosting fits well. For proposals, reports, and demos that are only for a client, add Access in front of Cloudflare Pages. You can also use the password protection of Netlify. Start with drag and drop. Automate only when you repeat the same steps often.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.