Google Search Console: How to Read the Reports Correctly

1. The Basics

Google Search Console is a free service from Google that reports what Google's own systems did with your website: which pages it found, which ones it crawled, which ones it put in the index, and how often those pages appeared in search results.

Two things make it different from every other tool in your stack. First, it is the only place Google speaks about your site directly. Every other SEO tool guesses at Google's behaviour from the outside by running searches and watching results. Search Console reports it from the inside. Second, and this is where most misreadings begin, it is not an analytics tool. It does not measure your visitors. It measures Google.

The free tool everyone has and almost nobody reads correctly. It does not tell you how good your website is. It tells you what Google did with it, which is a very different thing.

This article starts with the simplest question you can ask the tool "is this page on Google?" and builds up to the reporting API and the BigQuery export. Along the way it takes apart the three reports people misread most: why "average position" hides almost everything, why the totals never match the table, and why "Discovered - currently not indexed" is a statement about your server rather than a verdict on your content.

The right mental model: Search Console does not measure your website. It measures Google's relationship with your website. Every report answers the question "what did Google do?", never the question "how good is this page?".

1.1 What It Is Not

Getting the negatives right saves months of confusion:

• It is not analytics. A click in Search Console is a click from a Google search result. It knows nothing about visitors who arrived from a newsletter, a link, or by typing your address.
• It is not a tracker. It places no script and no cookie on your site, and it never sees your visitors. Section 7.3 explains why that removes it from the cookie banner entirely.
• It is not a ranking tool. There is no report that says "you rank fourth for this word". Position is an average over impressions, which is a different and much weaker statement.
• It is not real time. Google states that collected data "should be available in 2-3 days". A drop you see today happened earlier this week.
• It is not Google Search. Search Console covers Google only. Bing, DuckDuckGo, and any AI assistant reading your pages are invisible here.

1.2 Crawling, Indexing, and Serving Are Three Different Things

Nearly every confusing report in this tool becomes readable once you separate three stages that most people collapse into the single word "SEO". Google describes its own system in exactly these three steps, and says plainly that not all pages make it through each stage.

Two things happen inside those stages that are worth naming, because both cause problems people misfile. Rendering belongs to crawling: Google runs the page in Chrome, because sites often rely on JavaScript to put content on the page, and without rendering Google might not see it. Canonicalisation belongs to indexing: Google groups pages it treats as duplicates and picks the one most representative of the group, and the rest become alternate versions.

Each stage fails in its own way, and each failure appears in a different report:

never crawled        →  Pages report:  Discovered - currently not indexed
crawled, not kept    →  Pages report:  Crawled - currently not indexed
indexed, not shown   →  Performance:   indexed but zero impressions
shown, not clicked   →  Performance:   impressions but no clicks

This is the single most useful habit in the whole article: name the stage before you look for a cause. A page with impressions and no clicks has passed all three stages, and no amount of work on crawling or indexing will move it. A page stuck at the first stage cannot be rescued by rewriting its content. Section 6.5 turns this into a checklist.

1.3 Properties: The Two Kinds

Before any report makes sense, you need to know which slice of your site you are looking at. Search Console calls that slice a property, and there are two kinds.

Domain properties arrived in 2019 and solved a real problem: before them, a site that answered on four address variants needed four properties and had its data split four ways. If you are starting today, verify a domain property. Use URL-prefix properties in addition when you genuinely want a subdirectory reported separately, for example one language folder or one shop section.

1.4 What Verification Actually Proves

Verification is often treated as a formality. It is worth understanding what it means, because it explains the tool's whole permission model.

Every verification method asks you to do something that only a person with control over the site or the domain can do: place a file in the web root, add a tag to the HTML that is served, or publish a DNS record. Google then checks that the thing is there.

So verification proves control, not ownership. Nobody at Google checks a contract or a registration. This is why the check is repeated: if the file or the record disappears, the property loses verification and the data goes with it. It also explains why a DNS record is the only method a domain property accepts. A domain property makes claims about every subdomain, and the only thing that demonstrates control over every subdomain is control of the zone itself.

3. A Short History

Search Console is one of the oldest continuously running products Google has, and its shape today is the result of a long argument between what site owners want to know and what Google is willing to say.

Two moments in that table matter more than the rest.

The 2018 rebuild extended history from 90 days to 16 months. That sounds like a storage decision and is actually analytical: 16 months is the shortest window that lets you compare a month against the same month a year earlier. Below 16 months you cannot separate a seasonal dip from a real decline, and every year-on-year question was guesswork.

The 2023 BigQuery export matters because until then every route into the data - the screen, the export button, even the API - was capped and sampled. Section 6 covers what that changed.

