This is how you should read the Page Indexing Report on Google Search Console

First illustration of the article

Today, I finally had the opportunity to carefully listen again to episode 112 of Google Search Off the Record, “How to Read the Indexing Report”.

Below is a summary of the key points that emerged from the discussion between Martin Splitt and John Mueller, along with some personal observations.

Don’t treat the Indexing Report as a “to-do list”

One of the biggest misconceptions about this report is treating it as a list of errors that need to be fixed: according to the Search Console team, this is NOT the correct way to use the report.

This is because the “errors” reported are not always meant to be interpreted as actual errors: redirects, reporting delays, and even a high number of 404 errors can be perfectly normal if they reflect intentional changes made to the website.

Instead, the report should be viewed as a tool for identifying patterns, unexpected changes, and anomalies that may deserve further investigation.

When I open it, I should ask myself: “Is Google handling this website the way I expect, or is there something happening that differs from the intended behavior?”.

Not all non-indexed URLs represent a problem

Browsing through the report, do you see thousands of non-indexed URLs? Don’t panic.

A page may NOT be indexed because it:

  • redirects elsewhere,
  • intentionally returns a 404 error,
  • is not the canonical version of itself,
  • is marked as noindex,
  • has another URL selected by Google as the preferred version.

There are many other cases as well, but in the examples listed above, NONE of these situations automatically indicates an “SEO problem”.

For example, during a website migration, a significant increase in URLs classified as “Page with redirect” is often evidence that the migration is working CORRECTLY.

Likewise, if content has been intentionally removed from a website, 404 responses are expected behaviors and not something that necessarily needs to be fixed.

Search Console is the most authoritative source available for evaluating Google indexing, not the “site:” operator

The site: operator should not be considered “the ultimate source of truth” regarding a URL’s indexing status: Search Console should always take precedence when evaluating indexing.

If, during domain SEO migrations, Google continues to show URLs from the old domain in “site:” search results even years after a migration has been properly implemented, this should not be a cause for alarm… it is normal behavior.

In addition to what Google explained in this podcast episode, I would add that I have noticed this situation in several domain SEO migrations I have worked on, without it ever representing a migration issue.

Seeing this situation does not mean the migration failed or that Google is still indexing the old website: Google simply remembers those URLs and may continue displaying them when users explicitly search for the old domain using the “site:” operator.

In my opinion, this does not mean that the “site:” operator is useless, but rather that it should not be considered something it is not. If you’re interested, you can read an explanation here of what the “site:” operator is and how it works.

If Google chooses a different canonical URL… is it always a problem?

The podcast highlights an important point: a canonical discrepancy is often a diagnostic clue rather than a problem.

For example, Google may choose a non-www version because most external links point to that version.

The report can help us understand how Google interprets relationships between URLs and signals from external linking.

When a situation like this is identified, using the report can help us understand the reason behind the change.

Be careful: while it may be a sign of an inconsistent configuration, it is not necessarily automatically “an error” that needs to be “fixed”.

How should you use it when a large number of URLs suddenly change status?

If thousands of URLs suddenly change, becoming for example:

  • 404;
  • 403;
  • 410;
  • Non-indexable;
  • Assigned a canonical different from the one suggested by the website itself.

Very often, the root cause can be found in:

  • CDNs
  • Firewalls
  • Hosting providers
  • Bot protection systems

Google has repeatedly encountered situations where CDNs enable aggressive bot protection measures and accidentally block Googlebot. As a result, pages that still exist may suddenly appear inaccessible or missing to Google.

From my experience as an SEO consultant, this is an underestimated issue that can genuinely occur and cause problems for clients, especially when it is not identified quickly.

Watch out for infrastructure-related bugs

In the episode, John Mueller also mentions a scenario that many technical SEO professionals have probably encountered: sometimes “anti-bot” pages are displayed with messages asking users to verify whether they are human or a bot… the problem arises when those pages return an HTTP 200 OK status code.

That anti-bot page could be interpreted as the actual content of the URL.

At that point, what could happen?

  • The original content may disappear from the index
  • Pages may be classified as duplicates
  • Unexpected canonicals may appear
  • Google may index the verification page instead of the real content

The Indexing Report should be used as a pattern-detection tool: a single error is usually irrelevant, whereas a sudden change affecting thousands of URLs often deserves deeper investigation.

Quality does not necessarily mean “content”

When reading discussions among SEOs, I notice increasing attention being paid to these two statuses in the GSC Indexing Report:

  • Discovered – currently not indexed: Google is aware that the URL exists but has not yet crawled it.
  • Crawled – currently not indexed: Google has visited the page but has decided not to include it in the index for the time being.

Let’s be clear: neither of these statuses automatically indicates a technical problem. Nor do they mean that these “errors” are automatically harmless.

If these categories grow significantly across large sections of a website without an obvious technical explanation, Google suggests looking beyond technical SEO and evaluating the overall quality of the website.

This is the part of the episode that made me reflect the most: Google’s concept of quality.

When technical factors do not explain indexing decisions, Google may simply believe that the content does not provide enough unique value to users.

Second illustration

What about AI-Generated content?

The problem is not AI-generated content itself: the problem is content that provides little unique value.

In other words, content that anyone could have produced and that adds nothing new to the conversation.

Quality is not limited to the page’s “text”.

Google evaluates the entire user experience:

  • Intrusive advertising
  • Interstitials
  • Visual clutter
  • Page performance
  • Accessibility of the main content
  • Overall usability

An excellent article hidden behind a poor user experience may still struggle to achieve good results.

The Ratio Between Indexed and Non-Indexed Pages… may not mean much

Personally, I found this point interesting because many SEO professionals become concerned when only a fraction of their URLs are indexed, and this situation is more common than people might think.

The podcast explains that the percentage itself is NOT a quality indicator: what matters is that the pages that truly matter are indexed.

Sometimes Google’s indexing decisions are not “the problem”

In this final section, I want to provide a simple example, outside the scope of what was discussed in the podcast, of how the Indexing Report can support SEO analysis through pattern recognition.

A website whose Indexing Report continuously shows an increase in indexed pages is not always a positive sign: the fact that “Google is finding and processing more content” can be a negative thing if that content does NOT provide value.

If, while investigating a pattern like this, we discover an automated page-generation mechanism that continuously creates new URLs, many of which return HTTP 200 status codes, and those URLs contain neither directives preventing indexation nor clear canonical consolidation signals… then we have found the root cause of the “SEO mess” on our website.

This is one of the reasons why I completely agree with the podcast’s message: the value of the report rarely comes from analyzing individual URLs. Its real value lies in understanding large-scale behavior patterns and identifying situations that deviate from the website’s intended logic.

Another example? I would pay close attention to internal search result pages, especially if they do not have a noindex directive or other mechanisms that prevent indexation.

 

The Real Question behind every indexing report

The real value of Google Search Console’s Indexing Report comes from identifying situations where Google’s view of a website differs from the website’s intended behavior: its purpose is to help us answer a much more important question:

“Is Google interacting with this website in the way we expect?”

When the answer is no, the report, combined with manual analysis, often provides the first clues needed to understand why.

Third illustration