A spike in “not indexed” pages inside Search Console is not automatically a support ticket. Most practitioners open the page indexing report the way they’d open a bug tracker, hunting for a defect to close. That instinct, according to Google’s John Mueller and Martin Splitt, is the wrong mental model for the tool, and it sends people chasing fixes for outcomes that were never broken.
Splitt described the confusion showing up in the wild: a question at a Search Central Live event about a page that was indexed while the coverage report said otherwise, plus a Reddit poster convinced they had “screwed up” because dozens of their pages weren’t indexed. Mueller said the pattern is common among newer Search Console users, who see a large count of unindexed URLs and assume it reflects an error on their end that requires action.
The fix for that instinct is not a new dashboard. It’s a different question. Splitt reframed the exercise: instead of asking whether an individual URL is indexed, ask whether the site as a whole is behaving the way you configured it to behave. His example is a migration. Move a domain and set up redirects correctly, and the indexing report will show a steep rise in pages labeled “page with a redirect, not indexed.” Read as an inventory, that spike looks like a failure. Read as a monitoring signal, it’s confirmation the redirects are firing and Google is following them. The alarming-looking metric is the proof the migration worked.
404s work the same way, with one wrinkle. A 404 response is genuinely an error in the technical sense: a server told a crawler that a requested URL doesn’t exist. Splitt put it plainly: “It’s actually a good thing. The problem is that, and then I get the question like, so, but why does Search Console show it as an error? Because it is an error. It’s just an expected one.” Old URLs disappearing is normal site life, not damage.
Mueller drew the line that separates a genuine fix from a false alarm. A batch of 404s traced to a misconfigured server is a technical fault, and reporting it back to Google as resolved is warranted. But when a URL simply wasn’t indexed because “our systems decided we weren’t as curious as you might be,” in Mueller’s phrasing, there is no server setting to correct. That’s an indexing outcome, not a bug, and no amount of technical cleanup changes Google’s interest calculation.
Roger Montti, writing for Search Engine Journal, added the caveat that keeps this from becoming an excuse to ignore the 404 report entirely: a rising 404 count can still point to a broken link or an internal link that was never updated after a URL changed. The label being accurate (“it is an error”) doesn’t mean the alarm is always noise. It means the alarm needs a second look before anyone decides whether to route it to engineering.
That’s the actual skill Search Console demands: separating a metric that moved because you changed something on purpose from one that moved because something upstream broke. A redirect count climbing right after a planned migration doesn’t need a ticket. A 404 count climbing on pages nobody meant to remove does. Teams that triage every red number identically will burn engineering hours on migrations working as designed while a real broken-link problem sits in the same report, unexamined.
Roger Montti reported this for Search Engine Journal on July 20, citing a conversation between John Mueller and Martin Splitt on Google’s Search Off The Record podcast.
