One naming scheme, written down
Half the problem is that three people invented three conventions and none of them are documented.
Pick one shape and record it where people will see it. A prefix for the category, then the concept: err-401, doc-install, rel-2-4-0, ev-conf-2026.
Lowercase, hyphenated, no dates unless the thing is genuinely dated, no version numbers unless the link is genuinely version specific. Those two exceptions cover more cases than people expect and cause most of the confusion when applied loosely.
Group by project, not by person
Links created by whoever happened to be doing the task end up scattered, and finding them later means asking who made this.
Digily Link has projects, which exist for exactly this. One per product, campaign or docs site, and every link created against it.
The test is whether a new team member could find every link belonging to a piece of work without asking anybody. If not, the grouping is decorative.
Somebody owns each link
Not for blame. For the question that actually gets asked: is this still needed, and who do I ask before repointing it?
For a small team, a note in the link description is enough. For a larger one, team members and roles in the account do the same job with less bookkeeping.
Unowned links are the ones nobody dares delete and nobody maintains, which is the worst of both.
Never rename a live link
This is the one rule with no exceptions. Changing the path of a published link breaks every reference to it, which is the exact failure the link existed to prevent.
If the name is wrong, create the correct one, point the old one at the same destination, and stop using the old name in new material. The old address stays alive as long as anything might still reference it, which for anything printed means indefinitely.
The temptation to tidy is strong and it should be resisted. A slightly badly named link that works is better than a well named one that does not.
Review on a schedule
- Quarterly, open the list and check each link still resolves to something sensible.
- Look at the statistics. Zero requests over a quarter usually means either nobody can reach the reference, or the link is genuinely dead.
- Archive rather than delete anything that has ever been published, because you cannot know what still references it.
- Delete only links that were never shared outside the team, which is a smaller set than it feels like.
Twenty minutes a quarter, and the list stays something a person can read.
Automate the repetitive part
Links created by hand drift. Links created by a pipeline follow whatever rules the pipeline encodes.
Where links are generated per release or per document, create them from the API as part of the build, and let the naming scheme live in code rather than in someone's memory.
Leave the one off links in the dashboard. Automating six links is more work than maintaining them, and the script becomes another thing nobody remembers how to run.