find_quick_wins

Cost: 10 credits.

find_quick_wins reads your latest pull_gsc_data and surfaces the quick wins: (query, page) pairs that already rank just off the top of page one and already draw impressions, where a small on-page push can convert that demand into clicks. Run pull_gsc_data first.

What it does

From the pull's current window, it selects queries where your page ranks in positions 8–20 with at least 20 impressions, then prioritizes them by impressions (biggest opportunity first, ties broken by the better position). Already-winning queries (position under 8) and near-zero-demand long-tail queries are left out, so the list stays a focused shortlist rather than a dump.

A "page" here is a document: rows that differ only by a #fragment are added together before the bands are read. That changes outcomes in both directions — two anchor rows below the impression floor can clear it as one page, and no #anchor URL is ever printed as the page to go and fix.

Example

Ask your MCP client in plain language:

What are the quick wins for my example.com project?

Input

Returns

A prioritized list of quick-win opportunities, grouped by page — each page with its queries, their average positions, impressions, clicks, and CTR — best opportunity first. The list is capped; past the cap the reply says how many more pairs cleared the bands, so a shortlist is never mistaken for the whole set. If nothing clears the bands, it says so (and you are still charged for the delivered analysis).

Each page also carries one recommended next move, derived from that page's own rows: which of its queries to push, from its current position into the nearest band above it, and whether to widen the page to cover all the near-miss queries riding on it or tighten it around the single one.

When a page is being shown and not clicked — its click-through rate is below what the rest of this shortlist earns — the recommendation says so and points you at the results page before the page itself. An AI Overview, a featured snippet or ads can be taking the click while your rank is fine, and two more positions do not win that back. Both rates are printed; nothing here claims what a given position "should" earn, because Google publishes no such figure.

The list ends with one line saying what position is: Google reports it as an average over the whole window, not a rank on any single day, so a query that sat 5th for half the window and 16th for the other half reports the same figure as one that never moved — and the 8–20 band is applied to that average.

Every reply ends with the same footer: the window that was analyzed against the one before it, a caveat when either window hit the row cap, when the pull was taken plus a sentence once that is old, and — when your Search Console credential has stopped working — a warning to reconnect.

Inherited limits

This analysis sees only what pull_gsc_data brought back. A pull pages through a window and stops at 100,000 (query, page) rows at the very most — usually sooner, at a storage budget measured on the rows themselves, and the reply names the row count each window was cut at — so on a large property a quick win outside the top rows Google returned is not visible here — the analysis prints a caveat when the pull hit that cap.

Both windows also end 3 days before today rather than running up to it, so the newest days are not analyzed yet. See pull_gsc_data for both limits in full.