How to Update WordPress Safely: Staging, Backups and Automated Tests

The safest way to update WordPress is to never update the live site first. Take a backup, apply the updates to a staging copy, test what matters, and only then repeat the same updates on the live site. Add automated tests and the process becomes fast enough to do every week.

This article walks through that process step by step, explains where automated tests fit, and shows what to do when an update goes wrong.

Why updates break sites

Most WordPress updates go fine. The ones that break things usually fall into a few groups:

• Plugin conflicts. Two plugins change the same thing, and a new version of one changes how it behaves.
• Changed functions. Custom code or a child theme relies on a function or hook that a plugin renamed or removed.
• PHP compatibility. A plugin update needs a newer PHP version than your server runs, or old code fails on a newer PHP.
• Front-end changes. A new version of a page builder or theme changes markup or CSS, and layouts shift.
• Database updates. Some plugins change their database tables during an update. These changes can be hard to undo.

None of these are rare. The fix is not to avoid updates, since skipped updates leave known security holes open. The fix is a process that catches problems before visitors do.

Step 1: Take a fresh backup

Before anything else, take a backup of both files and the database at the same time. Do not rely on last night’s backup if orders or form entries came in today.

If you use WP-CLI, the WordPress command line tool, a database export is one command:

wp db export backups/before-updates-$(date +%F).sql

Store a copy off the server. And make sure you know how to restore it. A backup you have never restored is not a plan. The WordPress documentation covers backup basics.

Step 2: Create or refresh a staging site

A staging site is a private copy of your live site. It should match production as closely as possible:

• Same PHP version and server software.
• Same plugins, theme and versions.
• A recent copy of the database.
• Search engines blocked, and outgoing email turned off or caught, so tests do not email real customers.

Many hosts offer one-click staging. If yours does not, a local copy works too. For developers, the official wp-env tool starts a WordPress environment in Docker containers with one command.

Refresh staging from live before each update cycle. Testing against a month-old copy can hide problems.

Step 3: Review what is being updated

Before you click anything, look at the list. WP-CLI can show what would change without changing it:

wp plugin update --all --dry-run

For each item, check:

• Is it a major version? Going from 3.9 to 4.0 carries more risk than 3.9.1 to 3.9.2.
• What does the changelog say? Look for words like “breaking,” “requires,” “removed” or “database.”
• Does it touch something critical? Payment, forms, membership, search and caching plugins deserve extra care.

Group low-risk updates together. Update high-risk plugins one at a time so you know which one caused any problem.

Step 4: Apply updates on staging and test

Run the updates on staging. Then test. The goal is to check the things that make you money or that customers rely on, not every page on the site.

A practical checklist for most business sites:

1. The home page and top landing pages load and look right.
2. The main navigation works on desktop and mobile.
3. Each important form submits, and the notification email is generated.
4. Checkout or booking works from start to finish (use test payment mode).
5. Logged-in areas work for each user role.
6. The admin dashboard and editor load without errors.
7. The PHP error log shows no new warnings or fatal errors.

Where automated tests help

Doing that checklist by hand every week gets old fast, and people skip steps. Automated tests run the same checks every time, in a few minutes.

There are three kinds of tests worth knowing:

• Smoke tests load key pages and check for the right content and a good response.
• End-to-end tests act like a real visitor in a browser: fill a form, add a product to the cart, log in. Playwright is a popular tool for this.
• Visual comparison tests take screenshots and flag pixel changes. Playwright has built-in screenshot comparison.

For custom plugins and theme code, unit and integration tests with PHPUnit check the code itself.

Here is a small Playwright test that checks a contact form still submits:

import { test, expect } from '@playwright/test';

test('contact form submits', async ({ page }) => {
  await page.goto('/contact/');
  await page.getByLabel('Name').fill('Test User');
  await page.getByLabel('Email').fill('test@example.com');
  await page.getByLabel('Message').fill('Staging update test');
  await page.getByRole('button', { name: 'Send' }).click();
  await expect(page.getByText('Thanks for contacting us')).toBeVisible();
});

