IndexNow Implementation Without Submission Theater

The publisher notifies participating search engines that a URL was added, updated, or deleted. The engine acknowledges receipt and decides what to do next. An HTTP 200 means the URL submission was received; it is not a crawl receipt, index verdict, or ranking event. Keeping that boundary in logs and dashboards prevents an operational signal from becoming a marketing claim.

Participating engines share valid submissions within the protocol. Google is not documented as a participating IndexNow endpoint, so the implementation should be described as Bing-compatible secondary discovery. Google discovery still depends on crawlable links, sitemaps, recrawl requests where appropriate, and its own systems.

The key must meet the protocol’s character and length rules and be available in a text file that establishes ownership. Root placement supports the broadest URL scope and is simpler to reason about. A key under a subpath can only authorize URLs within the documented path boundary.

Generate and store the key as deployment configuration, but publish only the expected verification value in the expected file. Do not print unrelated environment values in build logs. Validate the production key URL from outside the platform and confirm that canonical host redirects do not move it to a different ownership scope.

The protocol accepts up to 10,000 URLs in one POST. Build the list from a deployment diff or content manifest, normalize hosts and paths, remove duplicates, exclude drafts and aliases, and include deleted canonical URLs when the publishing event calls for removal notification. A small content release should produce a small deterministic batch.

For a static Vercel deployment, run submission after a confirmed production promotion, not during preview builds. Preview hosts are not canonical and should never enter the batch. Keep production submission behind explicit release authorization because it mutates an external discovery system and creates noise if a deployment is rolled back.

Classify deterministic client errors separately from temporary responses. A malformed payload, invalid key, or host mismatch needs a code or configuration fix; immediate repeated requests only increase noise. Rate limits require bounded exponential backoff and a maximum attempt count. Persist a hash of the canonical batch so a job restart can identify an already accepted submission.

Log the endpoint, status, timestamp, URL count, batch hash, and sanitized error message. Do not log the full environment or thousands of URLs by default. A dry-run mode should output counts and a bounded sample, then exit without network mutation. This makes the release artifact reviewable before the confirmation boundary.

After an accepted submission, use Bing Webmaster Tools or subsequent verified crawler requests to study discovery. Check whether the canonical URL returns the expected content and whether the sitemap and internal links agree. If indexing does not follow, investigate quality, canonicalization, status, directives, and duplication rather than resubmitting continuously.

For Google, use Search Console and the URL Inspection tool or API under their documented limits. Do not use Google’s Indexing API for ordinary articles; its supported use is restricted to job posting and livestream pages. No notification protocol can compensate for a page that is thin, duplicated, blocked, or not worth indexing.