Skip to content
Gryz markGryz

Report this document

Describe the issue — this goes directly to our review queue.

0/500

Why an IndexNow ping does not put the URL in Google search results

An IndexNow ping notifies search engines that adopted the protocol. Google Search is not one of those engines. Bing, Yandex, Naver, Seznam, and Yep can receive the HTTP notice. Googlebot does not sit on that bus. A 200 from the IndexNow endpoint means the notice landed with a participant. It does not mean Google stored the document, ranked it, or even crawled it. Google tested the protocol in 2021 and never shipped it as a production recrawl channel. Official Google recrawl still lists URL Inspection and sitemaps. The Indexing API covers JobPosting and livestream structured data only. Ping is not index, even at Bing: the participant may crawl later and still drop the URL on quality. If Google Search Console says the URL is unknown after a green IndexNow log, that split is expected, not a bug in your token file.

How IndexNow grew as a Bing and Yandex ping Google never adopted

Microsoft Bing and Yandex launched IndexNow in October 2021 as a shared notification protocol. A site hosts a verification file, then sends a changed URL to one participating endpoint. Participants agreed to share those notices among themselves. The pitch was less exploratory crawl: tell engines the URL changed so they do not have to poll it blindly.

Google was asked to join at launch and stayed out. A few weeks later a Google spokesperson said the company would test the protocol for crawl efficiency and sustainability. That line produced a wave of plugin marketing that still reads “IndexNow indexes Google.” The test never became a public Google endpoint, never appeared in Search Console, and never landed in Google’s recrawl documentation. Years later, the engines that actually consume IndexNow remain the Bing-family and a short list of other participants. Google still discovers and recrawls on its own pipes.

The protocol always separated “we heard you” from “we indexed you.” Bing Webmaster Tools later added IndexNow Insights so a publisher can see that Bing received the URL. Receipt is a queue signal. Bing can still leave the document out of the Bing index. Google never logs the ping, so Search Console has no IndexNow report. The common SERP answer is right: IndexNow is Bing, Yandex, Naver and peers; Google tested and did not adopt; a ping is not an index row. The gap is operational proof: Google’s recrawl page names Inspection and sitemaps, Bing Insights can be green while GSC still says URL unknown, and Google’s Indexing API is a different, narrow product.

What a missing Google index row costs after a successful ping

Teams burn a week waiting on Google because a CMS badge said IndexNow succeeded. Product pages miss the first days of a launch. A guest post Bing already lists still produces a Google search with zero hits. Agencies that sold “instant Google indexing” via a protocol handshake then eat refunds, or they hide behind Bing screenshots.

The ping is cheap. The cost is the false stop: nobody opens URL Inspection, nobody checks robots for Googlebot, nobody asks whether the URL is even indexable, because the plugin already printed success. Googlebot Smartphone fetches the URL only after Google discovers it through links, a sitemap, Inspection, or another Google-side path.

SpeedyIndex sells the Google and Yandex index row as Pay-per-Result, not as a protocol receipt. That distinction is the whole product.

Bing can show IndexNow Insights the hour you publish while Google Search Console still says the URL is unknown. We bill 100 tokens only when the URL is indexed. If Google has not stored it on day 7, those tokens refund. A handshake is not the product. The index row is the product, and no vendor gets 100 percent of URLs stored.

— SpeedyIndex team

Treat IndexNow as a Bing and Yandex courtesy. Budget a separate Google path: fetchability, sitemap, Inspection, then a paced submit if the list is large. Do not pause Google work because a participant engine already said “received.”

Workflow: prove the ping never wrote a Google result

