Google Search Console — what it is and how to use it in business

Google says Google Search Console helps anyone with a website "to understand how they are performing on Google Search" (Google Search Central, updated 10 December 2025, accessed 4 October 2026). It shows what happens in Google before the click: whether a page is indexed, which queries it appears for, at what position, and how often people click through.

Each of these numbers has a Google definition that differs from what intuition suggests. Average position is your site's top-ranking link averaged across queries, not the average of all your links. An impression counts even if nobody scrolled down to the result. Rare queries are included in the chart total but missing from the table. A "URL is on Google" status doesn't mean the address will show up in results. And requesting indexing, the first thing most people try, guarantees nothing. Below we describe each report in Google's own definitions, and at the end we show how they look on our own blog's data.

Google Search Console — what it is and what it's for

In the words of the documentation, Search Console "provides information on how Google crawls, indexes, and serves websites" (Google Search Central, accessed 4 October 2026). People also search for it as "search console" or "google webmaster tools"; it is the same service.

You don't need to log in every day. Google says plainly that you'll get an email when new issues are found on your site, and that the account is worth checking around once a month or after content changes. A sitemap isn't required to appear in Google (pages can be discovered without one), but submitting it in Search Console "might speed up your site's discovery" (same source).

Search Console stops at the click; what a visitor does next is measured by Google Analytics. That split, and how to use it in diagnosis, is covered in our article on website KPIs. Here are two things that article doesn't cover.

The GA4 connection. Once you link a Search Console property to a GA4 data stream, two reports appear in Analytics: "Google Organic Search Queries" and "Google Organic Search Traffic". Search Console keeps data for the last 16 months, so the Analytics reports also cover 16 months at most, and data reaches both tools 48 hours after Search Console collects it. Search Console metrics combine with only three Analytics dimensions: landing page, device and country. One data stream links to one Search Console property (Google Analytics help, accessed 4 October 2026; the help page itself gives no update date).

Why a click in Search Console almost never equals a session in GA4. Google has a separate document on this and opens with a caveat: clicks and sessions are counted differently, so the numbers will differ and a small gap can be ignored; what matters is that the trends follow the same pattern. For a large gap, Google lists these causes (Google Search Central, updated 7 January 2026, accessed 4 October 2026):

• Analytics implementation — GA4 sees only what the tag collects, and some pages may lack the tag; Search Console data is processed the same way for every property.
• Consent — when users decline tracking, Analytics undercounts (details in our article on Consent Mode).
• Time zone — Analytics uses the one you set; Search Console counts days in Pacific Time (PT).
• Attribution — Analytics attributes sessions by an attribution model; Search Console counts every search click.
• Canonical URLs — Search Console reports only the canonical URL in Google; Analytics reports every URL that carries a tracking code.
• Traffic split — Search Console splits traffic into web, images, video, news and Discover; Analytics splits it differently.
• Non-HTML pages — PDF files shown or clicked in search appear in Search Console, and Analytics may not measure them at all.
• Bots — Analytics automatically excludes known bots; Search Console may not.

Adding a site to Google Search Console: domain property or URL-prefix property

The first decision is the property type. Google's help describes two basic kinds (Search Console help, accessed 4 October 2026):

• Domain property covers every subdomain (m, www and others) and every protocol (http, https, ftp). It requires verification through a DNS record, unless the site runs on a Google service such as Blogger or Google Sites.
• URL-prefix property covers only addresses that start with the given prefix, protocol included, so https://www.example.com/ doesn't cover http://example.com/.

For a business website a domain property is usually more convenient, because you don't have to keep track of www and non-www variants. The price is DNS access: if someone else manages the domain, you need their help to verify. The same help page also lists platform properties (Instagram, TikTok, X, YouTube) and a limit of 1,000 properties per account.

