Idempotency
Definition
Idempotency is the property that repeating the same intended publishing operation converges on the same remote result instead of creating additional pages or applying the same change multiple times.
Why idempotency matters in programmatic SEO
Bulk publishing involves timeouts, partial failures, retries, and uncertain responses. Without stable identity and idempotent behavior, a harmless-looking retry can create a second CMS page, overwrite the wrong object, or make it impossible to tell which remote page belongs to the approved source row.
Idempotency turns retry from "run it again and hope" into a controlled continuation of the original operation. The system needs enough identity and read-back evidence to know whether the intended result already exists before it sends another destructive request.
A simple example
A create request for an approved page times out after the CMS receives it. The client does not know whether the page was created. A naive retry sends another create and may produce a duplicate.
An idempotent workflow first reconciles the stable local page identifier with the remote object or another durable binding. If the intended page already exists, it records or verifies that object instead of creating a second one. If an update fails, the retry targets the same known remote object.
Common misconception
“Idempotency means every publishing request can simply be repeated safely. The property has to be designed through stable identifiers, operation state, remote bindings, and verification; an arbitrary POST create request is not idempotent merely because the user clicked Retry.”
How pSEO Guard handles idempotency
pSEO Guard's WordPress workflow uses stable page bindings and operation claims so failed-only retries do not repeat successful writes. An unknown create outcome becomes a remote mismatch that requires verification instead of an automatic second create.
Dry Run, saved Job state, stable WordPress IDs, read-back verification, and page-level results keep retries attached to the original intended operation. The practical goal is simple: a network failure or repeated user action should not turn one approved Page into two remote Pages.