What is IndexNow?

What is IndexNow?

IndexNow is a protocol for notifying participating search engines that a website address has been added, meaningfully updated, or removed. It sends a change notification rather than placing the page directly into an index. The search engine still decides how to crawl and process the resource, so successful submission must remain separate from later indexing evidence.

• The IndexNow protocol documentation, accessed October 8, 2026, defines single-URL and batch requests, ownership verification, and response handling.

  The official FAQ explains supported integration approaches. A notification communicates a changed address; it does not send the full page content as a replacement for crawling.

• For a service website, a newly published explanation or an accurately removed offering can be a relevant change.

  The page must still deliver its intended public response and information. Submitting an unavailable success shell does not repair the resource, and acceptance cannot establish that the visible explanation is useful or accurate.

• The protocol concerns participating engines.

  Do not assume that it is a universal submission mechanism for every search provider. Check the current official endpoint list and use each provider’s documented tools where appropriate rather than label an accepted IndexNow request as a confirmed Google indexing operation.

• The useful implementation goal is a reliable notification after a real public change.

  Ownership, host matching, correct addresses, and deliberate retry handling all matter. A plugin being enabled is implementation evidence, but a recorded request and response are needed to establish what the integration actually submitted.

Which search engines receive a notification?

Notifications are received through supported endpoints and shared according to the protocol’s participation rules. The current participant list determines that scope. It does not establish that every engine will crawl or index the resource identically, so identify the endpoint and participating provider before interpreting acceptance or comparing later search observations across different systems.

• The official endpoint list, accessed October 8, 2026, includes the global endpoint and participating provider endpoints.

  The protocol states that adopted submissions are shared with other participants. That arrangement differs from manually sending separate indexing requests to every search engine on the web.

• Do not hard-code an old tutorial’s short participant list into a current explanation.

  Participation can change. Refer to the verified official list when configuring the integration and retain the endpoint used in submission evidence. A provider’s presence also does not justify a promised processing deadline for its index.

• Google’s ordinary discovery and inspection evidence should be interpreted through Google’s own tools.

  The official IndexNow endpoint list does not identify a Google submission target in the verified documentation. An accepted IndexNow request therefore should not be described as Google’s acknowledgement that the page has been indexed.

What does the ownership key establish?

The ownership key lets the engine verify the host for which notifications are submitted through an accessible text file or supported integration. It is not a content-quality approval or an instruction to ignore access restrictions. Confirm the key relationship and public file delivery before investigating page indexing, because an invalid setup can prevent acceptance independently of the resource’s quality.

• The IndexNow verification specification describes hosting a UTF-8 text file containing the matching key.

  The FAQ also describes CMS or provider integrations that handle the mechanism automatically. Check the actual installation rather than assuming every site needs an additional manually maintained file.

• For manual setup, the filename and content need to correspond to the submitted value.

  A generated file path can look correct while the host returns the application’s default HTML shell. Inspect the full response and actual text, not merely whether the URL opens without an obvious browser error.

• Keep the host distinction explicit.

  A file available on a preview host does not establish verification for the public host used in the payload. An alternate hostname or redirect can also complicate the relationship. Test the intended public address under anonymous conditions and verify the actual configured key location.

• A successful key-file test supports accessibility, but the engine’s response remains the evidence of its handling of a submission.

  Do not convert a browser visit to the file into a claim that every engine has already validated the key or processed all changed pages linked to it.

How does key-file location affect the allowed URL scope?

Key-file location affects which addresses can be included under the documented verification method. A root-level file provides the recommended broad host setup, while an alternate location needs explicit notification and can limit the eligible path scope. Review that relationship before interpreting rejected addresses as a content problem or reusing a folder-specific key for unrelated routes.

• The protocol documentation describes root placement and the keyLocation option.

  Its folder example limits the associated submissions to the relevant prefix. Follow the documented scope rather than assuming that any accessible key file anywhere on a host automatically authorizes every resource beneath that host.

• A service-folder key can differ from a root-level key.

  A notification about a guide in another folder may fall outside the chosen setup. Inspect the actual file location and submitted target together. Repeatedly retrying the same mismatched payload will not repair the ownership relationship.

• Where manual root placement is available and appropriate, the protocol recommends it.

  Where another location is necessary, state the location in the supported request form and verify scope. Do not create additional files or keys without checking whether the existing integration already manages the required relationship correctly.

• Test after host or deployment changes.

  A site move can remove the file, alter the host, or route the key location through a generic page handler. The content change notification and the ownership file have different functions; both need accurate public delivery before submission acceptance can be interpreted usefully.