5. Moderate Use Cases

5.1 Filtering and Comparing

The Performance report is only useful once you stop looking at the default view. Every dimension across the top - Queries, Pages, Countries, Devices, Search Appearance, Dates - is both a tab and a filter, and filters combine.

The comparison mode is the part worth learning. Comparing a period against the previous period answers "is this changing?" Comparing against the same period one year earlier answers "is this changing for a reason other than the season?". For any site with a seasonal pattern, the second question is the only honest one, and it is the reason the 16-month window exists.

5.2 The Pivot That Answers Real Questions

The single most useful move in the interface: filter to one page, then switch to the Queries tab.

Pages tab       → click /guides/dns-explained
Queries tab     → now shows only the queries that produced
                  impressions for THAT page

This inverts the report. Instead of "what does my site rank for", you get "what does Google think this page is about". The two often disagree, and the disagreement is the finding. A page written about one subject that collects impressions for a different subject is telling you which words on it are doing the work.

5.3 Finding the Pages That Almost Rank

A repeatable exercise that needs no external tool. Filter the Queries tab to a position between 8 and 20, and sort by impressions.

Those queries have two properties at once: Google already considers your page relevant enough to show, and almost nobody sees it. Because that range spans the bottom of page one and the top of page two. The cost of moving a result from position 12 to position 8 is far lower than the cost of creating a page that ranks from nothing.

Add a low CTR filter, and you get a second, cheaper list: queries where you rank well but the result is not attractive enough to click. That is usually a title and description problem rather than a content problem, and it is fixable in minutes.

5.4 Exporting, and Why the Export Is Bigger Than the Screen

The export button offers CSV, Excel, and Google Sheets. It is worth using even when the screen seems to show what you need, because the screen is capped.

Google is direct about this: "Our tables can show a maximum of 1,000 rows, so some rows might be omitted." That cap applies per table, and it is the reason a site with thousands of ranking queries always seems to have exactly 1,000 of them.

Anything requiring arithmetic across more than 1,000 rows needs the export, and anything requiring the complete set needs the API or the BigQuery export in section 6.

5.5 The Core Web Vitals Report

The Core Web Vitals report is the one part of Search Console that reports on your visitors rather than on Google. It does not run a test. It comes from the CrUX report (short for Chrome User Experience Report), which collects anonymised timings from real Chrome users who visited your pages - what the industry calls field data.

Three metrics, each with a good and a poor threshold:

Two mechanics explain almost every confusing thing about this report.

First, the number shown is the 75th percentile over the last 28 days: 75% of page requests were this fast or faster. So a fix deployed today cannot show up today. It has to work its way through a 28-day window, and the report will keep reporting the old experience for weeks while doing nothing wrong.

Second, URLs are grouped by similar experience rather than listed individually, and a group needs a minimum amount of traffic before it can be reported at all. When there is not enough data, Search Console falls back to an origin-level group in the form protocol://host:port. This is why a small site often sees one row covering everything, and why the example URLs in a group are examples rather than the full list.

A group takes the status of its worst metric. One bad CLS score marks the whole group poor even when LCP and INP are fine.

5.6 The Two Reports You Hope Stay Empty

Two reports differ from everything else in Search Console: they are the only places where Google tells you that a human being made a decision about your site.

Manual actions. Google's definition is direct: "Google issues a manual action against a site when a human reviewer at Google has determined that pages on the site are not compliant with Google's spam policies." So is the consequence: "If a site has a manual action, some or all of that site will not be shown in Google search results." When you have fixed the cause, you select Request Review in the report and describe what you changed. Google says review can take several days or weeks.

Security issues. A separate report for a separate problem: hacking, malware, and injected spam pages. This is not about breaking Google's rules, it is about somebody else having broken into your site. It is often the fastest warning you will get that a site is compromised, because it can appear before anything looks wrong to a visitor.

Now the part that matters more than either report, and it is the reason to look at them early rather than late. An empty manual actions report does not mean Google approves of your site. The overwhelming majority of ranking losses are algorithmic, and an algorithmic demotion produces no manual action, no message, no report, and no notification anywhere in this product. If your traffic fell and this report shows a green tick, then the cause is not a penalty. People lose weeks hunting for a punishment that was never issued.

5.7 Moving a Site: the Change of Address Tool

When a site moves to a new domain, Search Console has a tool that "tells Google about your change, and helps to migrate your Google Search results from your old site to your new site". It is worth knowing precisely what it needs and what it refuses to do, because a migration is the moment this tool matters most.

It requires you to be a verified owner of both the old and the new property, under the same Google account, and it works at domain level only.

