Fixes with buttons, not reports.
- Five kinds of problem, none visible from one page — pages competing with each other, a topic split across two URLs, a page quietly declining, a search you nearly rank for, a search nothing of yours answers.
- The evidence is your own data — real impressions, clicks and positions per page and per term. Where there’s no data, the model is told there’s no data rather than left to assume.
- A flag is not a verdict — two pages sharing a word is normal; two pages fighting over a search is not. Something has to judge which one this is before it reaches you.
- Nothing changes without you — every fix is quoted and approved before it runs, and four of the five are confirmed one at a time.
- Every fix can be taken back — all five have a real undo path, not a note in the docs telling you to restore a backup.
winter coats
two of your pages · one search
- /collections/outerwear4,120 impressions96 clickspos 8.2
- /blogs/winter-coat-guide1,880 impressions11 clickspos 14.6
Verdict
Real conflict. Both pages rank for the same query and neither ranks well. The collection page has the commercial intent and the better position — it should own the term; the article should be retargeted to something adjacent.
Recommended fix Retarget the page 10 credits · reversible
Illustrative figures, real structure — every field shown is one the analyst actually receives. The point is the order: the evidence sits above the judgment, where you can check one against the other rather than take the verdict on trust.
Five problems. All of them structural.
None of these is a bad page. Each one is a relationship between pages, or between a page and its own history — which is why nobody finds them by opening a page and reading it.
Conflict
Two pages, one search
Your own URLs competing. Google picks one on the day; none of them accumulates authority.
Split
One topic, two homes
The same subject covered twice, each version half as strong as one would have been.
Decline
A page losing ground
Clicks falling over 28 days — with a mechanical check first, in case the page is simply gone.
Quick win
Nearly there
A search you rank just off the front page for. The cheapest traffic you will ever buy.
Coverage gap
Nothing answers it
Real demand in your own profile that no page of yours addresses at all.
a decline is checked mechanically before it is explained — if the page 404s or redirects, you are told that, not given a theory
The difference between a flag and a finding.
A rule can notice that two of your pages both mention “espresso”. That is not a problem — it’s a coffee shop. The same rule fires when two pages genuinely compete for one search, which is a real problem with a real cost. Telling those apart is a judgment, and it’s the judgment that decides whether you’re asked to change anything.
So the detector’s job is only to gather. Each competing page arrives carrying its actual performance for that exact term — impressions, clicks, position — pulled from your Search Console. Where a page has no row for the term, that absence is stated explicitly rather than left blank.
Why that last part matters
An earlier version of this system sent the model a page’s type, id and URL and nothing else. It was being asked which of a merchant’s pages should lose a search, with no information about how either page was performing. It now cannot be asked that question without the numbers in front of it.
| Sent to the judge | What it is | Source |
|---|---|---|
| The termthe exact query in dispute | Fact | your data |
| Each competing pageurl, type, and what it is | Fact | your store |
| Impressions per pagefor that term specifically | Fact | Search Console |
| Clicks and positionper page, per term | Fact | Search Console |
| “No row exists”stated, when a page has no data | Fact | stated absence |
| Is this real, and who should winseverity, owner, fix, rationale | Judgment | the model |
Five things it will actually do about it.
Every fix is priced before it runs, executed against your live store, and recorded so it can be measured afterwards — and undone. The two columns worth reading are the last two.
| Fix | What it does | Price | Approval | Undo |
|---|---|---|---|---|
| Merge duplicate pages | Two pages become one, with a redirect from the loser | 25 cr | Confirm each | Yes |
| Refresh the article | A declining post rewritten, with its ranking sections locked | 15 cr | Confirm each | Yes |
| Retarget the page | The losing page aimed at a different, adjacent search | 10 cr | Confirm each | Yes |
| Boost the rightful owner | The page that should win the term strengthened for it | 10 cr | Confirm each | Yes |
| Build internal links | Links added from relevant pages to the one that should rank | 2 cr | Batchable | Yes |
The approval column is a real distinction, not a setting. Four of the five are confirmed one at a time; only building internal links can go under a single approval. That is narrower than “reversible”, and narrower than “it only adds something”: retargeting a page is reversible and it still rewrites titles and descriptions, so one Approve could quietly change dozens of pages at once. Which group a fix belongs to isn’t decided per store and isn’t a preference — it’s declared against the fix class in the code, beside its price and its undo.
Every one of them has a way back.
This is the claim we’d most want you to check, because it’s the one most software gets away with not meaning. “Reversible” here does not mean you can edit the page afterwards, and it does not mean there’s a backup somewhere you could restore by hand.
Each of the five fixes has its own undo path that puts the store back — the merge is unmerged and the redirect removed, the refreshed article returns to its previous body, the retargeted page goes back to its old target, the links come out. One action, not a cleanup project.
What undo actually reverses
- Merge duplicate pages
- the merge and the redirect
- Refresh the article
- the whole body, to the previous version
- Retarget the page
- the page’s previous target and copy
- Boost the rightful owner
- the added emphasis
- Build internal links
- every link it inserted
five fixes · five undo paths · none of them optional
A fix isn’t finished when it publishes.
Every fix that runs is recorded with what the page was doing before it. Four weeks later the same measurement is taken again, and the two are compared — which is the only way to know whether the change helped, did nothing, or hurt.
That comparison is a separate feature, and it is allowed to come back negative. A system that only ever reports success isn’t measuring anything.
- The before is captured at the moment of the fix — not reconstructed afterwards
- The verdict can be “it didn’t work” — and where you asked for it, the fix is taken back for you
- Nothing is counted twice — one receipt per fix, keyed to the job that ran it
The loop
- 01
See
Your Search Console and your keyword profile, read together.
- 02
Fix
One of five actions, priced, approved and reversible.
- 03
Prove
Measured at day 28 against what the page was doing before.
this page is the middle step — the first is keyword intelligence, the last is receipts
The honest answers.
Will it change my store on its own?
No. Every fix is quoted and approved before it runs, and four of the five are approved individually rather than as a batch — including two that only add to a page, because reversible is not the same as unsurprising.
What if the fix makes things worse?
Then the measurement four weeks later says so, and the fix can be undone. That’s the point of recording the before — a change you can’t evaluate is a change you can’t reverse with any confidence.
Do I need Search Console connected?
For this, yes. The whole feature is built on your own performance data; without it there is nothing to detect a conflict or a decline against.
Why is merging pages so expensive?
Because it’s the one that’s hardest to get right and most consequential to get wrong — two pages become one and a redirect goes in. It’s priced to be considered rather than clicked through.
Can I just see the issues and fix them myself?
Yes. The issues are yours to read, and you’re charged only when you ask the app to act on one. Plenty of merchants read the conflicts and go and edit the pages by hand, which is a perfectly good outcome.
Your store is competing
with itself right now.
you’re charged only when you act · nothing runs until you press it · every action reversible