serpBatch for transport, not for content approval
A batch is a convenient delivery unit, not an editorial decision. Every URL in it should already correspond to a legitimate published change. Keep approval, deployment, and notification as separate steps so a large release does not bypass review just because it is easier to submit one request. IndexNow's protocol supports submitting multiple URLs together. Build batching around that documented request shape, while retaining the underlying article events. When support asks why a specific URL was included, you should be able to answer without reconstructing an entire publishing day from application logs.
Partition by the configured host
Group notifications by website ownership configuration before considering batch size. A multi-customer platform must not mix addresses from unrelated hosts under one customer's key. Validate the final URL, not just the article's site identifier, because a stale canonical origin or migration setting can produce a wrong address. Deduplicate URLs within the transport window while retaining a record of the revisions they represent. If two edits happen close together, the latest public content is what matters for retrieval; your audit trail can still preserve both editorial actions without sending a redundant storm of requests.
Use explicit limits and checkpoints
Choose an internal batch size that stays within the protocol's documented maximum and suits your operational needs. Smaller batches can be easier to debug even when a larger request is allowed. Persist the batch identifier, member events, send time, response, and retry state. Mark completion only after recording the response durably. If the worker crashes after sending, you need enough information to reason about uncertain delivery. Do not delete the only evidence of pending work before the request completes. These are ordinary reliable-job principles applied to a search notification integration.
A hypothetical mixed-host mistake
Imagine a fictional agency publishes ten articles for one customer and ten for another during the same hour. A naive cron job collects all changed URLs and sends them with the first available key. The bug is not solved by retrying the combined request. The correct repair partitions events by customer host, validates ownership settings, and sends separate batches. A regression check should include two customers with similar path names so accidental grouping by slug cannot pass unnoticed. This is an illustrative engineering scenario; no actual customer data or submission result is implied.
Measure the pipeline at each stage
Track queued events, validated events, sent batches, response categories, and unresolved failures. Do not use the count of submitted URLs as a substitute for useful articles or organic performance. Large submission counts can simply reveal repeated unchanged notifications. Give operators a way to inspect one batch and trace a URL back to its publication record. For a large release, test a small representative set of live pages before releasing the remaining notification queue. The completion criterion is that valid public changes have an accountable delivery record, while search inclusion and traffic remain separate measurements collected later.
Keep batches host-specific and transport-focused, with a traceable event behind every submitted URL.
Sources & further reading
Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.
From search signals to a useful first draft.
SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.
Join early access ↗