How a fix is applied
From proposal to live change, every step RankGrep takes, and what happens when something does not match.
On this page
A fix in RankGrep is a small, checked transaction against one field on one page. This is the whole sequence, in order.
1. Proposal
RankGrep picks an issue and a page, reads the current value straight from your site, and writes a replacement. You see both side by side: the exact text that is there now and the exact text that will replace it.
If the current value changes on your site between this preview and the moment you apply, RankGrep stops and asks you to prepare a fresh proposal. It never writes over something it has not shown you.
2. Approval
Nothing is written until you approve. Approving is a review of the exact before-and-after, not a general permission. Each proposal is approved on its own.
3. Apply
RankGrep writes the single approved field through the WordPress REST API, using the Application Password from your connection. It reads the field back to confirm WordPress stored exactly what was sent.
4. Verify on the live page
Storing a value is not the same as showing it. Themes and SEO plugins can print their own title or description regardless of what the database holds. So RankGrep fetches the public page, bypassing caches, and checks that a visitor now sees the new value.
- If it matches, the change is Live.
- If the page is being served from a cache that has not caught up, the change is Saved, confirming. The next audit confirms it once the cache clears.
- If the page shows something else and it is not a cache, RankGrep restores the original value automatically and tells you why. The usual cause is a theme printing its own tag; see Theme wiring.
5. Undo
Every live change keeps its original value. Undo writes it back and verifies that too. If someone has edited the field by hand since, Undo refuses rather than overwrite their work.
6. Audits keep checking
Each later audit reads the page again and compares it with every change RankGrep believes is live. If a change is gone, it is marked Overwritten on site and can be put back with one click. This is what protects you when a database restore or a deploy replaces the site's content; see If changes were overwritten.
Where to see all of this
Change history in the app lists every proposal for a website with its before, after, status and the action available: Apply, Undo or Re-apply. Clicking a status badge shows the reason behind it.