A safe WordPress update sequence

Updated · 31 Aug 2026

Short answer.

A safe update begins before the Update button: identify supported PHP and WordPress versions, create a verifiable checkpoint, and define the journeys that must not break. The less you know about the project, the smaller the first change set should be.

Check first

Evidence before change.

• Current WordPress, PHP, active theme, MU-plugin, and plugin versions.
• Declared requirements and changelogs of updated components.
• Custom code that relies on a third-party plugin’s internal functions.
• Free disk space, PHP limits, background jobs, and error-log access.
• A file and database backup from one consistent point in time.
• Critical pages, forms, payments, accounts, and integrations.

Safe sequence

Move in small verifiable steps.

• Recovery first. Prove where and how the site will be restored after a failure.
• Update a copy. Reproduce production on stage and preserve observable pre-change errors.
• Keep causes separate. Do not combine PHP, core, and every extension update into one unexplained step.
• Repeat the journeys. Test public pages, login, forms, jobs, mail, and integrations.
• Release with a checkpoint. Repeat a short postflight and inspect new errors after the production update.

Common mistakes

What usually increases risk.

• Updating production without a fresh database copy.
• Disabling a failing plugin and ignoring the business function it removed.
• Ignoring schema changes and background migrations.
• Leaving automatic updates without observable response and ownership.

320px Site Audit

What can be checked automatically.

Site Audit reports versions, available updates, selected compatibility declarations, cron, Site Health, and related signals. It cannot prove that custom code is compatible; only the concrete updated site can do that.

When help is useful

A concrete next step.

When a project cannot be safely updated in one action, 320px can prepare stage, separate changes, and run a verifiable release.