Google Search Console's crawl stats date toggle is broken, according to Search Engine Roundtable's latest recap. The bug affects the date control in the crawl stats report, limiting site owners' ability to move between time periods when investigating how Googlebot has crawled their site.
The crawl stats report shows how often Googlebot requests pages, how much data it downloads, and how the host responds. Its date toggle lets site owners compare periods, for example before and after a migration or a traffic drop. With the toggle broken, that comparison becomes difficult or impossible inside the report itself.
The bug is a reporting-interface problem, not a crawling problem. There is no indication that Googlebot's actual crawling has changed; the issue is that the tool site owners use to inspect crawling is not letting them change the date range as expected.
Crawl stats are a first line of defence when diagnosing indexing and visibility problems. A sudden fall in crawl requests can signal a server problem, a robots.txt error, or a site change that blocked the crawler, while a surge can reveal a crawl trap or a runaway parameter generating endless URLs.
When the date control fails, the workaround is to rely on other signals: server logs, Search Console's indexing reports, and the performance report. Server logs are the most reliable alternative, since they record every Googlebot request directly, without depending on the Search Console interface.
Export whatever crawl stats data is available for the current view, and pair it with server-log analysis for the periods you need to compare. Log analysis tools can reproduce the key crawl stats views, including requests by day, response codes, and the most-crawled URLs, without the broken toggle.
If you do not have log access, use the indexing report's trend lines and the performance report's date comparisons as a cross-check. Neither replaces crawl stats exactly, but together they can confirm whether a suspected crawling change coincides with a visibility change.
The crawl stats bug arrives in a month that has already seen several Search Console reporting issues, including performance data running more than 60 hours behind around October 11 and indexing report dates drawing concern from users. Individually these are minor; together they are a reminder not to treat any single Search Console report as infallible.
Google typically fixes interface bugs of this kind without announcement, so the practical approach is to check the toggle again periodically and to keep alternative data sources warm. A site that can answer crawling questions from its own logs is never hostage to one dashboard bug.
Build measurement redundancy before you need it. Server-log access, a second analytics source, and a habit of exporting key reports mean that any single tool failure, including this one, becomes an inconvenience rather than a blind spot.
For link builders, crawl health is link health: pages Googlebot cannot reach cannot rank, and pages that cannot rank earn fewer links. Keeping an independent eye on crawling protects the pages your links point to, which is the quiet half of every link-building campaign.
A basic log-based crawl dashboard needs only a few views: requests per day from Googlebot, response codes over time, the most-crawled URLs, and crawl by section of the site. Most log analysis tools produce these out of the box, and even a spreadsheet built from a weekly log export covers the essentials.
The payoff is independence. When Search Console has a bug, a delay, or a missing report, a log dashboard keeps answering the questions that matter: is Googlebot visiting, is it hitting errors, and did anything change after the last release. That independence is worth building before the next dashboard bug, not during it.
Sources: Search Engine Roundtable, October 31, 2026.
Linkbaits helps you create content that earns citations and backlinks. Start with the free tools and build your first linkable asset this week.
Start free trial