Index Checker: Indexation Checker and Indexing Checker for Google and Bing

Checking indexation across a whole site instead of one URL

The moment you move past a handful of pages, the question changes. You no longer want to know whether one URL is indexed; you want the list of URLs that should be indexed and are not. That is a set-difference problem: everything in your sitemaps and internal link graph, minus everything currently in the index, filtered down to the pages that actually matter commercially. Doing it by hand in Search Console does not scale, and the Page Indexing report will not hand you the full list because it samples.

A checker that works at this level has to do three things. It has to read status from official signals rather than scraping a results page, so the answers hold up. It has to cover Bing as well as Google, because Bing is a meaningful share of US commercial search and is the engine most teams never check. And it has to explain, not just report: a URL missing because of a noindex tag, a robots.txt block, a canonical conflict or a quality judgment each demands a different fix, and a bare not-indexed flag sends you looking in the wrong place. Once the cause is cleared, the URL goes back through the official Google Indexing API, Bing IndexNow and your sitemaps, and is rechecked until the status changes.

• Compare your intended URL set against indexed status, rather than checking pages one by one.
• Filter to commercially important pages first; not every excluded URL deserves attention.
• Cover Bing as well as Google, since most teams never look at it.
• Treat the exclusion reason as the deliverable, because it decides the fix.

What an index checker can verify, and what no index checker can

Worth being precise about, because the gap between the two is where most disappointment with these tools comes from.

What is checkable: whether a given URL is currently present in Google's or Bing's index, whether the URL you asked about is the one that got indexed or whether a different canonical won, whether a page that used to be indexed has dropped out, and whether the URL is blocked, redirected, noindexed or canonicalized somewhere else. All of that is observable, and at scale it is the difference between knowing your coverage and guessing at it.

What is not checkable by anyone: why Google made the decision. Google does not publish a reason for declining to index a page beyond the broad status names in the Page indexing report, and those names describe the state rather than the cause. Discovered, currently not indexed tells you Google knows the URL and has not fetched it. It does not tell you whether that is a crawl budget question, a quality judgment, or simply a queue.

Also not checkable: when it will change. No tool can give you a date, because Google publishes no schedule and the timing varies from hours on a well-crawled news site to months on a new domain. Any tool that quotes you a guaranteed indexing time is describing its marketing rather than its mechanism.

So the useful frame for an index checker is measurement, not diagnosis. It tells you exactly which of your URLs are in and which are out, which turns an unbounded problem into a specific list. What you do with the list is where the actual gains are, and the most common answer is that the missing pages have nothing linking to them.

• Checkable: current index status per URL, on Google and on Bing
• Checkable: which canonical actually got indexed instead of the URL you asked about
• Checkable: pages that were indexed before and are not now
• Checkable: blocked, noindexed, redirected or canonicalized states
• Not checkable: Google's reason for the decision, beyond the reported status
• Not checkable: when a page will be indexed, by any tool

Why Google and Bing disagree about the same page

Run the same URL list through an indexation checker for both engines and the results will not match. That is normal, and the differences are informative rather than noise.

The indexes are built by separate crawlers on separate schedules from separate discovery graphs. Bing tends to index new pages faster on small sites, largely because it accepts IndexNow submissions and Google does not, so a page pushed through IndexNow can be in Bing within hours while Google is still working through its queue. Google tends to be more selective on large sites, dropping thin or near-duplicate URLs that Bing keeps.

The practical readings are worth knowing. Indexed in Bing but not Google usually means the page is technically fine and reachable, and Google has made a judgment about its value or has not got to it, so the fix is more likely internal links and content depth than a technical bug. Indexed in Google but not Bing is usually just Bing being behind, and submitting through IndexNow closes it. Indexed in neither, on a page that is live and unblocked, points at something structural: nothing links to it, or the canonical points elsewhere, or the sitemap never listed it.

One thing that does not carry across: a removal request. A removal in Google Search Console has no effect on Bing whatsoever, and each engine has its own removal tool. Teams pulling a page out of search regularly do half the job and are surprised to still find it in Bing months later.

• In Bing, not Google: usually a value or queue judgment, not a technical fault
• In Google, not Bing: usually latency, and IndexNow submission closes it
• In neither, page live: check internal links, canonical target and sitemap coverage
• Removals are per engine. A Google removal does nothing in Bing