Run this on one URL before you argue with a plugin vendor. Each step names the action, the tool, the setting, what you should see, when to run it, and how success and failure look.

  1. Replay the IndexNow notice. Action: send the URL to a participating endpoint with the verification file in place. Tool: CMS IndexNow log or an HTTP client. Setting: Bing or Yandex IndexNow host, URL plus token. Observable: HTTP 200. When: right after publish. Success: a participant accepted the notice. Failure: 403 from a bad verification file. Google is not on this request.

  2. Read Bing IndexNow Insights. Action: open the Insights report. Tool: Bing Webmaster Tools. Setting: date range covering publish time. Observable: URL listed as received. When: same day as the ping. Success: Bing logged the notice. Failure: no row — plugin miss or unverified host. A green row still says nothing about Google.

  3. Inspect the URL in Search Console. Action: paste the exact URL. Tool: GSC URL Inspection. Setting: this property, live URL. Observable: on Google, unknown, or crawled/discovered and not indexed. When: after Insights already shows the ping. Success for this diagnosis: unknown or not indexed while Bing has a receipt. If Google already has it, the ping was coincidental.

  4. Fetch the document as Googlebot would. Action: read status, robots, meta, canonical. Tool: curl or GSC live test. Setting: follow redirects; inspect X-Robots-Tag, robots meta, rel=canonical. Observable: 200, indexable, self-canonical. When: before any Google submit. Success: Google may store this URL. Failure: 404, 410, 451, noindex, or a canonical that points elsewhere.

  5. Check robots.txt for Googlebot, not only Bingbot. Action: test the path. Tool: GSC robots tester plus the raw file. Setting: Googlebot and Googlebot Smartphone. Observable: Allow. When: Insights green and Inspection empty. Success: Googlebot may fetch. Failure: Disallow for Googlebot while Bingbot is open.

  6. Search Google for the exact URL. Action: paste the full URL. Tool: Google Search. Setting: URL as query, then a quoted title fragment if needed. Observable: a result at this exact address. When: after Inspection. Success: retrievable. Failure: no result. site: is a smell test, not an index table.

  7. Record Google status from outside GSC. Action: run a bulk-capable check. Tool: a Google index checker. Setting: exact URL, Google engine, no Search Console verification. Observable: indexed or not, with a timestamp. When: you need a dated row or you do not own the property. Success: a yes/no you can file. Checking does not submit the URL.

  8. Use Google’s actual recrawl tools. Action: request a recrawl only after the URL is indexable. Tool: Inspection “Request indexing” plus a sitemap that lists the URL. Setting: one request per URL within quota; sitemap lastmod updated. Observable: last crawl appears. When: after steps 4–5 pass. Success: Googlebot Smartphone fetches; quality can still refuse storage. Google’s page on how to ask Google to recrawl names Inspection and sitemaps. It does not name IndexNow.

  9. Pace Google submits on a large list. Action: do not dump thousands of URLs in one hour. Tool: drip-feed indexing or a daily cap. Setting: Standard for a short list; drip-feed for a large set; optional precheck drops 404/410/451, robots/noindex, and already-indexed URLs. Observable: daily accepted count, then index yes/no. When: fetchability is clean. Success: some URLs enter Google over days. Failure: still absent on day 7. SpeedyIndex refunds unindexed Google URLs on day 7 (Yandex day 15) under Pay-per-Result. Storage is not guaranteed.

  10. Retest Google on a calendar. Action: inspect and checker-test again. Tool: GSC plus the same checker. Setting: day 1, day 3, day 7. Observable: last crawl, coverage state, index yes/no. When: after a real Google-side submit. Success: URL on Google. Failure: still unknown or crawled not indexed. Open a content or duplicate ticket, not an IndexNow ticket.

IndexNow ping versus Google recrawl versus the Indexing API

Keep these pipes separate. Mixing them under one “indexing API” label is how the myth spreads.

  • IndexNow ping. Readers: Bing, Yandex, Naver, other participants. An HTTP notice that a URL changed. Success: 200 plus a Bing IndexNow Insights row. Does not write Google Search results.

  • Google recrawl. Readers: Google. URL Inspection “Request indexing” plus sitemap discovery. Success: Googlebot fetches; Inspection shows a last crawl. Does not assign a ranking or accept IndexNow as input. This is the path Google documents.

  • Google Indexing API. Readers: Google, for JobPosting and livestream (BroadcastEvent) pages only. Success: API 200 for those types. Does not index a blog post, product URL, or generic landing page.

  • Paid Google/Yandex submit (SpeedyIndex). Process toward Googlebot Smartphone and Yandex. Standard or drip-feed, Pay-per-Result, 100 tokens per indexed URL, 200 trial tokens, no GSC verification. Success: indexed on the recheck day. Unindexed Google URLs refund on day 7; Yandex on day 15. Does not promise every URL will be stored.

  • Organic discovery. Links, sitemaps, historical crawl. Success: a crawl with no ping. Does not arrive on a fixed SLA after IndexNow.

If a vendor slide draws one arrow from IndexNow to Google, replace the slide.

Troubleshooting when Bing has the URL and Google does not

Bing Insights green, GSC unknown. This is the default IndexNow story. Stop debugging the verification file for Google. Start a Google discovery path.

Plugin 200, Bing Insights empty. Wrong endpoint, bad verification file, or www versus apex in Bing. Fix Bing if you care about Bing. Google still needs its own path.

Google crawled, still not indexed. The ping is irrelevant. Inspection proves Google found the URL. You have a quality, duplicate, or canonical problem. Recrawling in a loop will not promote it.

Indexing API error on a blog URL. Expected. The API rejects document types outside jobs and livestreams. Do not “fall back” to IndexNow and call that a Google fix.

robots.txt blocks Googlebot, allows Bingbot. Bing can index from the ping plus a Bingbot fetch. Google never sees the body. Relax the Googlebot rule on the path you want stored.

Canonical points at another URL. Google may store the target and skip the pinged URL. IndexNow sent the duplicate. Align the tag before any Google submit.

Soft 404 or thin template. Participants may still log the ping. Google may crawl and refuse. Precheck for 404/410/451 and noindex before you spend tokens.

Sitemap omits the URL. Inspection can still request one URL. Add the URL to the sitemap as a Google hint, not as an IndexNow substitute.

You verified Bing but not GSC. You will see Insights and you will not see Inspection. Use an external Google checker, or verify GSC.

Three illustrative scenarios (not real clients)

Illustrative scenario 1 — WordPress badge versus Search Console. A publisher enables an IndexNow plugin. The log shows 200. Bing Insights lists the article within an hour. Inspection the next day says the URL is unknown to Google. The plugin notified participants. Google never subscribed. The fix is Inspection plus sitemap, not a second IndexNow keystroke.

