How a fix is applied

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.

Two things the preview tells you plainly. If your theme prints a meta description of its own while the SEO field is empty, the preview shows the description the live page renders, and the fix fills the field. And if RankGrep could not write a value it was confident in, the preview says which check the expert's draft failed, such as a description over 150 characters, so you know whether to try again or write it by hand.

A broken-link proposal names the link: the words it is on, the address it points at and what that address answered, then what to do about it. Where a live page on your site matches the dead address, by a redirect, a moved slug or a title, RankGrep proposes that page and says how sure it is. Where nothing matches, it says whether to remove the link or put the page back, judged by how many pages carry the link, because a dead address in a menu or footer is one change, not one per page. When the dead link is in the page's own content and the site is connected to WordPress, the proposal applies itself like any other fix: a replacement repoints the link, and a removal takes the link off its words and leaves the words in place. A removal is only ever proposed for a link that this page alone carries; a dead address shared across the site is left for you to restore. Undo puts a repointed link back on the dead address, and puts a removed link back around the same words exactly as it was written. If the audit's record of the page's links is out of date, RankGrep reads the page at proposal time and checks every link on it, and the preview says it did.

A heading or opening paragraph can live in two places: typed into the WordPress editor, or printed by the theme's template. RankGrep reads the live page to tell which. If the editor's text is what visitors see, the fix rewrites it there. If the theme prints its own, whatever sits in the editor is ignored, the preview shows what the page actually says, and the fix goes through the RankGrep Connector's heading field, which a wired theme reads. On a theme that is not wired, RankGrep says so instead of writing a change nothing would show; see Theme wiring.

Asking for another draft

Beside the proposed pattern's label, New draft writes a second draft, and then a third. Three is the limit. Each new draft is told every draft you turned down and is asked to lead differently, so the three differ in shape rather than in a word or two. The drafts stay on the preview as Draft 1, Draft 2 and Draft 3, and you can switch back to any of them before approving.

The pencil next to it opens a small box for what should change: shorter, plainer, keep the brand name, leave out a service you do not want mentioned. One line is enough, then Enter. It is the most useful thing you can give the expert, because a draft that knows your objection is a revision; a draft that does not is a re-roll.

Some requests RankGrep will not follow, and it says so under the draft rather than quietly doing less than you asked. Leaving out the focus keyphrase undoes the fix. Repeating it reads as keyword stuffing. Capitals read as shouting. A claim the page does not make, such as best, guaranteed or number one, misleads the reader. A length past what search results show gets cut off. In each case the draft follows the rest of your request and the note explains what was set aside and why. The expert itself works under the same rules on every draft: only what the page says, the keyphrase in place, the length within limits.

An ask to leave a phrase out is checked, not taken on trust. If you write "remove Tag:" and the expert's draft still carries it, the draft is rejected and asked for again, and if the second try keeps it too, the preview says so instead of showing a draft marked as followed. On a category or tag archive the expert is also told that the "Tag:", "Category:" or "Archives" the theme prints in the page's current title and description is the theme's label, not the page's name, and a title or description that copies it is rejected the same way.

What you ask for is remembered for this website. The next first draft RankGrep writes for any page on the site starts from what you asked on earlier fixes, so a site whose owner keeps asking for plainer wording gets plainer first drafts. Each extra draft is an expert call and counts against your data credits like the first one.

Before a page's first change

An audit finding is about the page's text. Whether the page is worth changing is about its search results, and those are two different questions. So before RankGrep writes its first title, description, heading or opening paragraph for a page, it reads where that page stands in Search Console over the last 30 days, and in Rank tracking where the search is tracked. The proposal opens with what it found, in one of four standings:

• Already winning. The page is in the top three for its focus keyphrase, or for its busiest search when no keyphrase is set. A tracked position counts here only when Search Console shows people actually making that search: a #1 for a phrase nobody types is a ranking, not a result. If the click-through is healthy for that position too, RankGrep declines to write a proposal and tells you why, with the numbers. There is nothing a rewrite could gain and a ranking it could lose. If the search is won but the clicks are poor, or the page wins a different search from its keyphrase, the proposal goes ahead with orders to keep the wording that earns the position and change only what the issue needs. A title change on a page like this is marked high risk.
• Seen but not chosen. The page has impressions, but sits below the top three, or is clicked less than its position usually earns. The title and description are exactly the lever here, and the expert is told to write for the click.
• Invisible. Almost no impressions while the rest of the site has plenty, or impressions only beyond position 20, which is where every page of a site picks up its head term without being in the running for it. There is nothing to protect, so the expert writes plainly for the search the page should win.
• Unknown. No Search Console import and no tracked position. The proposal is written from the page alone, as it always was.

In every case the expert is told which searches the page already earns impressions for, and never to drop them. Once a page has a measured outcome from an earlier change (section 7), that outcome is what the next proposal reads instead.

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.

On a site connected through GitHub, applying opens a pull request instead: one branch, one commit, and the before and after in its description. Merge it with the Merge pull request button, or on GitHub. The change goes live with the site's next deploy, and the next audit confirms it on the live page.

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 ahead of the connector's. When that is what happened, the message says so, and the fix is in the theme; 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. A link change is undone the same way: a repointed link goes back to the address it had, and a removed link goes back around the same words, written exactly as it was.

