Analysing Search Console data with Claude or ChatGPT: the exports and the prompts that work

Open the performance report, choose Search results, set the date range to the last 28 days and click Export. You get one table per dimension: Queries, Pages, Countries, Devices, Search appearance and Dates. Each has clicks, impressions, CTR and position. The UI export gives up to 1,000 rows per table.

For anything about change, set the date filter to Compare, last 28 days against the previous 28, before you export. Each row then carries both periods side by side, which is what the model needs to talk about gains and losses without guessing.

• Queries table: for near page one, seen not clicked, and queries you never planned.
• Pages table in compare mode: for losing pages.
• Page and query together: for two pages competing on one query. The UI never exports this, because each dimension is its own table. You need the API or Looker Studio.

The API returns up to 25,000 rows per request with page and query in the same row. This is the request body for the last 28 days of a site; the guide on the Search Console API covers authentication.

POST https://www.googleapis.com/webmasters/v3/sites/sc-domain%3Ayourproduct.com/searchAnalytics/query

{
  "startDate": "2026-08-23",
  "endDate": "2026-09-19",
  "dimensions": ["page", "query"],
  "type": "web",
  "rowLimit": 25000,
  "startRow": 0
}

Brand queries distort everything: they have high click rates and top positions, so they make the site look healthier than it is and push the real opportunities down the list. Remove them before export.

1. 1

   Filter out brand and site: queries

   In the performance report, add a Query filter, choose Custom (regex), set it to Doesn't match regex, and enter the pattern below with your own name and its misspellings. The site: part removes searches you or your team made to check indexing.

2. 2

   Export after filtering

   The export follows the filters on screen. Check the file name and the first rows before you upload it.

3. 3

   Tell the model what is missing

   Anonymised queries are left out of the Queries table, so the query totals are lower than the page totals. Say so in the prompt, or the model will report a gap that is not there.

yourproduct|your product|yourprodcut|^site:

If you pulled page and query rows from the API, filter them with a few lines of Python before handing them over.

import pandas as pd

# rows.csv: page, query, clicks, impressions, position (from the API response)
rows = pd.read_csv("rows.csv")
brand = r"yourproduct|your product|yourprodcut|^site:"
rows = rows[~rows["query"].str.contains(brand, case=False, regex=True)]
rows["ctr"] = (rows["clicks"] / rows["impressions"]).round(4)
rows.sort_values("impressions", ascending=False).to_csv("page-query-clean.csv", index=False)

Each prompt names the table it expects, what to return and the rule that keeps the answer honest. Paste one prompt with one file. Asking all five at once gives you five shallow answers.

Prompt 1, near page one. The queries where a better page could move you onto the first results page. Give it the Queries table.

You are reading a Google Search Console export for yourproduct.com.

The table: one row per search query for the last 28 days, with the columns query, clicks, impressions, CTR and position. Brand queries are already removed. Position is the average position, weighted by impressions, of the site's topmost result.

Task: find the queries with an average position between 4 and 20.

Return:
1. A table of those queries with the columns query, position, impressions, clicks, sorted by impressions, highest first.
2. Below it, the five queries you would work on first, each with one sentence that explains the choice using only the columns above.
3. For each of the five, the page on yourproduct.com that should answer it, if the query makes it obvious. Otherwise write "page unknown".

Rules: use only the figures in the table; say when a row is too small to judge. Do not estimate search volume, difficulty or future traffic. Do not guess why a query ranks where it does.

Prompt 2, seen but not clicked. Queries shown often where few people click. Give it the Queries table, or the Pages table for the same question per page.

You are reading a Google Search Console export for yourproduct.com.

The table: one row per search query for the last 28 days, with the columns query, clicks, impressions, CTR and position. Brand queries are already removed.

Task: find the queries with many impressions and a click rate that is low compared with other queries in this same table at a similar position. Group the rows by position (1 to 3, 4 to 10, 11 to 20) and compare within each group only.

Return:
1. For each group, the median CTR of the group, calculated from the table.
2. A table of the queries whose CTR is well below their group's median, with the columns query, position, impressions, clicks, CTR, group median.
3. For the ten with the most impressions, one line on what the searcher probably wants, based only on the words of the query.

