Most upload problems come from one thing: a build that assumes it lives at the domain root. The fix is to build with a relative base — and the easiest way to get that is to tell your AI tool up front. App To Page ships a copy-ready prompt for exactly this, and you can drop in a reusable skill so every build comes out deploy-ready.
The deploy-ready prompt
Paste this into Claude Code, Cursor, Codex, or any AI builder before it builds:
Build a production version of this app, deploy-ready for the App To Page WordPress plugin.
- Use a relative base so it works at any URL:
Vite -> base: './' | CRA -> "homepage": "." | Vue CLI -> publicPath: './'
Plain HTML/JS -> use relative asset paths (href="style.css", not "/style.css")
- Keep a single top-level index.html as the entry point.
- Bundle all assets (models, fonts, images, wasm) inside the build and reference them relatively.
- Run the production build, then zip the CONTENTS of dist/ (or build/) so index.html is
at the top of the archive.You’ll also find this prompt inside the plugin itself, under App To Page → Apps.
Reusable agent skills
Drop one of these into your project so the AI does the right thing every time, without re-pasting:
- Claude Code skill — download
app-to-page.skill.md. Place it in your project’s skills directory; it triggers whenever you ask to deploy to WordPress. - Cursor rules — download
app-to-page.cursorrules. Save it as.cursorrulesin your project root.
Both encode the same rules as the prompt above: relative base, top-level index.html, relative
assets, and a correctly-zipped build.
Why this matters
App To Page already rewrites asset paths on upload as a safety net, so builds that aren’t perfectly relative usually still work. Getting it right at the source just means fewer surprises — and it’s a one-line change in your build config.
Automating deploys from GitHub or driving the plugin from your editor over a deploy API or MCP is on the roadmap. For now, the workflow is: build deploy-ready, then drop the zip into App To Page → Apps.