Roll back a website change safely

When to use this guide

Use this when an error appeared soon after a code deploy, plugin update, content migration, DNS edit, server config change, or cache purge. A rollback should reduce risk while keeping enough evidence to find the root cause later.

Before you roll back

• Capture the failing URL, status code, logs, and current version identifiers.
• Check whether the issue affects one path, one platform, or the whole site.
• Tell active editors or deployers to pause changes until the rollback is complete.

Steps

1. Identify the smallest reversible change. Prefer reverting one plugin, one deployment, one config file, or one DNS record over rolling back unrelated work.
2. Check for database or schema coupling. If the deployment included migrations, confirm whether the previous application version can run against the current database.
3. Take a fresh backup or snapshot. Even when rolling back, preserve the current state so you can compare files, settings, and database rows afterward.
4. Apply the rollback in the owner system. Use your deploy tool, hosting panel, version control, or plugin manager. Avoid manual edits that bypass the normal source of truth.
5. Clear only the caches affected by the change. Purge page cache, object cache, CDN cache, or browser-facing assets only as needed.
6. Watch logs while testing. Confirm the original error stops and no new 404, 500, 502, or redirect loop appears.

Verify

Check the broken URL, a known-good URL, admin access, search or checkout flows if relevant, and the server logs. A safe rollback restores the failing path without introducing broader errors.

Rollback the rollback

If the rollback does not help, return to the captured current state or continue with layer-by-layer diagnosis. Do not stack multiple blind rollbacks without recording each change.