q=qequals

Google Search Console: queries, impressions, and when to pull the API

How to read your own site's queries, impressions, clicks and position in Search Console, and which questions need a live results page instead.

Qqequals·Oct 4, 2026·7 min read

Google Search Console is Google's free record of how your own site showed up in Google Search. Google's own about page describes it as the place to measure search traffic and performance, fix issues, and help pages shine in results, and Wikipedia describes the same service as the way webmasters check indexing status, search queries, and crawling errors to optimize visibility. It was called Google Webmaster Tools until 20 May 2015, according to Wikipedia.

Everything in it is about your own property. You prove you own the site before you see anything, because the data belongs to the site. So use it to read what already touched your pages, and use a live results page, the Google results for a query, when the question lives outside them.

Which Queries Bring Users to Your Site

Search Analytics, as Google's about page uses the term, means the Performance report: the view that shows which typed strings surfaced your pages.

Google's about page puts it in one line: see which queries bring users to your site, then analyze impressions, clicks, and position on Google Search. Wikipedia lists the same breakdown in more detail: clicks, impressions, click-through rate, and average position for queries, pages, countries, devices, and search appearance types.

Read each word literally:

  • A query is the exact string someone typed that surfaced one of your pages.
  • An impression is one appearance of your page in results for that query.
  • A click is one visit that started from that appearance.
  • Position is the average rank of those appearances.
  • Click-through rate is the share of impressions that became clicks.

Countries, devices, and appearance types slice the same numbers. A query that looks flat overall can split into a phone problem, a country problem, or an appearance problem once you break it out, so check the slices before you decide a page needs rewriting.

Impressions, Clicks, and Position per Query and per Page

The report answers two different questions, and mixing them up is where misreads start.

Per query shows demand that found you. Sort queries by impressions to see what Google already associates with the site, then read clicks and position beside each one. A query with many impressions, few clicks and a middling position is worth a look: the page is surfacing, and something about the title, the snippet or the match to what people wanted is not earning the visit.

Per page shows where that demand lands. Group the same numbers by page to see which URLs carry the weight, and which ones surface for queries they were never meant to serve. A page collecting impressions for queries it barely covers is a sign to expand that page, or to write the page that should have caught them.

In September threads about wiring Search Console data into a coding agent, that per-query to per-page move is what the working loops do. One builder describes sending the data in with a workflow, letting the agent name the pages to optimize, checking the live results for what to fix on each one, then checking the results for new queries to decide which pages to create next. A reply asks the approval question every team meets sooner or later: do you let the agent propose the list, or validate it before anything touches content?

Get Your Content on Google

The rest of the toolset is about whether Google can see the page at all.

Google's about page groups it as three jobs: submit sitemaps and single URLs for crawling, review index coverage so Google holds the freshest view of the site, and open the URL Inspection tool for crawl, index, and serving detail straight from the Google index. A sitemap is the file that lists the URLs you want crawled. Index coverage is which of those URLs Google actually holds. URL Inspection is the per-URL readout of what Google's index has on one address.

The same page adds the maintenance loop. Google sends email alerts when it finds an issue on the site, shows which URLs are affected, and lets you mark them fixed once addressed. Wikipedia adds the monitoring around it: Core Web Vitals, Rich Results and AMP checks, the loading and structured-result health that shapes how a page can appear.

When a page has no impressions at all, start here before you optimize anything. If coverage says the URL is not held, or inspection shows a crawl or serving problem, no title change will move the numbers.

Prove Ownership Before You See Anything

Search Console is owner-gated. Google's help docs give the reason: you prove you own the website because the tool shows information about your site that only owners should see. Wikipedia describes the property model that follows. Domain properties combine protocol and subdomain variants into one property, so http, https, www and non-www roll up together, and owners and associates are managed per property.

For a weekly routine that has one practical consequence: set up the domain property, so the queries, impressions and coverage for every variant of the site sit in one place.

Which Question Is a Search Console Pull, and Which Needs a Live Page

Search Console answers what already happened on your pages. It can't show competitors, terms you never surfaced for, or what the results page rewards right now.

Ask Search Console:

  • Which queries already surface your pages, and where clicks fall short of impressions.
  • Which pages carry the impressions, and which queries land on the wrong URL.
  • Whether a fixed page got recrawled and held, and whether its alerts cleared.

Ask a live results page:

  • Who ranks for a term you don't surface for yet.
  • What the winning pages cover that yours doesn't.
  • What searchers type that never touched your property.

That second list is what qequals is for: it returns live Google results and autocomplete suggestions for a query, the outside half of the picture Search Console can't give you.

The September threads show the same split in working setups. One builder pulling client-requested keywords alongside current keywords through Search Console, with a third-party API for the outside data, describes the order as own keywords first, market data second, then letting the model build on top. Another runs a weekly audit on autopilot by pulling queries and impressions straight into their codebase alongside a second API. A third, reviewing an SEO setup for a coding agent, points out the other side: with no Search Console key and no outside-data key, there are no volumes or rankings to review at all.

When to Pull the API

For a first look, the web interface is enough. Open the Performance report, group by query, then by page, and read the numbers.

Move to a programmatic pull, a way for code to fetch the same numbers without clicking, when the job outgrows the interface. Wikipedia lists an API for managing listings and crawl errors, plus BigQuery export, Google's warehouse for large data, and Looker Studio, its dashboard tool, as the paths beyond the interface. In practice the trigger is a weekly loop: pulling queries and impressions on a schedule, joining them to a crawl or analytics export, comparing this week against last, or feeding an agent that names optimization targets itself.

Once the job is a weekly pull you compare against last week, the interface stops being the tool. Pull the data on a schedule, store each pull with its date, and keep the interface for spot checks.