Google Search Console: Advanced Report Analysis Guide

Most people use Search Console as a dashboard: open it, look at the clicks line, close it. The value is in the reports one level down, and in combining filters to answer specific questions. Why did traffic drop on one section? Which pages does Google refuse to index, and why? Is Googlebot struggling with the server?

This guide covers the reports we rely on in every audit and the exact filters we use. Everything here is available in the current Search Console interface.

Performance: beyond the default view

The Performance report shows clicks, impressions, CTR and average position for Google Search, with up to 16 months of history. The default view (last three months, web search, all queries) hides most of what is useful.

Know what the numbers mean

Before filtering, be clear on three definitions:

• Impressions count each time a link to your site appears in a results page a user loaded. For most result types, the user does not need to scroll it into view.
• Average position is the average of the topmost position your site held for each query, weighted by impressions. A page ranking 3rd for one query and 40th for another can average out to a meaningless number. Always segment before reading position.
• Anonymized queries are hidden for privacy. The chart totals include them, but the Queries table does not, so the table rows will not add up to the total. This is expected.

The UI table shows a maximum of 1,000 rows. For larger sites, use the Search Console API or the bulk data export to BigQuery, both of which give you far more rows.

Regex filters

The Query and Page filters accept regular expressions. Click Add filter, choose Query or Page, then select Custom (regex) and choose "Matches regex" or "Doesn't match regex". Search Console uses RE2 syntax, which supports most common patterns but not lookaheads or backreferences.

Questions people ask, useful for finding FAQ and guide opportunities:

^(who|what|when|where|why|how|which|can|does|is|are|should)\b

Long-tail queries of six words or more:

^(\S+\s+){5,}\S+$

Non-brand queries, using "Doesn't match regex" (adjust for your brand and its common misspellings):

(?i)octane ?audit|octan audit|octaneaudt

Comparison and alternative intent:

(?i)\b(vs|versus|alternative|alternatives|compare|comparison)\b

The (?i) prefix makes the match case-insensitive. Query text in Search Console is usually lowercase, but it does no harm to include it.

For the Page filter, match sections of the site:

^https://www\.example\.com/(blog|guides)/

Or exclude parameters and paginated URLs to see only clean pages:

\?|/page/[0-9]+/?$

with "Doesn't match regex".

Compare mode for diagnosing drops

Click the date filter, choose Compare, and select the period after a drop against the same-length period before it. Then work through the tabs:

1. Pages tab, sorted by click difference. Is the drop concentrated on a few URLs or spread across the site? Concentrated usually means a page-level problem (lost ranking, changed content, indexing issue). Spread out usually means a sitewide factor (algorithm update, technical change, seasonality).
2. Queries tab for the worst pages. Did the page lose impressions (ranking or demand fell) or only CTR (a SERP change, such as a new feature above your result)?
3. Countries and Devices. A drop limited to mobile points toward mobile rendering or performance issues.
4. Search appearance. A drop in rich result impressions often follows broken or removed structured data.

Compare against the same period last year as well. A 20% drop from November to January means something very different for a retailer than for a B2B software site.

Finding cannibalization

Filter Query to a single important search term using Exact query, then open the Pages tab. If several of your URLs share the impressions and none holds a strong position, they may be competing with each other. Consolidate them, differentiate their intent, or make the preferred one clearly stronger through internal links and canonicals.

Page indexing: why pages are not in Google

The Page indexing report (under Indexing) splits known URLs into Indexed and Not indexed, with a reason for each non-indexed group. The reasons are the useful part.

Several of these are normal. Every site has redirected URLs and correctly canonicalized alternates. The question is whether the URLs in each group are the ones you expect.

Filter by sitemap

The most underused control in this report is the dropdown at the top: All known pages, All submitted pages, Unsubmitted pages only, or a specific sitemap. Selecting your sitemap shows indexing status only for URLs you told Google matter.

If your product sitemap has 12,000 URLs and 4,000 are "Crawled - currently not indexed", that is a real problem. If those 4,000 are filter URLs not in any sitemap, it is probably noise. Split sitemaps by template (products, categories, articles) so this view tells you which template has the problem.

Validate fixes

After fixing an issue, open the reason and click Validate fix. Google re-checks the affected URLs and reports progress. Validation can take days to weeks, so while you wait, confirm a few fixed pages directly with URL Inspection.

For the difference between noindex, robots.txt and nofollow and why combining them goes wrong, see robots.txt vs noindex vs nofollow.

Crawl stats: how Googlebot experiences your server