Illustrative scenario 2 — Agency screenshot swap. An agency promises “Google indexing in minutes via IndexNow.” The deliverable is a Bing Insights screenshot. The client searches Google for the product URL and finds nothing. The statement of work never split Bing receipt from Google storage. The Google path still has to start after the argument.

Illustrative scenario 3 — Jobs API mixed with protocol ping. A careers site uses the Google Indexing API for JobPosting URLs, then turns on IndexNow for the blog and reports that “Google push” is live everywhere. Job URLs may appear through the Indexing API. Blog URLs do not piggyback on that API and do not enter Google through IndexNow. Split reporting by URL type.

Illustrative model: protocol ping versus Google index storage

Illustrative model (not a production crawl log, not a real property):

CMS publish
    |
    +--> IndexNow HTTP notice
    |         --> Bing IndexNow Insights (received)
    |         --> Yandex / Naver / other participants
    |         --> optional Bing or Yandex index later
    |         --> Google: no subscriber on this wire
    |
    +--> Google-side path (separate)
              --> sitemap lastmod
              --> URL Inspection Request indexing
              --> optional paced submit (Standard or drip-feed)
              --> Googlebot Smartphone fetch
              --> Google index decision (store or refuse)

The left branch can succeed while the right branch has not started. That drawing is the whole article.

FAQ

Does an IndexNow ping put a URL into Google search results?

No. Google is not an IndexNow participant. The ping can reach Bing, Yandex, Naver, and other protocol hosts. Google Search results require a Google crawl and a Google index decision.

Which search engines actually read IndexNow?

Bing and Yandex launched it. Naver, Seznam, and Yep have been listed as participants at various times. Always check the current participant list on the protocol side. Do not add Google to that list from a plugin README.

Did Google adopt IndexNow after the 2021 test?

Google said it would test the protocol for crawl efficiency. It never documented a Google IndexNow endpoint, never added an Insights clone in Search Console, and never listed IndexNow on the recrawl help page. Treat the test as unfinished product, not as a live Google feature.

Why does Bing show the URL while Google Search Console does not?

Bing received a protocol notice and may have crawled. Google did not receive that notice. GSC URL unknown next to Bing Insights green is a consistent pair, not a contradiction.

Is the Google Indexing API the same thing as IndexNow?

No. IndexNow is a multi-engine notification protocol Google did not ship. The Indexing API is a Google API limited to JobPosting and livestream pages. A blog or product URL belongs on neither of those as a Google push channel.

Will a sitemap replace IndexNow for Google?

A sitemap is one of the two recrawl methods Google documents. It is a hint to Google, not a participant ping. Use it for Google. Keep IndexNow for engines that actually listen to it.

Should I still Request indexing after a successful IndexNow ping?

Yes, if you want Google to know about the URL and Inspection still says unknown. Request indexing talks to Google. The ping did not.

Does HTTP 200 from IndexNow mean the page is indexed anywhere?

No. 200 means a participant accepted the notice. Bing may still leave the URL out of the Bing index. Google never saw the request.

Should I disable IndexNow if Google is the only engine I care about?

You can leave it on for Bing and Yandex at low cost. Do not let it replace Google-side work. If the plugin is what your team watches, it will keep teaching the wrong success metric.

How do I check Google separately from Bing after a ping?

Use URL Inspection, a live Google search for the exact URL, and an external Google index checker. Do not use Bing Insights as a Google proxy.

Forecast for IndexNow and Google recrawl

IndexNow will keep spreading in CMS plugins because the integration is small and Bing still wants push notices. Google has no public plan to become a participant. Recrawl docs still point at Inspection and sitemaps. Expect more dashboards that blur “submitted” with “in Google.” Defense is a two-engine checklist: Insights for Bing, Inspection plus a dated Google checker row for Google.

Google’s push APIs will likely stay narrow. Jobs and livestreams already have a dedicated API. Paid recrawl products will keep selling process — submit, recheck, refund — not a seat inside ranking. SpeedyIndex’s day-7 Google refund is a bet on that split remaining honest. If Google ever joined IndexNow, receipt would appear on the Google side and indexing would still be a later decision. Until that participant row exists, do not wait on it.

The previous note in this series covers the step before this one: Why a JavaScript-only Shopify product page is not in the Google index. Read that first if you landed here on a related long tail.

About SpeedyIndex

SpeedyIndex is a Pay-per-Result indexing service for Google and Yandex. You submit URLs; 100 tokens bill per indexed URL; unindexed Google URLs refund on day 7 and Yandex on day 15. Standard handles a short list. Drip-feed paces a large list. Optional precheck drops 404, 410, 451, robots-blocked and noindex URLs, and URLs already indexed. The crawler presents as Googlebot Smartphone. You do not need to verify the domain in Search Console. New accounts can start with 200 trial tokens.

The service is a submit-and-recheck process. It does not sit inside Google’s ranking code and it does not claim 100 percent indexing. Use it when a URL is indexable and missing from Google or Yandex, not as a substitute for IndexNow theater and not as a ranking booster for a URL Google already stores.