Fixing a page
What to change on a page that scores Weak or Borderline for retrieval, in the order that pays, and how to tell whether the change worked.
Updated October 20, 2026
A page that scores Weak against a query you care about usually has one fixable problem rather than five. This is the order to work in, and each step ends with something you can check.
The fix, in order
1. Put the answer in one standalone paragraph
Find the query the page should serve and answer it in a single self-contained paragraph. Self-contained means a reader who sees only that paragraph, with no heading above it and no sentence before it, still gets a complete answer.
Most Weak pages fail here. The answer is genuinely on the page and spread across three paragraphs and a table, so there is no chunk to lift.
2. Use the query's own words
A low n-gram score with decent relevance means the page answers the question in entirely different vocabulary. One sentence using the phrasing from the fan-out query usually clears it.
This is not keyword stuffing; it is making sure the words a model matched on appear somewhere in the passage that answers it.
3. Name the subject in the passage
Pronouns and implied subjects break extraction. "It integrates with most CRMs" is useless out of context. "Omnipresence integrates with most CRMs" survives being quoted, which is the whole point.
4. Make the claim checkable
Vague claims are not quotable because they are not verifiable. A number, a constraint, a named integration or a stated limit turns a sentence into something a model will reuse.
5. Fix the structure around it
Headings that describe rather than tease. A list where the content is a list. A table where the content is a comparison. Structure tells a retriever what a passage is about before it reads it.
6. Re-score, then log it
Score the page again. The scorer fetches live, so the new number is immediate.
Then log the optimization against the page or the fanout, with what you changed. On a two-way MCP connection your agent can log it as it works, which is better than writing it up afterwards because it actually happens.
Reading the result
| What happens | What it means |
|---|---|
| Band moves to Ready | The passage now serves the query. Wait for the assistants to re-fetch. |
| Relevance up, n-gram still low | The answer is right and does not use the query's language. Step 2. |
| Nothing moves | The chunk you added is not the best chunk on the page for this query. Check which passage the score is actually reading. |
| Score fine, still never cited | Not a passage problem. Look at backlink authority and at which third-party sources win this query instead. |
Then wait, and keep the control
Check the score the same day and the presence figures in a fortnight. When they do move, the control prompt is what tells you it was the work rather than the model drifting.
Do one page at a time for the first five, keeping notes on what you changed. After five you will know which of these steps your site's pages habitually fail, and the rest go much faster.
Questions about fixing a page
- Should I rewrite the page or add to it?
- Add, usually. The chunk that answers the query has to exist somewhere on the page; it rarely requires the rest of the page to change.
- How long until presence moves?
- Days to weeks, and different per assistant, because each re-fetches on its own schedule. The readiness score moves immediately, which is why it is the number to check first.
- Do I log the work somewhere?
- Log it against the page or the fanout. That date is what every later before-and-after comparison is measured from.