Verification proves that you have rights to the site. Methods per Google's help (accessed 4 October 2026): uploading an HTML file, an HTML tag, a Google Analytics tracking code, Google Tag Manager, a Google Sites or Blogger account, and a record with your domain provider (a TXT or CNAME record in DNS). The HTML-file method only works for URL-prefix properties, not domain properties.

Two more points from the same help page. Verification lasts as long as Search Console can confirm a valid token, which it checks periodically. If a site rebuild removes the verification file or tag, you'll be notified, and if the problem isn't fixed, your permissions expire after a grace period. And data is collected for a property as soon as anyone adds it, even before verification, though it takes a few days to accumulate.

The broader question of how to get Google to see your site at all is covered in our article on SEO and indexing.

Logging in and access: who at the company, who at the agency

You sign in to Google Search Console with the Google account that owns the property or has been added as a user. If you don't see your site after signing in, there are two routes: an owner adds your account, or you verify ownership yourself with one of the methods above. If the Search Console login "isn't working", first check which Google account you are signed in with.

Roles per Search Console help (accessed 4 October 2026):

• Owner — verified or delegated; both have the same permissions.
• Full user — sees all data and can take some actions.
• Restricted user — sees most data.
• Associate — a person or account that can take specific actions on the site's behalf but cannot open Search Console or its data.

The rules with business consequences: a property needs at least one verified owner, otherwise nobody has access to it. A property can have at most 100 non-owner users. Delegated owners can be added until verified and delegated owners together reach 500; verified owners have no cap. Removing an owner requires deleting their verification tokens, or the removed person can simply re-verify. The help page adds a line worth remembering: "If you've found an owner that you don't recognize, you might have been hacked."

Our practical rule, derived from these policies:

1. The company is the verified owner, on an account that doesn't leave with an employee.
2. An agency gets full or restricted access, never ownership. Only an owner or a Full user can request indexing, so an SEO contractor usually needs full access.
3. After the engagement ends, remove the agency's users, and if the agency verified itself with its own token, remove that token too.

Read access is enough for an audit; what an audit does with that data is covered in our article on website audits.

The Performance report: clicks, impressions, CTR and average position

By default the Performance report shows clicks and impressions for the past three months (Search Console help, accessed 4 October 2026). You can break the data down by query, page, country, device, search appearance and date, and switch the search type between web (text-based, or multimodal, which covers searches with an image, for example from Google Lens or Circle to Search), image, video and news.

The definitions below come from Google's help page "What are impressions, position, and clicks?" (accessed 4 October 2026). Google notes that these rules are subject to change.

A click is any click that takes the user to a page outside Google Search, Discover or Google News. If someone clicks, comes back and clicks the same link again, that counts as one click.

An impression means a user saw, or could have seen, a link to your page. It counts whenever the result is on the current page of results, whether or not it was scrolled into view. The exceptions are carousels and expandable elements, which must actually be scrolled into view or expanded.

CTR — what it is

CTR (click-through rate) is clicks divided by impressions. For example, 50 clicks from 1,000 impressions gives 5%; that is arithmetic, not a benchmark. Because an impression counts even when nobody scrolled the result into view, CTR can fall simply because impressions build up on lower positions or on queries loosely related to the page. A low CTR can mean a weak title, or simply broader visibility.

On our Polish site (digitalvantage.pl), property sc-domain:digitalvantage.pl, site-wide CTR from 5 July to 2 October 2026 was below 0.1%. A caveat on our own data: this was a period of blog content rework, when Google was still re-crawling many posts. How to write titles and descriptions that raise CTR is covered in our article on SEO copywriting. We don't publish "CTR at position one" benchmarks, because Google doesn't.

Average position — how Google calculates it

This is easy to misread. Google defines position as "the topmost position occupied by a link to your property or page in search results, averaged across all queries in which your property appeared" — in other words, your site's top-ranking link, averaged across all the queries it appeared for.

Google's example: for one query your site has links at positions 2, 4 and 6, and 2 counts. For a second query it has links at positions 3, 5 and 9, and 3 counts. Average position is (2 + 3) / 2 = 2.5. The other links don't drag the average down, because they never enter the calculation.

