WordPress adds a suffix such as -2 when a requested published slug cannot be used in its relevant namespace. The conflict may involve another content item, an attachment, or a reserved name. Do not delete content or edit the database until you identify what owns the conflicting slug.
Write Down the Full Intended Address
Record the content type, requested slug, parent page, current status, and resulting URL. Two pages named Contact under different parents are not the same case as two root-level pages. A post title is also not the same field as its slug.
Open the intended address in a logged-out browser. Note whether it displays another item, redirects elsewhere, or returns an error. This is a useful clue, but a redirect or cache can hide the underlying record. Confirm the owner in WordPress before acting.
Look Beyond the Published Posts List
Search the relevant content lists, including drafts and trash, then inspect the Media Library for an attachment with the same name. These checks locate candidate records; finding a similar title alone does not prove it blocks the slug. Compare the actual slug and content type.
WordPress's unique-slug function treats attachments, hierarchical content, and ordinary posts differently. It also protects certain reserved names. Draft and pending content do not use the same uniqueness check at that stage, so a draft's accepted value is not a guarantee about its eventual published URL.
| Finding |
Safe next action |
| Another live item owns the address |
Decide which page should keep it |
| An attachment is a candidate |
Inspect its permalink and usage before renaming |
| Conflict depends on the parent page |
Compare the complete hierarchy |
| No obvious record explains it |
Check reserved names and slug-filtering plugins |
Ownership: Choose the page that keeps the URL. New address: Use a meaningful distinct slug. Migration: Plan redirects before moving live content. Verification: Check final URL and canonical. Explanatory checklist, not a customer test result.
Choose the Owner Before Renaming Anything
If the existing page serves the same intent, improving it may be better than publishing a competing URL. If the new page is genuinely different, give it a descriptive distinct slug. A meaningful address such as installation-checklist is usually easier to maintain than repeatedly fighting an occupied installation slug.
If you must move an existing live page, plan the destination and permanent redirect first. Update internal links and the sitemap through your normal publishing workflow. Verify the redirect without a chain. Do not assume that changing an attachment slug changes the underlying uploaded file URL.
Avoid running a database search-and-replace against every occurrence of a short slug. That can alter unrelated content and serialized settings. A targeted editor change with a backup and a known record is easier to verify and reverse.
Retest the Published State
Save the intended owner, reopen its editor, and confirm the persisted slug rather than trusting an unsaved field. Visit the final URL while logged out and inspect the canonical URL. Then test the old address if a redirect was required.
If WordPress accepts the address but the page returns 404, switch to permalink and rewrite troubleshooting. A suffix conflict and a routing failure are separate problems. When cloning a page, use our duplicate-page SEO checklist before publishing it.
For a conflict involving custom post types or third-party slug filters, request a focused repair with the two record IDs and full intended URLs. That evidence is more useful than another round of global permalink resets.
References reviewed October 6, 2026. Examples are explanatory, not customer test results.