Mastering the Exploration Section in Google Search Console in 2026

This page is for SEO managers, marketers and executives who want to know whether Googlebot is accessing their site properly. It explains how to read the Crawl stats report, which the old menu called the exploration section of Google Search Console, and which decision to draw from each part of it: fix, prioritise or wait.

It complements our guide to using Google Search Console day to day and our method for analysing indexing in Search Console.

The Crawl Stats Report: Understanding the Data and Managing Crawl

Where to Find the Report and What It Measures

The report sits under "Settings" and, at the time of writing, is only available for root-level properties, not for a subfolder. It shows what Googlebot requests and receives, not what users see.

The report is organised into four blocks:

• Three charts: total crawl requests, total download size, average response time.
• Host status: robots.txt fetch, DNS resolution, server connectivity.
• Four breakdowns: by response, by file type, by purpose (discovery or refresh), by Googlebot type.
• The host list: up to 20 hosts of the site, for example the main domain and its subdomains.

It is most useful when URL volume exceeds your capacity for manual control, when URL creation is dynamic, or when news cycles demand rapid publishing: faceted navigation on an e-commerce site, traffic spikes on a publisher.

Crawling vs Indexing: Two Steps Not to Confuse

Crawling describes Googlebot's access to a URL; indexing, Google's decision to include the page in its index. A page can be crawled without being indexed, and indexing can drop without a clear fall in crawl volume. This report therefore tells you nothing about indexing: it tells you whether Googlebot could access your resources, at what pace and with which responses.

The operational reading follows five checks, in this order:

• Discovery: does Google know the URL, through a link or a sitemap?
• Crawling: has Googlebot requested it recently?
• Accessibility: did the server respond with a usable code?
• Rendering: were the resources needed to display it available?
• Indexability: is the page eligible, according to the Pages report and the URL Inspection tool?

The first three are read here, the last two in GSC's indexing tools.

Accessing the Report and Setting the Analysis Period

Property Setup and Access Prerequisites

A Domain property aggregates all variants of the site and can show several hosts; a URL-prefix property isolates a single host. Give the people in charge of technical monitoring access to the settings.

A Fixed Window of About 90 Days, to Connect With Recent Changes

The report covers a fixed window of about 90 days, with no date selector: you cannot zoom in around a turning point. Read the trend over the whole period, then pinpoint the date of the break. An isolated spike may simply reflect catch-up crawling.

Link each break to a dated event, such as a deployment or a change to redirects, and keep a log of these changes. Check the report every week, like the Pages report: it is an alert report.

Reading Key Metrics: Volume, Download Size and Latency

The three charts are read together; none is good or bad in absolute terms. The following table summarises how to read them:

Total Crawl Requests: Interpreting a Rise or Fall

Total crawl requests indicate the pace at which Googlebot retrieves resources. A rise may signify more legitimate URLs, or an inflation of noisy URLs (parameters, facets). A fall may reflect cleaner URL patterns, or a host that is responding poorly: in that case, check host status first.

Download Size and Response Time: Read Them Together

A download size that increases without clear benefit signals inefficiency. Average response time aggregates server performance and page complexity: if it rises with crawl volume, your users are probably experiencing the same slowness.

Diagnosing Host Status: When Google Slows Down or Fails

Host status indicates whether Googlebot considers your infrastructure sufficiently available; a drop in stability reduces crawl pressure. Each part corresponds to a check:

A robots.txt fetch failure is diagnosed in the dedicated report: see our guide to the Search Console robots.txt report.

Recognising Saturation and Responding

Saturation shows through several symptoms, especially when they appear together:

• request spikes followed by a lasting drop;
• average response time climbing on the same dates;
• server connectivity failures or timeouts;
• a rise in server errors (5xx) in the breakdown by response.

The fix is a hosting matter; your job is to date the incident and measure its extent.

Analysing Crawl Responses: HTTP, Redirects and Errors

The breakdown by response classifies requests by the HTTP code returned; each family has its reference article:

"OK" Responses: Verifying That Crawl Serves Your Strategic Pages

A majority of "OK" responses is reassuring, but verify which URLs receive this crawl. If Googlebot consumes mainly low-value pages, your crawl budget is poorly focused.

Redirects and Errors: Prioritise Rather Than Fix Everything