Further rules from the same page:

• A link needs an impression for its position to be recorded.
• Ads don't occupy a position.
• Clicks, impressions and position are attributed to the link's canonical address.
• An AI Overview occupies one position, and all links in it get that position; clicks in it count as ordinary clicks.
• In Discover, position isn't recorded.

Google also notes that the same number can mean different things in different situations, and recommends watching changes in position over time, especially sudden jumps, alongside the value itself. How not to be misled by these numbers (for example, when one branded query spreads across several addresses) is covered in our article on SEO and indexing.

How to check your position on Google

In Search Console you do this in the Performance report: filter by query or page and read the position column. Before drawing conclusions, remember the distinction Google's help makes: on the chart, average position refers to the site's top result; in the table, to the specific page or row. That is why the number above the chart and the numbers in the table differ, and both are correct.

A second trap: the queries tab of the table leaves out anonymised queries. If a page has a position but no query in the table accounts for it, that is probably where its traffic comes from (more in the next section).

To separate branded queries from the rest, use a regex filter. In the query or page filter choose "Custom (regex)", or "Doesn't match regex" to exclude. Search Console uses RE2 syntax, matching is partial by default (the expression matches any part of the string, unless you use ^ or $), and it's case-insensitive unless you prefix the expression with (?-i). Separate variants with a pipe and wrap them in parentheses (Search Console help, accessed 4 October 2026). For example, (digital vantage|digitalvantage) with "Doesn't match regex" shows queries without the brand name. The same help page warns that filtering by query or URL can change the totals because of data truncation and the omission of anonymised queries.

Data limits: 16 months, 1,000 rows, and the queries you can't see

Before comparing a report with anything else, check what it leaves out.

History: 16 months. The figure comes from the Google Analytics help page on the Search Console integration: "Search Console keeps data for the last 16 months" (GA4 help, accessed 4 October 2026). To compare longer periods, you have to export the data yourself.

Freshness. According to the help page on data discrepancies, collected data is usually available in 2–3 days, and days (except in the 24-hour view) are counted in Pacific Time (Search Console help, accessed 4 October 2026). In the 24-hour view, the chart's data points are hours and include preliminary data (Search Console help). In GA4, Search Console data appears 48 hours after collection. In the API, the dataState parameter distinguishes final data (final, the default), everything including fresh data (all), and hourly data (hourly_all), with dates counted in Pacific Time (API documentation, updated 11 August 2026, accessed 4 October 2026).

Anonymised queries. These are queries not issued by more than a few dozen users over two to three months. Google always leaves them out of tables but includes them in chart totals, unless you filter by query (Search Central Blog, Daniel Waisberg, 19 October 2022, accessed 4 October 2026). Hence a common "mismatch": the table rows add up to less than the number above the chart.

Aggregation. The chart counts by property: if two of your site's results appear for one query, that is one impression. The table for queries, countries, devices and dates also counts per property, but the table for pages and search appearance counts per page. That's why chart and table totals can differ.

Export. The interface exports at most 1,000 rows; values shown as ~ or - are exported as zero. Through the API and Looker Studio the limit is 50,000 rows per day per site per search type, though, as Google writes, it "may not be reached in all cases" (the 19 October 2022 post cited above). For dimensions that involve neither queries nor pages (country, device, search appearance), Search Console shows and exports all the data.

The page indexing report: statuses in Google's own words

The Page indexing report answers one question: does Google have your page? We give status names exactly as Search Console help prints them (accessed 4 October 2026; the interface and API may show an en dash instead of a hyphen), with our own explanation alongside.

Two statuses are easy to confuse, so we put them side by side:

The first status is about the crawl schedule; the second is a decision taken after Google looked at the page. The help page gives no reason for the second, unlike the duplicate statuses, which name the cause. What to do with pages that were fetched and rejected is covered in our article on SEO and indexing.

