Prevent Duplicate WordPress Posts in n8n: A Retry-Safe Publishing Design

Direct answer: Give each editorial item a stable identity, keep a durable mapping from that identity to its WordPress post ID, and update the mapped post instead of creating again. Serialize competing writes for the same item. If a create request times out, treat the result as uncertain and reconcile it before retrying. A duplicate-removal node or a title search alone is not a complete publishing guarantee.

This is a design guide for an authorised n8n publishing workflow, not an installable template or a claim of exactly-once delivery. It separates input duplication, concurrent execution and uncertain remote writes because each needs a different safeguard. Begin with draft creation on a test site before allowing scheduled or public publication.

Scope and research method

The current n8n WordPress, duplicate-removal and error-handling documentation, WordPress REST posts reference and PostgreSQL constraint documentation were reviewed on 15 October 2026. The state machine and acceptance tests below are an original proposed architecture. No production workflow or failure experiment is claimed.

The n8n WordPress node provides post operations, while the WordPress posts API distinguishes creating a post from updating one by ID. Your workflow needs to decide which operation is appropriate; the presence of a connector does not decide editorial identity for you.

This is narrower than a general SEO automation workflow: it addresses the safety of repeated publishing requests. It does not justify producing duplicate or low-value content at scale.

Understand the three duplication problems

Problem	Example	Needed control
Repeated input	The same approved item arrives twice	Stable content identity and register
Concurrent execution	Two runs both decide no post exists	Atomic claim or serialized writer
Uncertain write	WordPress creates a post but the response is lost	Reconciliation before another create

A filter that removes duplicate items within one execution may help the first problem in a limited scope. It does not by itself resolve the other two. Likewise, making executions sequential does not tell the next execution whether a timed-out request already succeeded.

Write these failure cases into the design brief. If the team cannot explain how each is handled, keep automatic publishing disabled and route exceptions to a reviewer.

Step 1: create a stable editorial key

Use a source-system item ID that survives title edits and retries. Scope it to the destination site. For example, the pair site_a and editorial_item_482 can identify one article throughout its lifecycle. These are illustrative labels, not required formats.

Do not use the execution ID as the content identity: a retry or another run can have a different execution identity while referring to the same article. Do not rely only on the title either; two legitimate articles can share similar wording, and one article can be renamed.

Keep a revision identifier separate from the item key. A new revision normally updates the same editorial item after approval. If the business intentionally commissions a new article, create a new editorial item through the normal content process rather than letting a retry invent one.

Step 2: keep a durable publishing register

The register should survive workflow restarts and execution-log cleanup. Store destination, editorial key, state, WordPress post ID, approved revision, last attempt time, last verified state and an exception note. Avoid storing credentials or unnecessary article copies in the register.

State	Meaning	Permitted next step
Ready	Approved item has no known remote write	Claim and validate
Creating	A create operation is in progress	Wait or investigate, not parallel create
Known post	A verified remote ID is recorded	Read, compare and update if approved
Uncertain	A write may have succeeded	Reconcile before creating again
Review required	Conflicting evidence or approval problem	Human decision

These are proposed states, not n8n built-in status names. Define transitions explicitly. A failed HTTP response and a confirmed absence are not the same state. Preserve enough evidence to distinguish them.

If using a relational store, enforce uniqueness on destination plus editorial key. PostgreSQL's constraint documentation explains unique constraints. A database rule is stronger than hoping every workflow branch remembers to check first. Choose the storage technology with the administrator and back it up appropriately.

Step 3: serialize the decision and write

Two executions can both read “no row” before either creates a post. Protect the read-decide-write boundary through a supported atomic claim, a queue with one responsible writer or a carefully implemented locking design. A normal spreadsheet lookup followed by an append is not automatically atomic.

For a small agency, one serialized publishing worker may be simpler than distributed locking. The intake workflow records approved work; the worker owns WordPress mutations. Other processes must follow the same rule, or they can still create conflicts.

Document recovery from a worker crash. Do not expire a claim and immediately create again without checking whether the previous worker may have written remotely. A time limit helps detect stale work; it does not establish that the remote operation failed.

Step 4: use a known WordPress ID

When the register contains a post ID, retrieve that post and confirm the destination, editorial ownership and approved status. If the desired revision is already present, finish without another write. Otherwise, update only the approved fields on that specific post.

Never use a fuzzy title match to overwrite an existing article. A title or slug lookup can support investigation, but it is not enough evidence of identity. WordPress may produce a suffixed slug for a new post; a successful create is not proof that the content was unique.

Keep editorial status protected. If the workflow is authorised to create drafts, it must not silently publish them. If it schedules approved content, record the intended local date and timezone and verify the stored result. Do not reschedule existing posts merely to make the automation queue simpler.

Step 5: handle the first create carefully