How should a single changed URL be encoded?

A single changed URL should be transmitted as the supported request parameter with the address correctly encoded, preserving its intended host, path, and meaningful query data. The submitted resource and the notification endpoint are different addresses. Incorrect encoding can split the payload’s parameters or alter the target, so inspect the actual request rather than only the source string before transmission.

• The IndexNow single-URL specification requires appropriate URI encoding.

  The FAQ encoding guidance illustrates reserved characters. A question mark or ampersand belonging to the target URL must not accidentally become a separate parameter in the notification request.

• Illustrative request shape, not a live submission:

https://api.indexnow.org/indexnow?url=ENCODED_CHANGED_URL&key=KEY_VALUE

The placeholders identify values supplied by the real integration. They are not an executable production configuration or a manufactured notification result. Use the actual public resource and verified key, plus the supported key-location parameter where the verification method requires it.

• Preserve meaningful application state.

  A location or resource selector can change the target’s information. A campaign label may be unnecessary duplication. Canonicalization helps interpret equivalent addresses, but it does not configure the notification encoder. Select the intended changed resource before constructing the request.

• Check double encoding as well as missing encoding.

  A value processed twice can produce another literal address from the intended one. Inspect transmitted parameters through an appropriate controlled test and the recorded endpoint response. A correctly encoded string still needs an appropriate real resource change; syntax alone does not justify submission.

How should a batch payload group changed resources?

A batch payload should group actual changed addresses under the verified host and supported request structure. Keep the host and key relationship accurate, and avoid mixing unrelated hosts into one body. Batching reduces submission overhead but does not turn a list of arbitrary addresses into a valid notification or prove that every included resource became indexed.

• The IndexNow batch specification, accessed October 8, 2026, permits up to 10,000 URLs per POST and defines host, key, and urlList fields.

  That is a protocol limit, not an instruction to fill every batch or a measured number of pages changed on the website.

• Use valid JSON and the documented content type.

  JSON-LD is a different structured-data format; an IndexNow payload is an API body, not a page’s schema description. Do not add vocabulary context or graph wrappers to the notification merely because both implementations happen to use JSON serialization.

• Separate hosts deliberately.

  Subdomains can represent different verification boundaries. A batch assembled from a broad content export can mix them inadvertently. The FAQ describes separate subdomain handling. Review the actual hosts rather than treating every address owned by one business as a single protocol host.

What do acceptance and verification-pending responses mean?

Acceptance and verification-pending responses describe the notification’s handling, not a completed search result. Read the endpoint status according to the protocol and retain it with the submitted addresses. A successful submission record cannot establish that the engine fetched the page, selected it for indexing, or displayed a particular appearance for a customer query afterward.

• The protocol response table, accessed October 8, 2026, defines HTTP 200 as successful submission and HTTP 202 as receipt with key validation pending.

  These are API outcomes. They differ from the response returned by the notified page when an engine later requests that resource.

• The FAQ explains that engines evaluate crawling and indexing after notification.

  Keep that sequence explicit in dashboards or reports. A label such as indexed should not be attached automatically to an accepted request unless another appropriate source actually establishes the later indexing state.

• A pending response calls for checking the documented verification state, not changing accurate page content at random.

  An initial engine check can differ from subsequent accepted requests. Preserve timing and key-location evidence so the integration’s handling can be understood without an invented universal verification deadline.

• Later crawler activity can be assessed through available verified request evidence.

  Log-file analysis helps investigate actual requests within its coverage, but a partial origin export can miss edge-served traffic. Submission acceptance and recorded crawling remain separate observations, each with its own scope.

How should rejected or rate-limited requests be diagnosed?

Rejected requests should be diagnosed from the protocol response and the actual transmitted payload rather than handled through unlimited immediate retries. Formatting, ownership, host scope, and rate limits are different causes. Identify the relevant one and correct its source, because resending unchanged invalid data can repeat the failure without making the notification eligible or the page more useful.

• The protocol response table, accessed October 8, 2026, describes HTTP 400 for invalid format, HTTP 403 for an invalid key relationship, HTTP 422 for host or protocol-schema mismatch, and HTTP 429 for excessive requests.

  These documented codes concern notification handling, not the page’s ordinary delivery status.

• For formatting issues, inspect encoding or JSON serialization and required fields.

  For key failures, inspect file content and public accessibility. For host-scope errors, compare the target addresses with the declared host and key location. A single generic message that submission failed conceals the evidence needed to choose the appropriate repair.

