If changes were overwritten
A database restore or a deploy that pushed the database wipes RankGrep's fixes. Here is how RankGrep notices, and how to put them back in one click.
On this page
It happens. A backup is restored, a staging site is promoted, someone pushes from Local with the database ticked. Every value RankGrep wrote is replaced by an older copy. This page is what to do next.
RankGrep notices on the next audit
Every audit reads each page the same way RankGrep verified each fix. When a page no longer shows a value RankGrep applied, that change is marked Overwritten on site in Change history, with the value the page shows instead. The approved value is kept on the row, so nothing has to be diagnosed or approved again.
Putting them back
Open Change history for the website. A notice at the top counts the overwritten changes and offers Re-apply all. Each one is written again through the normal path: write the field, read it back, verify it on the live page. Any that cannot be verified are reported with a reason, and the rest go live.
You can also click Re-apply on a single row.
Re-applying records what the page held at that moment as the new "before" value, so a later Undo restores what was actually on your site, not what was there a deploy ago.
When Re-apply refuses
Re-apply checks your site before writing, and stops in three situations.
"WordPress still holds this value, and the live page is being served from a cache." Nothing was overwritten. The audit saw a stale copy of the page. Wait a few minutes and re-apply again, or purge your host's page cache.
"The active theme no longer declares RankGrep heading support." The database is intact but a theme without the wiring was uploaded, so the H1 and opening paragraph are not printed. Re-upload a wired theme. There is nothing to re-apply.
"A theme or SEO plugin is printing its own." WordPress holds RankGrep's value but something else prints a different title or description. Section two of Theme wiring explains which conflict this is and what to change.
Which fixes cannot be detected this way
Image alt text is not read from the page by the audit in a form that can be compared, so an overwritten alt-text repair shows up as the original issue reopening rather than as an overwritten change. Prepare and apply it again from the issue.
Preventing it next time
Deploying without losing changes covers Local, WP Engine, WP Migrate and staging. The short version: files go up, the database comes down.