Quick answer: A safe website deployment process moves changes through separate environments: developers build locally, changes are tested on a staging copy of the site, and only approved changes are released to the live (production) site. Code is tracked in version control such as Git, releases follow a written checklist, a fresh backup is taken before each release and there is a clear way to roll back. Content and database changes need their own rules, because the live site keeps changing while you work.
Why “editing live” causes trouble
On many small sites, changes happen directly on the live server: a plugin update here, a theme file edit there, a quick CSS tweak through the dashboard. It works until it does not. One bad update and the site shows errors to every visitor while someone scrambles to work out what changed.
A deployment process does three things:
- Catches problems before customers see them
- Records what changed, when and by whom
- Makes it possible to undo a bad change quickly
It does not have to be complicated. Even a small business site benefits from a staging copy and a simple release checklist.
The three environments
Local or development
Where developers write and test code on their own machines. Tools like Local by Flywheel, MAMP, XAMPP, Docker or a virtual machine run a copy of the site locally. Nothing here affects anyone else.
Staging
A private copy of the live site on a server that closely matches production: same PHP version, same web server, similar data. It is where changes are tested together and where clients or managers review work before release.
Keep staging private. Password protect it and block search engines so it does not get indexed as a duplicate of your live site.
Production
The live site. Changes arrive here only through the agreed release process.
Larger teams sometimes add more environments, such as a separate QA or user acceptance testing server. Most small and mid-sized sites do well with three.
Version control: the foundation
Version control tracks every change to your code. Git is the standard, with hosted services such as GitHub, GitLab and Bitbucket. Our guide to website version control explains the basics.
For a website, version control usually covers:
- Theme and custom plugin code
- Configuration files (without passwords and keys)
- Build tooling and deployment scripts
It usually does not cover:
- Uploaded media
- The database
- Third-party plugins on some setups, which are managed through a dependency tool like Composer or simply updated on each environment
A simple branching approach works for most teams: a main branch that always matches production, and feature branches for each change that get reviewed and merged.
How code moves between environments
From least to most automated:
- Manual FTP or SFTP upload. Common, error-prone, hard to roll back. Better than editing live, but only just.
- Pull from Git on the server. SSH in and pull the latest main branch. Simple and traceable.
- Deployment tools. Services like DeployHQ, Buddy or Envoyer deploy a Git branch to a server at the click of a button.
- Continuous integration and deployment (CI/CD). Pipelines in GitHub Actions, GitLab CI, Bitbucket Pipelines or similar run tests and build steps, then deploy automatically when code is merged.
Managed WordPress hosts such as WP Engine, Kinsta and others offer built-in staging and one-click push to live, which is a big step up for many site owners.
The database and content problem
Code flows one way: development to staging to production. Content flows the other way: editors add posts, orders and form entries on the live site every day.
That causes the classic problem: if you build a new feature on staging that changes database settings, then copy the whole staging database to live, you overwrite all the live content added since you made the copy.
Practical rules:
- Never push a full staging database over a live database on a site where content or orders change, unless you have frozen live content first.
- Pull live data down to staging and local regularly so you test against real content.
- Script configuration changes where possible, or record them as steps to repeat on live, instead of copying the database.
- For WordPress, tools like WP Migrate DB handle search and replace of URLs when moving databases, and WP Staging creates staging copies on the same server. Merging databases selectively is still tricky; plan changes that touch settings carefully.
- For ecommerce sites, schedule releases that require database changes for quiet periods and consider a short maintenance window.
Testing on staging
Before anything goes live, check on staging:
- Key pages load without errors on desktop and mobile
- Forms submit and send notifications
- Checkout works all the way through with a test payment, if you sell online
- Logins and member areas work
- No PHP errors or JavaScript console errors
- Page speed has not dropped
- Layout is right in the browsers your visitors use; see browser compatibility testing
For larger changes, have someone who did not build the feature run through it. Fresh eyes find different problems.
A simple release checklist
- Confirm the change is approved on staging
- Take a fresh backup of live files and database
- Announce the release window to the team
- Deploy code
- Run any database updates or configuration steps
- Clear caches (page cache, object cache, CDN)
- Test key pages and functions on live
- Watch error logs and uptime monitoring for the next hour
- Record what was released
Writing this down matters more than the specific tools. A checklist stops people skipping steps on a busy afternoon.
Rollback: plan for things going wrong
Before you deploy, know how you would undo it:
- Code: redeploy the previous Git commit or release. Deployment tools often keep previous releases ready to switch back to.
- Database: restore the pre-release backup, accepting that content added since then may need to be recovered separately.
- Plugin updates: keep the previous version available to reinstall.
Test your backups by restoring them to staging now and then. A backup you have never restored is a hope, not a plan. Our guide to website disaster recovery goes further.
When to release
- Avoid releasing right before weekends, holidays or your busiest sales periods
- Choose times when someone who can fix problems is available
- Group small changes into planned releases rather than constant ad hoc updates
- Communicate planned downtime to customers if any is needed
Plugin and core updates count too
WordPress core, theme and plugin updates are deployments. On business-critical sites, test them on staging first, especially major version updates and plugins that affect checkout, forms or memberships. Our WordPress maintenance guide covers a sensible update routine.
After release: monitoring
- Uptime monitoring alerts you if the site goes down; see website uptime monitoring
- Error logging catches PHP and JavaScript errors
- Analytics shows whether conversions drop after a release
If something looks off, roll back first and investigate second.
FAQ
Do small sites really need staging?
If the site matters to your business, yes. Many hosts include staging, and even a basic copy catches update problems before customers see them.
How often should staging be refreshed?
Pull fresh content from live before testing significant changes, so staging reflects the real site.
Can content editors work on staging?
It is usually better for editors to work on live with drafts and scheduled posts, while developers use staging for code and settings.
What if our host does not offer staging?
You can create staging on a subdomain or a separate low-cost server, or consider moving to hosting that supports it.
Release with confidence
A good website deployment process means changes are tested, recorded and reversible. Start with staging, version control and a checklist, then add automation as your site grows. If you want a site built and maintained with a safe release process, see how we help you turn visitors into customers.