Your labels and messages will differ, but the idea is the same: write down what “working” means, then let a script check it. We go deeper in our guide to automated WordPress testing with Playwright and PHPUnit.

This is everyday work for us. Our founder works daily with Docker, PHPUnit and Playwright, and we can spin up hundreds of WordPress test sites in automated environments. That lets us test an update across many setups, not just one.

Step 5: Update the live site

Once staging passes, apply the exact same updates to the live site. Same versions, same order. Do not pull in newer versions that came out after your staging test.

Good habits for this step:

• Pick a quiet time. Check your analytics for the lowest-traffic hours.
• Watch for database updates. Some plugins ask you to run a database update after the code update. Run it, then test.
• Clear caches. Page cache, object cache and CDN cache can serve old files after an update.

Step 6: Check the live site again

Run the same checks on production. If you have automated tests, point them at the live site, using test modes for anything that charges money or sends real emails.

Keep an eye on the error log for the next day or two. Some problems only show up when a scheduled task runs or when real traffic hits a rare path.

Step 7: Know how to roll back

Even with staging, something can slip through. Decide how you will roll back before you need to.

• One plugin caused it? Reinstall the previous version. WP-CLI supports this with wp plugin update <plugin> --version=<old-version> (see the command reference).
• The site is down with a fatal error? WordPress has a recovery mode that pauses the broken plugin and emails the site admin a special login link. If that email does not arrive, rename the plugin’s folder over SFTP to turn it off.
• Data changed? If a plugin ran a database update, rolling back the code may not be enough. You may need to restore the database backup from Step 1, which is why you took it right before updating.

Write down what broke and why. If the same plugin causes trouble often, that is a sign of technical debt worth fixing, not just patching.

What about auto-updates?

WordPress can update plugins and themes automatically. Minor core releases install automatically by default on most sites.

Auto-updates are a reasonable choice for:

• Minor and security releases of WordPress core.
• Simple, well-maintained plugins that do not touch payments, forms or custom code.

We would not turn them on for:

• E-commerce, membership and form plugins.
• Page builders and themes with heavy customization.
• Any plugin your custom code depends on.

A mixed approach works well: auto-update the low-risk items, and run everything else through staging on a set schedule.

How often to run this process

For most business sites, a weekly or every-other-week cycle works. Security releases should not wait for the next cycle. Apply them within days, still with a backup and a quick test.

Larger changes, like a major PHP upgrade, are a separate project. Our guide on upgrading PHP safely in WordPress covers that. And for the full picture of what ongoing care involves beyond updates, see what WordPress maintenance includes.

Signs your update process needs work

• Updates are often months behind because people are afraid to run them.
• Nobody can say when a backup was last restored.
• There is no staging site, or it is badly out of date.
• The same plugin breaks the site every few updates.
• Custom code has no tests and only one person understands it.

Each of these is a form of technical debt. If several apply, it helps to measure your WordPress technical debt first, so you know what to fix in what order.

Let us run your updates

If you would rather not run this process yourself, our WordPress maintenance service includes staging tests, tested backups and automated checks for the parts of your site that matter most. Get in touch and we will look at your site and give you a fixed quote.

Frequently asked questions

How do I update WordPress without breaking my site?

Take a fresh backup, apply the updates to a staging copy first, test the pages and features that matter most, then repeat the same updates on the live site and check it again. Keep the backup ready in case you need to roll back.

Should I update all WordPress plugins at once?

For low-risk plugins, batching is fine. For plugins that handle payments, forms, memberships or custom code, update them one at a time or in small groups so you can tell which update caused a problem.

What is a WordPress staging site?

A staging site is a private copy of your live site used for testing. You apply updates and changes there first, so problems show up before your visitors see them.

Do I need automated tests for a small WordPress site?

Not always. A short written checklist can be enough for a simple site. Automated tests start to pay off when you update often, run a store or have custom code.