Why Query Reports Lie: Page-Level vs Query-Level Data

Full transcript

1,081 words · script draft, under review.

Intro

Take any page on your site. Search Console gives it a click total for last month. Now add up the clicks from all of its queries. You get less. Sometimes a lot less.

So where did the rest go?

Nobody made a mistake. The query report and the page report are counted differently, and the query report is missing rows by design. In this episode we'll see why the numbers never add up, how big the gap is on one of my own sites, and which report to trust for which question.

Reason 1: hidden queries

The biggest reason is privacy. Search Console doesn't show queries that very few people have searched. Google calls them anonymized queries. The clicks and impressions from them are still counted in your totals. You just never see the query text.

That matters more than it sounds. For a site that lives on the long tail, many specific searches that each happen only a few times, a large share of the traffic can come from queries you'll never see.

So the totals are complete, and the query list is a sample. The rows that are missing aren't random either. They're the rare, specific searches. Which is exactly the long tail many content sites are built for.

Reason 2: two ways of counting

The second reason is how Search Console aggregates. There are two ways of counting, and you switch between them without noticing.

Here's one search. Two pages from my site appear on the same results page.

If you look at the data by site, or by query, that search counts as one impression for your site. The position is the higher of your two results.

If you look at it by page, each page gets its own impression. So that one search becomes two impressions, one per page.

So page-level impressions can be higher than site-level impressions for the same period. Clicks are less affected, because a user usually clicks one result. But impressions, CTR and position all shift depending on which view you're in.

The practical rule: never compare a number from a page view with a number from a query view, and never add one to the other.

Reason 3: row limits

The third reason is simply limits. The interface shows and exports at most a thousand rows. The API gives up to twenty-five thousand per call, and you can page through more, as we did in episode four.

But there's also a ceiling on how much detail Google keeps per day. The more dimensions you combine, say query, page, country and device, the more rows fall below the threshold and disappear. Add a dimension, and your totals from the rows get smaller.

What it looks like on a real site

Let's look at real data. Before we go on, a note about it. It's real, from one of my own sites, straight from the Search Console API. But it's anonymized: the domain, the page URLs and the search terms are replaced, so we stay focused on the principles and not on the keywords. The numbers are untouched.

The left bar is the site's total. The right bar is the sum of every query we could pull, with full pagination, over thirty-six thousand rows, for the same four weeks.

A side note on the footnote. If you add up the page-level rows instead, you land almost exactly on the site total for clicks. For impressions, the page sum here is actually a few percent lower, not higher. So don't assume a direction. Just don't mix the views.

The gap between them is the traffic from queries we're not allowed to see. On this site, it's about eighty-four percent of the clicks, and about three quarters of the impressions. And remember, this is a site built on many specific searches. A site that lives on a few big searches will usually have a smaller gap.

Checking one page

Now zoom in on a single page from the same site. Two numbers: the page's clicks at page level, and the clicks from the queries we can see.

Divide the second by the first, and you get the visible share for this page. Here it's about four in ten. That's how much of its traffic you can actually read at query level. The other six in ten are real clicks from searches we'll never see.

Is that good enough for query analysis? For spotting which searches drive the page, usually yes. For saying "this page gets all its traffic from these ten queries", no. Whatever share is missing, it's the long tail, and the long tail is often where the next opportunity is.

Which report to use when

So which one do you trust? Both, for different questions.

Use page-level data when you need totals. Is this page growing or shrinking? How does it compare to last year? How many clicks does a section of the site get? And when you join with Analytics, as in episode five, because Analytics is per page too.

Use query-level data when you need meaning. Which searches is the page showing up for? Is the intent what you expected? Which queries are sitting just off page one? That's the next episode. Which queries are split between two pages? That's episode twelve.

And one habit that ties them together. For each important page, calculate how much of its traffic is visible at query level. Visible query clicks divided by page clicks. If that share is high, query-level conclusions are solid. If it's low, treat any query analysis on that page as a hint, not a measurement. On my top five pages it ranges from about one in ten to about two thirds. Not one of them is close to complete.

Pitfall: summing what can't be summed

The classic mistake is building a report by summing query rows and calling it the page's traffic. It will always be too low, and it gets worse the more dimensions you add.

The second is averaging position across query rows without weighting. As we saw in episode eight, position only makes sense weighted by impressions.

And the third is a quiet one. When you filter on a query, for example every query containing a certain word, the hidden queries drop out of the totals too, because Google can't match them against your filter. So a filtered total is always smaller than you'd expect. Compare filtered numbers only with other filtered numbers.

Wrap-up

Totals from pages, meaning from queries, and never add the two together. The script that measures your hidden-query share is linked in the description. Next episode: finding the pages stuck on page two, just out of reach. See you there.