Other reasons a page isn't indexed, per the same help page:

• URL marked 'noindex' — the page itself asks to be left out.
• URL blocked by robots.txt — with Google's own caveat that a block "does not guarantee that the page won't be indexed through some other means".
• Soft 404 and Not found (404) — for the latter, Google notes there is no way to tell Googlebot to permanently forget a URL. More in our article on 404 errors.
• Server error (5xx) — covered in our article on server errors; alongside it, Redirect error and blocks from 401, 403 and other 4xx codes.
• Alternate page with proper canonical tag — an alternate page correctly points to the canonical one; "nothing you need to do".
• Duplicate without user-selected canonical — a duplicate with no declared canonical; Google chose another address and won't show this one.
• Duplicate, Google chose different canonical than user — you declared a canonical, but Google considers another address a better one.
• Page with redirect — the address redirects.

Indexed pages can carry two warnings: Indexed, though blocked by robots.txt and Page indexed without content. "URL is unknown to Google" isn't part of this report: it comes from URL Inspection and means Google hasn't seen the address before (help).

Time-saving pointers from the same help page:

• If your site has fewer than 500 pages, "you probably don't need to use this report"; a site: search is enough.
• Don't expect every URL to be indexed, only canonical pages.
• Being indexed doesn't guarantee that a page shows up in results.
• Example-URL lists are capped at 1,000 entries.
• Validating a fix typically takes up to about two weeks, sometimes much longer; an issue leaves the table 90 days after its last occurrence.
• In general, you can only fix issues whose source is "Website".

How long indexing takes, and what to do when a page waits for months, is covered in our article on how long SEO takes.

Our own site in this report: September and October 2026

We checked the index status of every blog post in the sitemap (posts-sitemap.xml) of our Polish site (digitalvantage.pl) twice, on 9 September and 3 October 2026, through the URL Inspection API. Between the two dates we rewrote the blog's content. The figures are shares of the blog posts in the sitemap on each date:

In our data the share of indexed posts doubled, from 20% to 40%. The share fetched but not indexed fell from about half (51%) to under a third (28%). The shares found but not fetched (16% → 17%) and unknown to Google (12% → 14%) did not improve.

That fits Google's definitions from the previous section: rewriting content can change a decision taken after Google has seen a page, but not the crawl schedule, nor whether Google has found the address at all.

Two caveats. First, the denominator changed: in our data the October sitemap held about 12% fewer blog posts, because we redirected merged posts, so part of the shift comes from pruning weak posts, not only from re-evaluation. Second, we already published the September shares in our article on SEO and indexing; the October figures are new.

Indexed doesn't mean visible. From 5 July to 2 October 2026, 12% of the blog posts in the sitemap had at least one impression, against 59% of the sitemap addresses in our resources section (tools, reports, templates). These figures replace the earlier 14% and 54% from 18 June to 15 September 2026. Of the posts indexed on 3 October, 73% had no impressions at all in that 90-day window. A caveat: Google re-fetched many of them after the rewrite, between 20 September and 3 October 2026, so the window mostly measures the old versions.

URL Inspection and requesting indexing: what they do, and what they don't

URL Inspection shows the status of a single page. According to Search Console help (accessed 4 October 2026), the default result is "not a live test": it describes the last indexed version of the page, not the current one. And "URL is on Google" doesn't guarantee that the page appears in results.

When a page "won't index", start with the canonical address. The Page indexing section of the result has two fields side by side:

• User-declared canonical — the address you declared as canonical (with a <link rel="canonical"> tag, an HTTP header, a sitemap or another method). Google says it takes it into account but doesn't guarantee to choose it.
• Google-selected canonical — the address Google chose as canonical among similar pages. If an unexpected address appears here, the help page recommends declaring the canonical explicitly.

If the two fields differ, the page may be fine; a different address is simply the one in the index. That is the situation behind the "Duplicate, Google chose different canonical than user" status (help). The Google-selected canonical shows only in the indexed result; as Google puts it, the live test cannot predict the canonical choice.

