Google Search Console briefly made healthy, indexed pages look as though they had fallen out of Google's index on September 8, creating a sharp but short-lived scare for technical SEO teams. The underlying pages remained indexed; the problem was in Search Console's reporting.
The incident became more consequential for teams using automation because at least some Search Console API extracts captured the incorrect state before the reporting layer recovered. One SEO reported seeing as much as 20% of URLs on some smaller properties move into “Crawled – currently not indexed” in data pulled during the affected window.
Google's John Mueller subsequently confirmed that the event was a brief reporting problem and had already been resolved. Search Engine Roundtable documented the incident on September 9, describing it as a short blip rather than a real indexing outage.
The distinction is crucial. Search Console can report what Google knows about indexing incorrectly without the underlying search index itself changing. When that happens, dashboards and API pipelines can generate alarming numbers even while search visibility remains intact.
Indexed homepages suddenly appeared as “Crawled – currently not indexed”
The first reports came from SEOs who noticed that pages known to be indexed were receiving a non-indexed classification in Search Console.
Glenn Gabe reported seeing homepages labeled “Crawled – currently not indexed” even though the pages were clearly present in Google's results. Ryan Tree observed similar behavior across client sites.
Search Engine Roundtable's Barry Schwartz checked his own properties minutes later and found that the issue had already cleared.
That rapid reversal was an early indication that the incident was a reporting inconsistency rather than a genuine large-scale removal of pages from Google's index.
John Mueller called it a “short blip”
Mueller said he checked with Google's team and confirmed that the problem had been resolved quickly during the night.
He also emphasized the difference between indexing functioning normally and Search Console reporting the status differently.
That distinction rules out the most alarming interpretation of the screenshots. Google was not confirming that indexed pages had been deindexed and then rapidly restored. It was confirming that the reporting view had briefly been wrong.
For site owners, that means there was no reason to change content, canonicals, robots directives or internal links merely because the temporary status appeared.
The visible problem lasted roughly an hour
According to Search Engine Roundtable's account, the anomaly appeared to resolve within approximately an hour.
The exact duration may have varied depending on when an account, tool or API request observed the incorrect data, so “about an hour” is better treated as an observed window than as a formal Google incident duration.
Google has not published a detailed postmortem specifying the precise start time, end time or number of affected properties.
What is clear is that the anomaly was short enough for many Search Console users never to encounter it at all.
The API made a short bug persistent in downstream datasets
A temporary interface error disappears when the interface recovers. An API extract can preserve it indefinitely.
Matthew Mellinger pulled Search Console data during the affected period and reported a large number of URLs moving from indexed into “Crawled – currently not indexed,” with the anomaly reaching as much as 20% on some smaller sites.
Schwartz advised rerunning the report after the incident had cleared.
This is the most important operational lesson from the event: an automated snapshot can faithfully record an incorrect upstream state. Once stored in a warehouse, spreadsheet or SEO platform, that bad snapshot does not automatically repair itself just because Google fixes the source.
The 20% figure is not Google's estimate of the outage
The reported 20% number needs careful framing.
It came from one practitioner's observation across some smaller properties captured during the problem. Google did not say that 20% of indexed pages were affected globally, and the Search Engine Roundtable report does not establish a representative sample of Search Console properties.
Small sites can also produce dramatic percentages from relatively few URLs. If a property contains 100 monitored pages, 20 incorrect statuses produce a 20% anomaly.
The figure demonstrates that the reporting error could be material for an individual dataset; it does not quantify the worldwide scope of the incident.
What “Crawled – currently not indexed” normally means
Outside this specific bug, “Crawled – currently not indexed” is a legitimate Search Console status.
Google's Page Indexing documentation explains that the report separates URLs Google considers indexed from URLs that are not indexed and provides reasons for the latter.
A page can be successfully crawled without being selected for the index. That does not automatically mean the site has a technical error, and Google does not promise to index every URL it discovers.
The September 8 incident was unusual because pages that were demonstrably indexed were temporarily being assigned that normal non-indexed label incorrectly.
Search Console is a reporting system, not the index itself
SEO teams often speak about Search Console statuses as if they were direct switches controlling Google's index. They are not.
The reports expose Google's information about crawling, indexing and search performance through interfaces designed for site owners. Those interfaces can have their own processing delays, classification issues and reporting bugs.
A status change in Search Console is evidence that deserves investigation, but it is not independently sufficient to prove that a live search-index change occurred at the same moment.
The September incident is an unusually clean example because Google explicitly confirmed that indexing was working while the status was being reported incorrectly.
URL Inspection can help verify suspicious cases
Google's Search Console guidance recommends URL Inspection for debugging page-level indexing questions.
The tool can show the current index status Google has available for a specific URL, while a live test can examine whether the page is accessible to Google at the time of testing.
During a broad reporting anomaly, checking a small sample of critical URLs can help determine whether the issue is real before a team begins remediation.
Homepages are particularly useful sanity checks because their index presence is generally easy to verify through multiple signals.
The URL Inspection API can propagate the same bad moment
Google's URL Inspection API gives developers programmatic access to URL-level index information for Search Console properties they manage.
Google describes the API as returning the indexed information currently available in the URL Inspection tool, including index status and related fields.
This is powerful for technical SEO monitoring, but it also means automation is dependent on the accuracy of Google's reported state at request time.
If the upstream reporting layer is temporarily wrong, a perfectly functioning script can collect perfectly structured wrong data.
Rerun exports captured during the incident window
Teams that scheduled Search Console index-status extracts around the September 8 anomaly should consider rerunning those jobs.
The goal is not to erase evidence that the incident occurred. It is to prevent a known reporting artifact from contaminating operational metrics that are supposed to describe real indexing history.
If the original snapshot is retained for audit purposes, it should be flagged as affected by a confirmed reporting issue and kept separate from normalized trend analysis.
Otherwise a future analyst may look back at the dataset and conclude that the site experienced a genuine deindexing event that never happened.
Automated alerting can amplify short reporting errors
Many enterprise SEO systems trigger alerts when indexed-page counts fall beyond a threshold.
That is normally useful. During a reporting incident, however, an alerting system can turn a one-hour upstream bug into dozens of Slack messages, tickets and executive escalations.
The answer is not to stop monitoring. It is to build confirmation logic into high-severity alerts.
A sudden index-status drop can be checked against search impressions, sampled URL Inspection results, live accessibility and a second data pull before it is classified as a production emergency.
One anomalous source should not trigger site changes
If pages appear non-indexed in Search Console but continue receiving search impressions and remain discoverable in Google, the signals conflict.
Conflicting signals call for verification, not immediate remediation.
Changing canonical tags, adding noindex directives accidentally, rewriting pages or submitting large numbers of URLs for recrawling can create genuine SEO problems while trying to fix a reporting problem.
The more dramatic the unexplained change, the more valuable a short verification step becomes.
Search impressions are a useful corroborating signal
A page cannot accumulate ordinary Google Search impressions if it has genuinely disappeared from the searchable index for the entire period being examined.
Search Console's Performance report can therefore provide useful context when the Page Indexing report suddenly claims a large set of established pages is no longer indexed.
Performance data is not real time and should not be treated as a perfect live index checker, but continued impressions can help challenge an implausible deindexing narrative.
Technical SEO diagnosis is strongest when several independent signals point in the same direction.
Site searches can provide a quick sanity check, with limitations
Mueller specifically noted that it was easy for people to double-check something obvious such as whether a homepage remained indexed.
A Google search for a distinctive brand or URL can be a quick sanity check when a critical page suddenly receives a contradictory Search Console status.
The site: operator can also provide directional evidence, but it is not a comprehensive or exact index-count tool and should not be used to calculate how many URLs Google has indexed.
The purpose during an incident is simply to test whether Search Console's claim is plausible, not to replace Search Console with search-result counting.
Do not confuse this incident with ordinary report latency
Search Console reports can naturally update at different speeds, and the Page Indexing report is not designed as a second-by-second representation of Google's systems.
Google's own documentation notes that URL Inspection can be useful for the current state of individual pages while aggregate reports describe broader site-level indexing information.
Ordinary latency can therefore produce temporary differences between views even without a bug.
The September 8 event goes further because Google confirmed that a short reporting blip occurred and practitioners saw clearly indexed pages assigned the wrong status.
The incident did not indicate a crawl-budget problem
The appearance of “Crawled – currently not indexed” can tempt SEOs to diagnose crawl quality, thin content or crawl-budget problems.
Those explanations were not supported in this case. The pages had already been indexed, and Mueller said indexing itself was functioning as expected.
There is no evidence from the confirmed incident that Google suddenly reevaluated the quality of affected pages or reduced their crawl priority.
The status label was the symptom of the reporting error, not a newly discovered site-quality signal.
There is no evidence of a ranking impact
A reporting-only indexing bug should not be described as a ranking outage.
Search Engine Roundtable's examples specifically involved pages that remained indexed despite the incorrect status. Mueller likewise framed the event as reporting differently while indexing continued to work.
No confirmed evidence in the incident report shows that affected URLs lost rankings or organic traffic because of the bug.
Any site that experienced an independent ranking change during the same period would need separate evidence before connecting it to this Search Console event.
Data pipelines need anomaly quarantine
The API contamination makes this incident particularly relevant beyond SEO.
Modern search teams often ingest Search Console data into warehouses where it is joined with crawling, analytics, revenue and content data. Once an anomalous snapshot enters that system, downstream reports may treat it as authoritative.
A robust pipeline can flag implausible discontinuities, preserve the raw response, mark the affected batch as provisional and schedule a verification pull after a short delay.
This pattern is common in financial and operational data engineering and is increasingly necessary for SEO systems that depend on external platform APIs.
Small sites may need percentage-based alerts with absolute thresholds
The anecdotal 20% anomaly on smaller sites also illustrates a monitoring-design problem.
Percentage changes can look catastrophic when the denominator is small. Losing the indexed status on two pages out of ten is a 20% drop; losing two pages out of 100,000 is negligible.
Alerting systems should therefore combine percentage and absolute thresholds where appropriate.
A warning might require both a meaningful relative change and a minimum number of affected URLs before escalating to an incident.
Confirmed platform incidents should become annotations in SEO history
Teams that maintain long-term technical SEO datasets should annotate September 8, 2026 as a known Search Console reporting anomaly if their collection window overlapped it.
Annotations prevent future investigations from rediscovering the same mystery months later.
They are particularly valuable when staff changes, because the person reviewing an old index-status graph may have no memory of a one-hour platform bug that occurred years earlier.
Operational SEO history should record platform incidents alongside migrations, releases, algorithm updates and major site changes.
The lesson is to verify the system before fixing the site
The September 8 Search Console bug was brief, but it exposed a weakness in increasingly automated SEO operations.
A reporting platform mislabeled indexed pages. Practitioners noticed the contradiction and verified that the pages were still in Google. The interface recovered quickly, but API snapshots captured during the wrong moment preserved the anomaly and could have turned it into a false historical event.
Google's confirmation closes the indexing question: this was a reporting blip, not evidence that the affected pages had genuinely been removed from the index.
For technical SEO teams, the response should be equally clear. Rerun affected API exports, annotate any retained snapshots, and add corroboration to high-severity indexing alerts. Search Console is indispensable, but like every reporting system it can briefly be wrong. The safest automation is not the one that reacts fastest to every red number; it is the one that knows when to verify whether the number describes the website or merely the dashboard.