Blog /
Drop a Claude Artifact onto your WordPress site in three clicks
There’s a workflow most Claude users run into eventually. You ask Claude for a tool: a budget tracker, a meal planner, a pomodoro timer, a tip calculator, a markdown-to-PDF utility. The artifact loads in the conversation. It works. The styling is thoughtful, the interactions are tight, and for the next thirty minutes it lives inside the chat.
Then what?
The realistic answer for most artifacts: they live for a week as a bookmarked claude.ai/share/... URL and then disappear. Sometimes you rebuild the thing months later when you need it again. Sometimes you forget you made it at all. The URL works, but it has no home in your actual life, so it falls out of attention.
That’s the wasted-artifact problem. Claude wrote code. The code does the thing. But the code is homeless, and homeless code disappears.
The DesignSetGo Apps importer is the smallest possible fix. Save the artifact as an HTML file. Upload it. Get a URL on your own domain. The artifact is now an /apps/{slug} page that has all the WordPress-side benefits (your hosting, your domain, your sitemap if you want, your auth if the artifact uses it) without you having to do anything special.
This post is the three-click walkthrough.
Step 1: save the artifact as HTML
In Claude, when an artifact is open, the Artifact panel has a ”…” menu. One of the options is “Copy as HTML” or “Download.” Pick whichever you prefer; the result is a single self-contained .html file with inline styles, inline scripts, and all the assets baked in.
If the artifact references external CDN assets (an icon font, a charting library, a Tailwind script tag), they stay external; the importer doesn’t try to fetch them. If the artifact has loose <img src="..."> references to images that are part of the artifact, you’ll need to inline them as data URIs first, or zip the file together with its assets and upload as a bundle. Most Claude artifacts are already self-contained because Claude tends to inline what it generates, but it’s worth checking.
Step 2: open the importer
In wp-admin, go to DesignSetGo Apps → Add new → Upload an HTML file. The importer is one input box and a slug field.
Drop the .html file in. The importer:
- Reads the file.
- Generates a
dsgo-app.jsonmanifest based on what it sees: title comes from<title>, slug comes from the filename (you can edit), isolation defaults to iframe, no permissions requested. - Wraps the file as a single-entry bundle.
- Validates the bundle against the v1 manifest schema.
- Shows you the install dialog.
The whole process takes about three seconds. The longest part is whatever amount of time you spend deciding the slug.
Step 3: approve and visit
The install dialog tells you what permissions the imported app is asking for. For a Claude artifact, the answer is almost always “none.” Claude artifacts are pure client-side code; they don’t ask the bridge for anything. The dialog reads:
This app does not request any permissions.
Which is the most reassuring possible install dialog and accurate.
The exception: if your artifact uses an external CDN (a chart library from cdnjs, jsdelivr, or unpkg), the importer detects the <script src> tag during parsing and adds the origin to runtime.external_origins in the generated manifest. The dialog then includes an “External services” bucket listing the CDN. That’s the truth: the artifact loads code from a third party, and you should know.
Approve. The app installs. You get a URL: https://yoursite.com/apps/your-slug/. Click it. The artifact runs. From the visitor’s perspective it’s the same artifact, on a URL they can actually share.
What the importer is doing under the hood
A short version, for the curious:
- It parses the HTML and looks for a
<title>to use as the app name. Falls back to the filename if missing. - It looks for a
<meta name="description">and uses that as the description. - It scans for
<script src>and<link href>references to external origins. If any are found, the importer adds them toruntime.external_originsso the install dialog discloses them. If they’re CDN-shaped (cdnjs, jsdelivr, unpkg), the importer flags them in the dialog as “this app loads code from a third-party CDN.” - It infers
isolation: "iframe"by default. Iframe is always safe for a static HTML artifact. If you wanted inline mode for SEO, you’d switch the manifest after importing. - It does not modify the artifact’s HTML, JS, or CSS. The file inside the bundle is byte-identical to the file you uploaded. If the artifact does X locally, it does X identically inside the runtime.
That last point is worth restating. The importer doesn’t transform your artifact. It wraps it in a manifest and validates the wrapper. If something works on your laptop opened with file://, it’ll work in the iframe. If it fails on your laptop with a CORS error or a missing asset, it’ll fail the same way once imported. Test locally first; the iframe is not a magic environment.
Why this is the casual on-ramp
A short comparison:
| Path | Time | Knowledge required |
|---|---|---|
| Build the artifact, deploy to Vercel | 30 minutes | Vercel account, DNS, domain, CLI |
| Build the artifact, embed via iframe in a WP page | 10 minutes | Vercel still needed; WP iframe oEmbed quirks |
| Build the artifact, paste into a custom HTML block in a WP post | 5 minutes | The artifact’s CSS bleeds into the rest of the post |
Build the artifact, save as .html, upload via the DSGo importer | 90 seconds | None |
The DSGo importer is faster than every other path and the only one that gives the artifact its own real URL inside a sandboxed runtime. The artifact’s CSS doesn’t bleed into the rest of the site; the artifact’s JS doesn’t conflict with other plugins; the artifact has its own page in the site’s nav if you want to put it there.
Things to know
A few honest sharp edges:
- External CDN scripts trigger the dialog warning. If your artifact loads jQuery from cdnjs (Claude artifacts sometimes do, especially older ones), the install dialog calls that out. You can approve anyway; the runtime allows it via
runtime.external_origins. But the warning is correct: a third-party CDN is a third-party trust decision. - Artifacts that try to do
fetch()to claude.ai itself won’t work. Claude artifacts generally don’t do that, but if one does, the bridge’s same-origin enforcement blocks the call. Solution: rebuild the artifact without that dependency, or approve the origin in the manifest after import (not always possible if claude.ai’s CORS policy doesn’t allow your origin). - Some Claude UI elements use APIs only Claude provides (the Artifact frame’s history scroll, share UI, Claude’s own console). Those don’t survive the export, because they’re part of claude.ai, not part of the artifact. The artifact’s actual content does survive.
- Multi-file artifacts (an HTML file referencing a separate
.jsand.css) need to be zipped first and uploaded as a bundle. The importer’s “single HTML” path is for self-contained files only. Most Claude artifacts are single HTML; longer projects are bundle-shaped.
When the CLI is the right call instead
If you’re a developer and you’re going to iterate on the artifact, the CLI is faster. npx designsetgo apps init scaffolds a starter, you cp the artifact’s HTML in, you make changes locally, you deploy. Each iteration is one command; the artifact’s URL stays the same across deploys.
The importer is for “I have this thing, I want it on my site, I am done.” The CLI is for “I have this thing, I want to keep working on it.” Both end up at the same URL with the same runtime; pick the one that matches what you intend to do next with the artifact. The Claude Code tutorial walks through the CLI path end-to-end.
The bigger pattern
The artifacts you make tend to be useful in proportion to how easy they are to reach. A tool you’d open once a week becomes a tool you open never if the URL is unmemorable. A tool you’d share with one other person becomes a tool you share with nobody if the share-link is claude.ai/share/abc123def456.
Putting the artifact at https://yoursite.com/apps/your-slug/ reverses both of those. The URL is short, your domain is part of your existing memory, and the link is shareable to people who don’t have a Claude account. Some artifacts deserve that promotion; some don’t. The importer makes it cheap enough that you can promote any artifact that you suspect might survive a week.
Where to go next
- The Claude Code tutorial for the iterative-development path.
- The v0 / Lovable / Bolt importer post for non-Claude artifacts.
- The permission buckets post for what the install dialog is doing under the hood.
Nealey