SEO

Learning Google Search Console

Search Console is the only place where your site's search data comes straight from Google: how often you were shown, how many clicks you got, and roughly where in the results you sat. But the report describes; it does not explain. What you actually have to learn is how to read those four numbers and which filters change them.

Lesson 11 of 15
Intermediate
Free, no signup

The four Search Console steps, in this order

The first three steps happen once; the fourth is what you repeat for months.

Verify ownership
You pick the property type here, and changing it later is expensive
1
Submit the sitemap
Once is enough; Google comes back on its own after that
2
Inspect one URL
See which version Google holds and which canonical it picked
3
Read the Performance report
The only step you repeat every month, and the only one to learn
4

The order matters, but none of these steps brings rankings. Search Console is a measuring tool, not an improving one.

Last checked: 6 September 2026 Facts and tool names in this lesson are re-checked against their sources on this date.

Start by not picking the wrong property type

Search Console has two website property types, and you choose between them once and then live with the choice for months. A Domain property adds up every subdomain and protocol together and can only be verified with a DNS record. A URL-prefix property takes only URLs that start with that prefix, protocol included, and offers many more verification methods.

One sentence in Google's own documentation decides this for a multilingual site: if you need to limit your data by URL path segments, such as example.com/es/ or example.com/en/, then create a URL-prefix property. So on a site whose English, Arabic and Turkish versions live under a path, a Domain property blends all four languages into one number and you never learn which language is working. The way out is to keep the Domain property for the overall picture and add one URL-prefix property per language beside it. The account limit is 1,000 properties, so you will not run out of room.

After ownership is verified, two jobs remain and both take ten minutes: submit the sitemap in the Sitemaps section, and put one URL through the URL Inspection tool to see what version of it Google holds. If the site is new or a page will not get indexed, your problem is not here, and it is covered in submitting a site to Google and why pages stay unindexed. If you also run an Instagram or YouTube account, those now have their own property type, which is what a platform property is.

The rest of this lesson is about what remains after setup and what nobody takes seriously: the Performance report.

What do the four numbers in the Performance report mean?

The Performance report shows clicks and impressions for the past three months by default, and carries four metrics that Google defines like this: clicks, the number of times a user clicked your site from Search results; impressions, how many times your site appeared in the results; CTR, the click count divided by the impression count; and average position, the average position of the topmost result from your site.

Pause on that fourth one, because it is where the misreading lives. The position number is not your page's position; it is the position of your topmost result. In the chart it is the topmost position of your entire site, and in the table it is the position of the specific URL or grouping in that row. So if three of your pages appear for one query, the chart counts only the highest of them.

And one point from Google's own docs that ends half the pointless arguments with a client: even if a query appears in your list, you might not see your site when you run that same query yourself, because Search results are specific to the time, place, device and recent history of the person searching. What you see in your own browser is one sample of one user; the report is the average of all of them.

Fresh data is not final either. Google writes that the newest data is sometimes preliminary, meaning it is still being collected and may change in the next few hours, and it is drawn on the chart with a dotted line. So any conclusion you draw from today's data is one you have to repeat tomorrow.

Why the table total does not match the number above the chart

Everyone asks this after two weeks with Search Console, and it does have an answer, only the answer is documented somewhere else. Data in this report is aggregated in one of two ways: by property, or by page. The chart is always aggregated by property, whatever dimension you picked. The table depends: queries, countries, devices and dates aggregate by property, while pages and Search appearance aggregate by page.

The difference becomes obvious in an example, and the example is Google's own. Imagine a search returns only three URLs, all from the same site, and one user sees all three and clicks every one of them:

Metric	Aggregated by property	Aggregated by page
CTR	100 percent	33 percent per URL
Average position	1	2 for each URL
Impressions	1 for the property	1 for each URL

One event, two completely different reports. Neither is wrong. The practical consequence is that when several of your pages surface for one query, CTR and average position always look better in the property view, and that is a definition rather than luck.

Three more things separate the table number from the chart number. First, the table displays at most 1,000 rows, so the long tail drops out of the table while staying inside the chart total. Second, anonymized queries: to protect user privacy Google omits some queries that are searched a very small number of times from the query table, while keeping them in the chart totals, unless you have applied a query filter. Third, and for that same reason, when you filter by query or page the "match" and "does not match" totals do not add up to the unfiltered total.

So the working rule: read the chart for the total, read the table for row-by-row comparison. And never add up the table rows expecting to land on the number above.

One event, two aggregations, two numbers

Neither pan is wrong. Knowing which one you are looking at makes all the difference.

Aggregated by property

The chart, and the queries, countries, devices and dates tabs
Several results from one site count as one impression
Position is the topmost position of the whole site
Right for the question "how is the whole site doing"

Aggregated by page

The pages tab and the Search appearance tab
Each unique URL is counted separately
Position is that specific page's position
Right for the question "which page is working"

The chart is always aggregated by property, whatever dimension you picked.

Which filters does nobody touch?

There are a few filters at the top of the report that most people never touch, and those are exactly the ones that change what the number means.