Validate the approved payload before sending it: destination, author, category, content, image references, metadata and intended status. Check for an existing mapped post and any unresolved prior attempt. Only a genuinely new, approved item should enter the create path.

After a successful response, persist the returned WordPress ID immediately and retrieve the post to verify it. There is still a failure window between the remote write and the register update. That is why a reconciliation design remains necessary even with a durable register.

If you add a source key to WordPress, implement it through a supported, authorised mechanism. Custom REST metadata needs suitable registration and permissions; arbitrary fields do not become searchable API identity keys merely because a workflow sends them. Have a developer define the server-side contract.

Step 6: reconcile uncertain writes

Suppose the request times out after WordPress may have created the draft. Mark the item uncertain and preserve the request time, destination, editorial key and non-secret response evidence. Do not treat the timeout as permission to create another post.

Use a trusted reconciliation mechanism to find and verify the intended post. A server-side source-key lookup can help if implemented correctly. A narrow authenticated inspection of likely candidates can support a human decision. If multiple candidates remain, stop and request review rather than choosing the newest automatically.

For stronger guarantees, a developer may build a destination-side operation that atomically enforces the editorial key and returns the existing post for repeats. That is custom server work requiring authentication, validation, concurrency tests and maintenance. Do not describe a basic client workflow as exactly-once publishing without such evidence.

What duplicate-removal and retries actually contribute

n8n's Remove Duplicates documentation describes filtering scopes and operations. Use it where appropriate to reduce repeated input, but distinguish that convenience from a transactional register and remote-write recovery.

Its error-handling guidance describes routing failures and stopping workflows. Design your error path to preserve uncertainty and alert the owner. Do not configure blind retries for a non-idempotent create operation simply because retrying is available.

Read operations and updates with a verified identity can have different retry risks from a new create. Classify operations separately. A workflow-wide “retry everything” policy ignores the most important distinction in this design.

A conceptual decision sequence

receive approved editorial item
derive destination + stable item key
claim the key through the agreed concurrency control
if a verified post ID exists:
    read and compare the approved revision
    update only when authorised and necessary
else if a prior write is uncertain:
    reconcile or send to review
else:
    create the approved draft
    persist returned ID and verify the post
record the final evidence and release the claim

This is pseudocode, not an importable n8n workflow. The storage operations, lock behaviour, authentication and reconciliation endpoint depend on the environment. Review those dependencies before implementation.

Worked failure example

Imagine editorial item 482 creates a draft successfully, but the network connection closes before n8n receives the response. This is a hypothetical failure scenario. A naive rerun creates a second draft; a retry-safe design marks the first outcome uncertain.

The reconciliation path finds a post carrying the verified editorial identity, confirms the expected approved content and records its ID. The next execution reads that ID and finishes without a new create. If the identity cannot be verified, the item remains in review rather than being recreated.

The important result is one verified editorial mapping, not merely one successful execution. A workflow can report an error while the remote write succeeded, or report success while downstream metadata is incomplete.

Acceptance tests before enabling publication

• Send the same approved item twice: no second post should be created.
• Change only the title under the same item key: follow the approved revision policy.
• Start two competing requests: verify the claim or serialized writer.
• Interrupt after the remote create but before register persistence: exercise reconciliation.
• Return an authentication or validation error: confirm no unsafe fallback occurs.
• Provide a conflicting post ID: route to review rather than overwrite.
• Retry an image or metadata failure: repair the known post instead of creating another article.
• Verify status, date, featured image and required metadata after recovery.

Run destructive failure tests on a controlled test site. Use labelled fixtures, preserve evidence and remove only the approved test data afterward. Passing tests supports the tested design; it does not justify an unlimited reliability claim.

Credentials, operations and FAQs

Use the supported WordPress authentication approach appropriate to the integration and the minimum permissions needed. Keep credentials in the configured credential store, not content fields, public logs or screenshots.

Can a slug be the idempotency key?

It can be a useful locator, but do not assume it atomically prevents duplicates or proves editorial identity. Keep the durable item mapping and reconcile uncertain writes.

What if the mapped post is deleted?

Route to the agreed recovery policy. Do not recreate automatically unless that action is explicitly authorised; deletion may have been deliberate.

Should old register rows be cleared?

Not merely to save space. Removing identity history can allow an old input to create again. Set retention around the editorial lifecycle and keep a reviewed archive strategy.

Does this prevent topic cannibalisation?

No. It prevents repeated writes for the same editorial item. Two different item keys can still target the same search intent. Inventory and editorial review remain necessary.

Conclusion

Duplicate-safe publishing needs stable identity, durable state, controlled concurrency and reconciliation after uncertain writes. Keep draft-first approvals and verify the remote post. If the workflow cannot establish what happened, stop safely instead of creating again.