Moving a locally built AI WordPress site to your own host: static copy or full move?

Disclosure: I build ShipPress, the Mac app I use for the example near the end. Everything before that section works with any local WordPress setup and any AI coding agent.

Your AI agent built the site on your laptop, and every page looks right at localhost. Then you try to put it online and the reservation form returns a 404, the search box goes nowhere and half the links still point at http://localhost:8080.

I've moved a fair few of these sites now, mostly small business sites built with Claude Code or Codex. The first decision is whether you need WordPress running on the live site at all. Everything else follows from that answer.

AI agents tend to add things you didn't ask for. Before you choose how to move the site, open it and list anything that needs PHP after the page has loaded:

A quick way to catch forms is to search the theme and the rendered pages for where they send their data:

grep -rnE "admin-post \. php|admin-ajax \. php|wp-comments-post \. php" wp-content/themes/ Enter fullscreen mode Exit fullscreen mode Agents love admin-post.php for forms because it's the documented WordPress way to handle a custom POST. That's fine on a live WordPress install. On a static copy the file doesn't exist, so the form posts into nothing.

If your list is empty (or only has search), a static copy will probably do. If it has a shop, logins, comments or forms you want to keep as they are, move the full site.

The usual route is a static export plugin (Simply Static is a common choice) or a crawler such as wget --mirror. Whichever you use, check these before you upload:

Permalinks. If the site still uses plain links like /?p=123, a static host sees every page as the same file. Go to Settings › Permalinks, choose Post name and save, then export again. Pages come out as menu/index.html, about/index.html and so on, which every static host understands.

Local addresses. Search the exported folder for localhost and 127.0.0.1. Also search for the escaped form localhost:8080\/, which hides inside inline JSON and block markup:

grep -rlE "localhost|127 \. 0 \. 0 \. 1"./static-export/ Enter fullscreen mode Exit fullscreen mode Media. Make sure every size in each image's srcset was saved as well as the original. Open a few pages on a phone-sized window and watch the network tab for 404s. Background images set in CSS are the ones crawlers miss most often.

Forms. Anything posting to admin-post.php, admin-ajax.php or wp-comments-post.php needs a replacement. Your static host may offer form handling, or you can point the form at a form service. Otherwise, swap it for a plain mailto: link or your booking provider's widget.

Search. WordPress search is a query ( /?s=udon ) that PHP answers. On a static copy you need a client-side index (Pagefind or Lunr) or you remove the search box.

404, robots and sitemap. Check that you have a 404.html and that robots.txt doesn't still say Disallow: / from development.

If the site needs PHP, it needs a WordPress host. The move has three parts.

1. Files. You only need wp-content (themes, plugins, uploads). Install a fresh WordPress on the host and let it keep its own wp-config.php with its own database login.

2. Database. Export it and import it on the host:

wp db export site.sql # on the host, after uploading the file wp db import site.sql Enter fullscreen mode Exit fullscreen mode Watch out if your local setup uses SQLite. Many quick local tools do, and most hosts run MySQL or MariaDB, so you need to convert the database before you import. A plugin-based migration tool can do this for you.

3. Addresses. Replace the local URL everywhere, including serialised data, which a plain find-and-replace in a text editor will corrupt:

wp search-replace 'http://localhost:8080' 'https://example.co.uk' --all-tables --precise Enter fullscreen mode Exit fullscreen mode Then check these four things on the live site:

Leave out what only made sense locally: SQLite plugins, local sign-in helpers and any files your AI tool used for its own notes or history.

ShipPress is a free Mac app I make that lets your AI coding tool (Claude Code, Codex, Cursor CLI and others, on your own account) build a WordPress site locally. Each site is a normal WordPress folder in your home folder, with the database as a single SQLite file in wp-content/database. You can always take it and leave.

For a static copy, Go live has a link at the bottom of the Free address tab: "Only want the files? Download the static copy". It saves every page, then checks the result before you upload anything. It looks for plain permalinks, leftover local addresses, a shop, links to wp-admin and forms that post to PHP. In the video it caught?p=123 addresses, and the fix was the Permalinks step above. The output has index.html, one folder per page, a 404 page, robots.txt, a sitemap and a headers file. When a page has a search box, it also adds a small search index that runs in the browser.

For the full site, the WordPress host tab connects to a host once. InstaWP, Hostinger and Pressable connect directly, xCloud and Kinsta take an API key, and Cloudways takes your email and an API key. Any other host with SSH works through Connect with SSH. Go live then exports the database as a MySQL backup, swaps the local address for the live one and packs wp-content. It leaves out the SQLite plugin, the local sign-in helper, ShipPress's editing helpers, its own.aiwp folder and wp-config.php.

Changing hosts later works the same way in reverse: download the site from the old host as a new local site, connect the new host and click Go live.

Here's the whole flow on a restaurant site, Hinoki Udon, from the site folder to the static copy and the WordPress host tab:

The written version, step by step: https://shippress.codotx.com/docs-export-move?ref=devto-en

Which part of the move has caught you out with an AI-built site? For me it was a booking form that worked perfectly on my laptop and posted to admin-post.php on a static host.