Staging, production and Git after an AI to WordPress move
An IT consultant explains how to set up staging, production and version control for WordPress after converting an AI-built website.
Convert2WP – convert your AI website to WordPressClick here
Why one live site is not enough
Most AI builders hide environments from you. You press publish and the change is live, and if you are lucky there is a version history to roll back. When a site moves to WordPress, that safety disappears unless you build it back yourself. I have seen small teams edit plugins directly on the live server on a Friday afternoon and spend the weekend restoring backups.
The fix is not complicated. You need at least two copies of the site: a staging copy where changes are tested and a production copy that visitors see. For larger teams a third local copy per developer makes sense. The point is that nothing reaches visitors without having run somewhere else first.
Deciding what belongs in version control
WordPress mixes code and content in a way that confuses people coming from React or Next.js projects. Code lives in files: the theme, child theme, custom plugins and configuration. Content lives in the database: posts, pages, menus, settings and uploaded media references. Git should track code, never the database and never the uploads folder.
In practice I put the theme generated by the converter into its own repository, together with any small custom plugin that holds site-specific functions. WordPress core and third-party plugins are either managed through Composer or simply documented with exact versions. That keeps the repository small and makes every change readable in a pull request.
Building a staging copy that tells the truth
A staging site is only useful if it behaves like production. That means the same PHP version, the same object cache, the same plugins and ideally a recent copy of the real database. Many managed hosts offer one-click staging, which is fine for small sites. For anything larger I script it so it can be rebuilt in minutes.
Two details are easy to forget. Staging must be blocked from search engines with HTTP authentication rather than just the reading setting in WordPress, and outgoing email must be disabled or redirected. Otherwise customers receive test order confirmations, which is an embarrassing way to discover your staging site exists.
Moving changes in the right direction
The golden rule I teach every client is simple: code moves up, content moves down. Code goes from local to staging to production through Git and a deployment step. Content goes from production down to staging when you need fresh test data. You never push a staging database over production, because you would wipe out orders, comments and edits made in the meantime.
When a change needs both new code and new settings, I write the settings as code where possible, for example with a small migration routine in the custom plugin or WP-CLI commands in the deployment script. That way the change is repeatable and does not depend on someone remembering which checkbox to tick.
A deployment pipeline that fits a small team
You do not need an enterprise setup. A GitHub or GitLab action that runs on every push to the main branch is enough. It installs dependencies, runs a basic PHP lint, builds any CSS or JavaScript assets and copies the theme to the server over SSH or rsync. Deploying to staging happens automatically, production requires a manual approval.
After deployment the script clears caches and runs a short smoke test: it requests the homepage, a post, the sitemap and a form page and checks for a normal response. If any request fails, the job reports it immediately. That small test has saved me from more broken releases than any code review.
Handling plugin and core updates safely
Updates are where most WordPress sites break. I disable automatic updates on production for plugins that touch checkout, membership or forms, and apply them first on staging. Security releases of WordPress core are the exception and may update automatically, because the risk of waiting is higher than the risk of the update itself.
Keep a simple log of each update round: date, plugin, old version, new version and anything unusual. After a few months that log becomes a valuable record of which plugins cause trouble and which never do, which helps when you decide what to replace.
Common mistakes after a conversion
Teams coming from AI builders often keep editing the theme files through the WordPress theme editor because it feels similar to editing in the builder. That bypasses Git and the next deployment silently overwrites the change. I recommend disabling file editing in wp-config so the only path for code is the repository.
Another common mistake is hardcoding the domain in templates or options. A converted site should work on staging and production without search and replace in code. Use the WordPress functions for URLs, and keep environment-specific values in configuration, not in the theme.
What I hand over to the client
At the end of a project the client receives a short document: where the repository lives, how to create a staging copy, how to deploy, how to roll back and who to call. It fits on two pages. A workflow that nobody understands will be abandoned within a month, so simplicity matters more than technical elegance.
Small glitches after a conversion are normal, and a proper staging and deployment setup is exactly what makes them cheap to fix. Instead of patching the live site under pressure, you correct the issue calmly, test it, and release it with confidence.