The live test has other limits. Google says no test can guarantee that a page gets indexed, and the live test doesn't check for duplicates, compliance with quality and security guidelines, manual actions or removals.

Requesting indexing, per Google's documentation (updated 10 December 2025, accessed 4 October 2026):

• only an owner or a Full user can send one;
• fetching can take "anywhere from a few days to a few weeks";
• it doesn't guarantee that the page appears in results "instantly or even at all";
• there is a quota, but Google doesn't publish the number, and requesting the same address repeatedly won't get it crawled faster;
• for many addresses, a sitemap is the right route;
• for "Crawled - currently not indexed", there is no need to resubmit (help).

Sitemaps in Search Console

You submit a sitemap in the Sitemaps report, but only as a property owner. If you aren't one, list the sitemap in your robots.txt file instead (Search Console help, accessed 4 October 2026).

The report shows four statuses: Success (every address goes into the fetch queue), Has errors, Couldn't fetch and Unknown. "Success" doesn't mean indexed: Google says there is no guarantee that a URL found in a sitemap will be crawled or indexed.

From the same help page: deleting a sitemap from the report doesn't make Google forget it or the URLs in it. The report shows only sitemaps submitted through the report or the API, up to 1,000 submissions. In the Page indexing report you can narrow the view to sitemap pages with the "All submitted pages" filter and compare them with pages outside the sitemap.

The Core Web Vitals report and Search Console Insights

The Core Web Vitals report uses CrUX data, collected from real Chrome users (Search Console help, accessed 4 October 2026). It puts similar pages into URL groups and shows each group's 75th percentile over the last 28 days, separately for mobile and desktop. A group's status is set by its worst metric. Groups without a minimum amount of LCP and CLS data are left out, and "No data available" means a new property or too little data in CrUX. The examples table is limited to 200 rows.

A single URL's result in PageSpeed Insights "might not match" the group result in this report, because PageSpeed Insights usually shows data for individual URLs. How to read that tool's report is covered in our article on PageSpeed Insights; thresholds and what each metric means are in our article on Core Web Vitals.

Search Console Insights, in the new version announced on 30 June 2025, is built into the main Search Console interface and replaces the standalone beta (Search Central Blog, 30 June 2025, accessed 4 October 2026). It shows click and impression trends, top pages and queries, and those trending up or down. According to Google's help, trending items are ordered by the change in the number of clicks, not the percentage change. One card splits traffic into branded and non-branded queries; the classification is done by AI, may mislabel queries, and isn't available for sub-properties or sites with few impressions. The report is being introduced gradually and may not be available to everyone. If you don't have it, or don't trust it, the regex filter described earlier gives you the same split on your own terms.

The Search Console API: when the interface stops being enough

The interface is fine for one-off questions. To check hundreds of addresses or keep more than 16 months of history, you need the API. Limits per Google's documentation (updated 28 August 2025, accessed 4 October 2026):

• Search Analytics API (Performance report data): 1,200 queries per minute per site and 1,200 per user, 30,000,000 per day and 40,000 per minute per project, plus short-term and daily load limits. Queries grouped or filtered by both page and query are the most expensive.
• URL Inspection API: 2,000 queries per day and 600 per minute per site.

The URL Inspection API shows index status only for the version in Google's index. It has no live test and no indexing request, so neither can be automated. The 2,000-per-day limit applies to the API, not to the button in the interface. We collected the data for the section on our own site this way, pacing calls to stay within these limits.

What to check, and how often

A routine that follows directly from Google's documentation:

• Day to day, rely on Search Console's emails about new issues; daily logins aren't necessary.
• Once a month, and after every content change, open the Performance report and compare periods.
• After a deployment, check the Page indexing report and run changed addresses through URL Inspection, starting with the canonical fields.
• Read position as a change over time, not a single reading.

To go through a site yourself, step by step, use our website audit checklist.