The number to write down: Google forwards signals "for 180 days after you start migration in Search Console". That is the floor for how long your redirects must stay up. Remove them earlier and you throw away the migration; after that window Google treats the two sites as unrelated.

What it will not do, and each of these catches somebody:

• It does not apply to an http to https move.
• It does not handle www to non-www on the same domain.
• It cannot migrate a path-level move inside one domain.
• It does not move subdomains for you; each is migrated separately.
• It does not clear the old site: "Google does not erase the old site from the index, and URLs from the old site can continue to be shown in Search results".

The tool is a signal, not a switch. Server-side redirects still do the actual work.

7. Something Most Users Do Not Know

7.1 Average Position Is an Average of Averages

Position is the most quoted number in Search Console and the least trustworthy. Google's definition: the topmost position of a link to your property, averaged across all queries.

Consider two pages that both report an average position of 5.5.

Page A     ranks 5 or 6 for every one of its 40 queries
           average 5.5   → genuinely a page-one result

Page B     ranks 1 for 20 queries, ranks 10 for 20 queries
           average 5.5   → not a page-one result for anything;
                             two different behaviours, averaged
                             into a number matching neither

The average is the same. The situations have nothing in common, and they need opposite responses. Page A needs a small push. Page B needs its twenty weak queries examined, because the strong twenty are already winning and are hiding them.

There is a second trap inside the same number. Because position averages over impressions, a page that stops appearing for its worst queries shows an average position that improves while traffic falls. Position going up and clicks going down at the same time is not a paradox and not a bug. It usually means you lost the long tail.

Never read an average position without impressions next to it. On its own it is a statistic with no defensible meaning, and it moves for reasons that have nothing to do with ranking better.

7.2 Anonymised Queries, and Why the Totals Never Match

Add up every row of the query table, and you get a smaller number than the total on the chart above it. This is not rounding, and it is not a bug.

Google does not show queries made a tiny number of times, or queries containing personal or sensitive information. These are anonymised queries, and they exist to protect the person who typed them: a search rare enough to identify someone must not be handed to a website owner.

The mechanics are precise and worth memorising:

• Anonymised queries are always omitted from the table.
• They are included in the chart totals - unless you filter by query, at which point they drop out of the totals too.
• So filtering by query silently changes the number at the top of the page.

Here is the part that surprises even experienced users. The BigQuery export includes a field the interface has no way to show:

is_anonymized_query      "Rare queries (called anonymized queries) are marked
                          with this bool. The query field will be null when
                          it's true to protect the privacy of users making
                          the query."

is_anonymized_discover   the same threshold applied to Discover, where URL
                          and country are dropped as well

You still cannot read the anonymised queries. But you can count them, and count their clicks. For most content sites this is a large and completely unexamined share of traffic, and the export is the only place where its size can be measured at all.

7.3 It Sets No Cookies, So There Is Nothing to Consent To

European site owners spend real effort on cookie banners, consent records, and processing agreements. Search Console needs none of it. The reason is worth understanding rather than simply accepting, because it is the sharpest illustration of what this tool actually is.

Compare the direction the data travels.

GOOGLE ANALYTICS
  your visitor  →  script on YOUR page  →  Google
                you place the tracker, you set the cookie,
                you send Google data about a person

GOOGLE SEARCH CONSOLE
  google.com    →  Google's own logs    →  you
                you place nothing, you set no cookie,
                Google sends YOU aggregated counts

Four of the six verification methods put something completely inert on your site: a text file in the web root, a <meta> tag in the <head>, or a DNS record. None of them runs any code. A meta tag is markup that a browser reads and ignores; it cannot set a cookie or observe anything, and a DNS record never reaches the visitor at all.

The data you get back never touched your website. It is Google's record of what happened on google.com. Google is the controller of that record, gathered from its own users under its own privacy policy, and you receive a summary of it. You are not sending Google anything about your visitors, so there is nothing for a visitor to agree to.

This is also the point of the anonymisation in section 7.2. Google removes rare queries, and queries containing personal or sensitive information, before the data ever reaches you. The identifying detail is stripped on Google's side. That is why the totals never add up, and it is the same mechanism that keeps what you receive aggregated rather than personal.

Analytics measures your visitors and needs their consent. Search Console measures Google and needs nobody's. That difference is not a policy Google chose to be generous; it follows from which direction the data travels.

There is one exception, and it is not really an exception. Two of the six verification methods are Google Analytics and Google Tag Manager: if either is already on your site, Search Console will accept it as proof of control. Those two do collect visitor data - but they were doing that before Search Console was involved, and they carry their own obligations either way. Verifying with them adds nothing new to disclose. Verifying with a DNS record avoids the question completely, which is one more reason to prefer it.