• Rate-limited handling needs a deliberate retry policy consistent with the provider’s current guidance.

  Avoid loops that send the same unchanged batch continually. Preserve the affected events and relevant response so an integration can recover without silently dropping changes or creating another burst of duplicate notifications.

• Retest after correcting the responsible condition.

  Do not use success on another host or another key as proof that the original issue is resolved. The useful verification is the intended valid request’s response under the actual public setup, followed by separate evidence where crawling or indexing questions remain.

Which publishing changes should trigger notifications?

Publishing changes should trigger notifications when they materially add, update, or remove a public resource. The event should correspond to the delivered website, not merely a saved draft or unchanged rebuild. Decide which meaningful content changes the integration observes so notifications accurately describe resource events instead of repeatedly advertising cosmetic or internal operations with no relevant public change.

How should moved and removed pages be notified?

Moved and removed pages should be notified according to their actual changed resource state, while the website returns an accurate response. A permanent move needs an appropriate replacement relationship; a removal without replacement needs accurate missing behavior. Notification does not repair either condition, so verify the route before interpreting the event as a completed technical migration or deletion.

• The IndexNow FAQ explicitly discusses redirected and deleted addresses.

  A 301 redirect can represent a permanent move to an equivalent resource. The old address changed and may therefore be relevant to notify, while the replacement’s actual publication or update can be a separate event.

• A 404 error can accurately represent a resource unavailable without a relevant replacement.

  The notification does not require inventing a successful page at that address. Do not create generic service text solely to avoid submitting a removed resource whose correct current state is missing.

• Trace a redirect chain where migration rules overlap.

  An accepted notification for the old address cannot prove its final destination works. Inspect the complete response path and substantive replacement rather than count the first redirect as evidence that the customer’s original task remains available.

Does IndexNow replace sitemaps or internal links?

IndexNow does not replace sitemaps or useful internal links because those mechanisms serve broader inventory and navigation purposes. A notification communicates a changed address to participants. It does not establish that customers can reach the resource through related information, that every intended page appears in an inventory, or that another search engine uses the same notification protocol.

• The official FAQ discusses using notifications alongside sitemaps.

  An XML sitemap can communicate intended resources that change less often. Maintain an accurate inventory rather than submit the entire unchanged website repeatedly through a mechanism intended to report recent resource events.

• Orphan pages concern incoming internal relationships.

  A notified page can still lack a useful route from its relevant category or guide. Add appropriate contextual navigation where the resource deserves it; the notification record alone does not provide that customer path or explain the page’s place in the site.

• Crawl budget involves a provider’s broader crawling decisions.

  Avoid asserting that one accepted event proves a specific scheduling improvement or that eliminating notifications automatically increases important-page requests. Diagnose actual resource and request evidence instead of treating the protocol as direct control of another system’s entire crawl plan.

• Keep all mechanisms tied to verified intent.

  A sitemap entry, incoming link, and notification can all point to an incomplete page. They assist different kinds of access and communication but do not replace accurate substantive information, current delivery, or the engine’s own later processing requirements.

How should access restrictions and indexing instructions be interpreted?

Access restrictions and indexing instructions still need their own review after notification. IndexNow does not turn a blocked or excluded resource into an unrestricted eligible page. Confirm the intended audience and public delivery, because an accepted request can coexist with a resource that should remain private or one accidentally prevented from normal processing by another configuration.

How should an IndexNow implementation be tested and reported?

Test an implementation by verifying the actual public key relationship, outgoing changed addresses, payload format, and endpoint responses under relevant publish events. Keep acceptance separate from later crawling and indexing evidence. The report should describe the tested mechanism and remaining limits rather than label every successful request as an indexed page or claim an unmeasured visibility improvement.

• The protocol documentation and FAQ provide the request and verification rules.

  Use them to select controlled valid tests and diagnose errors. Do not send live notifications merely to demonstrate syntax for this glossary; its examples describe implementation rather than perform a submission for an unrelated site.

• Illustrative diagnosis, not client data.

  A notifier declares the public host but loads its key file only on a preview host. The content page is correct, yet ownership verification fails. The developer makes the appropriate file available at the intended public location and checks the valid host and scope before retesting the payload.

• The test verifies meaningful publication and removal events, plus failure handling relevant to the actual integration.

  It confirms that an unchanged build does not repeatedly send the same resource as a new event. No fabricated indexing deadline or conversion result is needed to establish that notifications now represent real changes correctly.

• Report the endpoint, tested event, transmitted target, ownership setup, response, and separate later observations where available.

  Those details support an actual technical decision. IndexNow is useful when it reliably communicates resource changes within its documented scope, with an honest account of what acceptance does and does not establish.