Recover from a media rename

Use Rollback this batch while the analyzed or applied job remains available. The rollback restores recorded database values, managed settings, attachment metadata, optional title/slug changes, and file names in reverse order.

If application fails

The tool can mark the batch as requiring rollback when a later phase fails after earlier changes were applied.

1. Keep the administration page open.
2. Do not manually move either the old or new files.
3. Click Rollback this batch when offered.
4. Wait for Rollback complete.
5. Verify the original attachment URL, sizes, metadata, and pages from the dry-run report.

Rollback depends on the batch records and safety copies created for that operation. Jobs expire, so they are not a substitute for a retained site backup.

If the built-in rollback is unavailable

Restore the database and uploads directory from the same pre-rename recovery point. Restoring only files or only the database can leave the two sides inconsistent.

After restoration:

1. clear page, object, browser, image, and CDN caches;
2. open the attachment and confirm its original filename;
3. check every generated size and WebP companion;
4. load representative content that used the image;
5. verify any redirects added for the renamed URL;
6. re-run a dry analysis only after the restored state is stable.

When rollback succeeds but an old URL still fails

Check whether the failure comes from a CDN, external link, browser cache, or redirect rule rather than WordPress storage. The built-in rollback restores recorded local changes; it cannot retract remote cache entries or edits made outside the batch.