Should you stop using the site: operator to verify Google indexation?

This statement from Martin Splitt is torpedoing a practice deeply rooted for over 15 years among SEOs: typing site:mysite.com/my-page to verify whether Google has indexed a URL.

The problem? This first-level diagnosis turns out to be approximate. The site: operator queries a different index than the one used for actual user searches — a simplified cache that doesn't always reflect reality.

Why does the site: operator give incorrect results?

The site: operator draws from a secondary index designed for fast queries, not precision. It can display pages that are not indexed or, conversely, fail to show URLs that are perfectly indexed and ranking.

Google guarantees neither exhaustiveness nor temporal consistency. A page can appear one day, disappear the next, without its actual status in the primary index having changed.

What is Google's recommended method?

Google pushes toward using Google Search Console, particularly the URL inspection tool. This tool directly queries the production index and provides accurate diagnosis: page indexed or not, reason for any blocking, last crawl date.

Unlike the site: operator, Search Console clearly distinguishes pages that are discovered but not indexed, those blocked by robots.txt, or those excluded by a noindex tag.

Does this fundamentally change how we diagnose indexation?

Yes, because we can no longer rely on an immediate reflex. The site: was convenient for a quick check — too quick, precisely. It gave a false sense of control.

From now on, any serious indexation diagnosis must go through Search Console or, failing that, through a search containing a unique snippet of the page's content (a phrase fragment in quotation marks). This latter method is less direct, but more reliable than site:.

• The site: operator queries a secondary index, not the primary index used for actual SERPs
• Results can be incomplete, outdated, or downright wrong
• Google officially recommends Search Console to verify indexation
• The URL inspection tool provides accurate diagnosis and reasons in case of blocking
• A search with a unique text snippet in quotation marks remains an acceptable alternative

Is this statement consistent with field observations?

Absolutely. For years, we've observed flagrant inconsistencies with the site: operator. Pages that rank on competitive queries but don't appear in a site: search. URLs blocked by noindex that nonetheless show up in site: results.

The problem is that this practice was so deeply ingrained that we long ignored its limitations. How many panicked clients because a page "no longer appears in Google" when it's actually perfectly indexed and visible on actual searches?

Why did Google wait so long to clarify this?

Good question. [To verify] — Google never explained why it maintained this ambiguity for years. The site: operator has existed since the search engine's beginnings, but its documentation remained vague until Splitt publicly disavowed it.

A hypothesis: as long as it didn't cause massive problems, Google had no incentive to correct perceptions. But with Search Console's rising power and the multiplication of incorrect diagnoses, a decision had to be made.

In which cases can we still use the site: operator?

For a macro overview of the approximate number of indexed pages on a domain, it remains acceptable. If you see 50,000 pages when you've published 10,000, there's clearly a duplication or parasitic crawl problem.

But as soon as you get down to a specific URL level, it's over. The site: operator can no longer serve as proof or counter-proof of indexation. End of story.

What should you do concretely right now?

First step: stop relying on site: to diagnose individual page indexation. If a client or colleague tells you "my page isn't indexed, I checked it with site:", respond that this is no longer valid proof.

Second step: migrate to Search Console as your reference tool. URL inspection must become your first reflex — it gives exact status, last crawl date, and any potential blockers.

How do you adapt your audit and monitoring processes?

If you're regularly auditing site indexation, forget about scraping site: results. Instead, use the Search Console API to extract the list of indexed pages and cross-reference with your XML sitemap.

For continuous monitoring, set up alerts in Search Console on variations in the number of indexed pages. A sharp drop signals a real problem, unlike phantom fluctuations from site:.

What errors must you absolutely avoid?

Don't force a re-indexation via "Request indexation" because a page doesn't appear in site: results. You'll unnecessarily saturate Google's crawl budget and risk slowing down indexation of genuinely new pages.

Also avoid creating redirects or modifying internal structure based on a site: diagnosis. You could break what's already working perfectly in the main index.

• Abandon the site: operator for URL-level indexation diagnostics
• Systematically use the URL inspection tool in Search Console
• Cross-reference Search Console data with your XML sitemap to identify real gaps
• Set up automatic alerts on indexation variations via Search Console
• Never force re-indexation based solely on a negative site: result
• Train your clients and teams on this new reality to prevent false alarms