Reading the Search Console performance report

The four metrics, clearly

The Performance report shows four numbers per row, independent of your analytics tool:

• Clicks: the number of times a user clicked a result from your site in Google search.
• Impressions: the number of times a result for your site appeared in front of a user.
• CTR: clicks divided by impressions.
• Position: the average place of the URL in the results when it appeared (an average across impressions, so a page that mostly shows at position 9 can average low even when it ranks well for one query).

Position is an average and should be read without fooling yourself. A page can show at position 1 for a narrow "near me" query and at position 7 for a broad variant, and the average blends both. Treat the average as trend context, not as the rank of the page.

What the report is and is not

The Performance report is click data in aggregate, sampled by Google. It is not a server log, it is not near-real-time, and it is affected by user signals (a user clicking a paid ad at the top does not generate a click for you). It also shows the data Google chooses to provide. So the report gives you relative direction to act on, and you should corroborate big claims with other evidence before changing strategy.

The data is sampled and delayed by up to two days (the non-sampled windows are usually daily, and heavily-visited properties can still be sampled on some rows). This is normal and is not an error anywhere in your work.

Reading date ranges and filters

The three hard-to-miss controls look like they filter, and they do, but with traps:

1. Date range: the report shows the range you select, and the UI numbers that help compare (compare to previous period, compare to previous year) are in the top bar with the type-of-device filter.
2. Page and query dimensions: things like "page" and "query" are available under Snapshot and otherwise hidden behind the filter button at the top; most users never open them and read the wrong granularity. Open Filters / Dimensions to see a breakdown by query.
3. The gear next to the date: includes more options such as "Where" (search type, country, device). Use the search type to split web from image from video.

A query row agg shares clicks across the queries that produced them, so filtering to one query and reading the trend works, but reading a single query's values alone underreports the total of that keyword across its query variants.

The workflow that avoids the traps

1. Open the report and set the date range to a meaningful unit comparing like-for-like (last 28 days vs prior 28, or last 6 months vs prior 6 months).
2. Apply the search type filter to web.
3. Sort by clicks descending, then impressions descending, and read the top twenty as a trend statement.
4. Look only at the queries whose position and CTR both need action (low CTR at high position = headline or snippet problem; high position, low impressions = relevance problem).
5. Keep the same filters every time you compare. Changing the date range silently re-pivots the story; consistent filters are the whole game.

What not to measure from this report

• Do not use position alone as the ranking story; the average hides the distribution.
• Do not confuse impressions with visibility; a result can show far below the fold.
• Do not read CTR from stray impressions rows (a single position-9 impression gives a CTR of 0%).
• Do not panic over a "decline" in the last two days; compare to the same period last year first.

The report's partner in the console is the Search results page, which serves the same numbers as a fuller UI, and the indexing analysis flow handles the other half of the console, which is the index health, not the traffic.