Google Search Console guide: 7 reports, 7 decisions

Google Search Console is the free tool Google offers site owners, and the only one that shows how your site appears in search using Google's own data. Even so, most accounts look only at the clicks chart while the remaining reports sit unopened. This guide is not a report-by-report manual of Google Search Console; it is a reading order that pairs each report with a single decision. We picked seven reports because, in practice, these are the ones that produce decisions in a monthly SEO meeting. The aim is to move from "we have data but don't know what to do" to "this report drives this decision". We covered report screenshots and moving them into a dashboard separately, in Looker Studio SEO dashboard.

What Google Search Console is, and what it is not

The short answer to "what is Search Console": a service that reports how Google crawls, indexes and displays your site in search results, accessible only to a verified site owner. Google's own help page summarises its function under four headings: confirming that Google can find and crawl the site, fixing indexing problems and requesting re-indexing, viewing search traffic data, and receiving alerts about indexing, spam or security issues. What it is not matters just as much: Search Console is not an analytics tool; it shows what happens in search, not what happens on your site. What a user does after landing on your site is GA4's story. Reading both data sources in one dashboard is one of the core jobs of our analytics and data service; in this article we stay on the Search Console side only.

Report 1: Performance, decision: which pages to grow

The Performance report gives clicks, impressions, click-through rate and average position across the query, page, country, device and search appearance dimensions. The default view shows the last three months; for decisions, use compare mode rather than that view. The report drives two decisions. First: pages with high impressions and low click-through rate. These pages appear in search but are not chosen; there is title and meta description work to do. Second: queries with an average position between 8 and 20. These sit at the threshold of the first page and are the group where a content refresh or internal links pay off fastest. Watch the trap when reading average position: the report takes the position of the topmost result from your site; a broad page appearing for many queries can show a low average without being a failure. If you will compare year over year, export the data regularly; the report keeps history for a limited time.

Report 2: Page indexing, decision: what to fix and what to leave

The Page indexing report splits your URLs into "indexed" and "not indexed", and groups the latter by reason: server error, redirect error, blocked by robots.txt, noindex tag, soft 404, not found, "crawled, currently not indexed", "discovered, currently not indexed", canonical differences. The decision here is not to fix every reason. A share of the reasons are your own choices: filter pages consolidating under a canonical or old campaign pages being noindex is normal. The group that needs fixing is pages you do want indexed piling up under "crawled, not indexed" or soft 404; this usually points to thin content or a template problem. We laid out the flow for reading the report and finding the root cause step by step in indexing problems.

Report 3: URL Inspection, decision: assumption or proof

The URL Inspection tool does two things for a single page: it shows the version in Google's index, and the live test checks whether the page is indexable right now. The decision point is this: stop answering "was the problem fixed" with "probably". After making the fix, run the live test, record the result and request indexing. Google's help page states plainly that there is a daily limit on inspections and indexing requests, and that submitting a sitemap is the right route for many pages; use the tool for proof, not for batch work.

Report 4: Sitemaps, decision: does Google see your site the way you do

The Sitemaps report shows, for every sitemap you submit, the number of discovered URLs and any read errors. The decision here is a comparison: how big is the gap between the URLs in the sitemap and the URLs indexed? If the gap is large, the problem is in one of two places: the sitemap contains unnecessary URLs, or Google finds the submitted pages low in value. On multilingual sites it is also critical that the sitemap carries the correct URLs for each locale; a wrong locale entry both burns crawl budget and pollutes the indexing report.

Report 5: Core Web Vitals, decision: is speed work really a priority

The Core Web Vitals report takes its data from CrUX, meaning real Chrome users, not from lab tests. That distinction matters for the decision: a page that looks red in Lighthouse can be green for real users, and vice versa. The report answers the question "should we do speed work at all". If the page groups are "good", turn your resources to content and indexing problems instead. If there are "poor" groups, look at which template they come from; the problem usually concentrates in a single template. We explained the difference between the three tools in site speed test.

Report 6: Links, decision: is the internal linking architecture working

The Links report shows, as a sample, your most linked pages, the sites linking to you most, the anchor texts and the internal link distribution; Google notes that this is a sample, not a complete list. The external part is interesting for most businesses, but the real decision sits in the internal links table. Where does your most important service page rank in internal links? If newly published content receives no internal links at all, your blog is not feeding your service pages. This table is the cheapest check of whether your content calendar connects to your service pages.

Report 7: Manual actions and security, decision: stop everything or not

The Manual actions report lists cases where a human reviewer at Google has decided your site violates the spam policies; the result is pages being demoted or removed from results. This report should be empty, and on most sites it is. If it is not, the decision is clear: set the other six reports aside; fix the violation first, then submit a reconsideration request. The same rule applies to the Security issues report. Checking these two reports once a month should be the first item on the monthly meeting agenda.

Tying seven reports to one agenda

For this order to work, read the reports in sequence rather than one by one: manual actions and security first, then indexing and sitemaps, then performance, and Core Web Vitals and links last. The order is not random; you ask first whether the site exists in search, then how many of its pages are visible, then what the visible pages earn. On the technical side, finding the root causes the reports point to and proving the fix is the core of our technical SEO service. If you are unsure what to look for in which report, writing these seven reports and their matching decisions on one page and carrying it into the monthly meeting as the agenda is the fastest start for most businesses.

Sources

• About Search Console — Search Console Help
• Performance report (Search results) — Search Console Help
• Page indexing report — Search Console Help
• URL Inspection tool — Search Console Help
• Core Web Vitals report — Search Console Help
• Links report — Search Console Help
• Manual actions report — Search Console Help