How to Read a Search Console Report

What the console is actually a record of

Search Console is the least interesting screen in a marketing stack and the one most often read wrongly. There is no dashboard flourish, the charts are plain, and every figure invites a conclusion. A site owner opens it in April, sees clicks down by a fifth and concludes the content plan failed. A developer opens the same screen, sees a page sitting in the discovered-but-not-indexed state and concludes the domain has been blocked. Both conclusions come from the same habit: reading a summary number without knowing what went into it.

So this is a guide to reading the reports in the order a working team reads them, and more usefully to the places where the tool tells you less than it appears to. At SmartEdge IT Solutions the console is usually the first document requested in a full website audit, because the gap between what a site thinks it has published and what Google has recorded is frequently the first real finding.

Two things to establish before touching any numbers. First, the property: domain properties cover all URL variants, prefix properties cover a single scheme and host, and the console treats them as separate datasets. An audit built on the wrong property can look thorough while describing a site nobody uses. Second, the date range and the range it is compared against, because the tool will cheerfully compare a good fortnight with a bad one and present the result as a trend.

One habit worth adopting early, because it costs nothing: compare the same period against the same period rather than against the last one. Day of week and seasonality both sit inside a month-to-month comparison.

Performance: read the four columns out of order

The Performance report gives you impressions, clicks, click-through rate and average position, filterable by search type, country, device and page. The instinct is to read left to right. Do not. Impressions first, because it tells you whether the other three mean anything at all.

Impressions count the times one of your pages appeared on a results page for the queries you then filter down to. When that number falls there are only three explanations worth checking: the demand changed, your positions moved, or Google decided to show fewer of your results for reasons you cannot see from here. Clicks sit downstream of all three. A clicks figure with no impressions line beneath it cannot be interpreted.

Average position is a distribution, not an address

This is the most quoted and least understood figure in search reporting. It is the arithmetic mean of every impression a page received, and a mean destroys the shape of the data. A page ranking first for one high-volume query and nineteenth for forty small ones reports an average around position ten. Nothing is at position ten. It has one win and a tail sitting just under the fold.

The same distortion in the other direction is more common and more expensive. Hundreds of impressions in positions eleven to twenty, almost none above, an average of fifteen, and very little traffic behind it. Anyone reading only that summary row concludes the site is nearly there and stops. In practice the most reliable gain available to a mid-ranking site is not new keywords at all — it is taking a defined set of existing queries, on a defined set of pages, out of the second band and into the first. Decide that from the query and page filters, never from the summary.

Position data is bucketed and rounded, with the leading positions compressed together, so the difference between fourth and sixth is invisible. Daily figures also move around, so treat small changes in average position as noise unless clicks confirm them over a longer window.

Click-through rate describes the result, not the ranking

A low click-through rate on page one means the result did not earn the click. The title, the description and the surrounding context in the results page are what the searcher read before deciding. It does not mean the page is poor, and it certainly does not mean the page should go.

The comparison worth doing is click-through within a position band. Filter by query, sort by impressions, then compare your rate against pages already ranking for similar intent in the same band. Sitting at position four with a fraction of a competitor’s click-through at position four is a snippet problem, and it is cheap to test: rewrite the title and description, wait, compare. If every page in that band has a low rate, the band is the constraint and you need position rather than copy.

Split by device while the report is open. Mobile and desktop rates for the same URL often diverge sharply, because a title written for a wide desktop ribbon can be truncated to nothing on a phone. Filter by search type too: short video results can take a disproportionate share of impressions in some verticals and convert at a fraction of the rate, dragging down a page’s overall figure for reasons that have nothing to do with the page.

Indexing: the states worth acting on

These reports have been renamed and reorganised more than once, which is why older notes and internal documents go stale so quickly. They sit under Indexing now, covering Page Indexing, Sitemaps, URL Inspection and Crawl Stats. The underlying states are the familiar ones, and four of them are worth distinguishing.

• Crawled, currently not indexed — Google fetched the page and decided not to keep it, usually because it looks too much like pages already in the index. Consolidate rather than rewrite.
• Discovered, currently not indexed — Google has the URL from your sitemap or your links but has not fetched it, typically because other URLs on the site look more worth having.
• Duplicate without user-selected canonical and alternate page with proper canonical tag — both normal in the reporting sense, and neither should be chased.
• Cancelled, or a run of soft 404s — act here. These consume crawl attention on URLs that will never rank and never should.

Fix the template, not the list of URLs. The usual sources are unbounded faceted navigation, internal search results, calendar and tag pages that stay empty until somebody visits them, and paginated archives that add nothing a crawler has not already seen. Each one is a trap spending attention that your real pages need. Where the trap lives in a template, the fix is a release rather than a page edit — which is why a crawl budget question belongs in DevOps and release planning instead of in a content task list.

