Recommended Free Tools
First determine whether your request is creating a new item or updating an existing one. A duplicate post slug does not, by itself, identify what returned an “already exists” error: the message could come from custom code, a plugin, client-side validation, or a taxonomy-term request rather than core post handling. Capture the complete REST response and request details before changing or deleting content.
1. Capture the complete REST response
Do not diagnose the problem from a client-side toast or a paraphrased message. Record the HTTP status, endpoint path, request method, submitted payload, and the full JSON response—especially its code and message fields. Those details help distinguish a server-side REST error from a client’s own validation message.
As an Amazon Associate I earn from qualifying purchases.
2. Confirm what kind of item the request targets
Check whether the endpoint is for a post, page, custom post type, category, tag, or another taxonomy term. WordPress handles post names and taxonomy-term slugs through different core functions, so a term conflict should not be debugged as if it were a post conflict. See the WordPress reference for unique term slugs and the reference for unique post slugs.
3. Establish whether the request is creating or updating
The posts REST API exposes a collection route and routes for individual items. A collection request is used to create an item; an update should target the existing item. WordPress documents that supplying a post ID to wp_insert_post() updates the corresponding post, while omitting it creates a new one. See the REST API posts reference and the wp_insert_post() reference.
#1 Best Overall
Compare the endpoint and method you actually sent with the operation you intended. Repeatedly sending a create request to the collection route will not update the existing record simply because its title or slug matches.
4. Find the existing record before changing anything
Search the intended post type for the title or slug, including drafts and other statuses visible to your account. If you find a likely match, confirm its ID, post type, status, and ownership. Do not delete or overwrite a record until you know it is the item you mean to change.
5. Update the matching item by ID
If the existing record is the one you want, send an update to its item route using an HTTP method supported for updating. Authenticate and use an account with the permissions required by the site. WordPress’s REST API authentication guide explains authentication in the context of REST requests. The core insertion reference states: “If the $postarr parameter contains an ‘ID’, the corresponding post will be updated.”
6. Choose a distinct slug only for genuinely new content
If you intend to publish a separate item, give it a meaningful slug distinct from the existing item. Core post processing calls wp_unique_post_slug() to compute unique post names, but changing the slug is not a good substitute for fixing a request that should update an existing record. The function reference describes that core slug handling.
7. Isolate plugins and custom behavior if the error remains
If the structured error persists after correcting the request, compare its code and message with the endpoint and object type you are using. Then inspect, preferably on a staging copy:
- Plugins that validate or alter slugs.
- Custom REST routes or callbacks.
- Custom post type registration and its REST configuration.
- Hooks that change post names or reject duplicates.
- Client code that may be generating the message before the response reaches you.
This is a way to locate the source, not evidence that a particular extension is responsible. The exact source cannot be identified without the raw response, request details, and relevant site configuration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.8. Retry once, then verify the result
After correcting the endpoint, target, or slug, retry the request once. Verify the returned post ID, final slug, and URL. Do not blindly retry: a request may have succeeded even if the client misread or failed to display the response, and another create request could add unwanted content.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Best Value
Which diagnostic clues matter most?
| Question | What to inspect | Why it matters |
|---|---|---|
| Create or update? | Collection versus item route; method; whether the target ID is present. | An update must identify the existing item; a create request can attempt to add another. |
| What object type? | Post, page, custom post type, or taxonomy term. | Post and term slugs use different core handling. |
| Where did the error originate? | Structured response code and message; endpoint; client behavior; plugins and custom callbacks. | The wording alone does not establish that WordPress core produced the message. |
| What exactly was sent? | HTTP status, request method, endpoint path, and payload. | These let you compare the failed request with the intended operation. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