Crawl stats is not in the main menu. Go to Settings, then Crawl stats, and click Open report. It covers roughly the last 90 days.

The top chart shows total crawl requests, total download size and average response time. Below it:

• Host status. Whether Google had problems fetching robots.txt, resolving DNS or connecting to your server. Any red here deserves immediate attention. If robots.txt returns server errors, Google may stop crawling the site until it recovers.
• By response. The share of requests returning 200, 301, 304, 404, 5xx and so on. A rising share of 404s or redirects means Googlebot is spending requests on URLs that no longer matter.
• By file type. HTML, JavaScript, CSS, images, JSON and others. A JavaScript-heavy site that shows large volumes of JSON or script requests is spending crawl on rendering dependencies.
• By purpose. Discovery (new URLs) versus refresh (recrawling known URLs).
• By Googlebot type. Smartphone, desktop, image, page resource load and others.

What to look for:

• Average response time climbing while crawl requests fall. Google adapts crawl rate to server responsiveness, so a slower server gets crawled less.
• Sudden spikes in crawl requests that do not match new content. Often an infinite URL space: calendars, faceted filters or session parameters.
• A high share of non-200 responses relative to your site size.

For large sites, the parallel guide on crawl budget audits goes into log file analysis alongside this report.

Core Web Vitals: grouped field data

The Core Web Vitals report (under Experience) uses field data from the Chrome UX Report. It assesses LCP, INP and CLS at the 75th percentile, separately for mobile and desktop, and groups URLs that Google considers similar.

How to read it well:

• Open each issue and look at the URL groups. Each group shows an example URL and the group's metric value. Fixing the template behind the example usually fixes the group.
• Low-traffic URLs may not appear at all. If a URL lacks enough field data on its own, it is assessed as part of a group or not shown.
• Changes take time. The data reflects a rolling 28-day window, so a fix shipped today moves the report gradually over the following weeks. Use Validate fix after deploying, then be patient.

For what each metric measures and how to fix it, see the Core Web Vitals developer guide.

URL Inspection: the ground truth for one URL

URL Inspection shows what Google knows about a single URL, and with Test live URL, what it would see right now.

The indexed view tells you:

• Whether the URL is on Google, and if not, the reason.
• Discovery: the sitemaps and referring pages through which Google found it.
• Crawl: last crawl date, whether it was crawled as Googlebot smartphone or desktop, and whether crawling and indexing were allowed.
• Indexing: the user-declared canonical and the Google-selected canonical. When these differ, Google has overridden your canonical, and the indexed URL may not be the one you wanted.
• Enhancements: structured data detected and any errors.

The live test adds View tested page, with the rendered HTML, a screenshot and a list of page resources that failed to load. This is the fastest way to confirm whether JavaScript-rendered content is visible to Google.

Request indexing is useful after fixing an important page, but it is rate-limited and does not guarantee indexing. For checking many URLs, the URL Inspection API exposes the same index data programmatically, subject to a daily quota.

Other reports worth a regular look

• Links: top linked pages internally and externally, and top linking sites. Useful for checking that your important pages receive the most internal links.
• Sitemaps: submission status, last read date and discovered URL counts for each sitemap.
• Removals: temporary removals and outdated content requests. Check it during audits; forgotten temporary removals confuse diagnosis.
• Manual actions and Security issues: rarely populated, but check them first whenever traffic drops sharply.
• Shopping and rich result reports under Shopping and Enhancements, for the structured data types Google detects on your site.

Some reports you may remember are gone. The Mobile Usability report was retired at the end of 2023, so do not rely on old guides that send you there. For mobile issues, the parallel guide on fixing mobile usability issues covers the current approach.

Build a routine

A practical cadence:

• Weekly: Performance with non-brand regex and compare mode; Page indexing for submitted pages.
• Monthly: Crawl stats host status and response breakdown; Core Web Vitals issue groups; Links report for key pages.
• After every release: URL Inspection live test on one URL per changed template.

If you want this watched for you, AI Monitoring checks your key pages every day and flags indexing, canonical and Core Web Vitals changes before they show up as a traffic drop. For a full baseline, our technical SEO audit checklist lists the checks behind each report.

Summary

• Segment Performance with regex filters (non-brand, questions, sections) and use compare mode to locate drops by page, query and device.
• Filter Page indexing by sitemap so you see the status of URLs that matter, and read each reason as a diagnosis.
• Open Crawl stats in Settings to check host status, response time and wasted requests.
• Treat the Core Web Vitals report as template-level field data that moves over 28 days.
• Use URL Inspection to compare user-declared and Google-selected canonicals and to see the rendered page.