Core Web Vitals: field data against lab data

The experience report shows Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift on real user devices, alongside a separate lab section based on simulated conditions. Treat them differently. The lab figure is a diagnosis; the field figure is the fact.

A page can pass every lab check and still fail in the field, because the expensive thing only happens on a mid-range Android phone with a cold cache. Field data also comes from real visitors, so a site with modest traffic may have too few samples in a given period to conclude anything. That is a waiting problem, not permission to guess.

Read the distribution rather than the middle. The chart does not present a simple average, and the worst quarter of sessions is often where the business is being lost. Interaction to Next Paint only exists in field data at all, because it needs genuine interaction to measure.

Where the field figure is poor, the work usually starts with third-party script weight: tag managers loading several vendors in sequence, chat widgets placed above the fold, consent tooling that injects itself late and shifts the layout. Cutting those is cheap, measurable and reversible. Images and fonts come after that, then the server side, where time to first byte and response under load are the two numbers a developer can actually move. Those belong in custom web application work or a hosting review, not in a design review.

The enhancement panels, ordered by business consequence

Structured data validity, mobile usability, HTTPS status and appearance in AI surfaces each have their own panel, and most are a red or green box with a number attached. Sort by consequence rather than by how alarming the colour looks.

Structured data is the one that changes what can appear beside your result, so it earns its place near the top for product pages, articles, FAQs and organisation details. Appearance in AI surfaces reflects how your content is retrieved and quoted, which is a different problem from ranking and a different set of decisions — we cover that separately under answer engine optimisation and generative engine optimisation.

Mobile usability is worth reading only where it lists specific broken interactions. On most sites the count is a handful of elements and the fix is small. Do it, but do not let it delay the page above it.

The panels nobody opens

Links, manual actions and security issues live where nobody looks, and two of them can invalidate everything else on screen.

Manual Actions is empty on a healthy site, which is exactly why it stays collapsed. When a notice is present, visibility can be partial or heavily reduced while it stands, and recovery after the fix takes weeks rather than days. Security Issues reports compromise or harmful-content signals, and usually arrives alongside a domain-wide drop in impressions. Check both on the first day of any audit. Ten seconds each, and they reorder the whole plan.

The Links reports deserve more caution than they usually get. The external and internal tables are a sample, not a census; a genuine link can be absent for months while one new link dominates the top pages list. Use them for direction. The per-page drill-down showing which internal pages link to which is genuinely useful, and it is the section most teams get real value from, because it tells you which of your target pages have almost nothing pointing at them — frequently the cheapest ranking work available.

Do not build an outreach plan from that table. It describes where links already exist and says nothing about where they are needed, and the second question is a decision about the pages you are trying to move.

Turning the console into a worklist

A report earns its place only when it produces decisions with an owner and a date. Here is a shape that holds up.

1. List the pages with the most impressions in positions four to twenty. Open each in the URL Inspection tool to confirm it is indexed and self-referencing canonical. Twenty URLs is a reasonable month of work.
2. Group them by intent. Pages chasing the same intent compete with each other. Consolidating two thin pages into one strong page often beats optimising both, and the data can support that argument because it shows the impressions going to two URLs instead of one.
3. Take the queries with high impressions and low click-through. Pair each with a page already performing well in that band. The pairing produces a specific change to test rather than a general instruction to improve the content.
4. Check your own click-through curve by position. If you sit below the pages above you at every band, the problem is the result snippet and your category metadata rather than the page. That is technical search engine optimisation work, and it usually shows up within the first month of looking.
5. Annotate every release. The console lets you mark changes on the timeline. A deployment, a migration, a template change and a new tag container all move these numbers without any change in content quality.

Then read it twice at fixed intervals, by the same person. Search reporting only becomes useful when it is a repeated comparison rather than a reaction to a bad week.

Questions worth settling before you quote the numbers

Does this console measure the channel the business depends on? It covers organic search only. Where email, social, direct referral or paid search carry the commercial load, this is one input among several, and reading it as the whole answer is a common and expensive error.

How long is the window, and does it cross a seasonal boundary? Four weeks compared month on month will mislead you in almost any business with a cycle to it. Comparing the same weeks year on year is steadier, if the history exists.

What else changed on the site? If nobody can answer, the numbers will be read as evidence about content quality when they are mostly evidence about a release.

And which properties does the export cover, in writing? Access levels differ between properties, an agency may hold delegated access to some and not others, and a report built on a partial view produces confident conclusions about the wrong site. Confirming that is part of the audit rather than an afterthought, and it is why we document the data sources alongside the findings at SmartEdge IT Solutions.