DesignSetGo apps
How it works Examples Docs Pricing Blog WP Blocks Install free

Blog /

How to put an AI-built app on your WordPress site (no code, no CLI, 5 minutes)

By Nealey

If you built an app in Claude (or ChatGPT, Lovable, v0, Bolt) and you want to put it on your WordPress site without code, terminal, or a developer, this is the path. Save your AI-built app as a single HTML file, drop it into the DesignSetGo Apps importer in wp-admin, and the app loads at yoursite.com/apps/your-slug/ in about five minutes. Sandboxed inside an iframe with a strict Content Security Policy, no plugin file edits, no Vercel account, no FTP.

Most posts in this calendar assume you’re a developer. This one doesn’t.

If you have an HTML file on your laptop and a WordPress site with DesignSetGo Apps installed, you can have that file running on your site in five minutes without writing a line of code. No CLI. No Claude Code. No build step. Just an upload form, a checkbox, and a URL at the end.

This is the version of the tutorial we’d hand to a marketing director who has a tool and wants it on the site. If you’re reading this and thinking “I am that person,” this is the right post for you. Skip the developer-flavored ones; you don’t need them.

Step 0: install the plugin

Once. WordPress admin, Plugins → Add new, search for “DesignSetGo Apps,” install, activate. The plugin is free.

If you’re already past this step, skip ahead.

Step 1: open the importer

In wp-admin sidebar, click DesignSetGo Apps, then Add new. The page shows two upload paths:

  • Upload an HTML file. For a single self-contained .html file. This is the fast path most people want.
  • Upload a bundle (.zip). For multi-file bundles (index.html plus separate CSS, JS, images, additional routes). Pick this only if your tool came as multiple files.

Pick the first one for now. Drop your HTML file into the file picker.

Step 2: name it

The importer auto-fills two fields:

  • App name. Defaults to whatever’s in your file’s <title> tag, or the filename if there is no title.
  • Slug. Defaults to a URL-safe version of the filename. This becomes the /apps/{slug}/ URL.

Edit either if you want. Slug is the only one you can’t easily change later (changing it breaks any links pointing at the old URL), so think about it for a beat. A few examples:

  • File Tip Calculator.html produces slug tip-calculator. URL: yoursite.com/apps/tip-calculator/.
  • File pomodoro-with-sound.html produces slug pomodoro-with-sound. URL: yoursite.com/apps/pomodoro-with-sound/.
  • File index.html (the kind of name a download might default to) produces slug index, which is fine but not memorable. Rename it before uploading, or override the slug in the form.

Step 3: review the install dialog

The dialog tells you what permissions the app is asking for. For a generic HTML file with no <script> references to external services, the dialog reads:

This app does not request any permissions.

For a file that includes a third-party CDN script, the dialog reads:

This app loads code from a third-party CDN: cdn.jsdelivr.net.

The dialog is generated from the manifest. The manifest is generated from the file. There’s no hand-curated “trust this app” claim; the dialog is mechanical disclosure.

If the dialog mentions a CDN you don’t recognize, that’s worth pausing on. Most CDNs (cdnjs, jsdelivr, unpkg) are widely used and benign, but they are still third-party trust decisions. If you’re not sure why your file pulls from one, ask whoever made it.

Step 4: approve

Click Install. The plugin:

  • Validates the file against the v1 manifest schema.
  • Creates the app in your site’s database.
  • Wraps it in the iframe runtime.
  • Generates the URL.

This takes about two seconds.

Step 5: visit the URL

The dialog confirms with a link: https://yoursite.com/apps/your-slug/. Click it. The app loads inside the runtime. From the visitor’s perspective it is identical to the file you uploaded; from the security perspective it is sandboxed inside an iframe with a strict Content Security Policy.

That’s the whole flow. You’re done.

What HTML files this works for

The single-file importer handles any self-contained HTML file. That includes:

  • Claude Artifacts saved as HTML.
  • ChatGPT canvas exports.
  • Old “I built this in 2019” tools you have lying around.
  • Hand-coded calculators and one-pagers.
  • HTML mockups your designer sent you.
  • Documentation snippets that should be live pages on your site.
  • Internal tools your team built in a hackathon and never deployed.
  • Games (any single-file HTML game from the itch.io “html5” tag, for instance).

It doesn’t handle:

  • Multi-file bundles. (Use the .zip upload instead.)
  • React/Vue/Angular component source files. (Build them to HTML first.)
  • HTML files that depend on local assets (./images/foo.png) the importer can’t resolve. (Either inline them as data URIs, or zip them up as a bundle.)
  • Files that try to write to a server. (DSGo Apps run client-side. If your file expects a backend, the backend has to live somewhere.)

Where things sometimes go sideways

A short list of issues people hit, and what to do:

The page loads blank. Usually means the file’s JavaScript references absolute paths (/css/style.css, /js/app.js) that worked on its original host but don’t resolve inside the iframe. Open the browser’s devtools (right-click, Inspect, Console tab) and look for 404 errors in red. If you see them, the file needs to be zipped together with the missing assets and uploaded as a bundle, or the absolute paths need to be replaced with relative ones (./css/style.css).

The page shows a console error about CSP. Usually means the file has an inline event handler (<button onclick="...">) that the strict CSP blocks. Move the handler to a <script> block at the bottom of the file (document.getElementById('btn').addEventListener('click', ...)). If you don’t know how to do that, this is the moment to ask a developer or paste the error into Claude.

The page reaches an external service that fails. The CSP blocks third-party connections unless they’re declared in the manifest. If the file calls fetch('https://api.example.com/data'), you’ll need to add api.example.com to the manifest’s external origins, then re-upload. The first install creates the manifest with no origins; the second adds them. You edit the manifest in the DSGo admin page on the app’s settings tab.

The styles look off. If the file inherits from a parent stylesheet (Tailwind via CDN, an external font), and the import didn’t list the CDN, the styles fail to load. Two options: vendor the styles into the bundle (paste them inline), or add the CDN origin to the manifest.

When you’d reach for the bundle path instead

The .zip uploader is the right call when:

  • The HTML file references separate .css, .js, or asset files in adjacent folders.
  • The app is multi-page (multiple HTML files, each one a route).
  • You want to declare the manifest yourself (extra fields, custom permissions, dataset routes).

For a single-file artifact, the single-file path is faster. For anything more complex, the .zip path gives you control.

A note on what this is NOT

A few things people sometimes expect that the importer doesn’t do:

  • It doesn’t make your file faster. The runtime is fast (the iframe is essentially a thin wrapper), but if your file is slow on your laptop, it’ll be slow inside the runtime too.
  • It doesn’t add features. What you upload is what runs. The bridge can be added by editing the bundle, but the importer doesn’t inject it.
  • It doesn’t auto-update. Each upload is a snapshot. If you change the source file, you re-upload to update.
  • It doesn’t promise the file will outlive the site. If your WordPress site goes down, the imported app goes with it. The app is part of the site, not a separate thing.

Why we built this

A short product-rationale paragraph. The CLI path (Claude Code, build step, deploy command) is the right path for developers who are going to iterate. The single-file uploader is the right path for everyone else: site owners with a one-shot artifact, designers with a static mockup, marketing teams with a Codepen-shaped tool. The audience for the CLI is real, but the audience for the file uploader is bigger, and it’s the audience that doesn’t have a fallback for “where do I put this?”

If you’ve been sitting on an HTML file you’ve never quite known what to do with, this is the way to put it on your site without thinking about it. Five minutes, three clicks, one URL.

Where to go next

Keep reading

More from the blog.