One report deserves a closer look, because it does describe real people: Core Web Vitals. Those timings come from actual Chrome users. But Chrome collects them, from its own users, under Google's terms - nothing on your site gathers them. They reach you as a percentile across a group of URLs, never as a person, and a group is only reported once it has enough traffic to hide the individuals inside it.

The practical result is unusual for a Google product: Search Console adds nothing to your cookie banner, nothing to your consent records, and nothing to the list of things your privacy policy has to declare about tracking visitors. It is one of the few tools you can put on a website without changing anything a visitor is asked to agree to.

7.4 "Discovered - Currently Not Indexed" Is About Your Server

This label causes more unnecessary content rewriting than anything else in the product because it is read as "Google saw your page and judged it too weak". That is not what it says.

Google's own definition: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore, Google rescheduled the crawl."

Google never fetched the page. It cannot have an opinion about the content because it has not read it. The sentence is about crawl capacity: Google estimated that fetching this URL would put too much load on your server, so it queued it for later.

Compare it with the label immediately next to it, which is the one that is a content signal: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling."

If the "Discovered" group is large and growing, the useful question is not "is my content good enough" but "what is consuming the crawling Google is willing to spend here". On a big site the usual answers are structural: faceted navigation and filter combinations generating an effectively unlimited URL space, calendars that go on for ever, session identifiers and tracking parameters creating a new URL for every visit, internal search-result pages, long redirect chains, and repeated 5xx or 429 responses that teach Google to back off. Slow responses make all of it worse, because a slower site earns fewer fetches.

Getting these two the wrong way round wastes months. A large and growing "Discovered" group on a slow site is a hosting and crawl-budget problem, and rewriting the pages will not move it. Note the last line of the "Crawled" definition too: "no need to resubmit this URL for crawling". Resubmitting is the first thing most people try, and Google says plainly that it does nothing.

7.5 Knowing Where Search Console Stops

Good tools have edges. These are the ones that matter:

• It stops at Google. Bing has its own Webmaster Tools, with its own index and its own crawler. An AI assistant fetching your pages appears in neither.
• It stops at what Google chose to tell you. Sampled reports, 1,000-row tables, anonymised queries. Your server log has every request Googlebot ever made, with no cap and no sampling - it is the only complete record of crawling that exists, and it is on your own disk. One warning before you trust it: a user agent string can be spoofed, and plenty of traffic calls itself Googlebot without being Googlebot. Google's documented check is a reverse DNS lookup on the IP, confirming the name ends in googlebot.com, google.com, or googleusercontent.com, then a forward lookup on that name to confirm it resolves back to the same IP. Google also publishes its crawler ranges as JSON at https://www.gstatic.com/ipranges/, including common-crawlers.json.
• It stops at your verified property. It says nothing about competitors. Every tool claiming to show a competitor's search data is estimating from the outside. The one question you can still ask about a site you do not own is a site: search (section 4.1), and it answers only the yes half.
• It stops at field data. Core Web Vitals reports what real visitors experienced over 28 days. To find out why a page is slow you need a lab tool - Lighthouse, WebPageTest, or browser developer tools - which measures a single controlled load and can point at the specific asset.
• It stops at describing. Search Console diagnoses; it does not fix. Every repair happens in your own templates, server configuration, or content.

9. Common Mistakes

9.1 Nine Myths

9.2 Other Traps to Avoid

• Comparing a URL-prefix property with a domain property and calling the difference a traffic drop. They cover different sets of URLs.
• Panicking at the last three days of any graph. Recent data is incomplete and always slopes downward.
• Filtering by query and then reading the total. That filter removes anonymised queries from the total as well, so the number changes for a reason that has nothing to do with your filter.
• Treating the sitemap "Success" message as an indexing confirmation. It confirms the file parsed.
• Requesting indexing repeatedly for the same URL. Google states plainly there is no need to resubmit, and repeating it changes nothing.
• Using the temporary removals tool to hide a page permanently. It hides results for about six months. To remove a page, delete it or mark it noindex.
• Verifying with Google Analytics or Tag Manager out of convenience. It works, but it ties your Search Console access to a tracker that may be removed or blocked by a consent choice. A DNS record depends on nothing and keeps the property free of any visitor-facing component.
• Letting verification lapse. Remove the DNS record or the HTML file during a migration, and the property unverifies, taking the reports with it at exactly the moment you need them.
• Assuming the property is the whole site. A domain property covers every subdomain; a URL-prefix property covers one prefix, and www and non-www are different prefixes.