/wp-restore replays a backup snapshot onto your site. Three layers of safety stand between you and a bad restore.
The safety net
- You explicitly choose which backup to restore from a list — never automatic.
- Claude asks you to confirm in plain English before running, naming the backup and the target site.
- A fresh pre-restore backup of the current state is taken first. Even if the restore is wrong, you can roll forward.
Typical session
You: “/wp-restore”
Claude: “Here are your last 5 backups [lists snapshots]. Which one?”
You: “The one from May 14 at 17:25.”
Claude: “About to restore backup_20260514_172547.json to yourdomain.com. This will overwrite current pages, posts, products, comments, and settings with what was in that snapshot. A pre-restore backup of the current state will be taken first. Confirm?”
You: “Yes.”
Claude runs wp_restore, reports each content type restored, and gives you the pre-restore snapshot ID so you can roll forward if needed.
Partial restore
You don’t have to restore everything. “Restore just the products and orders from backup 20260514, leave everything else alone.” Claude scopes the restore to those content types only.
When to restore vs. when to fix surgically
If a specific page or post is wrong, ask Claude to revert just that one (WordPress’s built-in revision history covers most edit mistakes). Save full /wp-restore for cases where a lot of state is wrong or a destructive operation went broader than intended.