URLs are a long-term promise. People bookmark them, share them in docs and tickets, and use them as references in other content. Search engines and analytics systems also treat URLs as durable identifiers.
A CMS makes it easy to edit titles and reorganize pages. Without a plan, those edits can quietly break links, fragment search signals, and create a mess of near-duplicate pages that are hard to clean up.
This post lays out a pragmatic strategy for slugs, redirects, and governance that works for blogs, docs, knowledge bases, and marketing sites. The goal is not perfection. It is to make URL changes rare, intentional, and recoverable.
What “stable URLs” actually mean
A stable URL is one that keeps working even when the content around it evolves. That does not mean nothing ever changes. It means that when change happens, the old URL either still resolves to the right content or forwards cleanly to the new location.
Practically, stability comes from three choices:
- Decouple the slug from the title. Titles are written for humans and can change frequently. Slugs should be written for durability.
- Minimize moving parts in the URL. Every extra segment that can change (category, date, product line) is another future redirect.
- Treat redirects as first-class content infrastructure. If the CMS cannot manage redirects reliably, URL changes become dangerous.
If you only remember one rule: a URL should identify a piece of content, not your current opinion about where that content fits in navigation.
Choose a slug policy you can defend
A slug policy is a small set of rules that determine how slugs are created, when they can change, and what else must happen when they do. The best policy is the one your team actually follows.
A simple default policy (works for most teams)
- Slug is set once at publish time. Drafts can change slugs freely. Once published, the slug is “locked” unless a higher-trust role changes it.
- Slug is derived from an “evergreen name,” not the display title. Think of it as an internal label a reader might still recognize in two years.
- Keep slugs short and readable. Prefer 3 to 7 words, all lowercase, hyphen-separated.
- No dates in slugs unless the content is inherently date-bound. Dates create pressure to move or rename later.
- Allow only one canonical URL per piece of content. Any alternate paths must redirect.
Copyable checklist for creating a slug
Use this quick checklist when a new page is being published:
- Is the slug likely to make sense if the title is rewritten?
- Is it free of version numbers, dates, and internal team jargon?
- Is it short (ideally under ~60 characters) and spelled correctly?
- Is it unique within the site, with no collisions?
- If the page might move sections later, does the URL avoid fragile category paths?
One practical trick: if the slug feels like a sentence, it is probably too long. If it feels like a label, it is usually about right.
Handling title changes, merges, and splits
Most URL pain comes from normal editorial work. Here is how to handle the common scenarios without breaking the web of links you have already built.
Scenario: the title changes (most common)
If your slug is decoupled from the title, this is easy: change the title, keep the slug. Many teams do the opposite and let the CMS auto-update the slug, which creates a new URL and breaks existing inbound links.
Rule of thumb: a title change is not a URL change unless the old slug is actively misleading (for example, a page renamed from “API Keys” to “Billing”).
Scenario: you merge or split pages
When two pages become one, pick the URL you want to keep based on which page has stronger inbound links, bookmarks, or historical importance. Then redirect the retired URL to the surviving page. When one page becomes two, keep the original URL for the “primary” concept and create a new slug for the second page. Link them clearly and consider adding a short note for readers at the top of the original page if it changes meaning significantly.
A concrete example (hypothetical, but realistic)
Imagine a small SaaS company with a help center in a CMS. They publish an article titled “Reset Your Password” at /help/reset-password/. Later, the product adds passkeys and the article is renamed “Sign in and Account Recovery”.
If the CMS auto-updates the slug, the URL becomes /help/sign-in-and-account-recovery/ and older support macros, onboarding emails, and in-app links start 404ing. With a stable slug policy, the title changes but the URL stays /help/reset-password/. The label is not perfect, but it continues to work, and the content is what matters.
If they truly need a new URL, they can create it intentionally and redirect the old one. Either way, users do not hit dead ends.
Redirects and canonicals: the safety net
Even with good slugs, you will occasionally need to change a URL. The difference between a clean change and a long-tail problem is whether you treat redirects as part of the publishing workflow.
At minimum, your system should support:
- Permanent redirects (301). Used when a URL is replaced by another URL.
- Canonical URLs. A signal that says “this is the primary URL for this content” when duplicates exist (intentional or accidental).
- A redirect registry. A place to record old to new mappings so they can be reviewed, tested, and kept consistent.
The redirect registry can be a CMS collection, a configuration file, or a database table. What matters is that it is controlled, auditable, and checked during publishing.
content:
id: "kb_1842"
canonicalPath: "/help/reset-password/"
aliases:
- "/help/password-reset/"
- "/help/sign-in-and-account-recovery/" # redirects to canonicalPath
redirects:
"/help/forgot-password/": "/help/reset-password/"Notice the intent: one canonical path per content item, optional aliases that forward to it, and separate redirects for retired pages. This keeps the “truth” in one place.
Governance: who can change a URL and when
Many CMS problems are permission problems in disguise. If anyone can change a published slug, someone eventually will, often to “make it prettier” without realizing the downstream cost.
A workable governance model for small teams:
- Authors can edit slugs only in draft.
- Editors can request slug changes on published content. The CMS can enforce a reason field (short text) so changes are intentional.
- Publishers (or admins) can approve slug changes. Approval should require selecting or creating a redirect from the old URL to the new one.
- URL changes trigger a lightweight checklist. Check internal links, update navigation, and verify the redirect works in preview.
If your CMS cannot enforce these permissions, you can still implement the process socially. Even a shared checklist and a single “URL owner” can reduce breakage dramatically.
Key Takeaways
- Write slugs for durability, not for matching the current title.
- Lock published slugs by default and treat slug changes as a higher-trust action.
- Keep URLs simple: fewer segments means fewer future moves.
- Make redirects and canonicals part of the publishing workflow, not an afterthought.
- Use governance (roles, approvals, and checklists) to prevent accidental URL churn.
Common mistakes to avoid
- Auto-regenerating slugs on every title edit. This is the biggest source of accidental link rot in CMS-driven sites.
- Embedding taxonomy into the URL path. URLs like
/guides/security/authentication/reset-password/look organized until you reorganize. Then everything moves. - Using “pretty” redirects instead of correct redirects. Redirecting many old pages to the home page or a generic archive might reduce 404s, but it harms user trust and makes troubleshooting harder.
- Letting duplicate content exist at multiple URLs. Without canonicals, you can split analytics and confuse search crawlers. Pick one canonical and redirect the rest.
- Forgetting non-obvious consumers of URLs. Support macros, product UI links, PDFs, and internal wiki docs are often the last to get updated.
When NOT to freeze slugs
“Stable slugs” does not mean “slugs never change.” There are cases where changing the URL is the right call:
- The slug is wrong enough to mislead users. If the URL implies the page is about one thing but it is now about another, it can harm trust.
- You are correcting sensitive leakage. If a slug contains internal project names, customer identifiers, or anything that should not be public, fix it quickly and redirect.
- You are consolidating a messy legacy URL scheme. During a planned cleanup, you might intentionally change many URLs, as long as redirects are comprehensive and tested.
In these situations, the principle is the same: change intentionally, redirect permanently, and ensure there is a single canonical destination.
Conclusion
A CMS makes publishing fast, but speed without URL discipline creates long-term friction. A stable slug policy, backed by redirects and basic governance, is one of the simplest ways to protect your site’s usability and maintainability.
If you are unsure where to start, begin with one rule: published slugs do not change without creating a redirect. That single constraint prevents most accidental breakage.
FAQ
Should my CMS generate slugs automatically?
Auto-generation is fine for drafts, because it saves time. For published content, prefer a review step or a “lock” so the slug does not drift every time the title is edited.
Is it okay to include categories in the URL?
Sometimes, but it increases churn. If your categories are stable and meaningful to users (for example, /docs/ versus /blog/), one top-level segment is usually safe. Deep category nesting is where problems multiply.
How many redirects are too many?
A few redirects per page is common in mature sites. The real risk is chains (A redirects to B redirects to C). Keep redirects pointing directly to the current canonical URL and periodically collapse chains.
What if two pages want the same slug?
Do not resolve collisions by adding randomness. Add a meaningful qualifier such as a short noun (/help/billing-login/ vs /help/admin-login/) or reframe one slug to reflect the distinct intent of that page.