Rules: use only the figures in the table; say when a row is too small to judge. Do not use outside click-rate benchmarks. Do not suggest titles yet.

Prompt 3, losing pages. Pages whose clicks fell against the previous period. Give it the Pages table exported in compare mode.

You are reading a Google Search Console export for yourproduct.com, in compare mode.

The table: one row per page, with clicks, impressions, CTR and position for the last 28 days and for the previous 28 days, side by side.

Task: find the pages whose clicks fell between the two periods.

Return:
1. A table with the columns page, clicks before, clicks after, change in clicks, impressions before, impressions after, position before, position after, sorted by the largest fall in clicks.
2. For each of the top ten, one label:
   - "shown less" if impressions fell and position held,
   - "ranked lower" if position got worse,
   - "clicked less" if impressions and position held but CTR fell.
3. Nothing else. Do not explain causes.

Rules: use only the figures in the table; say when a row is too small to judge. A page with only a handful of clicks in both periods is too small to judge; list it separately.

Prompt 4, queries you never planned. Searches you are shown for that no page on your site was written for. Give it the Queries table and a short list of your pages with the search each one targets.

You are reading two things for yourproduct.com.

Table A, a Google Search Console export: one row per search query for the last 28 days, with the columns query, clicks, impressions, CTR and position. Brand queries are already removed.

List B, my pages: one line per page, with its URL and the search it was written for.

Task: find the queries in Table A that no page in List B was written for.

Return:
1. Those queries grouped by theme, each theme named in plain words, with the total impressions of the group calculated from Table A.
2. For each theme: whether an existing page in List B could answer it with a new section (name the page), or whether it needs a page of its own.
3. Themes with very few impressions in total, listed at the end under "too small to judge".

Rules: use only the figures in the table; say when a row is too small to judge. Do not invent search volumes for the themes. Do not propose more than one new page per theme.

Prompt 5, two pages on one query. Queries where more than one of your pages is shown. Give it the page and query table from the API.

You are reading a Google Search Console export for yourproduct.com from the API.

The table: one row per page and query pair for the last 28 days, with the columns page, query, clicks, impressions, CTR and position. Brand queries are already removed.

Task: find the queries for which two or more of my pages have impressions.

Return:
1. For each such query, sorted by total impressions: the query, then one line per page with page, clicks, impressions and position.
2. A label for each query:
   - "one page leads" if one page has most of the clicks and impressions,
   - "split" if the impressions are shared and no page ranks well,
   - "too small to judge" if the query has few impressions in total.
3. For the "split" queries only, which page looks like the better answer based on its URL and its figures, and why, in one sentence.

Rules: use only the figures in the table; say when a row is too small to judge. Two pages sharing a query is normal when they answer different parts of it; do not recommend merging on the figures alone.

Models are good at sorting, grouping and naming patterns in a table. They are bad at knowing what they do not know. Check each answer against the export before you act on it.

An analysis is only worth the changes it produces. Keep the loop short so each change can be judged on its own.

1. 1

   Pick three findings

   Not twenty. Three pages you can change this week, taken from different prompts if you like: one near page one, one seen not clicked, one losing page.

2. 2

   Change one thing per page

   A title and description for a page seen but not clicked. A better first paragraph and a missing section for a page near page one. A refresh for a losing page.

3. 3

   Write down the date and the queries

   One line per change: the date, the page, the queries it targets, what changed. Without the date, you cannot tell later what moved and why.

4. 4

   Compare four weeks later

   Filter the report to that page, compare the 28 days after the change against the 28 days before, and look at clicks on the queries you wrote down. Then run the prompt again for the next three.

The UI export is fine for a small site. It stops being enough in three cases.

• You hit the 1,000 row limit on the Queries table, so the long tail, where most unplanned queries sit, is cut off.
• You need page and query in one row, for cannibalisation or to see which queries each page wins. That needs the API.
• You want longer comparisons. Search Console keeps sixteen months, so you can compare a season with the same season last year, but only if you pull it before it rolls off.

At that point, either pull the data through the API on a schedule, or connect Search Console to your assistant so it can ask for a page's rows when it needs them. The guide on Search Console with MCP covers the second route.