Hakaru Lab | Published: 2026-09-25 | Review
Who this is for: Individual site operators and small-blog operators who want to tell search engines about new publications and updates on their own site as quickly as possible, and anyone who wants to sort out the difference between "we sent it" and "it showed up in search results."
Key points (3 lines)
・Our lab implemented IndexNow (a free mechanism for notifying search engines that a site's URLs have been updated) with a single key file and a small script, and on September 6, 2026 we sent 9 URLs and received HTTP status code (a three-digit number representing a server's response) 202.
・This gives individual site operators who want to notify search engines of their updates as quickly as possible, without paid tools, material for judging what is and isn't possible, and what remains unconfirmed.
・IndexNow is a mechanism for a subset of search engines that does not include Google, and having a submission accepted is a different fact from the page actually being indexed (sections 4 and 3 below cover how to check indexing status and the most recent submission status).
Basis of this review
・Reviewed on: 2026-09-13 (cross-checking the implementation and first-submission records)
・Status re-checked: 2026-09-17 (just before publication)
・Conflicts of interest: There are no advertising links in this article.
IndexNow (a name meaning "index it now") is a shared communication protocol (a set of rules that let multiple computers exchange information) for telling search engines which URLs on a site have been newly published or updated. According to the official site, the protocol was released with support from Microsoft Bing, Naver, Seznam.cz, Yandex, and Yep (all search engines), and Bing's webmaster blog has an article dated October 2021 introducing the protocol (sources are listed at the end). The mechanism is simple: the site identifies itself as its own by way of a "key file" it hosts (described below), and then sends a list of updated URLs in a single request.
The important point to note here is that Google is not on this list. As far as our lab could confirm (as of the reference date 2026-09-13), we found no record of Google itself officially stating support for IndexNow. Since no statement of support could be confirmed, sending through IndexNow cannot be expected to speed up Google-driven traffic or reflection in Google's search results (our lab has not been able to confirm primary information from Google on this point). For Google, the established way to communicate site updates remains submitting a sitemap.xml (a machine-readable file listing the URLs on a site) or waiting for the search engine to revisit (crawl) the site on its own.
Our lab chose IndexNow because it involves no additional cost and requires only a single key file, and because we could reuse the output of our existing sitemap.xml generator as-is. Note that "0 yen" refers only to the scope of using IndexNow and our lab's own script; it does not include the cost of the site's hosting infrastructure or of acquiring and maintaining the domain. Because Google is out of scope, we handle Google separately through our sitemap.xml.
```mermaid
flowchart LR
A["Site updated / newly published"] --> B["Regenerate sitemap.xml"]
B --> C{"Where to notify?"}
C -->|"Bing/Yandex etc."| D["Send updated URLs via IndexNow<br/>→ 202 means accepted; key verification pending"]
C -->|"Google"| E["Publish sitemap.xml<br/>+ wait for normal crawling<br/>(no submission to Search Console yet)"]
D --> F["Accepted only —<br/>whether it was indexed needs a separate check"]
```
Diagram: where an update gets announced branches by search engine. Even when IndexNow returns 202, whether the page was actually indexed needs a separate check (our lab has not yet built a route to confirm indexing status, so it is left out of the diagram).
Our lab implemented IndexNow without any additional paid service, using a single script written with the standard library only (version notation v0.1, as of 2026-09-06; subject to change). The design rests on three points.
The key file. In IndexNow, the site indicates that it is the administrator of that site by hosting a key file. According to the official documentation, the key only needs to be a hexadecimal string (a notation that represents numbers using only the 16 characters 0–9 and a–f) of 8 to 128 characters, and it does not have to sit at the site root — you can add a field (keyLocation) pointing to wherever the key actually lives. Our implementation places a 32-character hexadecimal string at the site root; this key is not secret information, since the specification assumes it is public (we are withholding the actual value here). If the file does not exist, the script auto-generates it at startup and writes it into the publish directory.
How the submission list is decided. The list of URLs to send is read, as-is, from whatever the sitemap.xml file contains at that moment; that file is produced by a separate sitemap-generation run and is not linked to the sending script. The generation script itself re-checks, every time, which of a predetermined set of targets (a handful of fixed pages, article pages, and the English-language pages) actually exist as files, and assembles the list from those. For an article page, if the update date cannot be read from the publication date / update date noted in the body text (update date takes priority), that page is left out of the sitemap. Fixed pages (top page, about, privacy, etc.) carry over the value already in the existing sitemap, or use the current date if there is none. Redirect URLs used for measurement are excluded. On the IndexNow side, only URLs whose update date falls within the last 7 days are sent by default.
A guard against double-sending on the same day; the default is no send at all (dry-run). Unless you pass the explicit `--go` option, this script does not actually send anything — it only records which URLs it would send, an execution mode known as dry-run (running only to preview the outcome, without carrying out the actual operation). Furthermore, once a submission has been accepted (response code 200 or 202), re-running the script on the same day will not resend it. If a submission fails, this record is not updated, so re-running it later the same day will resend it. This cap exists to avoid sending the same update repeatedly on the same day, which a search engine could treat as excess load. However, this guard has a downside: if a new URL is published after that day's submission has already gone out, it will not be sent until the script is run again. How this downside actually played out is covered in section 3.
According to our lab's execution log, at 2:46 AM on September 6, 2026 (local time on the machine that ran it; the log is recorded in a format with no timezone information, and in operation we assume Japan Standard Time (JST, Japan's standard time, 9 hours ahead of Coordinated Universal Time, UTC), but the log itself does not confirm this), we ran this script with `--go` and sent 9 URLs. The breakdown was 4 fixed pages (the top page, the methodology page, about, and privacy), 3 Japanese-language articles (30days-50man, opera-cli-tokens, systemeio-free-plan), the English-language top page, and 1 English-language article (30days-50man). The response was HTTP status code 202, which, per the official documentation, means "the URL was received; key verification is pending" — acceptance of the submission and completion of key verification are separate stages.
About 22 minutes earlier that day (2:24 AM), a dry run of the same script without `--go` recorded 8 URLs as candidates for sending. The difference of one URL was the English-language top page; according to our lab's own working notes from the day of implementation (dated 2026-09-06), the English-language entry page had just been newly created, and sitemap.xml had just been regenerated to 9 entries. Because the sitemap generator handles a fixed page's update date as "the existing sitemap.xml value, or the current date if there is none," the newly created English top page appears to have passed the 7-day filter using that day's date and been added to the submission target. That said, the exact time of the regeneration is not recorded in the log, and that one point remains unconfirmed.
Also, at the moment the key file was generated at 2:24, it was noted as "effective after deploy (deploy: publishing created files to the live server) — deploy is required," and the submission went out 22 minutes later. There is no record of a deploy happening in that window; the most recent publish record before the key was generated was at 2:13, earlier than the key generation. Because 202 signals that key verification is pending, if the key was not yet present at the publish destination at the time of submission, the subsequent key verification could fail to pass. Our lab did not perform a reachability check (a single access to the key's URL) during this window, and that too remains unconfirmed.
What this record shows is only the fact that IndexNow's shared intake endpoint (api.indexnow.org) accepted the request. 202 does not guarantee that the submitted URLs are actually reflected in search results or crawled preferentially. Furthermore, after this first submission, 3 more articles (1 Japanese, 2 English) were published that same day, but cross-checking the publication records against the sitemap.xml (12 entries) as of the review date (2026-09-13) shows these were not included in the first submission's URL list (9 entries) and had, at that point, never once been sent to IndexNow. The overlap between the "once per day" guard described in section 2 and the absence of a scheduled recurring run left part of the submission targets (3 of 12 as of the review date) unsent for more than a week after publication.
These 3 unsent URLs have since been resolved. According to our lab's execution log, on the same day as the review date, 2026-09-13, at 12:08 PM (again, local time on the machine that ran it), we ran the IndexNow sending script with `--go --all` (an option that sends all URLs regardless of whether they are already recorded as sent), resending all 12 published URLs at once, including these 3, and received HTTP status code 200 in response (the basis for this is a record in our lab's IndexNow submission log reading "SENT urls=12 http=200"; our lab has not confirmed whether 200 means key verification also passed). We have also since added a step to the publishing process itself that sends to IndexNow immediately after publication, changing the design so that individual URLs are now less likely to slip through. However, ongoing confirmation of whether this step actually works as intended each time is outside the scope of this article's review.
A common misunderstanding after adopting IndexNow is treating "the submission was accepted (202 came back)" as equivalent to "the search engine actually indexed the page (made it available to appear in search results)." These are two different facts, and a 202 response indicates only the former.
The typical way to check whether a page has been indexed is to register your site with the dedicated management console each search engine provides and look at the count of indexed URLs or impression counts. For Google, there is Google Search Console (a free management console Google provides that shows how your site appears in Google's search results). According to our lab's own working notes from the day of implementation (dated 2026-09-06), a Search Console ownership-verification tag had not been detected at that point, and we have no record of registering since then. A machine inspection of the site's published files just before publication of this article (2026-09-17) likewise found no ownership-verification tag, so the site still appears to be unregistered (we have not opened the Search Console management console itself, so confirmation through the console has not been performed). For Bing, the destination of our IndexNow submissions, there is Bing Webmaster Tools (a similar free management console Microsoft provides), but our lab has no record showing whether registration has been done, and this remains unconfirmed as of 2026-09-17. About 11 days have passed between the first submission (2026-09-06) and this pre-publication check (2026-09-17), yet our lab still does not have an adequate way to confirm whether the 9 submitted URLs (12 if you include the 2026-09-13 resend) were actually indexed.
What matters here is that "we have no way to check" is different from "it was not indexed." Our lab calls this state "unmeasured," not "unindexed." It could be indexed, or it could not be — we simply have no record confirming either way. Failing to keep this distinction risks the mistaken conclusion, if a page happens not to turn up in search results later, that "IndexNow didn't work."
Similarly, our lab has not yet built a way to determine "whether a crawler (an automated crawling program) from Bing or elsewhere actually revisited the site" by cross-referencing the User-Agent (the identifying information the accessing software declares about itself) and IP address (a number identifying a device on the internet, showing where an access came from) in our access logs. The list where our lab tracks planned and completed initiatives sets 72 hours as a rough benchmark for when Bing's crawler could be confirmed to have arrived after a submission, but this is an estimate, not a measured result, and confirming it remains a task for the future.
For anyone considering adopting IndexNow, here is a checklist built from our lab's own implementation.
Our lab itself has an example that failed items 4 and 5. In the publication records for the two preceding days (September 4 and 5, 2026), a reachability check for one article (systemeio-free-plan) had failed with HTTP status 403 (access denied), yet the dry run and the actual send the following day, September 6, still included this URL among the submission targets. This is a counterexample showing that a file existing and it actually being readable at the publish destination are different things.
If even one of these items does not hold, you may end up operating the mechanism — sending, but with no way to confirm whether it had any effect.
Adopted (our lab's decision): Our lab first ran IndexNow submission with a single key file and a single script on 2026-09-06, sending 9 URLs and confirming HTTP 202 (accepted; key verification pending). We adopted a design that sends nothing by default (dry-run) and only sends with an explicit flag, with no double-send on a day already accepted. Three URLs published after that first submission went unsent through the review date (2026-09-13), because the once-per-day guard and the lack of a scheduled recurring run overlapped; that same day (2026-09-13, 12:08 PM) we resent all 12 URLs including these 3 using `--go --all` and confirmed HTTP 200. We have also added a step to the publishing process (as of 2026-09-13) that sends to IndexNow immediately after publication, changing the design so individual omissions are now less likely.
Recommended (advice to readers): If you want to speed up update notifications, we recommend first confirming whether the search engine you care about is on IndexNow's list of supported engines. If you are hoping for an effect on Google, prioritize maintaining sitemap.xml instead of IndexNow (our lab has not been able to confirm a statement of support from Google's side). Do not assume "submission accepted" means "indexed" — we recommend also registering with each search engine's management console and recording submission and indexing separately. If you add a once-per-day guard, we also recommend pairing it with a mechanism (a scheduled recurring run, diff detection, or building it into the publishing process itself) so that URLs newly published after that day's submission are not missed. The baseline date is the review date (September 13, 2026), and the status was re-checked as of September 17, 2026.
Method: This article is a review based on the source code of the IndexNow submission script and the sitemap.xml generation script our lab operates, the actual execution logs (submission timestamps, submission counts, response codes), and the site's publication records (publish timestamps, reachability check results). Response codes are used exactly as recorded in our lab's execution logs. For IndexNow's specification (key length, the meaning of 202, the list of supported search engines), we confirmed the official IndexNow site as of the reference date. Many of the figures in this article are based on our lab's own internal execution logs and records; what readers can open and confirm directly is limited to the parts with links in the sources section — the official IndexNow site, its official documentation, and each search engine's official help pages.
Unverified items:
Correction history:
Sources:
Our lab's research, writing, and verification are carried out through a division of labor among multiple AIs. This article explains a notification mechanism our lab itself adopted, based on our actual execution records. Policy decisions and final confirmation are handled by humans on the operating side.