ANALYTICS & REPORTING

Search Console query triage

Use when you have a Search Console query export and need to know which queries actually deserve work.

search-console-query-triage.md

Download .md

You are a search analyst. I will paste a Google Search Console query export.

Data:
{{GSC_QUERY_EXPORT}}

Site context: {{SITE_AND_AUDIENCE}}
Date range: {{DATE_RANGE}}

Sort every query into exactly one of five buckets:
1. High impressions, low CTR (title and snippet problem)
2. Position 5 to 15 with real volume (ranking problem, close to winning)
3. Position 1 to 4 with low CTR (SERP feature or intent mismatch)
4. Low impressions, high CTR (small but qualified, expansion candidate)
5. Noise (ignore)

Output a table per bucket with columns: Query | Clicks | Impressions | CTR | Position | Why it is in this bucket | Single next action.

Rules:
- Rank rows inside each bucket by clicks that could realistically be gained, not by current clicks. Show that estimate as a number and state the assumption behind it in one clause.
- Do not invent any figure that is not in the data. If a field is missing, write "not in export".
- Do not recommend "create more content" as an action. Actions must name a specific page or a specific element on it.
- Cap each bucket at 15 rows and say how many rows were cut.
- Finish with the three queries you would work on first and why those three, in under 100 words. No summary paragraph restating the table.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{GSC_QUERY_EXPORT}}
{{SITE_AND_AUDIENCE}}
{{DATE_RANGE}}

Getting a better result

Export 3 months rather than 28 days so seasonal queries are not misread as decline.
Paste the page dimension alongside the query dimension so it can name the URL to fix.
Run it again after 6 weeks with both exports so it can check whether the actions moved anything.

Questions about this prompt

When should I run this rather than sorting the export by clicks?

Sorting by clicks tells you what already works. This sorts by what could work, splitting every query into five buckets so a title problem sitting at high impressions is never treated like a ranking problem at position twelve. Reach for it when the export holds more queries than the pages you could realistically touch this quarter.

What does the export need to contain?

Clicks, impressions, CTR and position per query, with the page dimension alongside the query dimension so an action can name a URL rather than a theme. Pull three months instead of 28 days, or a seasonal query reads as decline. The site and audience line matters for bucket four, where small means qualified rather than trivial.

What comes back, and which part is the useful bit?

Five bucket tables, each row carrying a reason and one next action, capped at fifteen rows with the number cut stated. The useful bit is the ordering inside each bucket, which is by clicks realistically gainable rather than by current clicks, plus the closing three queries it would start with and why those three.

What is the mistake that costs me here?

Working bucket one because it is the longest. High impressions with low CTR is often a query you were never going to win the click on, while position five to fifteen is where the same effort moves a real ranking. The second error is skipping the re-run six weeks later, which is the only check that anything moved.