Redirects cost requests and can form chains or loops: point internal links to the final destination. A 404 is not an error to fix in itself; redirect only to a genuine equivalent. Categorise errors by frequency and proximity to strategic pages.

Breaking Down Exploration by File Type

Why Non-HTML Resources Count Towards Exploration

Google also retrieves CSS, JavaScript and images to interpret the page. If these resources are heavy or inaccessible, crawling remains "OK" at HTTP level, but rendering is incomplete.

To reduce noise without breaking rendering, four levers apply:

• Limit the generation of non-strategic URLs: noise consumes requests.
• Clarify indexability choices.
• Identify the file types that explain a rise in download size.
• Lighten JavaScript to speed up crawling, whilst preserving functional rendering.

Understanding Crawl Purpose: Discovery vs Refresh

The breakdown by purpose separates requests that discover new URLs from those that refresh known URLs:

• Discovery dominates when the site publishes a lot or when external signals announce new content.
• Refresh dominates when Google estimates that existing URLs are changing, based on technical consistency and editorial signals.
• The split shifts when technical, structural or editorial signals change: the report shows when these changes produce an observable effect.

If discovery stays low despite regular publishing, check internal linking and sitemaps.

Interpreting Googlebot Type

The mix between Googlebot smartphone and Googlebot desktop reflects mobile-first indexing. An unexpected imbalance can signal resources unavailable on mobile or hidden content, with incomplete rendering that can affect indexing eligibility.

Before adjusting your configuration, carry out three checks:

• content consistency between the mobile and desktop versions;
• no inadvertent blocking of resources in robots.txt;
• the rendering of a few typical pages in the URL Inspection tool.

Transforming Findings Into an SEO/GEO Action Plan

Prioritising Fixes

Sort each finding against four criteria:

• The business stakes of the affected pages;
• The volume of URLs or requests concerned;
• The recurrence of the problem over the 90-day window;
• The cost of correction, to be estimated with the technical team.

The most profitable levers (server performance, internal linking, URL cleanliness) also matter for generative engines: AI Overviews and AI Mode rely on Google's index, which a poorly crawled page does not reach. See our guide to Generative Engine Optimization.

What to Monitor After Correction

After a fix, track three signals in the report:

• Stabilisation of the three charts at their usual level.
• Crawl reallocation towards strategic pages.
• Effects on indexing, visible in the Pages report.

The fixed window shows the before and after, provided the intervention is dated.

Depending on Your Situation

Depending on the problem spotted in the report, continue here.

• Your new pages are slow to be discovered. Check the Search Console Sitemaps report.
• Your pages are crawled but excluded from the index. See how to diagnose a noindex exclusion.
• You want to understand crawl budget. Read our article on SEO crawling.
• You are preparing a full audit. Include this report in a technical SEO audit.

To connect crawl signals to the pages that matter, the Incremys 360° SEO and GEO audit cross-references Search Console and Google Analytics data.

FAQ

What Period Does the Crawl Stats Report Cover?

The report covers a fixed window of about 90 days, with no date selector, at the time of writing. You can neither narrow the view nor go further back: date each deployment so you can link a break in a chart to its cause before it falls out of the window.

Why Is Google Crawling My Site Less Even Though I'm Publishing More?

Publishing more doesn't automatically lead to more crawling. Google may reduce crawl if the host becomes unstable, if response time increases or if too many low-value URLs appear. Check host status first, then the breakdown by purpose.

Is a Rise in Crawl Requests Always Good News?

No, a rise in crawl requests can reflect an inflation of noisy URLs. The right indicator is crawl quality: which URLs receive the requests, and with which responses. A rise without matching publication calls for an analysis of parameters and facets.

How Do I Distinguish a Performance Issue From an Indexing Issue?

A performance issue shows through latency and server errors; an indexing issue occurs when Google accesses the page but chooses not to index it. The first is read in the Crawl stats report, the second in the Pages report and the URL Inspection tool.

What Should I Do if 5xx Errors Increase in Console Reports?

A rise in 5xx errors signals a server that is no longer responding properly to Googlebot. Date the start of the rise, check server connectivity in host status and pass these details to hosting, then confirm that the errors subside.

How Can I Reduce Crawling of Unnecessary URLs Without Losing Traffic?

Act on the source of unnecessary URLs rather than on their symptoms. Identify noisy families, such as parameters or facets, limit their generation and clarify their indexability, whilst preserving pages that meet genuine demand.