A custom taxonomy failing to register or its rewrite rules breaking — terms not appearing correctly, archive URLs 404ing, term assignment failing — shares many of the same root causes as a broken custom post type, since both rely on the same underlying WordPress registration and rewrite systems.
Check whether the taxonomy’s terms are visible in wp-admin at all
Look for the taxonomy’s term management screen in wp-admin. If it’s missing entirely, that points to a registration failure; if terms are visible but their archive pages don’t resolve correctly, the issue is more specifically rewrite-rule related.
Custom taxonomy registration & rewrite errors
A custom taxonomy not registering or resolving, fixed alongside its rewrite rules.
- 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 taxonomy isn’t registering, showing terms correctly, or its archive URLs aren’t resolving | This fix covers it |
| The issue is with the custom post type itself, not a taxonomy | Custom post type registration errors |
| You’re getting a slug conflict specifically involving the taxonomy | Post type slug conflict resolution, worth checking if the conflict involves a taxonomy slug specifically |
| Terms are working but need bulk reassignment across content | Worth checking Content & Updates bucket fixes for bulk reassignment, a different kind of task |
What you are seeing
- The taxonomy or its terms missing entirely from wp-admin
- Term archive pages returning a 404 instead of the expected listing
- Terms failing to save or assign correctly to content
- The issue possibly appearing only after a permalink structure change
Common causes
- A syntax or logic error in the taxonomy registration code
- Permalinks not flushed after registration or a structure change, leaving rewrite rules stale
- A slug conflict between the taxonomy and an existing post type, page, or another taxonomy
- The taxonomy registered without being correctly associated with its intended post type
- A caching plugin continuing to serve stale rewrite rules even after they’ve actually been correctly regenerated
What we do
- Review the taxonomy registration code for errors
- Check for slug conflicts with existing content types or taxonomies
- Verify correct association between the taxonomy and its intended post type
- Flush and verify permalinks resolve correctly after correction
- Confirm terms display and assign correctly
- Check archive pages resolve as expected
What is included
- The taxonomy registration and rewrite rules corrected
- Verified correct term display and assignment
- Confirmed archive page resolution
- The pre-fix backup, kept for 30 days
Not included
- Building a new custom taxonomy from scratch, if that’s genuinely needed instead of fixing an existing one
- Custom post type registration issues, a separate, related fix if that’s also affected
- Bulk reassignment of terms across content, a separate, related fix
- Ongoing maintenance as the taxonomy’s requirements evolve
Questions about this fix
Why would terms fail to assign correctly to content?
This often points to the taxonomy not being correctly associated with the post type you're trying to assign terms on, or a registration error preventing the taxonomy from functioning as intended for that content type.
Do I need to manually flush permalinks after this fix?
We handle this as part of the fix, since a fresh permalink flush is typically necessary for corrected rewrite rules to actually take effect.
Will existing term assignments on my content be affected by this fix?
No, correcting the registration and rewrite rules shouldn't affect already-assigned terms on your existing content — the data itself remains intact while the underlying registration is corrected.
Could a plugin conflict cause this rather than a straightforward code error?
Yes, if another plugin registers something with a conflicting slug or interferes with the taxonomy's expected behaviour, that's a distinct, real possibility we check for separately from a code error in the registration itself.
Is this the same root cause as a broken custom post type?
Often related, since both rely on the same underlying WordPress registration and rewrite systems, though the specific fix addresses whichever one — taxonomy or post type — is actually affected in your case.
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.