Search type. The default is web. If your site is image-heavy, image data is a separate view you have simply never opened. Same for video and news.

Time zone. This one genuinely matters outside the US: Google writes that in all views except the 24-hour view, daily data is tracked and labelled in Pacific Time. So your "yesterday" is not the report's yesterday, and a drop you think happened this morning may be half of the day before. Comparing day by day against your own server data without accounting for that is wasted time.

Time granularity. You can see the chart hourly, daily, weekly or monthly. Hourly exists only in the 24-hour view, and that is where preliminary data shows. Weekly and monthly smooth out the weekend swing and are the honest choice for a long-term trend.

Branded and non-branded queries. A ready-made filter that splits your traffic in two: searches that contain your brand name and searches that do not. Google writes that the filter carries 16 months of history from when it was introduced in March 2025, is not available for sites with a low number of impressions, and that some queries may be classified incorrectly. That single filter tells you whether your growth came from your brand becoming known or from SEO work.

Case and pattern. Query filtering is not case-sensitive, and you can use regular expressions to match several similar queries at once. Most of what people do in a spreadsheet fits into one filter here.

And one behaviour that is not a filter but acts like one: on the Pages tab, performance data is assigned to the page's canonical URL rather than to a duplicate. If a user clicks a duplicate URL, the click counts toward the canonical. On a site with several versions of one page, that means the page you see in the report is not necessarily the one the user opened. You can find any page's canonical with the URL Inspection tool, or with the free SEO tools that show a URL's meta tags and canonical in one run.

Four things that change the number and nobody looks at

Pacific Time

The report's day is not your day, except in the 24-hour view
Branded and non-branded

Separates growth that came from your name from growth that came from SEO
Credited to the canonical

A click on a duplicate URL counts toward the canonical URL
Anonymized queries

In the chart total but not in the table, and the table caps at 1,000 rows

The number

None of these is a bug. All four are documented behaviour, and knowing them is what reading the number correctly means.

What is actually worth looking at once a month?

A short routine worth more than staring at the dashboard. Open the Queries tab over three months and sort by impressions rather than clicks: terms with high impressions and low clicks are where your title and description do not match what the searcher expected. Then sort the Pages tab by CTR ascending, which shows the same thing from the page side. Google itself suggests both moves as common uses.

Then compare two periods rather than reading one. A number on its own says nothing; the difference between two periods says something worth chasing. And keep remembering that this report only ever sees your own site: no competitor, no city by city, no live rank, a boundary drawn exactly in the difference between Search Console and a rank tracker.

There is a newer part of the report too: the view for AI results, enabled for only some sites and reported mostly as impressions. The Search Console AI performance report covers it separately and we will not repeat it here.

And the last thing, which is the most important: Search Console does not tell you why. It tells you impressions for this query halved; it does not tell you whether Google withdrew a rich result, or a competitor moved above you, or your page got slow. You have to bring that answer from somewhere else and set it beside the number. That is where SEO work starts, not in the dashboard.

The fast path, with AI

What people do with a Search Console export is drop the file in front of a language model and ask what happened. An answer always comes back, fluent and convincing, and it is usually invented: the model has the two periods of data and knows nothing about algorithm updates, competitors or what you shipped, so it makes the reason up. The fast route is to take the arithmetic away from the model and give it to a script, then ask the model only for what it is genuinely good at: clustering and framing the question. A cheap fast model is enough; our current pick is in the <a class="text-link" href="/en/ai/">AI section</a>.

In the Performance report set the range to compare two periods, open the Queries tab and export. Do the same once with the Pages tab. Note that values shown in the report as a tilde or a dash become zeros in the downloaded file.
Run the script below on those two files. All it does is subtract and sort by which change actually carries weight; it interprets nothing, and that is the point.
Feed the script's output table to the model with the stage two prompt. Ask for topical clustering and a "what to check" column, not for reasons. The model does not know the reason.
For the top five rows, open the page yourself and write the answer. That step is what separates analysis from guesswork, and no model can do it for you.

Copy-ready recipe

python3 - "queries.csv" "pages.csv" <<'PY'
import csv, sys

def rows(path):
    with open(path, newline="", encoding="utf-8-sig") as f:
        r = list(csv.reader(f))
    head = [c.strip().lower() for c in r[0]]
    return head, r[1:]

def num(v):
    v = (v or "").replace("%", "").replace(",", "").strip()
    try:
        return float(v)
    except ValueError:
        return 0.0

for path in sys.argv[1:]:
    head, data = rows(path)
    print("==", path, "|", ", ".join(head))
    out = []
    for row in data:
        key = row[0]
        n = [num(c) for c in row[1:]]
        # comparison exports put the pairs side by side: new period, then previous.
        if len(n) < 4:
            continue
        d_click = n[0] - n[1]
        d_impr  = n[2] - n[3]
        out.append((abs(d_click) * 10 + abs(d_impr) * 0.1, key, d_click, d_impr))
    out.sort(reverse=True)
    for _, key, dc, di in out[:25]:
        print(f"{key}\t{dc:+.0f} click\t{di:+.0f} impr")
