Undoing a fix

Undoing one fix

Open History from the sidebar. Every applied fix is listed with its date, the page it touched and the value it wrote. Click Undo on any row and the previous value goes back.

The rollback record was written before the original change ran, so it exists even for fixes that were interrupted partway through.

Undoing a whole scan

If you applied a batch and want the lot reversed, select the scan in History and click Undo all. Each fix is reverted individually and reported on, so a single failure doesn’t abort the rest.

Site-wide fixes — things like llms.txt or a security header — are removed cleanly rather than left as orphans.

When undo refuses

Before restoring anything, undo compares the current value against what it stored. If they differ, it means you edited that page after the fix was applied — and it stops.

This is deliberate. Blindly restoring would throw away work you did later. Instead the row is marked as drifted and skipped, and you’re told exactly which pages and why.

If you genuinely want the old value back on a drifted page, WordPress revisions will still have it.

What can’t be undone

Two operations are irreversible, and both are labelled as such before you run them and excluded from bulk apply:

• Submitting a URL to Google for indexing. The request has already left; there’s nothing local to reverse.
• Requesting removal of a URL from the index. Same reason — the message is out in the world.

Everything else on the fixable list stores a rollback record.

Reverting by hand

Because every change lives in your own content and your own SEO plugin’s fields, you’re never dependent on this plugin to undo something. WordPress revisions, your SEO plugin’s own editor, or a database restore all work exactly as they normally would.

Nothing is stored in a proprietary format you’d need us to unlock.

Next: Dashboard and scores →