For a GitHub change, the ⋯ menu on its row closes the pull request while it is still open, and reverts it once merged: RankGrep opens a pull request that puts the original back and merges it, so the site changes back with its next deploy. Both actions are yours to take; neither happens on its own.

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.

7. Did it work?

A change needs time before anyone can say. Search Console reports three days late, a small site is re-crawled over a week or two, and four weeks of data is the least that averages out a local trade's weekly rhythm. So RankGrep waits: it will not propose the same kind of fix on the same page again for 35 days, and it judges the change once that window has passed.

The judgement is stricter than "clicks before versus after":

• The site's own trend is taken out. A page down 10% on a site down 40% held up well, and is read that way.
• Position is read on the search the fix was aimed at, the page's focus keyphrase or its busiest queries, and only on queries seen both before and after. A better title often starts matching new long-tail searches at poor positions, which drags the page's average down while the fix is working; that trap is avoided.
• The tracked position counts. Where Rank tracking checks that search, the verdict compares the position measured on the last check before the change with the latest check after it. That is a real position read from your town, not an average, so it can give a verdict on its own even when Search Console has too few impressions to.
• The competitor is named. If a tracked competitor holds the top three for that search, the verdict says who, at what position, with what title.

The verdict is one of Worked, Fell back, Mixed or No clear change, and it appears on Results, one row per change that went live, with a count of how the judged changes split at the top. A change still inside its window shows as Awaiting verdict with the date it is due. The verdict also reaches two other places. The next proposal for the same page is written with it in hand: refine an approach that helped, take a different one if it did not, and beat the named competitor's title without copying it. And a fix that fell back or did nothing becomes a finding on SEO Intelligence, so it is not a silence.

Nothing is rewritten on its own. A verdict of No clear change, Mixed or Fell back puts a Propose a new title button, or description, heading or paragraph, under the row's next step. It prepares a fresh proposal for that page with the verdict in hand and opens it on the Overview, where you review and approve it like any other. The page does not have to still appear under the issue on the audit; the first fix satisfied the audit, and the verdict is the reason to go again. The button stays away from a fix that worked, one you have undone, and one whose verdict is on hold because the whole site fell or another change landed on the page in the same weeks; those wait for the second reading described below.

If it fell back

A drop after a change is not always the change's fault, and a second rewrite is often the wrong reply, so RankGrep asks what else moved before it blames the fix. The checks run in the order an SEO would rule things out:

1. The page stopped loading. If an audit after the change could not open the page, nothing written to it can rank until it loads again.
2. The new wording dropped the search phrase. If the old title or description said the keyphrase and the new one does not, that is the cause, and the previous value is what to restore.
3. The whole site fell. A page down with every other page is not the fix's doing. The advice is to leave the change in place and look for what changed site-wide, because rewriting it now would only hide the answer.
4. Another change landed on the same page in the same weeks. Two changes, one verdict: neither can be blamed alone, so the second one gets its own verdict first.
5. Another page of your site took the search. When Search Console shows a sibling page going from almost none to a large share of the impressions for the target search, the two pages are competing, and the fix is to give the other page its own keyphrase.
6. A competitor overtook you. When the site Rank tracking sees above yours is a different one than before the change, or one that was below you, the verdict names it and its title.
7. Nothing else moved. Then the change itself is the likely cause, and the advice is to restore the previous value and keep its wording in the next attempt, not to start from a blank page.

The cause and the next step appear in the row's Next step column on Results, with what was checked in the tooltip, and in the finding on SEO Intelligence. The next proposal for that page is written against the cause: keep the phrase that earned the old position, claim the search unambiguously from the sibling page, or answer the intent better than the named competitor.

A drop the site shared, or one a second change muddied, is a verdict on hold, not a verdict on the fix. The fix stays as it is: the row offers no new proposal, and asking for one from the Overview is refused with the reason. After another 35 days RankGrep reads the page again, the same weeks before the change against the most recent thirty days, with every change that has landed since treated as part of the page as it stands. That second reading replaces the hold with a verdict you can act on, and the row says it was read again. A page still on hold after the second reading, because the whole site is still down, is read again after the next window.

A clear result can end the wait early. From day 21, if the change has enough impressions behind it and has moved the target search by two positions or more, or clicks by 40% or more against the site's trend, the page is released for a new proposal. Anything less waits the full 35 days, because "no change" needs the whole period to mean anything.

The same data is read before a page's first change, so a page that is already winning is not rewritten in the first place; see section 1.

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, 50 to a page. Clicking a status badge shows the reason behind it. Results lists every change that went live with its verdict, why it fell back when it did, and the one thing to do next. Click a count at the top to see only the changes with that result, pick a field (title, meta description and so on), or search for a page, a value or an issue. The table shows 50 changes to a page. Each row shows the short form so the table scans; Details on a row opens the whole of it: both values in full, every sentence of evidence, the cause with what was checked and ruled out, and the full next step. It holds no actions, so undoing or re-applying a change is always done from Change history.