When a custom post type’s slug conflicts with an existing page, another post type, or a core WordPress URL structure, one of them typically wins unpredictably while the other becomes unreachable or behaves strangely — a conflict that’s often invisible until someone tries to access the specific, affected URL.
Check whether the conflicting URL resolves to the content you actually expect
Visit the specific URL you’d expect either the post type archive or the conflicting page to use, and note which one actually displays. Getting the unexpected one, or a 404 instead of either, confirms a genuine slug conflict rather than a different kind of issue.
Post type slug conflict resolution
A post type slug conflicting with an existing page or another type, resolved with redirects.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| A custom post type’s slug conflicts with an existing page, post type, or WordPress’s own URL structure | This fix covers it |
| The post type isn’t registering at all, separate from a specific slug conflict | Custom post type registration errors, the broader version |
| The conflict is specifically with a taxonomy’s slug, not the post type itself | Custom taxonomy registration & rewrite errors, worth checking if that’s more precisely your situation |
| You want to deliberately change a slug as part of a broader URL restructuring | Structured URL & slug standardisation, in the Technical SEO Implementation category, a different kind of change |
What you are seeing
- A URL resolving to unexpected content, not what you’d intend for either the post type or the conflicting page
- One of the conflicting items (the post type archive or the specific page) becoming unreachable
- A 404 error at a URL that should resolve to something
- The issue possibly only appearing after creating a new page or post type with an overlapping name
Common causes
- A custom post type’s slug matching an existing page’s slug exactly
- A post type’s slug conflicting with a reserved WordPress core URL structure
- Two separately registered post types or taxonomies sharing the same intended slug
- A slug conflict introduced by a plugin update changing a previously non-conflicting slug
- A multilingual plugin generating a translated version of a slug that collides with an entirely different, already-existing post
What we do
- Identify the specific conflicting slugs and what’s competing for them
- Determine the appropriate resolution — renaming one, or restructuring how they coexist
- Implement the resolution, updating registration or the conflicting page as agreed
- Set up redirects where a URL’s meaning is changing as part of the resolution
- Verify both previously conflicting items now resolve correctly and predictably
- Check for any other instances of the same conflict pattern on the site
What is included
- The specific slug conflict identified and resolved
- Redirects implemented where a URL’s meaning changes as part of the fix
- Verified correct, predictable resolution for both previously conflicting items
- The pre-fix backup, kept for 30 days
Not included
- A broader URL restructuring beyond resolving the specific conflict
- Registering a new custom post type from scratch, if that’s a separate, additional need
- Custom taxonomy-specific conflicts, a separate, related fix if that’s more precisely the situation
- Ongoing monitoring for future slug conflicts as new content types are added
Questions about this fix
How would I even know I have this kind of conflict?
It's often invisible until someone specifically tries to reach the affected URL and gets unexpected content or a 404 — this isn't something that typically shows up during normal, everyday use of the site.
Which one usually wins when there's a slug conflict?
This can depend on registration order, WordPress's own internal rules, and the specific types involved — rather than assuming a predictable winner, we identify what's actually happening in your specific case.
Will resolving this change any URLs visitors or search engines already know about?
Potentially, if the resolution involves renaming one of the conflicting items — where that's the case, we set up redirects so existing links and search engine indexing aren't simply broken by the change.
Could a plugin update really introduce a new slug conflict?
Yes, if a plugin changes a post type's slug in an update without checking against what else exists on your specific site, a previously fine configuration can suddenly conflict, through no direct action of your own.
Is this something that could happen again with a different slug later?
It's a genuine, ongoing risk any time new content types or pages are added without checking against existing slugs — worth a quick check when introducing something new with a similar or ambiguous name.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.