PY

---- Stage 2: the model prompt ----

Role: search data analyst. You have only the table below and no other
information about this site.

Two-period change table:
{script output}

Write the output in three parts:

1) Topical clustering: group the rows by shared subject and give each group its
   summed click and impression change.
2) A "what to check" column: for each group, at most two things a person should
   look at, on the site or in the results, to find out what happened.
3) Patterns visible in the numbers themselves: impressions up while clicks are
   not, or the reverse.

Rules:
- Write no reasons. You do not know what changed and guessing is not your job.
- Name no update, no competitor and no algorithm change.
- Write no number that is not in the table above, and recompute nothing.
- If a group has fewer than three rows, label it "scattered" and do not make it
  a group.

Before you trust the output: Keep three things for yourself. First, the export columns are not always in the same order; the script prints the headers so that if they do not match its assumption, you see it and fix it. Second, anonymized queries and the 1,000-row cap mean your file is not everything, so never conclude "this query is gone" from its absence in the file. Third, and above both: any sentence the model writes about a reason, even when you asked it not to, is a guess until you have checked it yourself, not a finding. The real analysis is step four.

AI in this kind of work

Our position on AI and Search Console is simple: a language model is good at sorting, clustering and framing a question, and no good at all at telling you why a ranking moved. The reason is technical rather than a matter of taste: the model has no access to what actually changed in Google or on your site, so it produces something that fits the data.

Tools that actually help

Claude Suits the clustering stage and the "what to check" column, because when you explicitly say do not write reasons, it goes back on that less often. Iran is on neither of Anthropic's two supported-countries lists.
Gemini Easier on large export files. Our own entry notes Iran is not on Google's supported-countries list; the payment route is in <a class="text-link" href="/en/ai/buy/">buying AI access</a>.
Search Console bulk data export Not AI, and the answer to the 1,000-row ceiling. It pours the data into BigQuery, and the most complete list of queries comes from there. It needs a Cloud project with billing enabled; there is a free usage level and anything above it is charged.

Where it backfires

The main risk here is causal storytelling. You hand over two columns of numbers and the model hands back a narrative: "a core update caused this", "a competitor moved above you", "content quality dropped". None of that is in the data. Worse, several documented properties of the report make those guesses feel plausible: anonymized queries and the 1,000-row cap leave queries absent from the file without their traffic going to zero, the two to three day data lag leaves the last two days of any export incomplete, and labelling days in Pacific Time shifts where a day begins. A model that knows none of the three will invent a content reason for all three. The second risk is about the data itself: a Search Console export is a list of your site's URLs, and if some of them are private or unpublished, sending them to an outside service is a decision rather than a habit; whether your conversation is used for training depends on that service's plan and settings, and is written on its own page.

Sources: Search Console Help: Performance report, troubleshooting data discrepancies Search Console Help: Performance report, dimensions and data groupings Search Console Help: start a new bulk data export Anthropic: is my data used for model training Google: Gemini Apps Privacy Hub

Where this advice stops

Search Console only sees Google, and only your own site. No competitor, no live rank, and no more than 16 months of history. Its data arrives two to three days late, some queries are removed to protect privacy, and its table caps at 1,000 rows. Above all: the report says what happened and not why it happened. If someone tells you the cause of a drop from Search Console alone, they are guessing.

From our own work

This site runs in four languages, and the English, Arabic and Turkish versions sit under a path. One page, four URLs. Open the WHOIS tool page and look at the source: the Persian version puts its own canonical on rgb.ir/seo-tools/whois/ and the English one on rgb.ir/en/seo-tools/whois/. There is a technical point here we paid for ourselves: these pages are plugin virtual routes, and the SEO plugin prints no canonical at all on a virtual route, so our own plugin prints it. Had it not, the Performance report would have credited all four languages to whatever canonical Google guessed. What that means for reading the report: on the Pages tab these are four separate rows rather than one, and to see one language's performance you need a URL-prefix property for that language. A multilingual site with nothing but a Domain property does not actually know which of its languages is working.

Real follow-up questions

Why do Search Console clicks not match Analytics sessions?

Because they count two different things. Search Console counts the click on Google's side; Analytics counts the visit on the browser side. Google lists several reasons for the gap itself: data withheld for privacy, processing of the source data, time lag, different time zones, and the fact that tools like Analytics only see users for whom JavaScript ran.

My average position is 8 but I do not see the page myself. Which is right?

Both. That number is the average over every impression and you ran one search. Google writes that results depend on the time, place, device and recent history of the searcher, so your own search is a sample rather than a measurement. If rank in a specific city and device matters to you, Search Console is not the tool for it.

How many properties should a multilingual site have?

One Domain property for the overall picture, plus one URL-prefix property per language if the languages live under a path. Google's documentation says plainly that limiting data by URL path segments requires a URL-prefix property. The account limit is 1,000 properties, so this costs nothing but a few minutes.

Learning Google Search Console

Verify ownership

Submit the sitemap

Inspect one URL

Read the Performance report